장애 발생 시 대처 방법: 4단계 장애 대응 플레이북

스타트업 운영 중 첫 번째 대규모 장애가 발생했습니다. 결제 페이지에서 500 오류가 발생하고, #alerts 채널에는 "혹시 다른 분들도 이런 현상 겪고 계신가요?"라는 메시지가 쏟아지는데, 팀원 중 누구도 사고 대응을 해본 경험이 없습니다. 장애 발생 시 대응 순서: 사고 대응 책임자(Incident Commander) 지정, 근본 원인 파악에 앞서 피해 확산 방지(mitigation), 단일 정보 소스 확보, 정해진 주기에 따른 상황 공유. 서비스 복구와 책임 소재를 묻지 않는 사후 분석(blameless postmortem)은 불을 끄는 도중이 아니라 서비스가 정상화된 후에 진행해야 합니다. 첫 사고를 겪을 때, 무엇보다 먼저 왜 문제가 발생했는지 진단하려는 본능은 사고 발생 초기 10분 동안 저지를 수 있는 가장 치명적인 실수입니다.

‍

핵심 요약: 장애 발생 시 다음 4단계를 순서대로 수행하세요. 1단계, 분류 및 억제: 사고 대응 책임자를 지정하고 심각도를 선언한 뒤, 원인 조사에 앞서 피해 확산 방지(롤백, 경로 변경, 스케일링, 플래그 전환 등)를 수행합니다. 2단계, 커뮤니케이션: 단일 사고 대응 채널을 개설하고, 심각도가 높은 경우 30~60분 간격으로 외부 상태 업데이트를 게시합니다. 3단계, 복구: 실제 지표를 통해 확인하고, 트래픽 급증(thundering herd) 현상을 방지하기 위해 점진적으로 트래픽을 복구합니다. 4단계, 사후 분석: 타임라인을 작성하고, 책임 소재를 묻지 않는 '5 Whys' 분석을 수행한 뒤, 담당자와 기한이 명시된 후속 조치를 할당합니다.

‍

개요

이 플레이북은 다음 내용을 다룹니다:

• 첫 5분: 구체적인 장애 대응 체크리스트
• 1단계: 분류 및 억제 (역할 정의 및 '피해 확산 방지 우선' 원칙 포함)
• 2단계: 커뮤니케이션 (상태 페이지 모범 사례 및 고객 대상 장애 업데이트 포함)
• 3단계: 해결 및 복구 (트래픽 급증 문제 포함)
• 4단계: 책임 소재를 묻지 않는 사후 분석 (근본 원인 분석 및 사후 분석 템플릿 포함)
• 지금 바로 도입할 수 있는 사고 대응 계획 템플릿
• 장애 발생 시 절대 하지 말아야 할 행동
• AI 네이티브 도구가 초기 10분을 어떻게 변화시키는가
• 자주 묻는 질문

이 문서는 다음을 알기 위한 대응형 가이드입니다. 애초에 언제 사고 관리가 필요한지. 만약 사고가 진행 중인 상황에서 이 글을 읽고 있다면, 아래의 '첫 5분' 섹션으로 바로 넘어가세요. 여기에 제시된 프레임워크는 즉흥적인 것이 아닙니다. 다음 자료들을 바탕으로 작성되었습니다. Google SRE 도서, 사고 지휘 시스템(ICS) (소방 및 재난 대응 분야에서 수십 년간 사용해 온 방식), 그리고 ITIL v4 사고 관리 (심각도 분류 기준). 여러분의 런북과 아키텍처 다이어그램은 이러한 프레임워크가 다루지 않는 구체적인 전술적 세부 사항을 보완해 줍니다.

‍

장애 발생 시 대처법: 첫 5분

어떤 조치를 취하기 전에 다음 다섯 가지를 먼저 수행하세요. 이 단계에서의 속도가 전체 사고 해결 속도의 상한선을 결정합니다.

1. 알림을 확인하세요. 이제 누군가 책임지고 있다는 뜻입니다. 확인되지 않은 알림은 아무도 해결하고 있지 않은 장애와 같습니다.
2. 사고를 선언하세요. 채널에 "사고(incident)"라고 명확히 언급하세요. 모호한 태도("일시적인 현상 아닐까?")는 SEV-1급 장애를 20분 동안 방치하게 만드는 원인이 됩니다.
3. 장애 책임자(Incident Commander)를 지정하세요. 최초 대응자가 스스로 역할을 맡을 수 있습니다. 사람보다 역할이 더 중요합니다.
4. 채널을 하나 개설하세요. 일반 알림이 쏟아지는 곳이 아닌, 장애 전용 채널이나 브릿지를 사용하세요.
5. 진행 상황을 공유하세요. 내부 및 외부 공지: "현재 결제 오류 증가 문제를 조사 중입니다. 30분 후에 다시 업데이트하겠습니다." 이렇게 하면 집중할 시간을 확보할 수 있습니다.

