Incident Management & Remediation

1. Overview

장애 대응과 복구, 그리고 포스트모템(Incident Management & Remediation)은 서버가 불타오르고 수만 명의 유저가 트위터에 분노를 쏟아내는 지옥 같은 실전 상황(Incident)에서, 시스템과 조직을 붕괴시키지 않고 우아하게 사태를 수습해 내는 SRE의 최전선(Frontline) 전략을 해부합니다.

학습자는 화재 경보(Pager)가 울렸을 때 당황하지 않고 지휘관(Commander)과 소방수(Responder)로 역할을 쪼개 기계처럼 대응하는 **장애 대응 지휘 체계(Incident Command System)**를 뜯어봅니다. 나아가 근본 원인(Root Cause)을 찾느라 황금 같은 시간을 버리지 않고, 트래픽 차단과 롤백(Rollback)으로 일단 "지혈(Mitigation)"부터 해버리는 무자비한 SRE의 생존 철학을 장악합니다. 마지막으로, 장애가 끝난 뒤 "누가 잘못했어?"라며 사람을 질책하는 문화를 혐오하고, "시스템이 왜 사람의 실수를 허용했는가?"를 집요하게 파고드는 **비난 없는 포스트모템(Blameless Postmortem)**의 엔지니어링 문화를 확보합니다.

2. Scope & Boundaries

In-Scope

• Incident Response (장애 대응): PagerDuty, On-call(온콜) 로테이션, MTTA (평균 인지 시간), MTTR (평균 복구 시간).
• Incident Command System (ICS): Incident Commander (지휘자), Responder (작업자), Communicator (소통자)의 철저한 롤 분리.
• Mitigation vs Resolution: 완화(Mitigation - 지혈, 롤백, 트래픽 차단)와 근본 해결(Resolution)의 우선순위.
• Blameless Postmortem: 비난 없는 사후 분석 문서화, 5 Whys (5번의 왜?), Action Item (재발 방지 대책).

Out-of-Scope

• 소스 코드 레벨의 버그 픽스: NullPointerException 등 개별 언어의 디버깅 기법 → 05-02 Compiler & Runtime 영역으로 위임 (본 문서는 시스템 롤백과 인프라 레벨의 대응에 집중).
• 자동화된 CI/CD 파이프라인: 롤백(Rollback) 버튼의 물리적 구현 → 09-02 CI/CD & DevOps 영역.

Boundaries

• Root Cause Analysis(근본 원인) vs Mitigation(지혈): 새벽 3시에 장애가 터졌을 때 "이 에러 로그가 왜 찍히는지 소스 코드를 뜯어보자"라고 덤비는 것은 주니어들의 가장 흔하고 치명적인 실수입니다. 수백만 원의 매출이 초당 날아가는 상황에서 근본 원인(Root Cause)은 중요하지 않습니다. "방금 배포한 코드가 의심되니 일단 과거 버전으로 롤백(Rollback) 때려!" 혹은 "서울 서버가 이상하니 트래픽을 당장 도쿄로 돌려(Failover)!"라고 일단 유저의 피를 멈추게(Mitigation) 하는 것이 장애 대응의 유일한 제1원칙임을 명확히 선을 긋습니다.

3. Counterexample

• 영웅주의(Hero Culture)의 폭망: A 개발자는 천재입니다. 장애가 터지면 항상 혼자 소스코드를 고쳐서 1시간 만에 서버를 살려냅니다. 모두가 그를 찬양하지만 구글 SRE는 이를 '가장 최악의 안티 패턴'으로 꼽습니다. 지휘 체계(ICS)와 매뉴얼(Runbook) 없이 개인의 뇌에 의존하는 시스템은, A 개발자가 휴가를 가거나 퇴사하는 날 전체 서비스의 파산으로 돌아옵니다. 장애 대응은 개인이 아니라 조직과 매뉴얼이 기계처럼 움직여야 합니다.
• 마녀사냥 포스트모템 (Blameful Culture): 신입 개발자가 DB 테이블을 실수로 Drop 했습니다. 회사는 장애 회의를 열어 신입을 엄청나게 질책(Blame)하고 시말서를 썼습니다. 결과적으로 팀원들은 앞으로 실수를 숨기고(Cover-up), 장애를 늦게 보고하며, 위험한 도전(혁신)을 극도로 꺼리게 되었습니다. "왜 시스템이 신입사원이 Production DB를 Drop 하도록 권한을 열어두고 안전망을 치지 않았는가?"를 묻지 않는 조직은 똑같은 장애를 무한 반복하게 됩니다.

4. Prerequisites

• SLO와 에러 버젯 (Basic): 장애의 정의와 기준선. (07-05-01 Observability & SLI-SLO)
• 버전 관리 및 배포 (Basic): Git Revert와 롤백 개념. (09-01 Source Control)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 새벽 3시의 사이렌, 온콜과 트리아지 (The On-call & Triage)

