Incident Response 장애 보고서
3줄 요약
- 장애 대응의 첫 목표는 원인 확정이 아니라 사용자 영향 제한과 의사결정 기록이다.
- Severity, 초기 커뮤니케이션, 원인 격리, 임시 완화, Postmortem은 각각 다른 질문에 답한다.
- 좋은 장애 보고서는 타임라인, 영향 범위, 근거, 조치, 재발 방지 소유자를 남겨 다음 사고의 대응 시간을 줄인다.
핵심 정리
- 장애 탐지는 내부 에러 수만 보지 말고 사용자 영향, 기능 범위, 우회 가능성, 지속 시간을 함께 본다.
- Severity는 기술적 난이도가 아니라 고객 영향과 긴급도 기준으로 정한다.
- 초기 대응은 누가 지휘하는지, 다음 업데이트가 언제인지, 어떤 사실이 확인됐는지를 빠르게 맞추는 절차다.
- 원인 격리는 시간, 버전, 엔드포인트, 의존 시스템, 데이터 범위를 좁혀 가는 작업이다.
- 임시 완화는 완벽한 해결보다 영향 축소가 목적이며, 조치마다 기대 신호와 되돌림 조건이 필요하다.
- Postmortem은 비난이 아니라 시스템이 같은 실패를 덜 반복하도록 만드는 운영 문서다.
헷갈리는 지점
- 원인을 알아야 대응할 수 있다고 생각하기 쉽다.
- 실제 장애 중에는 원인을 모른 채로도 기능 제한, 이전 버전 전환, 배치 중단 같은 완화가 필요하다.
- Severity를 내부 장애 원인으로 정하면 우선순위가 흔들린다.
- DB 문제인지 코드 문제인지보다 사용자 결제, 로그인, 주문, 관리자 처리에 얼마나 영향을 주는지가 먼저다.
- 장애 보고서는 끝난 뒤 쓰는 형식 문서라고 오해하기 쉽다.
- 사고 중 기록한 사실이 사후 분석과 재발 방지의 핵심 증거가 된다.
확인 질문
- Severity를 정할 때 가장 먼저 봐야 할 기준은 무엇인가?
- 사용자 영향 범위, 핵심 기능 여부, 우회 가능성, 지속 시간이다.
- 초기 대응 메시지에는 무엇이 들어가야 하는가?
- 확인된 사실, 영향 범위, 현재 조치, 담당자, 다음 업데이트 시간이 들어가야 한다.
- Postmortem action item이 좋은지 판단하는 기준은 무엇인가?
- 소유자, 기한, 검증 방법이 있고 같은 장애의 탐지 또는 완화 시간을 줄이는가이다.