¶ 14권 — 장애 대응 프로세스와 포스트모템 문화 만들기
모니터링·배포 체계를 갖춘 다음 단계는 "알림이 울렸을 때 실제로 무엇을 하는가"다. 이 책은 도구 도입이 아니라 장애 감지부터 대응, 복구, 재발 방지로 이어지는 흐름에서 팀이 미리 합의해 두어야 할 판단 기준을 정리한다.
¶ 장애 대응의 전체 흐름: 감지 → 대응 → 복구 → 포스트모템
네 단계로 구성된다.
- 감지 — 장애를 얼마나 빨리 알아채는가
- 대응 — 누가 맡고 언제 더 부르는가
- 복구 — 정상화가 원인 규명보다 우선
- 포스트모템 — 기록과 재발 방지
각 단계마다 팀이 미리 합의해 둘 규칙이 있으며, 장애가 터진 순간 규칙을 새로 정하려 하면 이미 늦는다.
¶ 장애 등급 정의: 모든 장애가 같은 무게를 갖지 않는다
| 체계 | 구성 |
|---|---|
| 정식 5단계 | SEV-1(치명적, 즉각 전사 대응) ~ SEV-5(경미한 버그) |
| 작은 팀 단순화 | 긴급 / 중요 / 경미 3단계 |
등급이 애매하면 더 높은 등급으로 간주하고 구체적 수치로 기준을 정의할 것을 권한다. 중요한 것은 몇 단계냐가 아니라 등급마다 "누구를 부르고 얼마나 빨리 대응하는가"가 문서로 남아 있는가다.
¶ 대응: 역할을 정하고, 에스컬레이션 기준을 미리 합의한다
역할은 다음과 같이 구분한다.
- 인시던트 커맨더 — 전체 조율
- 기록자 — 타임라인 초안 작성
- 주제 전문가
- 고객·내부 연락 담당
작은 팀은 겸임하더라도 "지금 누가 지휘하는가"만은 초기에 명확히 해야 한다.
¶ 복구: 원인 규명보다 서비스 정상화가 먼저다
완화(Mitigation)를 먼저 검토한다(롤백, 기능 플래그 끄기, 트래픽 우회). 최근 배포나 설정 변경을 되돌리는 것이 원인을 모르는 상태에서도 가장 빠른 완화책인 경우가 많다.
완전한 해결은 복구 이후 포스트모템의 후속 작업으로 미룰 수 있다.
¶ 포스트모템: 무비난(Blameless) 원칙이 핵심이다
Google SRE는 포스트모템을 장애의 영향·조치·근본 원인·후속 조치를 기록한 문서로 정의한다. 무비난 원칙은 "관여한 모든 사람이 좋은 의도로 그 순간 옳다고 판단한 행동을 했다"고 전제한다.
이는 도덕적 이유가 아니라 실용적 이유다. 비난을 두려워하면 정보가 숨겨져 진짜 근본 원인을 찾을 수 없기 때문이다.
¶ 포스트모템 템플릿: 무엇을 기록해야 하는가
템플릿은 다음 여섯 항목으로 구성된다.
- 요약
- 타임라인
- 분석(전조-발생-영향-감지-대응-복구-재발 가능성 국면별 점검)
- 근본 원인("5 Whys")
- 교훈
- 후속 조치(이슈 트래커 연결)
특히 "분석" 단계를 건너뛰고 타임라인과 근본 원인을 바로 연결하면 프로세스 개선점을 놓치기 쉽다.
¶ 재발 방지 액션 추적
후속 조치가 실제로 처리되지 않으면 포스트모템은 기록을 위한 기록에 그친다. 핵심은 다음 네 가지다.
- 모든 액션에 담당자·기한을 명시
- 일반 백로그와 별도 라벨로 관리
- 정기적으로 완료 여부를 점검
- 완료가 실제로 재발을 막았는지 확인
¶ (옵션) 게임데이와 SLA·에러 버짓 연계
게임데이(Game Day)/장애 주입 훈련은 의도적으로 장애를 만들어 실전처럼 연습하는 방식으로, 대응 문서와 런북이 여전히 유효한지 검증한다.
¶ 핵심 포인트: 무비난 문화가 재발방지의 전제조건이다
등급 체계·에스컬레이션 규칙·템플릿은 모두 정확한 정보가 있어야 작동하는데, 그 정보를 내놓을지는 결국 장애 당시 담당자의 심리적 안전감에 달려 있다.
무비난 문화 없이 도구만 정교하게 도입하면 포스트모템은 형식적 서류 작업으로 전락한다.
¶ 참고할 만한 사례
LINE의 감지-전파-해결-보고-회고 5단계 무비난 장애 처리 프로세스, AWS의 2025년 10월 US-EAST-1 DynamoDB 장애 포스트모템, Cloudflare의 2025년 11월 전역 장애 포스트모템이 소개된다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.