• Why to Learn: 장애 알람이 울렸을 때 당황하여 이 사람 저 사람 깨우는 혼란을 막고, 정해진 매뉴얼(Runbook)에 따라 심각도를 기계적으로 분류하기 위함입니다.
• What to Learn:
  • Concepts: On-call Rotation (온콜 대기), PagerDuty / OpsGenie, Runbook (장애 조치 매뉴얼), Triage (심각도 분류 - SEV1 ~ SEV5), MTTA (Mean Time To Acknowledge).
  • Skills: 노이즈 알람을 무시하고 실제 SLI 위반(유저 고통)에만 Pager를 울리게 하는 설정.
• How to Learn:
  • 1단계: 온콜(On-call): 24시간 모니터링을 위해 엔지니어들이 돌아가며 삐삐(Pager)를 차는 문화를 해부합니다. 무의미한 CPU 알람에 잠을 깨면 온콜 엔지니어가 번아웃되므로, 진짜 유저 장애에만 알람이 울리도록 세팅하는 것이 생명입니다.
  • 2단계: 트리아지(Triage): 응급실처럼 장애의 등급을 나눕니다. SEV1(결제 불가 - 전사 총동원), SEV2(검색 딜레이 - 해당 팀 대응), SEV3(내부 어드민 에러 - 내일 출근해서 수정). 모든 알람에 똑같이 긴장하지 않는 멘탈 관리법을 뜯어봅니다.
• Implement: Pager 알람 Triage 시뮬레이터 로직. Event(type, user_impact_ratio). user_impact_ratio > 10% 이면 [SEV1: Wake up CEO], > 1% 이면 [SEV2: Wake up Team], 그 미만이면 [SEV3: Slack message only] 로 터미널에 액션을 라우팅하는 스크립트.

Recommended

Core Topic 02: 군대식 지휘 체계, ICS (Incident Command System)

• Why to Learn: 장애 상황에서 천재 개발자 혼자 키보드를 두들기게 놔두면 파국으로 치닫음을 인지하고, 철저히 통제된 역할 분담으로 혼란을 압살(Crush)하기 위함입니다.
• What to Learn:
  • Concepts: Incident Command System (ICS), Incident Commander (IC - 통제관), Responder (작업자), Communicator (소통자), War Room (상황실).
  • Skills: 장애 상황실(Slack Channel / Zoom) 개설 및 룰(Rule) 통제 (IC의 승인 없는 작업 금지).
• How to Learn:
  • 1단계: 영웅주의의 종말: 장애가 나자 A, B 개발자가 각자 터미널을 열고 DB를 조작하다가 서로의 설정이 충돌해 서버를 아예 날려 먹는 최악의 호러쇼를 해부합니다.
  • 2단계: 역할의 극단적 분리: IC(지휘자)는 절대 코드를 만지지 않고 전체 판만 봅니다. Responder(작업자)는 IC의 승인이 떨어져야만 커맨드를 칩니다. Communicator(소통자)는 CS팀과 임원진에게 10분 단위로 상황을 보고하여, 개발자들이 코딩에만 집중하게 막아주는 완벽한 방어벽을 뜯어봅니다.
• Implement: Slack 봇 모사 콘솔 챗봇. /incident start 입력 시 [WAR ROOM CREATED] 선언. "DB를 리부트할까요?"라는 입력에, 지휘관 역할(IC)로 지정된 계정이 승인(Approve)하기 전까지는 [BLOCKED: IC Approval Required]로 강제 방어하는 프로세스 렌더링.

Practical

Core Topic 03: 진단은 나중에, 일단 지혈하라 (Mitigation First)

• Why to Learn: 서버가 초당 수천만 원의 손실을 내며 불타고 있을 때, "왜 불이 났지?"를 분석(Root Cause)하는 바보 짓을 멈추고 일단 불부터 끄는(Mitigation) 야만적인 생존 능력을 갖추기 위함입니다.
• What to Learn:
  • Concepts: Mitigation (완화/지혈), Resolution (근본 해결), MTTR (Mean Time To Recovery), Rollback (롤백), Failover (장애 우회), Traffic Shedding (트래픽 버리기).
  • Skills: Runbook에 기반한 3대 지혈기(롤백, 페일오버, 서킷 브레이커) 즉시 발동 결단.
• How to Learn:
  • 1단계: 시간의 가치: 장애 10분째. 로그를 까보니 특정 쿼리에서 데드락이 납니다. "아! 쿼리 수정해서 빌드 다시 할게요(30분 소요)" → Resolution(해결)에 집착한 하수입니다.
  • 2단계: 무자비한 지혈: "방금 배포한 버전에 데드락 쿼리가 있군. 분석은 나중에 하고 당장 어제 버전으로 롤백해(1분 소요)!" 일단 유저 서비스부터 정상화(Mitigation) 시켜놓고, 개발자는 커피 한 잔 마신 뒤 여유롭게 로컬에서 원인을 분석하는 SRE의 진정한 냉혹함을 뜯어봅니다.
