Incident Response와 Postmortem

Overview

장애 대응의 첫 목표는 완벽한 원인 규명이 아니라 사용자 영향을 안전하게 줄이는 것이다. 안정화 뒤 Timeline과 증거를 보존하고 직접 원인, 기여 요인, 탐지 공백, 재발 방지를 분리해 기록한다.

한 문장 설명: Incident Response는 영향을 제한하고 증거를 보존한 뒤 재발 가능성을 낮추는 시간 순서의 의사결정 절차다.

왜 필요한가

장애 상황에서는 정보가 불완전하고 변경 위험이 크다. 담당, 지휘, 소통, 중단 기준을 미리 정하지 않으면 여러 사람이 동시에 설정을 바꾸고 원인과 복구 근거를 잃는다. 반복 가능한 절차는 개인의 기억이 아니라 조직의 안전장치가 된다.

핵심 원리

Severity는 기술 오류 이름이 아니라 사용자 영향, 범위, 지속 시간과 데이터 위험으로 정한다. Incident Commander는 우선순위와 변경을 조정하고, 기술 담당은 가설 하나씩 증거로 검증하며, Communication 담당은 일정한 주기로 사실과 다음 갱신 시점을 공유한다.

내부 동작

탐지 후 최근 변경, Error Rate, Latency, Saturation, Dependency 상태로 영향 경계를 잡는다. 완화는 Rollback, Feature Flag, Traffic 차단, Capacity 증설 중 가장 빠르고 되돌릴 수 있는 수단을 택한다. 복구는 지표가 정상으로 돌아온 순간이 아니라 Queue와 데이터 정합성, 지연 작업이 회복된 시점까지 확인한다.

Example

배포 직후 API 5xx가 1%에서 20%로 증가했다면 먼저 신규 Version과 구버전의 오류율을 비교한다. 신규에만 집중되면 Canary 중단과 Rollback을 실행하고 시각·담당·근거를 Timeline에 남긴다. 복구 뒤 Stack Trace, 배포 Diff, 관련 Metric을 보존하고 재현 Test를 만든다. 운영 중 즉흥 Patch를 먼저 넣어 원인을 가리지 않는다.

실무에서 발생하는 문제

여러 Dashboard의 시간대가 달라 Timeline이 어긋나거나, Log Sampling으로 최초 오류가 사라질 수 있다. Retry가 실제 장애보다 더 큰 Traffic을 만들고, 부분 복구 후 쌓인 Queue가 Dependency를 다시 압박할 수 있다. 고객 식별정보와 Token을 대응 채널에 복사하는 것도 별도 보안 사고가 된다.

Trade-off

빠른 Rollback은 영향을 줄이지만 새 Version이 수행한 비호환 DB Migration이 있으면 더 위험할 수 있다. 상세 Logging은 증거를 늘리지만 비용과 개인정보 노출을 키운다. 자동 복구는 MTTR을 줄이지만 잘못된 Health 조건에서는 재시작 Loop를 만들 수 있다.

flowchart LR; D[탐지] --> T[분류·담당 지정]; T --> M[영향 완화]; M --> R[복구 확인]; R --> E[증거·Timeline]; E --> P[Postmortem]; P --> A[Owner·기한 있는 조치]; A --> V[효과 검증]

대응 중 기록

발생·인지·완화·복구 시각, 사용자 영향, 변경 사항, 가설과 검증 결과, 명령과 관측 근거를 남긴다. Status 공유 담당과 기술 대응 담당을 분리하면 Communication 때문에 Debugging이 끊기는 일을 줄일 수 있다.

Postmortem 구조

• 사용자와 Service에 미친 영향
• Detection과 대응 Timeline
• 직접 원인과 기여 요인
• 잘된 점과 늦어진 점
• 즉시 조치와 근본 조치
• 각 Action의 Owner, 기한, 검증 방법

흔한 오해

“사람이 실수했다”는 재발 방지가 아니다. 왜 Review, Guardrail, Test, Alert가 그 실수를 막지 못했는지 본다. 모든 장애에 거대한 문서를 쓰기보다 영향과 반복 가능성에 비례해 깊이를 정한다.

Production Considerations

On-call 연락, 권한, Dashboard, Rollback, Backup Restore를 정기적으로 Game Day에서 검증한다. MTTA/MTTR만 목표로 삼지 않고 탐지 품질, 잘못된 Alert, Action 완료율과 같은 선행 지표를 본다. Runbook에는 마지막 검증일과 안전한 중단 조건을 기록한다.

Interview Questions

1. Incident 중 원인 분석보다 완화를 우선하는 이유는?
2. 직접 원인과 근본 원인을 어떻게 구분하는가?
3. Action Item을 실행 가능하게 만드는 조건은?
4. Blameless가 책임 없음이라는 뜻이 아닌 이유는?

Related Topics

Application Observability, Load Testing과 연결한다.