Incident Management & Postmortem Culture

1. Overview

장애 관리 및 포스트모텀 문화(Incident Management & Postmortem Culture, IMP)는 시스템이 멈추는 물리적 '위기'를 하드웨어나 코드의 결함을 넘어 조직 전체의 '자산'으로 승화시키는 운영의 물리학입니다.

학습자는 장애 발생 시 당황하지 않고 복구에 집중하게 만드는 장애 대응 프로세스와 지휘 체계(Incident Commander)의 수리적 흐름을 배웁니다. 특히, "누가 실수했는가"가 아닌 "시스템의 어떤 물리적 방어선이 뚫렸는가"에 집중하는 **비난 없는 포스트모텀(Blameless Postmortem)**의 사상과 **근본 원인 분석(RCA)**의 수리적 사상을 익힙니다. 이를 통해 장애로부터 도망치는 것이 아니라, 장애를 딛고 더 단단한 아키텍처를 세우는 하이엔드 신뢰성 운영 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Incident Lifecycle: 감지, 수습, 복구, 분석의 물리적 단계
• Incident Command System (ICS): 지휘자, 통신 담당, 실행 담당의 역할 분리 물리학
• Blameless Postmortem Principles: 심리적 안전성 확보와 시스템적 원인 추적
• Root Cause Analysis (RCA): 5 Whys, 물고기뼈 다이어그램 기반의 수리적 인과 추론
• Corrective Action Tracking: 장애 재발 방지를 위한 하드웨어/소프트웨어 개선 항목 관리

Out-of-Scope

• 서비스 데스크(Help Desk)의 고객 응대 스크립트 (비즈니스 관리 영역으로 위임)
• 구체적인 서버 모니터링 도구의 활용 상세 (07-05-02 영역에서 분담)

Boundaries

• IMP vs. Disaster Recovery: DR(07-03-04)이 '도시 단위 소실 시의 인프라 전환'에 집중한다면, IMP는 '일상적 장애 처리와 그 후에 따르는 조직적 학습'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "장애 보고서 쓰기"라 설명하는 것은 IMP 학습이 아닙니다. 왜 **비난(Blame)**이 섞인 보고서가 장애의 진짜 원인을 물리적으로 은폐하게 만들어 시스템을 더 위험하게 만드는지 수리 증명할 수 있어야 하며, 재발 방지 대책이 "주의하겠다" 같은 추상적 결론이 아닌 "어떤 하드웨어 설정을 물리적으로 강제하겠다"라는 실질적 조치로 연결되지 못한다면 IMP의 본질을 이해하지 못한 것입니다.

4. Prerequisites

• Monitoring, Observability & Distributed Tracing (Basic): 장애 감지 도구 이해가 필수입니다. (07-05-02 MOD)
• SLIs, SLOs & Error Budgets (Recommended): 장애 심각도 판단 기준 이해가 권장됩니다. (07-05-01 SSE)

5. Learning Map

1. The Alarm: 시스템이 내뱉는 비명(Alert)을 듣고 즉시 비상 연락망(On-call)을 가동합니다.
2. Stopping the Bleed: 원인을 알기 전에, 일단 서비스가 돌아가게 만드는 물리적 응급처치를 수행합니다.
3. The Autopsy: 조용해진 현장에서 무슨 일이 벌어졌는지 기록(Logs)과 데이터로 수리적 시사점을 찾습니다.
4. Resilient DNA: 분석 결과를 아키텍처에 주입하여, 똑같은 물리적 충격에는 다시는 구멍 나지 않는 방어선을 완성합니다.

6. Learning Topics

Basic

Core: 장애 대응 4단계 수순 (Incident Lifecycle)

• Why to Learn: 골든 타임을 놓치지 않고 사용자 피해를 물리적으로 최소화하기 위해서입니다.
• What to Learn:
  • Triage: 장애의 심각도를 보고 인력을 얼마나 투입할지 수리적 판단
  • Stabilization: 백업 장비 가동, 트래픽 차단 등 물리적 응급복구
  • Communication: 내부 이해관계자와 유저에게 현재 물리 상황 투명하게 공지
• How to Learn:
  • 모의 장애 상황을 부여받고, 5분 내에 상황 전파 및 지휘 체계를 구성하는 훈련 실습
  • 장애 시간이 지날수록 비즈니스 손실액($Loss$)이 어떻게 하드웨어적으로 누적되는지 산출
• Implement: 장애 발생 시 등록된 슬랙 채널로 긴급 호출을 쏘는 AlertDispatcher

Recommended

Core: 근본 원인 분석과 수리적 추론 (RCA Mechanics)

