장애 대응 Runbook 설계: 탐지·완화·복구·회고까지

장애 대응 Runbook은 장애의 정답을 적어놓는 문서가 아니다. 실제 장애는 예측하지 못한 Dependency, 배포 변경, 데이터 상태, 트래픽 패턴이 겹쳐 발생하고 같은 증상도 원인이 다를 수 있다.

그래서 좋은 Runbook이 고정해야 하는 것은 원인보다 대응 방식이다.

탐지된 문제가 실제 Incident인지 누가 판단할지, Severity는 무엇을 근거로 정할지, 누가 지휘권을 갖고 어떤 순서로 사용자 영향을 줄일지, 언제 복구됐다고 선언할지, 무엇을 기록하고 누구에게 알릴지, 교대할 때 어떤 상태를 넘길지까지 합의돼 있어야 한다.

NIST의 최신 Incident Response 지침도 가능한 모든 상황을 위한 상세 절차를 미리 작성하는 것은 현실적이지 않다고 본다. 대신 조직의 역할과 권한을 정하고 반복되거나 중요하고 시간에 민감한 활동에는 실행 가능한 절차와 Playbook을 준비하도록 한다.

즉 Runbook의 역할은 장애를 예언하는 것이 아니라 장애 중에도 팀이 같은 운영 규칙을 사용하게 만드는 것이다.

Runbook은 두 층으로 나누는 편이 낫다

Incident Runbook 하나에 모든 명령어와 장애 유형을 넣기 시작하면 문서는 금방 낡는다.

오히려 두 층으로 나누는 편이 관리하기 쉽다.

Incident Coordination Runbook은 거의 모든 Incident에서 공통으로 사용하는 규칙을 가진다. Detection, Triage, Severity, Incident Commander, Communication, Handoff, Closure, Post-incident Review가 여기에 속한다.

그 아래에는 Technical Runbook 또는 Recovery Procedure가 붙는다. 예를 들면 DB Failover, Queue Backlog 처리, 외부 API 장애 우회, 캐시 비활성화, 특정 서비스 재시작, 배포 Rollback처럼 시스템과 실패 유형에 따라 달라지는 절차다.

한 Incident에서 여러 Technical Runbook을 사용할 수도 있다. 하지만 누가 어떤 상태에서 어떤 절차를 실행하고 결과를 어떻게 확인할지는 하나의 Coordination Runbook이 통제해야 한다.

이 구분을 해두면 기술 스택이 달라져도 Incident Management 자체를 다시 설계할 필요가 줄어든다.

장애 대응 상태를 먼저 합의한다

실무에서는 Incident의 현재 상태조차 사람마다 다르게 이해하기 쉽다. 한 사람은 이미 복구됐다고 생각하고 다른 사람은 여전히 원인을 조사하고 있을 수 있다.

Runbook에 다음과 같은 상태 모델을 두면 공통 언어를 만들 수 있다.

Detected → Triaged → Declared → Mitigating → Recovering → Monitoring → Resolved → Reviewed

이것은 표준이 정한 유일한 상태 모델이 아니라 운영을 위한 예시다. 중요한 것은 이름보다 각 상태에서 현재 목표가 무엇인지다.

Mitigating 상태의 목표는 완벽한 수정이 아니라 사용자 피해의 확산을 멈추는 것이다. Recovering은 임시 조치에 기대지 않고 의도한 운영 상태로 돌아가는 과정이다. Monitoring에서는 실제 사용자 결과와 데이터 상태가 회복됐는지 확인한다.

상태가 다시 악화되면 이전 단계로 돌아갈 수 있어야 한다.

Detection — 무엇을 발견했는지부터 기록한다

Incident는 반드시 모니터링 Alert에서 시작하지 않는다.

사용자가 오류를 신고할 수도 있고 고객지원이 반복 문의를 발견할 수도 있으며 외부 Provider가 장애를 알릴 수도 있다. 배포 담당자가 예상하지 못한 동작을 먼저 발견하는 경우도 있다.

Detection 단계에서 필요한 것은 원인 추측보다 최초 사실이다.

언제 감지했는가

어떤 경로로 감지했는가

어떤 사용자 행동이 실패하고 있는가

어떤 사용자·지역·기능이 영향을 받는 것으로 보이는가