이후의 모든 과정은 4단계 구조에 따라 순서대로 진행됩니다.

‍

1단계: 트리아주 및 차단 (피해 확산 방지)

1단계의 목표는 장애 원인을 파악하는 것이 아니라 장애를 끝내는 것입니다. 먼저 서비스 상태를 정상으로 복구하고, 고객이 더 이상 영향을 받지 않게 된 후에 여유를 가지고 진단하세요.

책임을 묻기 전에 역할을 먼저 할당하세요

ICS에서 차용하고 구글 SRE가 체계화한 다음 세 가지 역할이 대부분의 장애를 커버합니다.

1. 장애 책임자(IC). 조정과 결정을 내리고 타임라인을 관리합니다. IC는 직접 키보드를 잡지 않습니다. IC의 업무는 버그 수정이 아니라 대응 과정을 운영하는 것입니다.
2. 기술 리드(운영). 실제 문제 해결과 완화 작업을 주도합니다. 대시보드와 터미널을 깊이 파고들어야 하는 유일한 사람입니다.
3. 커뮤니케이션 리드. 내부 및 외부 업데이트를 전담하여, 기술 리드가 "진행 상황이 어떤가요?"라는 질문에 답하느라 디버깅을 멈추는 일이 없도록 합니다.

소규모 팀에서는 한 사람이 두 가지 역할을 겸할 수도 있지만, IC와 기술 리드는 가급적 같은 사람이 맡지 않아야 합니다. 최고의 디버거가 다섯 명을 조율하려 하는 순간, 두 업무 모두 차질을 빚게 됩니다. 아직 온콜 로테이션을 구축하지 않았다면, 다음 가이드를 참고하세요. 소규모 팀을 위한 온콜 설정 1차, 2차 및 에스컬레이션 경로를 단계별로 안내합니다.

진단 함정:  장애 발생 후 첫 10분 동안 가장 흔히 발생하는 실패 유형은 사이트가 여전히 다운된 상태에서 근본 원인을 찾으려 하는 것입니다. 근본 원인 분석은 4단계 활동입니다. 1단계에서 유일하게 중요한 질문은 "지금 당장 서비스를 복구할 방법은 무엇인가?"입니다. 로그를 읽으며 15분을 허비하는 팀은 왜 배포가 실패했는지 파악하는 데 시간을 쓰느라 90초면 끝날 롤백을 미루고 있으며, 이는 고객보다 이해를 우선시하는 선택입니다. 먼저 완화하고, 나중에 진단하십시오.

‍

출혈을 멈추십시오: 근본 원인보다 완화가 우선입니다

완화는 서비스를 복구하고, 근본 원인 분석은 그 이유를 설명합니다. 활성 장애 상황에서 두 작업의 시급성은 동일하지 않습니다. 이를 동일하게 취급하면 10분짜리 소동이 2시간짜리 사고로 커집니다.

‍

완화와 근본 원인 분석은 서로 다른 시점에 서로 다른 질문에 답합니다. 장애 중에는 서비스를 복구하기 위해 완화에 집중하고, 복구 후에야 비로소 실패 원인을 조사해야 합니다. 이 둘을 혼동하는 것이 팀이 장애 시간을 늘리는 가장 흔한 원인입니다.

일반적인 완화 수단은 효과가 높은 순서대로 다음과 같습니다. 가장 최근 배포를 롤백하고, 장애가 발생한 구성 요소에서 트래픽을 우회하거나 차단하며, 부하가 원인일 경우 리소스를 확장하고, 최근 변경 사항과 관련된 기능 플래그를 끕니다. 지난 한 시간 내에 배포가 있었다면, 다른 가설을 세우기 전에 먼저 롤백부터 하십시오.

영향 평가 및 심각도 선언

회의 없이도 모두가 상황의 심각성을 이해할 수 있도록 심각도를 할당하십시오. ITIL 기반의 일반적인 척도는 다음과 같습니다.

