Incident Response Runbook 설계

도입

장애 대응에서 가장 큰 비용은 기술적 복구보다 의사결정 지연이다. 런북이 있어도 실제로는 최신 상태가 아니거나 역할 분담이 모호해 현장에서 바로 쓰기 어려운 경우가 많다. 이 글은 SRE 관점에서 즉시 실행 가능한 Incident Runbook 설계 방식을 정리한다.

Incident Response Runbook 설계 커버 — Wikimedia Commons 기반 무료 이미지

문제 정의

런북이 실패하는 이유는 문서 품질이 아니라 실행성 부족이다.

탐지 기준과 심각도 분류가 모호해 대응 시작이 늦다.
핵심 명령어가 환경별로 달라 초동 조치가 지연된다.
사후 회고가 런북 업데이트로 연결되지 않아 같은 장애가 반복된다.

실무 런북은 읽는 문서가 아니라 실행 스크립트의 인덱스여야 한다. 단계별 명령, 의사결정 기준, 연락 체계를 한 화면에 담아야 한다.

핵심 개념

관점	설계 기준	검증 포인트
감지	알람 임계치 + 중복 억제	탐지 후 알림 시간
분류	sev 기준 테이블 고정	초기 오분류 비율
조치	자동화 스크립트 링크	초동 복구 소요 시간
학습	회고 후 런북 갱신	재발률 감소

좋은 런북은 상세 설명보다 빠른 실행을 돕는다. 명령어와 체크포인트를 압축해 의사결정을 앞당기는 것이 핵심이다.

코드 예시 1: 런북 단계 정의

export type RunbookStep = {
  id: string;
  objective: string;
  command: string;
  doneWhen: string;
};

export const apiLatencyRunbook: RunbookStep[] = [
  {
    id: "detect",
    objective: "지연 급증 확인",
    command: "./scripts/slo/check-latency.sh --window 5m",
    doneWhen: "p95 > 800ms 재현",
  },
  {
    id: "mitigate",
    objective: "트래픽 완화",
    command: "./scripts/release/rollback-canary.sh",
    doneWhen: "error rate < 1%",
  },
];

코드 예시 2: Sev 분류 규칙

severity_rules:
  - sev: SEV1
    condition: "checkout_success_rate < 70% for 5m"
    action: "incident channel + oncall page"
  - sev: SEV2
    condition: "api_p95 > 1200ms for 10m"
    action: "oncall page"
  - sev: SEV3
    condition: "single region degraded"
    action: "slack alert"

아키텍처 흐름

Mermaid diagram rendering...

트레이드오프

런북 표준화는 대응 속도를 높이지만 팀별 유연성을 일부 제한한다.
자동화 조치를 늘리면 사람 실수는 줄지만 잘못된 자동화가 피해를 키울 수 있다.
회고를 강제하면 학습 효과가 크지만 운영 인력 부담이 증가한다.

정리

Incident Runbook의 목표는 문서 완성도가 아니라 복구 시간 단축이다. 알림부터 회고까지 단계를 일관된 형식으로 고정하고 자동화를 연결하면 재발 비용을 줄일 수 있다.

이미지 출처

Cover: source link
License: CC BY 2.0 / Author: Alan Levine from United States
Note: Wikimedia Commons 무료 라이선스 이미지를 다운로드 후 1600px 기준 JPG로 최적화했습니다.

도입