처음 관찰한 증상은 무엇인가

그 판단을 뒷받침하는 Dashboard, Log, Trace, 요청 ID 등은 무엇인가

Alert를 받았다는 사실과 Incident라는 판단은 구분해야 한다. Alert를 Page·Ticket·Dashboard 중 어디로 보낼지는 별도의 Alert Routing 문제이고 021은 탐지된 현상을 Incident Response로 전환한 이후를 다룬다.

Triage — Root Cause보다 영향 범위를 먼저 잡는다

초기 Triage에서 가장 위험한 행동 중 하나는 너무 빨리 원인을 확정하는 것이다.

“방금 배포했으니 배포 문제다”, “DB CPU가 올라갔으니 DB 문제다” 같은 가설은 조사에 필요하지만 사실과 섞여서는 안 된다.

Triage의 첫 목적은 Root Cause Analysis가 아니라 현재 운영 상황을 공통으로 이해하는 것이다.

확인할 질문은 다음과 같다.

실제 사용자 영향이 존재하는가

어떤 Critical User Journey가 실패하는가

영향 범위가 확대되고 있는가

특정 Region, Tenant, 기능, 버전에 제한되는가

직전 배포·설정 변경이 있었는가

외부 Dependency 상태는 어떤가

쓰기 작업이나 데이터 정합성에 위험이 있는가

보안 또는 개인정보 사고 가능성이 있는가

사용 가능한 우회 방법이 있는가

Infrastructure Metric은 중요한 원인 신호지만 이것만으로 사용자 영향을 판단해서는 안 된다. 복구 여부 역시 같은 이유로 Critical User Journey의 결과와 연결해야 한다.

Severity — 숫자보다 판단 근거를 남긴다

Severity를 정해야 하는 이유는 이름표를 붙이기 위해서가 아니다.

사람을 얼마나 모을지, 누가 의사결정에 참여해야 하는지, 어떤 Communication Channel을 열지, 다른 작업보다 무엇을 먼저 중단할지를 결정하기 위해 필요하다.

그렇다고 모든 조직에 통하는 10분이면 SEV-1, 30분 이상이면 SEV-2 같은 표를 만들 수는 없다.

NIST도 Incident 우선순위를 Scope, Impact, Time-critical Nature, Recoverability 등 위험 요소를 바탕으로 평가하도록 설명한다.

Runbook에서는 최소한 다음 축을 검토하는 편이 낫다.

판단 축	확인할 질문
사용자 영향	핵심 사용자 여정이 중단됐는가? 일부 기능인가, 서비스 전체인가?
영향 범위	일부 사용자·Region·Tenant인가, 빠르게 확대되고 있는가?
데이터	손실·중복·오염·정합성 훼손 가능성이 있는가?
보안·안전	보안 사고나 개인정보 노출 가능성이 있는가?
시간 민감성	시간이 지날수록 손상이 누적되거나 복구가 어려워지는가?
우회 가능성	사용자가 사용할 수 있는 안전한 Workaround가 있는가?
복구 가능성	알려진 완화·복구 경로가 있는가, 결과가 불확실한가?
조정 복잡성	한 팀이 처리 가능한가, 여러 팀·외부 Provider가 필요한가?
불확실성	원인뿐 아니라 영향 범위 자체를 아직 알 수 없는가?

각 조직은 이 축을 자사의 Severity Label과 연결하면 된다.

그리고 Severity는 최초 선언 후 고정돼서는 안 된다. 영향이 확대되거나 데이터 위험이 새로 발견되면 올릴 수 있고 반대로 Scope가 제한됐음이 확인되면 조정할 수 있다.

변경할 때는 무엇이 달라졌기 때문에 Severity를 바꿨는지를 Timeline에 남긴다.

Incident Commander — 가장 잘 디버깅하는 사람이 지휘할 필요는 없다

장애가 커질수록 기술 문제보다 Coordination 문제가 커진다.

여러 사람이 동시에 로그를 보고 같은 설정을 수정하고 별도의 Slack Thread에서 서로 다른 가설을 이야기한다면 인원이 늘어날수록 오히려 상황을 파악하기 어려워진다.