1. SEV-1. 치명적. 핵심 서비스 중단 또는 주요 데이터 위험, 수익 손실 발생 중. 전사적 대응 및 경영진 보고 필요.
2. SEV-2. 주요. 심각한 성능 저하 또는 핵심 기능 중단, 우회 방법이 있을 수 있음. 긴급하지만 전사적 대응은 불필요.
3. SEV-3. 경미함. 제한적이거나 외관상의 영향, 수익이나 SLA에 실질적인 영향 없음. 업무 시간 내 처리.

심각도는 이후의 모든 과정(누구에게 호출을 보낼지, 소통 빈도는 어떻게 할지, SLA 크레딧 보상 대상인지 등)을 결정합니다.

‍

2단계: 커뮤니케이션 및 조정

사고가 악화되는 이유는 기술적인 문제보다 커뮤니케이션 부족인 경우가 더 많습니다. 2단계는 기술 작업과 병행하여 진행되며, 커뮤니케이션 책임자가 주도합니다.

단일 정보 소스 구축

전용 사고 대응 브리지(Slack 채널 또는 화상 회의)를 하나 개설하고 타임스탬프, 수행 작업, 가설, 결정 사항 등 모든 내용을 기록하세요. 규칙은 간단합니다. 사고 채널에 기록되지 않은 내용은 발생하지 않은 것으로 간주합니다. 이 채널은 사후 분석 타임라인의 기초 자료가 되므로, 기록 담당자가 실시간으로 타임스탬프를 남기면 나중에 내용을 재구성하는 시간을 한 시간 이상 절약할 수 있습니다.

정해진 주기에 따라 외부와 소통

침묵은 사고 대응팀 외부 사람들에게 무능함으로 비춰집니다. 커뮤니케이션 공백(The Comms Vacuum) 은 대응팀이 문제 해결에만 몰두하여 소통을 중단할 때 발생합니다. 고객은 최악의 상황을 가정하고, 고객 지원팀은 문의 폭주로 마비되며, 경영진은 개별 엔지니어에게 직접 연락하여 업무를 방해하게 됩니다. 정해진 주기로 소통하면 이를 방지할 수 있습니다. 심각도가 높은 사고의 경우, "여전히 조사 중이며 예상 완료 시간은 미정"이라는 내용이라도 30~60분마다 외부 업데이트를 게시하세요. 고객에게 필요한 것은 해결책이 아니라 예측 가능한 정보입니다.

고객에게 장애 상황을 알리는 방법

고객 대상 업데이트는 엔지니어링 채널과는 다른 어조를 사용해야 합니다. 내부적인 기술 세부 사항보다는 서비스에 미치는 영향 위주로 작성하세요. 고객은 커넥션 풀이 고갈된 이유에는 관심이 없습니다. 결제가 실패하고 데이터가 안전한지가 중요할 뿐입니다. 업데이트는 짧게 유지하고, 데이터 영향 여부를 명시하며, 반드시 다음 업데이트 시간을 약속하세요.

상태 페이지 운영 모범 사례

공개 상태 페이지는 장애 발생 시 고객과 소통할 수 있는 가장 효과적인 도구입니다. 팀 규모와 상관없이 지켜야 할 몇 가지 규칙은 다음과 같습니다.

1. 자체 인프라와 분리하여 호스팅하세요. 앱과 함께 상태 페이지가 다운되면 아무런 소용이 없습니다. 별도의 서비스 제공업체나 도메인을 사용하세요.
2. 고객이 묻기 전에 먼저 게시하세요. 원인이 파악되지 않았더라도 사고 선언 후 몇 분 이내에 첫 번째 업데이트를 게시해야 합니다.
3. 기술 용어를 배제하고 쉬운 언어를 사용하세요. "인증 서비스 503 오류" 대신 "일부 사용자가 로그인할 수 없음"과 같이 표현하세요.
4. 다음 업데이트 시간을 약속하고 반드시 지키세요. 약속한 업데이트를 제때 하지 않는 것은 장애 그 자체보다 더 큰 신뢰 하락을 초래합니다.
5. 항상 해결 완료 업데이트를 게시하고, 심각도가 높은 장애의 경우 추후 게시될 사후 분석 보고서를 언급하세요.

‍

3단계: 해결 및 복구

