장애 대응과 포스트모템

장애 대응이란

장애 대응(incident response)은 서비스가 정상 동작하지 않는 상황을 빨리 알아채고, 피해를 줄이고, 다시 일어나지 않게 만드는 절차다.

출발점은 사람이 아니라 시스템을 본다는 원칙이다. 실수한 개인을 추궁하면 장애를 숨기게 되고, 숨긴 장애는 다른 팀의 도움도 경험도 얻지 못한다. 같은 실수가 다시 나와도 막히도록 시스템 쪽에서 장치를 만드는 것이 목표다. SRE에서 말하는 비난 없는 포스트모템(blameless postmortem)이 이 원칙이다.

다섯 단계

flowchart LR
  a["탐지"] --> b["전파"] --> c["해결(확산 차단)"] --> d["보고"] --> e["회고(포스트모템)"]
  a -.- a1["알람<br/>제보"]
  b -.- b1["관련 팀<br/>공유 채널"]
  c -.- c1["롤백·재기동·증설<br/>핫픽스·기능 스위치"]
  d -.- d1["표준<br/>템플릿"]
  e -.- e1["재발 방지·탐지·처리<br/>개선 과제 추적"]

단계	하는 일	요점
탐지	모니터링 알람, 감시 조직, 내부 보고 채널, 외부(사용자) 제보	경로를 여러 개 둔다. 알람이 아예 울리지 않는 장애(배치 미실행 등)는 외부에서 따로 감시한다
전파	원인 파악과 동시에 관련 부서에 알린다	영향이 크면 공유 채널로 넓게 알린다. 해결 담당과 전파 담당을 나눈다
해결	확산을 먼저 막고 근본 원인은 나중에	아래 「해결 수단」 표
보고	대응이 일단락되면 표준 템플릿으로 보고서를 쓴다	1차 공유는 가능하면 당일. 원인이 미확정이면 TBD로 두고 먼저 공유한다
회고	원인을 분석하고 개선책을 정한다	팀 내부 정리 → 관련자와 재검토의 두 단계

해결 수단

수단	쓰는 때	미리 준비할 것
롤백	최근 배포가 원인일 때 가장 먼저	스키마 변경처럼 롤백할 수 없는 변경을 배포 전에 표시해 두면 판단이 빨라진다. 배치 작업도 되돌릴 수 있게 만든다
재기동	자원 고갈·상태 꼬임	임시방편이다. 근본 원인 해결이 반드시 뒤따라야 한다
증설	트래픽 급증	쉽게 늘릴 수 있는 구조, 오토스케일링
핫픽스	롤백·재기동으로 안 될 때	빠른 배포 파이프라인
기능 스위치	앱 배포가 느린 환경(모바일)	서버에서 기능을 켜고 끄는 피처 플래그. 점진 배포 중이면 노출을 0%로 내린다

심각도 등급

장애를 심각도로 나누고 등급마다 해결 기한을 정해 두면 대응 우선순위를 두고 다투지 않는다. 가장 심각한 등급은 임시 조치로 먼저 복구한 뒤 근본 원인을 고친다.

장애 보고서 항목

항목	내용
요약	무엇이 얼마나 영향을 받았나 한두 문장
최초 탐지 시각	발생 시각과 탐지 시각이 다르면 둘 다
영향 범위	영향받은 서비스·사용자
원인	직접 원인과 그 배경
타임라인과 대응 과정	시각별로 무엇을 보고 무엇을 했나
해결 과정과 예방책	추적 티켓 링크 포함
관련 문서	선택

포스트모템 원칙

사건 나열이 아니라 시나리오로 쓴다. 원인이 된 작업의 배경부터, 사건들이 어떻게 이어져 장애가 됐는지를 이야기로 연결한다. 발견 경위와 대응이 늦어진 이유도 함께 적는다.
개선안을 세 갈래로 나눈다. 재발 방지, 탐지 개선, 처리 개선. 탐지와 처리도 개선 대상이라는 점을 놓치기 쉽다.
액션 아이템은 검증 가능하게. 「주의하자」 대신 테스트 추가, 체크리스트 도입, 알람 임계값 설정, 대시보드 구축, 작업 사전 공유처럼 끝났는지 확인할 수 있는 항목으로 쓴다.
사람 손이 덜 가는 쪽을 고른다. 사람의 주의력에 기대는 대책보다 자동화·권한 제한 같은 구조적 대책이 오래간다.
단기와 장기 과제를 나누고 장기 과제는 추적한다. 장기 과제는 비즈니스 우선순위에 밀려 사라지기 쉬우므로 별도 프로젝트로 가시화한다.

정리

장애는 개인의 잘못이 아니라 시스템의 빈틈이 드러난 사건으로 다룬다.
해결은 확산 차단이 먼저다. 롤백·기능 스위치가 바로 쓰일 수 있게 평소에 준비한다.
전파는 해결만큼 중요하고, 담당을 따로 둔다.
포스트모템의 산출물은 재발 방지·탐지·처리 세 갈래의 검증 가능한 액션 아이템이다.

버그 제보