Google SRE는 Incident Commander, Communications Lead, Operations Lead 같은 역할을 분리해 Incident Management를 운영한다. Incident Commander는 전체 상황과 우선순위를 조정하고 Operations Lead는 실제 완화·복구 작업에 집중하며 Communications Lead는 이해관계자와의 정보 흐름을 맡는다.

작은 팀이 세 명을 따로 배정할 필요는 없다. 한 사람이 여러 역할을 겸할 수도 있다.

하지만 최소한 다음 두 가지는 모호해서는 안 된다.

현재 Incident의 최종 조정 책임자는 누구인가.

Production에 변경을 가할 수 있는 사람 또는 역할은 누구인가.

Incident Commander가 가장 뛰어난 Debugger일 필요도 없다. 오히려 IC가 모든 명령을 직접 실행하면 전체 상태, 우선순위, Communication을 놓칠 수 있다.

IC가 가져야 할 것은 모든 정답이 아니라 현재 무엇을 알고 있고 무엇을 모르며 다음에 어떤 결정을 내려야 하는지를 유지할 권한과 책임이다.

Mitigation — 원인을 고치기 전에 피해부터 줄일 수 있다

Mitigation과 Recovery를 같은 말로 쓰면 대응이 흔들린다.

Mitigation의 목적은 현재 사용자 영향을 줄이거나 추가 피해를 제한하는 것이다. 임시 상태여도 괜찮다.

상황에 따라서는 문제가 있는 기능 노출을 중단하거나, 트래픽을 다른 경로로 보내거나, 일부 쓰기 작업을 제한하거나, 과부하를 만드는 요청을 줄이는 쪽이 Root Cause를 찾는 것보다 먼저일 수 있다.

배포가 원인 후보라면 Rollback이 하나의 선택지가 될 수 있다. 하지만 Rollback을 실행할 수 있는지는 코드만이 아니라 설정, DB Schema, 데이터, Feature Exposure, Traffic 상태의 호환성에 달려 있다. 이 메커니즘은 별도의 Rollback 설계 문제다.

Incident Runbook은 특정 복구 방법을 정답으로 고정하기보다 각 행동에 다음 내용을 남기도록 해야 한다.

항목	기록할 내용
Action	무엇을 변경할 것인가
Owner	누가 실행하는가
Objective	어떤 사용자 영향을 줄이려는가
Expected Signal	효과가 있다면 어떤 신호가 바뀌어야 하는가
Risk	이 변경이 만들 수 있는 추가 위험
Safety Control	실패할 경우 중단·복구 방법
Result	실제 결과
Evidence	결과를 판단한 근거

특히 “실행했다”와 “효과가 있었다”를 구분해야 한다.

Evidence Preservation — 완화하면서도 나중에 설명할 수 있게 남긴다

장애가 급하면 기록을 미루기 쉽다. 그러나 복구가 끝난 뒤 원인을 재구성하려면 변경 전 상태와 대응 과정이 필요하다.

가능하다면 파괴적인 변경을 하기 전에 다음 정보를 남긴다.

실행 중이던 애플리케이션·배포 버전

설정과 Feature Flag 상태

주요 Dashboard와 Query의 기준 시각

Queue나 DB 등 상태를 가진 시스템의 당시 상태

외부 Dependency 상태

누가 어떤 변경을 왜 실행했는지

변경 후 무엇이 달라졌는지

NIST는 Incident 분석에서 수집한 데이터와 메타데이터의 무결성·출처를 보존하도록 권고한다. 동시에 모든 Incident에서 법적 수준의 Chain of Custody가 필요한 것은 아니라고 구분한다.

따라서 일반적인 서비스 장애에서는 “나중에 상황을 재구성할 수 있는 기록”이 기본 목표가 된다.

다만 보안 침해나 개인정보 유출 가능성이 있다면 일반 운영 장애와 다르다. 이때는 Security·Legal Procedure와 Evidence Handling 기준으로 전환해야 한다.

증거를 보존하느라 진행 중인 피해를 방치해서도 안 된다. 사용자 영향이 계속 커지고 있다면 Containment와 Evidence Preservation의 우선순위를 Incident Commander가 명시적으로 결정해야 한다.

Recovery — 임시로 버티는 상태에서 정상 운영 상태로 돌아간다