장애는 수정 사항이 배포되었다고 끝나는 것이 아닙니다. 지표를 통해 시스템이 정상화되고 트래픽이 완전히 복구되었음이 확인되어야 비로소 끝납니다. 성급하게 상황 종료를 선언하면 10분 뒤에 장애가 재발하는 원인이 됩니다.

느낌이 아닌 지표로 확인하세요

새로운 불만이 없다고 해서 복구되었다고 판단하지 말고, 운영 지표를 통해 확인하세요. 오류율이 기준치로 돌아왔는지, 응답 지연 시간이 정상인지, CPU, 메모리, 큐 깊이가 안정적인지 확인해야 합니다. "이제 괜찮아 보인다"는 것은 검증이 아닙니다. 대시보드가 장애 이전 상태로 돌아온 것이 진정한 검증입니다.

천둥 떼(thundering herd) 현상을 방지하기 위해 트래픽을 점진적으로 복구하세요

복구된 서비스를 다시 가동할 때는 단계적으로 진행하세요. 천둥 떼 현상은 재시도 중인 모든 클라이언트, 대기 중인 큐, 캐시가 비어 있는 요청들이 갓 복구된 서비스에 한꺼번에 몰려들어 서비스를 다시 다운시킬 때 발생합니다. 트래픽을 단계별로 늘리고, 동일한 지표를 주시하며, 캐시와 연결 풀이 충분히 예열된 후 전체 부하를 처리하도록 하세요. 복구 과정에서 2차 장애를 일으키는 것은 흔히 발생하는, 충분히 피할 수 있는 실수입니다.

‍

4단계: 학습 및 비난 없는 사후 분석

장애 상황이 안정되었습니다. 이제 교훈을 얻어야 합니다. 장애로부터 배우지 않는다면, 그 장애를 다시 겪을 권리를 미리 구매한 것과 다름없기 때문입니다. 이 단계를 처음 공식화하는 경우, 비난 없는 사후 분석 보고서 작성법 에 대한 상세 가이드에서 검토 회의 진행 방식에 대해 더 자세히 알아보세요.

정확한 타임라인을 구축하세요

첫 알림부터 완전한 해결까지의 연대기를 재구성하세요. 장애 시작 시점, 감지 시점, 사고 대응자(IC) 배정 시점, 각 완화 시도, 그리고 복구가 확인된 순간을 기록합니다. 만약 스크라이브(Scribe)가 장애 채널에서 실시간으로 타임스탬프를 기록했다면, 이는 고고학적 발굴이 아닌 단순한 기록 정리가 될 것입니다.

비난 없는 근본 원인 분석을 수행하세요

비난이 없다는 것이 아무도 책임을 지지 않는다는 뜻은 아닙니다. 인간의 실수가 장애로 이어지게 만든 시스템적 결함을 공격해야 한다는 의미입니다. 구글 SRE 워크북의 핵심 전제는 다음과 같습니다. 엔지니어 한 명의 실수가 프로덕션 환경을 마비시킬 수 있다면, 그 결함은 엔지니어가 아니라 그 실수를 허용한 시스템에 있다는 것입니다.

'5 Whys(5번의 왜)'는 가장 효과적인 기법입니다. 사람을 탓하기보다 시스템적 원인에 도달할 때까지 "왜"라고 질문하세요.

Problem: Checkout returned 500s for 54 minutes.
1. Why? A deploy introduced a null-pointer path in the payment handler.
2. Why did it reach production? Tests did not cover the null case.
3. Why not? The test suite has no integration coverage for the payment path.
4. Why not? Payment tests were deprioritized under deadline pressure.
5. Why? There is no policy requiring integration coverage for revenue-critical paths.

Root cause (systemic): No coverage requirement for revenue-critical
code paths. Fix: gate deploys on payment-path integration tests.

‍

하단에 제시된 답변은 부주의한 엔지니어가 아니라 안전장치 부재가 문제의 원인임을 지적합니다. 이것이 바로 비난 없는 문화의 핵심입니다.

포스트모템 작성하기

포스트모템은 지속 가능한 기록물입니다. 활용하기 좋은 템플릿은 다음과 같습니다.

# Postmortem: [Incident title]
Date: [date]   Severity: [SEV-x]   Duration: [start to resolution]
Author: [name]   Status: [draft / reviewed / actioned]

## Summary
2-3 sentences: what broke, who was affected, how long, how it ended.

## Impact
Customer, revenue, and SLA impact in concrete numbers.

## Timeline (all times UTC)
HH:MM  First alert
HH:MM  Incident declared, IC assigned
HH:MM  Mitigation attempted: [action]
HH:MM  Service restored
HH:MM  Incident closed

