장애 대응은 영웅 서사가 아니라 플레이북이다

1️⃣ 영웅 서사가 생기는 조직의 공통점

• 문서 없음
• 책임자 불명확
• 장애 유형 분류 안 됨
• “일단 뛰어가서 고치자”

결과:

• 특정 개인만 시스템을 앎
• 야간·휴일 호출 고정 멤버
• 같은 장애 재발
• 퇴사 순간 리스크 폭발

👉 이건 조직 실패입니다.

---

2️⃣ 플레이북의 목적

플레이북은 “잘 고치는 법”이 아니라 **“생각 안 해도 되는 상태”**를 만드는 겁니다.

• 누가?
• 언제?
• 어디서?
• 무엇을?
• 어떤 순서로?

이게 정해져 있으면
사람이 아니라 절차가 대응합니다.

---

3️⃣ 최소 장애 플레이북 구성 (현실 버전)

① 장애 분류 (5분 컷)

• 장애 유형:
  • 인프라 / 애플리케이션 / 외부 연동 / 데이터
• 영향 범위:
  • 전체 / 일부 / 특정 기능
• 심각도(S1~S3)

👉 분류 안 되면 대응도 안 됩니다.

---

② 즉시 조치 체크리스트

예시 (웹/백엔드 기준):

• 트래픽 차단 여부
• 롤백 가능 여부
• 외부 API 차단 / 우회
• 배치 중지
• 재시작 허용 여부

❗ “코드 수정”은 맨 마지막

---

③ 커뮤니케이션 룰

• 외부 공지 주체 1명
• 내부 상황 공유 채널 1개
• 기술 대응자 ≠ 커뮤니케이터

👉 이거 안 지키면 기술보다 사람이 더 망가집니다.

---

④ 사후 조치 (이게 핵심)

• 타임라인
• 근본 원인 (5 Why)
• 재발 방지 항목
• 플레이북 수정 여부

❌ “담당자 주의”는 금지
⭕ 시스템/프로세스 수정만 허용

---

4️⃣ 플레이북이 있으면 생기는 변화

• 장애 대응 속도 ↓
• 심리적 압박 ↓
• 신규 인력 투입 가능
• 휴가 중 연락 차단 가능

그리고 제일 중요:
👉 영웅이 필요 없는 조직이 됩니다.

---

5️⃣ 좋은 장애 대응 조직의 문장

“누가 있어도 같은 대응이 나온다”

이 문장이 되면
이미 SRE/플랫폼 조직 절반은 한 겁니다.