Mitigation으로 오류율이 줄었다고 Incident가 끝난 것은 아니다.

예를 들어 일부 기능을 꺼서 서비스는 사용할 수 있지만 핵심 기능이 제한돼 있다면 이것은 Mitigated State일 수는 있어도 완전한 Recovery는 아니다.

Recovery에서는 조직이 합의한 Target State로 돌아가는 작업을 진행한다.

여기에는 임시 변경 해제, 정상 트래픽 복원, 데이터 정합성 처리, Queue Backlog 해소, Dependency 정상화, 필요한 경우 Rollback·Roll-forward·Failover·Restore 같은 Technical Procedure가 포함될 수 있다.

중요한 것은 “Recovery Action을 끝냈다”와 “서비스가 복구됐다”를 다시 구분하는 것이다.

Recovery Verification — 서버가 초록색이라고 끝내지 않는다

복구 선언은 가장 쉽게 성급해질 수 있는 단계다.

CPU가 내려갔다. Pod가 모두 Running이다. Error Log가 줄었다.

모두 좋은 신호지만 이것만으로 사용자가 다시 서비스를 정상적으로 사용할 수 있다는 뜻은 아니다.

NIST Rev.3도 복구 과정에서 핵심 서비스가 실제로 복원됐는지 확인하고 복구된 시스템의 무결성과 정상 동작을 검증하며 이후 모니터링을 수행한 뒤 종료 기준에 따라 Recovery를 끝내도록 한다.

복구 확인은 장애가 처음 영향을 준 사용자 결과로 돌아가야 한다.

실패했던 Critical User Journey가 다시 성공하는가

성공하더라도 지연이 비정상적으로 남아 있지 않은가

데이터 누락·중복·정합성 문제가 남지 않았는가

Queue나 비동기 처리 Backlog가 계속 쌓이지 않는가

특정 Region·Tenant·사용자 Segment만 여전히 실패하지 않는가

외부 Dependency까지 정상 경로로 돌아왔는가

모니터링과 Alert 자체가 정상적으로 작동하는가

임시 우회 조치로 새로운 위험을 만들고 있지 않은가

얼마 동안 관찰해야 하는지는 서비스의 트래픽, 실패 주기, 데이터 처리 방식에 따라 다르다. 모든 서비스에 적용할 범용 15분 정상 = 복구 완료 같은 기준을 만드는 대신 서비스별 Recovery Acceptance Criteria와 Observation Condition을 정해야 한다.

Communication — 기술 작업과 별도의 Workstream으로 본다

장애 중 Communication은 “나중에 공지하는 일”이 아니다.

Responder끼리 현재 상태를 공유하는 Internal Coordination, 경영·지원·영업 등 이해관계자에게 영향을 전달하는 Stakeholder Communication, 필요할 경우 사용자·외부 기관에 알리는 External Communication이 동시에 존재할 수 있다.

NIST는 Incident Coordination, Notification, Public Communication, Incident Information Sharing을 별도의 Response 활동으로 다룬다. Google SRE 역시 사용자 중심 사고 대응에서 기술적 완화만큼 현재 영향과 대응 상태를 명확히 전달하는 것을 중시한다.

업데이트에는 적어도 다음 정보가 있어야 한다.

Incident:

Current State: Current Severity: User Impact: Affected Scope: What Changed Since Last Update: Mitigation / Recovery in Progress: Known Workaround: Known Unknowns: Next Decision Point: Next Update:

여기서 Next Update는 근거 없는 복구 ETA와 다르다.

복구 시점을 알 수 없는데 “30분 안에 정상화 예정”이라고 추측하기보다 “다음 복구 절차가 끝나면 상태를 갱신한다” 또는 조직이 정한 Communication Cadence를 사용하는 편이 정확하다.

Handoff — 교대는 메시지를 남기는 것으로 끝나지 않는다

장애가 길어지면 한 사람이 끝까지 대응하는 방식 자체가 위험해진다.

문제는 교대가 필요한지 여부가 아니라 현재 Incident State가 손실 없이 넘어가는가다.

Google SRE의 Incident Management 모델에서도 Incoming Incident Commander에게 상황을 설명한 뒤 명시적으로 지휘권을 인수하도록 한다.