## Root cause
The systemic cause, per the 5 Whys. Blameless.

## What went well / what went poorly
Detection speed, comms, tooling gaps. Be honest.

## Action items
| Action | Owner | Due date | Ticket |
|---|---|---|---|
| ... | ... | ... | ... |

‍

재발 방지를 위해서는 조치 사항 표가 가장 중요합니다. 근본 원인을 아무리 훌륭하게 분석했더라도 담당자와 기한이 명시된 후속 조치가 없다면, 그것은 해결책이 아니라 단순한 일기에 불과합니다.

실행 가능한 담당자 지정 후속 조치

모든 조치 사항에는 명확한 담당자와 기한이 있어야 하며, 문서 속에 묻어두지 말고 평소 사용하는 티켓팅 시스템에서 관리해야 합니다. "테스트 커버리지를 개선해야 한다"는 조치 사항이 아닙니다. "결제 경로 통합 테스트 추가, 담당자: Priya, 기한: 10월 3일, JIRA-4821"와 같이 구체적이어야 합니다.

‍

장애 대응 계획 템플릿

아직 팀의 대응 계획이 없다면, 오늘 바로 런북에 복사해서 사용할 수 있는 이 템플릿으로 시작해 보세요.

# Incident Response Plan

## 1. Declare
Anyone can declare an incident. Say "declaring an incident" in
#incidents. When in doubt, declare.

## 2. Roles
- Incident Commander: coordinates, owns timeline, does not code.
- Tech Lead: drives mitigation and diagnosis.
- Comms Lead: internal + external updates.

## 3. Severity
- SEV-1: core service down / revenue or data at risk. All hands.
- SEV-2: major degradation, workaround may exist. Urgent.
- SEV-3: minor / cosmetic. Business hours.

## 4. Mitigate first
Restore service before finding root cause. Levers: roll back,
reroute, scale, toggle flag.

## 5. Communicate
- One incident channel = single source of truth.
- External status update every 30-60 min for SEV-1/2.

## 6. Recover
Verify with metrics. Restore traffic gradually.

## 7. Learn
Blameless postmortem within 5 business days. 5 Whys.
Owned, dated action items.

‍

심각도와 주기는 상황에 맞게 조정하되, 순서는 유지하세요. 선언, 완화, 소통, 복구, 학습으로 이어지는 과정이 당황스러운 상황을 체계적인 프로세스로 바꿔줍니다.

‍

장애 발생 시 절대 하지 말아야 할 행동

안티 패턴을 아는 것은 대응 단계를 아는 것만큼 중요합니다. 다음 사항들을 피하세요.

1. 사이트가 다운된 상태에서 근본 원인을 찾으려 하지 마세요. 우선 완화부터 하세요. 이는 '진단의 함정'으로, 장애 대응에서 가장 큰 비용을 치르게 되는 실수입니다.
2. 침묵하지 마세요. SEV-1 장애 상황에서 한 시간 동안 외부 공지가 없는 것은 장애 자체보다 더 큰 평판 손상을 초래합니다. 새로운 정보가 없더라도 계속 소통하세요.
3. 모두가 동시에 디버깅하게 두지 마십시오. 5명의 엔지니어가 운영 중인 시스템에 조율되지 않은 변경 사항을 적용하면 또 다른 장애가 발생합니다. 사고 대응 책임자(IC)가 대응 과정을 순차적으로 정리해야 합니다.
4. 직감만으로 상황이 해결되었다고 판단하지 마십시오. 해결 상태로 전환하고 전체 트래픽을 복구하기 전에 반드시 지표를 통해 복구 여부를 확인하십시오.
5. 비난하는 사후 분석을 하지 마십시오. 사후 분석에서 특정 인물을 원인으로 지목하는 순간, 사람들은 사고를 솔직하게 보고하지 않게 되며 데이터는 신뢰를 잃게 됩니다. 사람이 아닌 시스템의 문제를 파고드십시오.
6. 해결책이 "뻔하다"는 이유로 사후 분석을 건너뛰지 마십시오. 증상에 대한 뻔한 해결책은 근본적인 시스템 문제를 그대로 남겨둡니다. 그것이 바로 한 달 뒤에 똑같은 장애가 다시 발생하는 이유입니다.

‍

AI 네이티브 도구가 초기 10분의 대응을 바꿀 수 있을까요?