• Implement: MTTR 최소화 의사결정 게임(CLI). [장애 발생: CPU 100%]. 선택지: A) 로그 분석 시작(시간 +20분, 복구 실패 확률 50%), B) 30분 전 스냅샷 롤백(시간 +2분, 무조건 복구됨). 유저가 A를 선택 시 [회사 파산] 메시지, B를 선택 시 [MTTR 2분 달성: Mitigation 완료] 출력하는 인터랙티브 스크립트.

Advanced

Core Topic 04: 사람을 탓하지 마라, 포스트모템 (Blameless Postmortem)

• Why to Learn: 장애를 낸 개발자를 해고(Blame)해 봤자 다음 달에 다른 개발자가 똑같은 장애를 내는 무한 루프를 끊고, 인프라의 시스템적 구멍(Hole)을 영원히 메워버리기 위함입니다.
• What to Learn:
  • Concepts: Blameless Postmortem (비난 없는 사후 분석), 5 Whys (다섯 번의 왜), Action Item (재발 방지 대책), Single Point of Failure, Psychological Safety (심리적 안전감).
  • Skills: 인간의 실수(Human Error)를 시스템의 결함(System Flaw)으로 치환하는 포스트모템 문서 작성.
• How to Learn:
  • 1단계: 마녀사냥의 부작용: "김 사원이 설정을 잘못 입력해서 장애가 남. 김 사원 징계." 끝. 이렇게 끝나면 엔지니어들은 다음부터 실수를 교묘하게 숨기거나 로직 변경을 두려워하게 되는 최악의 문화적 퇴보를 해부합니다.
  • 2단계: 5 Whys와 시스템 개선: 1) 왜 터졌나? "잘못된 설정 배포". 2) 왜 배포됐나? "검증 툴이 없어서". 3) 왜 검증 툴이 없나? "우선순위에서 밀려서". "그렇다면 김 사원이 아니라, 잘못된 값이 입력되어도 통과시켜 준 우리의 배포 파이프라인(시스템)이 쓰레기였다!"라는 결론 도출 후 파이프라인 룰을 추가하는(Action Item) 완벽한 엔지니어링 문화를 뜯어봅니다.
• Implement: 포스트모템 문서 생성기(템플릿 파서). 장애 타임라인 배열(Timeline), 근본 원인(Root Cause), 5 Whys, Action Items(Jira 티켓 매핑)의 JSON 데이터를 넣으면 깔끔한 Markdown 포맷의 사후 분석 보고서를 터미널에 예쁘게 렌더링해 내는 스크립트.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - System Reliability and Incident Management
• [P5] SFIA - Incident Management (USUP) - Major Incident Response

Secondary

• [Site Reliability Engineering: How Google Runs Production Systems] - Incident Response and Postmortem Culture
• [The Practice of Cloud System Administration] Thomas A. Limoncelli - Emergency Response

Industry

• [PagerDuty Incident Response Documentation] - How PagerDuty responds to major incidents
• [Atlassian Incident Management Handbook] - Incident roles, responsibilities, and postmortems

9. Final Checklist

Primary

• 새벽에 알람(Pager)이 울렸을 때 모든 엔지니어가 다 깨서 덤벼드는 대신, 온콜 로테이션(On-call)과 트리아지(Triage) 심각도 분류를 통해 피로도(Fatigue)를 통제하는 매뉴얼의 중요성을 설명할 수 있는가?
• 장애 대응 체계(ICS)에서 가장 실력이 뛰어난 시니어 개발자가 상황을 총괄하는 지휘자(Incident Commander)를 맡았을 때, 절대 자신이 직접 DB 쿼리나 터미널 커맨드를 실행하면 안 되는 인지적 맹점을 증명할 수 있는가?

Secondary

• 코드 배포 후 즉시 에러율(SLI)이 치솟았을 때, 로그를 뜯어보며 핫픽스(Hotfix)를 준비하는 시간(Resolution)과 무조건 어제 버전으로 롤백(Rollback) 때리는 시간(Mitigation) 사이의 비즈니스 생사 결단을 논증할 수 있는가?
• 장애가 종결된 후 포스트모템 회의에서 "5 Whys" 기법을 사용할 때, 그 꼬리물기 질문의 끝이 "개발자의 부주의"로 끝나지 않고 반드시 "안전 장치 부재(System Flaw)"로 귀결되어야 하는 이유를 해부할 수 있는가?

Industry

• 클라우드 인프라가 엉켜서 롤백(Rollback)조차 불가능한 끔찍한 상태(Stateful Data 오염 등)에 빠졌을 때, 트래픽 차단(Traffic Shedding)이나 타 리전 우회(Failover)로 시간을 버는 플랜 B 아키텍처를 설계할 수 있는가?
• 회사의 모든 비난 없는 포스트모템(Blameless Postmortem) 문서 끝에 도출된 Action Item(재발 방지 대책)들이 백로그에 파묻히지 않고, 다음 스프린트 최우선 순위로 강제 배정되도록 하는 에러 버젯(Error Budget) 룰과 어떻게 결합할지 평가할 수 있는가?