좋은 Handoff에는 최소한 다음 내용이 포함돼야 한다.

현재 사용자 영향

현재 Severity와 그 판단 이유

Incident Commander와 주요 역할

지금까지 확인된 사실

아직 가설인 내용

실행한 Mitigation과 실제 결과

진행 중인 작업

실패했거나 다시 실행하면 안 되는 작업

다음 Decision Point

외부·내부 Communication 상태

보존한 Evidence 위치

현재 남아 있는 위험

Outgoing Owner가 문서를 남겼다는 것만으로 Handoff가 완료되는 것은 아니다.

Incoming Owner가 상태를 이해하고 명시적으로 책임을 인수한 시점을 기록해야 한다.

언제 Incident를 종료할 것인가

Root Cause를 완전히 알아냈을 때까지 Incident를 열어둘 필요는 없다.

반대로 Error Rate가 잠깐 낮아졌다고 바로 닫아서도 안 된다.

Resolved 상태로 전환하기 위한 조건은 사전에 Runbook에 합의해 두는 편이 좋다.

사용자 영향이 더 이상 지속되지 않는다.

영향을 받았던 Critical User Journey가 Recovery Criteria를 충족한다.

데이터·Queue·비동기 작업의 잔여 문제가 허용 가능한 상태인지 확인했다.

주요 Dependency의 상태를 확인했다.

Monitoring과 Alert가 정상 상태다.

임시 Mitigation과 우회 조치가 무엇인지 기록했다.

제거하지 않은 임시 조치에는 Owner가 있다.

남아 있는 Residual Risk를 기록하고 필요한 책임자가 인지했다.

필요한 내부·외부 Communication을 갱신했다.

Post-incident Review Owner를 지정했다.

NIST 역시 Recovery 종료를 단순한 기술 작업 완료가 아니라 복구 확인과 종료 기준, 문서화까지 포함하는 과정으로 다룬다.

Post-incident Review — Root Cause 한 줄로 끝내지 않는다

회고에서 흔히 던지는 질문은 “원인이 뭐였나?”다.

필요한 질문이지만 이것만으로는 같은 장애의 재발만 겨우 막을 수 있다.

Incident Response 자체를 개선하려면 더 넓게 봐야 한다.

Detection: 사용자보다 먼저 알아챘는가. 필요한 신호가 없었던 것은 아닌가.

Triage: 영향 범위를 빨리 파악했는가. 잘못된 가설 때문에 시간이 소모됐는가.

Severity: 적절한 사람과 팀이 충분히 빨리 참여했는가.

Coordination: 지휘권과 Production Change Authority가 명확했는가.

Mitigation: Root Cause 조사보다 사용자 피해 감소를 적절히 우선했는가.

Recovery: 임시 완화와 정상 복구를 구분했는가.

Verification: 실제 사용자 결과와 데이터 상태를 확인했는가.

Communication: 필요한 사람이 필요한 시점에 같은 상태를 알고 있었는가.

Handoff: 교대 과정에서 Context가 손실되지 않았는가.

Google SRE도 Postmortem의 목적을 Root Cause 분석에 한정하지 않고 Detection, Mitigation, Coordination, Communication까지 개선하는 데 둔다. Action Item은 실제 Backlog로 연결돼야 한다.

Blameless하다는 말은 책임이 없어도 된다는 뜻이 아니다.

개인의 잘못을 찾는 대신 시스템이 왜 그 행동을 허용하거나 요구했는지 살피되, 수정 작업에는 분명한 Owner가 있어야 한다.

Follow-up Ownership — 회고 문서를 썼다고 개선된 것은 아니다

Postmortem이 문서 저장소에서 끝나면 다음 Incident의 행동은 바뀌지 않는다.

모든 Follow-up에는 최소한 다음 정보가 있어야 한다.

Field	내용
Gap	어떤 실패 가능성을 발견했는가
Action	구체적으로 무엇을 바꿀 것인가
Owner	끝까지 책임질 사람 또는 팀
Priority	다른 운영 작업과 비교한 우선순위
Target	조직이 합의한 완료 목표
Acceptance Evidence	무엇을 확인하면 완료라고 볼 것인가
Tracking ID	Issue·Ticket 등 추적 위치
Status	현재 상태