사람이 시작하든 기계가 시작하든 4단계 과정은 동일합니다. 달라지는 것은 대응이 시작되는 지점입니다. 기존 방식에서는 사람이 갑작스럽게 호출을 받고 시간이 흐르는 동안 빈 화면을 보며 "무엇이 고장 났는가?"라는 질문에 답해야 합니다. Vibe OnCall과 같이 AI 조사 계층을 추가하는 도구는 이 과정을 뒤집습니다.

기존의 호출 방식은 사람을 깨워 미스터리를 던져주지만, AI 네이티브 도구는 호출 전에 경고를 조사하므로 1단계가 막막한 탐색이 아닌 맥락 파악부터 시작됩니다. 한 중견 기업 고객은 Vibe OnCall의 사전 호출 분류 기능을 도입한 후 평균 복구 시간(MTTR)이 60% 감소했다고 보고했습니다. 플레이북은 바뀌지 않지만, 출발선이 앞당겨지는 것입니다.

어떤 방식을 선택하든 원칙은 동일합니다. 진단하기 전에 완화하고, 일정한 주기로 소통하며, 축하하기 전에 검증하고, 비난 없이 배우십시오.

‍

자주 묻는 질문

장애 발생 시 가장 먼저 해야 할 일은 무엇인가요?

‍알림을 확인하고 장애를 선언한 뒤, 인시던트 커맨더(IC)를 지정하세요. IC는 조정과 타임라인을 총괄하고, 별도의 기술 리드(Tech Lead)가 문제 해결을 주도합니다. 초기 2분 이내에 책임자를 지정해야 알림이 방치되는 상황을 막을 수 있습니다.

장애 발생 중에 근본 원인을 찾아야 할까요?

‍아니요. 장애가 진행 중일 때는 서비스 복구를 최우선으로 완화 조치(롤백, 경로 변경, 스케일링, 플래그 전환 등)를 취해야 합니다. 근본 원인 분석은 장애 이후 '비난 없는 사후 분석(blameless postmortem)' 단계에서 수행하는 활동입니다. 서비스가 중단된 상태에서 원인을 쫓는 것은 장애 시간을 늘리는 행위이며, 팀이 가장 흔히 저지르는 초기 실수입니다.

장애 발생 시 고객에게 얼마나 자주 업데이트해야 할까요?

‍심각도가 높은 장애라면 새로운 정보가 없더라도 30~60분마다 업데이트하세요. 첫 업데이트는 장애 선언 후 몇 분 이내에 게시하고, 기술적인 용어를 배제한 쉬운 언어로 작성하며, 항상 다음 업데이트 시간을 명시해야 합니다. 예측 가능한 소통은 문제 해결 그 자체보다 더 빠르게 신뢰를 회복시킵니다.

비난 없는 사후 분석(blameless postmortem)이란 무엇인가요?

‍비난 없는 사후 분석은 개인의 잘못을 따지는 대신 장애를 유발한 시스템적 조건을 조사하는 과정입니다. 구글 SRE 워크북에서 제시하는 이 원칙은, 한 사람의 실수로 장애가 발생할 수 있다면 그것은 시스템의 결함이라고 봅니다. 비난 없는 검토는 엔지니어가 장애를 솔직하게 보고하도록 유도하며, 결과적으로 신뢰성 데이터를 정확하게 유지하게 해줍니다.

복구 과정에서 발생하는 '천둥 치는 무리(thundering herd)' 문제란 무엇인가요?

‍천둥 치는 무리 문제는 복구된 서비스에 재시도하는 클라이언트, 쌓여 있던 대기열, 차가운 캐시 등이 한꺼번에 몰리면서 서비스가 다시 다운되는 현상을 말합니다. 이를 방지하려면 한 번에 모든 부하를 복구하지 말고, 단계적으로 트래픽을 늘리면서 지표를 모니터링해야 합니다.

장애 대응 계획에는 무엇이 포함되어야 하나요?

‍최소한 장애 선언 방법, 정의된 역할(인시던트 커맨더, 기술 리드, 커뮤니케이션 리드), 심각도 척도(SEV-1~SEV-3), 완화 우선 원칙, 소통 주기, 복구 검증, 그리고 책임자가 지정된 실행 항목을 포함한 비난 없는 사후 분석 단계가 포함되어야 합니다. 선언, 완화, 소통, 복구, 학습이라는 순서가 내용만큼이나 중요합니다.

‍