• Why to Learn: 겉으로 드러난 현상(Symptom)이 아닌, 숨어있는 하드웨어적 병목(Cause)을 뿌리 뽑기 위함입니다.
• What to Learn:
  • The 5 Whys: "왜?"를 반복하여 물리적 연쇄 작용의 끝에 도달하는 기법
  • Proportional Response: 장애 규모에 맞는 복구 하드웨어 리소스 투입 비율 산출
  • Latent Defects: 평상시엔 보이지 않다가 특정 부하에서 터지는 물리적 결함 탐색
• How to Learn:
  • 과거의 실제 장애 사례(예: AWS 장애)를 가져와 5 Whys 분석을 직접 수행해 보는 실습
  • 분석 보고서에서 '사람의 실수'로 적힌 부분을 '시스템의 결함'으로 물리적 치환 시연
• Implement: 장애 원인들을 카테고리별로 분류하고 재발 빈도를 집계하는 IncidentAnalyzer

Practical

Core: 비난 없는 포스트모텀 문화 (Blameless Culture)

• Why to Learn: 실패를 숨기지 않는 문화를 만들어, 더 큰 물리적 재앙을 미리 방어하기 위해서입니다.
• What to Learn:
  • Psychological Safety: 실수자가 비난받지 않아야 진실(Data)이 공유된다는 수리 철학
  • Postmortem Template: 시간대별 기록, 영향도, 근본 원인, 조치 사항의 물리적 구조
  • Action Items: "교육 강화"가 아닌 "코드 리뷰 자동화", "배포 가드레일 설치" 등의 수리적 실천
• How to Learn:
  • 가상의 실패 사례를 바탕으로 비난 없이 '시스템적 개선안'만 담긴 포스트모텀 보고서 작성 실습
  • 포스트모텀 결과가 실제 인프라 변경(IAC)으로 이어지는 물리적 루프 확인
• Implement: 장애 기록을 입력하면 표준 포스트모텀 템플릿으로 변환해주는 ReportGenerator

Advanced

Core: 운영 성숙도 측정과 지식 자산화 (Operations Asset)

• Why to Learn: 장애를 겪을수록 운영 팀의 역량이 수치적으로 향상되게 만들기 위함입니다.
• What to Learn:
  • MTTD/MTTR: 장애 감지(Detection) 및 복구(resolution)까지 걸리는 물리 시간 지표 수립
  • Operational Load: 수동 복구(Toil)가 전체 하드웨어 운영 리소스에서 차지하는 수리적 비중
  • Game Days: 가상 장애를 내고 대응 역량을 물리적으로 테스트하는 훈련 설계
• How to Learn:
  • 지난 1년간의 장애 데이터를 모아 MTT* 지표의 개선 추이를 시각화 실습
  • 'Toil(재کر업)'이 개발 속도를 얼마나 물리적으로 늦추는지 기회비용 산출
• Implement: 팀 내 온콜(On-call) 성과와 장애 처리 효율을 지표화하는 OperationsScorecard

7. Terminology

8. References

Primary

• [P5] SFIA v9 - IT Infrastructure (IT operations / Incident management) — Competency requirements.
• [P2] SWEBOK v4.0 - Software Maintenance / Maintenance Process (Problem handling) — Structural context.

Secondary

• [Site Reliability Engineering (SRE Book)] Google — Chapters on Incident Management and Postmortems.
• [The Field Guide to Understanding 'Human Error'] Sidney Dekker — Foundational for blameless culture.

Industry

• [Atlassian: Incident Management Handbook] — Practical industry standard workflows.
• [PagerDuty: Training for Postmortems] — Interactive learning resources.

9. Final Checklist

Primary

• '장애 수습(Stabilization)' 단계와 '완전 복구(Permanent Fix)' 단계의 물리적 차이를 명확히 구분하여 설명 가능한가? (P5)
• '비난 없는 포스트모텀'이 왜 조직의 하드웨어 운영 데이터의 신뢰도를 높이는지 수리적으로 논증할 수 있는 가? (P2)

Secondary

• '5 Whys' 기법을 실제 시스템 장애 시나리오에 적용하여, 코드 레벨의 버그 배후에 숨은 '설계 결함'을 짚어낼 수 있는 가?
• **MTTR(복구 시간)**을 단축하기 위해 어떤 하드웨어 자동화 장치를 우선적으로 도입해야 하는지 소통 가능한가?

Industry

• 장애 상황에서 '지휘자(Incident Commander)'가 의사결정의 병목을 어떻게 물리적으로 해결하며 팀을 이끄는지 제안할 수 있는 가? (SFIA)
• 장애 보고서에 포함된 '조치 사항(Action Items)'이 미래의 오류 예산($Error Budget$)을 지키는 하드웨어적 방패가 되는 원리를 분석할 수 있는 가?