특히 장애 중 급하게 넣은 Feature Flag, 임시 Firewall Rule, Traffic 우회, 수동 Cron 같은 조치를 별도 Cleanup Item으로 남겨야 한다.

장애 대응의 마지막 단계는 Postmortem Meeting이 아니라 발견한 운영 Gap이 다시 Backlog의 소유권을 갖는 순간이다.

Incident Runbook Template

아래 Template은 특정 장애 원인을 위한 Technical Runbook이 아니다. 서비스별 명령어와 복구 절차는 별도 Runbook으로 연결하고 이 문서는 Incident Coordination의 공통 상태와 책임을 관리한다.

Runbook Metadata

runbook_name:
service:
runbook_owner:
last_reviewed_at:
review_due_at:

critical_user_journeys:

related_alerts:
technical_runbooks:
recovery_procedures:
rollback_guide:
escalation_path:
communication_channels:

Detection

incident_id:
detected_at:
detected_by:
detection_source: alert | user_report | support | operator | dependency | other

observed_symptom:

suspected_user_impact:
affected_journey:
affected_scope:
initial_confidence:

initial_evidence:

dashboards:
logs:
traces:
request_ids:
external_status:

Triage & Incident Declaration

사용자 영향이 실제로 존재하는지 확인했다.

영향받은 Critical User Journey를 확인했다.

현재 Scope와 확산 여부를 기록했다.

최근 배포·설정·Feature 변경을 확인했다.

주요 외부 Dependency를 확인했다.

데이터 손상·정합성 위험을 확인했다.

Security / Privacy Incident 가능성을 확인했다.

알려진 Workaround가 있는지 확인했다.

Incident 선언 여부를 결정했다.

declared: true | false

declared_at:
declaration_owner:

current_state:

initial_severity:
severity_rationale:
known_facts:
hypotheses:
unknowns:

Roles & Authority

역할	담당자	책임
Incident Commander		전체 상태·우선순위·Decision 관리
Operations / Technical Lead		완화·복구 실행
Communications Owner		내부·외부 상태 전달
Scribe / Timeline Owner		Timeline·결정·Evidence 기록
SME		특정 시스템 분석
Production Change Authority		Production 변경 승인·실행 권한

작은 팀에서는 역할을 겸할 수 있다. 단, 현재 지휘권과 Production 변경 권한이 누구에게 있는지는 명시한다.

Severity Assessment

current_severity:
assessed_at:
assessed_by:

user_impact:

scope:
data_risk:
security_or_safety_risk:
time_criticality:
workaround:
recoverability:
coordination_complexity:
uncertainty:

rationale:

Severity가 바뀌면 기존 기록을 덮어쓰지 않는다.

시간	Previous	New	변경 근거	결정자

Current Incident State

state: DETECTED | TRIAGED | DECLARED | MITIGATING | RECOVERING | MONITORING | RESOLVED

current_objective:

current_user_impact:
current_scope:
latest_decision:
next_decision_point:

Mitigation Log

Action	Owner	Objective	Expected Signal	Risk / Safety Control	Status	Result	Evidence

Evidence Preservation

배포·Artifact 버전을 기록했다.

주요 Configuration 상태를 기록했다.

Feature Flag 상태를 기록했다.

관련 Dashboard·Query의 기준 시각을 남겼다.

필요한 Log·Trace·Request ID를 보존했다.

DB·Queue 등 Stateful System의 필요한 상태를 남겼다.

외부 Dependency 상태를 기록했다.

누가 어떤 Production 변경을 실행했는지 남겼다.

변경 이유와 결과를 남겼다.

Security / Privacy Incident라면 별도 Evidence Handling 절차를 연결했다.

evidence_location:

retention_requirement:
sensitive_data_present:
security_or_legal_escalation:

Recovery Plan

target_state:
recovery_owner:
prerequisites:
technical_runbooks:
recovery_actions:
temporary_controls_to_remove:
known_residual_risk:

Deployment Rollback이 필요한 경우 세부 절차는 별도 Rollback Runbook을 사용한다.

Recovery Verification

영향을 받았던 Critical User Journey가 다시 성공한다.

사용자 관점의 Latency가 허용 상태다.

데이터 손실·중복·정합성 문제를 확인했다.

