Incident Management
인시던트가 뭔가
서비스 품질이 저하되거나 중단되는 사건이다.
중요한 건 발생했을 때 표준화된 절차로 대응하는 것이다.
인시던트 대응 5단계
| 단계 | 설명 |
|---|---|
| Detection (감지) | 알림으로 장애 인지 |
| Response (대응) | 담당자 연락, 상황 파악 시작 |
| Mitigation (완화) | 임시 조치로 영향 최소화 |
| Resolution (해결) | 근본 원인 해결 |
| Postmortem (사후분석) | 재발 방지 문서 작성 |
Mitigation과 Resolution을 헷갈리기 쉬운데 이렇게 구분하면 된다.
Mitigation = 불 끄기 (서버 재시작으로 일단 복구)
Resolution = 불이 왜 났는지 찾기 (메모리 누수 코드 수정)
급할 때는 Mitigation 먼저, 그 다음 Resolution이다.
Postmortem (사후 분석)
인시던트가 끝난 후 재발을 막기 위해 작성하는 문서다.
서비스가 복구됐다고 안 쓰면 같은 장애가 반복된다.
Blameless (무비난) 원칙
사람을 비난하지 않는다. 시스템의 문제를 찾는다.
❌ 잘못된 접근
"김개발이 배포하다가 실수한 거잖아요"
✅ 올바른 접근
"왜 배포 실수가 장애로 이어질 수 있는 구조였는가?"
사람을 탓하면 다음번에 장애를 숨기게 된다.
시스템을 탓해야 다음번에 솔직하게 보고한다.
5 Whys 기법
근본 원인을 찾는 방법이다. "왜?"를 5번 반복한다.
장애: 사용자들이 로그인을 못 하고 있다
Why 1: 왜? → 인증 서버가 응답하지 않는다
Why 2: 왜? → 메모리가 꽉 찼다
Why 3: 왜? → 특정 요청이 메모리를 반환하지 않는다
Why 4: 왜? → 예외 발생 시 finally 블록이 없다
Why 5: 왜? → 예외 케이스 테스트 기준이 없었다
근본 원인: 테스트 기준 부재
표면적 원인만 보면 재시작으로 끝난다.
근본 원인까지 찾아야 재발을 막을 수 있다.
5 Whys의 핵심은 마지막 원인이 팀이 실제로 개선할 수 있는 것이어야 한다는 점이다.
"회사에 돈이 없어서" 같은 답은 Action Item으로 이어질 수 없다.
Postmortem 구성
| 항목 | 내용 |
|---|---|
| 인시던트 요약 | 언제, 얼마나, 어떤 영향 |
| 타임라인 | 시간 순서로 무슨 일이 있었는지 |
| 근본 원인 | 5 Whys로 찾은 진짜 원인 |
| Action Items | 재발 방지를 위한 구체적 조치 목록 |
Action Items는 반드시 구체적이고 추적 가능해야 한다.
❌ 나쁜 Action Item
"장애 재발 방지를 위해 노력한다"
✅ 좋은 Action Item
"예외 케이스 테스트 가이드라인 작성 (담당: 김개발, 기한: 3/20)"
