온콜과 인시던트

학습 목표

인시던트 lifecycle(detect → mitigate → resolve → learn)을 설명할 수 있다.

Severity(SEV1~4) 기준으로 page vs ticket·에스컬레이션을 구분할 수 있다.

Runbook 구조·alert annotation 연결을 설계할 수 있다.

Incident Commander·온콜·커뮤니케이션 역할을 설명할 수 있다.

Blameless postmortem에서 타임라인·근본 원인·action item을 작성할 수 있다.

문제 상황

• burn rate page — Slack에서 “뭐부터?” 없음
  • runbook URL 404·6개월 전 스크린샷
• SEV 정의 없음 — “큰 장애”마다 누구를 깨울지 감으로
• on-call 1인 — mitigate + comms + root cause 동시 → MTTR ↑
• alert 100개 동시 — 같은 원인인데 100번 ack
• 복구 후 “끝” — postmortem 없음 → 같은 장애 3주 후
• postmortem이 책임 추궁 — action item 미이행

12편까지 SLO·신호·연계는 갖췄다. page가 왔을 때 조직이 움직이는 층.

1. 인시던트 lifecycle

단계	목표	관측 도구
Detect	사용자·SLO 영향 확인	alert, burn rate
Triage	severity·scope	dashboard, RED
Mitigate	복구 우선	rollback, scale, toggle
Resolve	근본 조치·검증	deploy, fix
Learn	재발 방지	postmortem

Mitigate ≠ Fix

  checkout 5xx 100%
    → traffic shift to last good (5 min)
    → root cause debug (30 min)
    → patch (later)

• 앞서 11편 조사 playbook — triage 이후 deep dive
• 앞서 error budget 0% — incident mode (12편)

2. Severity

Level	영향	응답	page
SEV1	핵심 서비스 전면 down	즉시, 24/7	✅ all-hands
SEV2	핵심 부분·workaround 없음	15m	✅ on-call + lead
SEV3	제한 영향·workaround	business hours	ticket
SEV4	미미·cosmetic	backlog	ticket

• alert label severity: page vs ticket (12편 burn alert)
• customer-facing impact 기준 — CPU 아님
• SEV 승격/강등 — triage 15m 내 재평가

정의 예: code/severity-definitions.yaml

3. 온콜

항목	권장
로테이션	1주 primary + secondary backup
핸드오프	outgoing → incoming 15m sync
부하	primary mitigate — deep debug는 day team
도구	PagerDuty/Opsgenie — schedule + escalation
피로	page 품질 > alert 양 (8편 cardinality)

Escalation (예):
  5m  no ack  → secondary
  15m no ack  → engineering manager
  SEV1        → incident commander + comms lead

• runbook 없는 alert — 금지 (또는 ticket only)
• on-call training — 분기 game day

4. Runbook

Runbook — alert 맥락에서 첫 15분 행동을 고정한 문서.

섹션	내용
Symptoms	alert·dashboard 무엇이 보이나
Impact	SLO·어떤 기능
First steps	3~5 명령 — copy-paste
Escalate when	15m no progress → 누구
Related	dashboard URL, 11편 trace/log

# alert annotation — code/alert-runbook.yaml
annotations:
  summary: "API 5xx rate above 5% for 5m"
  runbook_url: "https://wiki.example/runbooks/api-5xx"
  dashboard: "https://grafana/d/api-red"
  severity: page

Runbook 본문 예: code/runbook-api-5xx.md

First steps 템플릿 (api 5xx)

1. Grafana RED — 어느 route·언제부터
2. 최근 deploy annotation 확인 (Platform CI/CD)
3. exemplar 또는 log trace_id → Payment hop (11편)
4. rollback 또는 traffic shift 권한 확인
5. SEV2+ → incident channel 개설

5. 역할 · 커뮤니케이션

역할	책임
Incident Commander (IC)	우선순위·결정·단일 목소리
Operations Lead	mitigate·runbook·기술
Comms Lead	내부·고객 상태 — 30m update
Scribe	타임라인·결정 기록

• IC가 디버깅까지 — 역할 분리 실패 패턴
• #incident-YYYYMMDD — noise 한곳
• status page — SEV1/2 외부 공지

6. Blameless postmortem

섹션	내용
Summary	2~3문장 — 무슨 영향
Timeline	detect → mitigate → resolve (UTC)
Root cause	기술 + 왜 detection/migrate 늦었나
What went well	runbook hit, fast rollback
Action items	owner · due date · tracking

• Blameless — “누가” not “왜 시스템이 허용했나”
• 앞서 trace_id·로그 — timeline 증거
• action item 없으면 postmortem 무의미

안티패턴
postmortem = 징계	신고 억제
action item 20개	아무것도 안 함
timeline 없음	재구성 불가
runbook 미갱신	같은 alert 같은 혼란

7. 실무 체크리스트

항목	권장
severity	문서 + alert label 일치
runbook	alert마다 URL — 분기 review
on-call	primary/secondary + escalation
incident	IC·comms SEV1/2 필수
postmortem	SEV1/2 5영업일 내
game day	분기 tabletop + runbook drill

8. 정리

• Lifecycle — mitigate 먼저, fix 나중
• Severity — impact 기준, page 남용 금지
• Runbook — alert와 1:1 — on-call 첫 15분
• Blameless postmortem — 시스템·프로세스 학습
• 다음 — K8s 관측

다음에 다룰 것

• K8s 관측
• kube-state-metrics, cAdvisor

---

해당 내용은 Site Reliability Engineering (Google), Observability Engineering (Charity Majors, Liz Fong-Jones, George Miranda), PagerDuty Incident Response Documentation 의 내용을 기반으로 합니다.