Queue·비동기 Backlog의 상태를 확인했다.

영향받은 Region·Tenant·Segment를 다시 확인했다.

주요 Dependency가 정상 경로로 돌아왔다.

Monitoring Coverage가 정상이다.

필요한 Alert가 정상적으로 동작한다.

임시 Mitigation이 만드는 Residual Risk를 확인했다.

서비스별 Observation Condition을 충족했다.

verification_started_at:

verification_owner:
journey_evidence:
data_evidence:
dependency_evidence:
monitoring_evidence:
observation_condition:
verification_result:

Communication

Audience	Owner	전달할 내용	Last Update	Next Update Trigger

Incident Responders

Internal Stakeholders

Users / Customers

External Provider

Legal / Security / Regulatory

Status Update Template

Incident:

Current State: Severity: User Impact: Affected Scope:

Changes Since Previous Update:

Mitigation / Recovery in Progress: Available Workaround: Known Unknowns:

Next Decision Point:

Next Update:

Handoff

handoff_at:
outgoing_owner:
incoming_owner:

current_user_impact:

current_severity:
severity_rationale:
current_state:

confirmed_facts:

active_hypotheses:
unknowns:

completed_actions:

actions_in_progress:
failed_or_unsafe_actions:
pending_actions:

next_decision_point:

communication_status:
evidence_location:
guardrails:

incoming_owner_accepted_at:

Outgoing Owner가 현재 상태를 설명했다.

Incoming Owner가 질문할 시간을 가졌다.

진행 중인 Production 변경을 확인했다.

다음 Decision Point를 합의했다.

Incoming Owner가 명시적으로 인수를 확인했다.

다른 Responder에게 지휘권 변경을 알렸다.

Closure

사용자 영향이 중단됐다.

Recovery Verification을 통과했다.

데이터·Queue 상태를 확인했다.

Dependency 상태를 확인했다.

Monitoring과 Alert가 정상이다.

임시 변경을 모두 기록했다.

미제거 Temporary Control에 Owner가 있다.

Residual Risk를 기록했다.

필요한 Communication을 완료했다.

Post-incident Review Owner를 지정했다.

resolved_at:

resolved_by:
closure_rationale:
remaining_risks:
temporary_controls:
post_incident_owner:

Post-incident Review

review_owner:
review_date:
incident_summary:

timeline:

user_impact:
technical_factors:
contributing_factors:

detection_review:

triage_review:
severity_review:
coordination_review:
mitigation_review:
recovery_review:
verification_review:
communication_review:
handoff_review:

what_worked:

what_did_not_work:
remaining_unknowns:

Follow-up Ownership

ID	Gap	Action	Owner	Priority	Target	Acceptance Evidence	Tracking ID	Status

Runbook Improvement

runbook_gap_found:
runbook_change_required:
change_owner:
technical_runbook_change_required:
alerting_change_required:
observability_change_required:
deployment_change_required:
next_review_or_drill:

Runbook의 완성도는 장애가 없을 때 드러난다

Runbook은 Incident가 터진 뒤 처음 읽는 문서가 되어서는 안 된다.

서비스 담당자와 On-call 담당자가 현재 Severity 기준을 알고 있는지, Incident Commander가 어떤 권한을 갖는지, Communication Channel이 실제로 열리는지, Technical Runbook 링크가 살아 있는지, Handoff가 가능한지를 평소에 점검해야 한다.

또 실제 Incident를 겪을 때마다 Runbook 자체도 수정돼야 한다. NIST Rev.3는 Lessons Learned를 Recovery가 모두 끝난 뒤 한 번 수행하는 단계로만 보지 않고 Incident Response 전반의 Improvement로 환류하도록 한다.

잘 만든 Runbook이 장애를 없애주지는 않는다.

대신 장애가 발생했을 때 사람마다 서로 다른 방식으로 대응하면서 만드는 두 번째 장애를 줄여준다.

원인을 처음부터 알지 못해도 괜찮다.

누가 판단하는지, 지금 무엇을 지키려는지, 어떤 변경을 했는지, 무엇을 보고 복구됐다고 말할지, 다음 사람에게 무엇을 넘길지를 알고 있다면 대응은 반복 가능한 운영 체계가 된다.