온콜 프로세스 설계하기

온콜(On-call)은 운영 장애에 즉각 대응하기 위한 당직 체계입니다. 잘 설계된 온콜 프로세스는 **평균 복구 시간(MTTR)**을 줄이고 팀의 번아웃을 방지합니다.

온콜 설계의 핵심 원칙

1. 알림은 실행 가능한 것만

모든 경보가 온콜 담당자를 깨우면 알림 피로(Alert Fatigue)가 발생합니다.

좋은 알림: "결제 API 에러율 5% 초과 — 즉시 조치 필요"
나쁜 알림: "CPU 사용률 60% — 정보 알림"

알림 분류 기준:

등급	조건	대응
P1 (Critical)	서비스 중단, 결제 실패	즉시 깨움 (24/7)
P2 (High)	에러율 > 1%, p95 > 2초	업무 시간 내 1시간 내
P3 (Medium)	성능 저하, 경고 수준	다음 근무일 처리

2. 명확한 에스컬레이션 경로

1차: 온콜 담당자 (5분 내 응답)
  ↓ 응답 없을 경우
2차: 팀 리드 (10분 내)
  ↓ 응답 없을 경우
3차: 관리자 / 비상 연락망

3. 로테이션으로 부담 분산

• 1주일 단위 로테이션 권장
• 연속 야간 담당 최대 2주 제한
• 보상: 온콜 수당 또는 대체 휴무

알림 도구 설정

PagerDuty / OpsGenie

# 서비스 정의 예시 (PagerDuty)
service:
  name: "Payment API"
  escalation_policy: "payment-team-policy"
  alert_grouping: "intelligent"   # 유사 알림 자동 그룹화
  auto_resolve_timeout: 14400     # 4시간 후 자동 해소

Prometheus AlertManager

alertmanager.yml

route:
  group_by: ['alertname', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'pagerduty-critical'

receivers:
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: '<PAGERDUTY_KEY>'
        severity: critical

장애 대응 런북(Runbook) 작성

런북은 장애 발생 시 담당자가 따라야 할 절차를 문서화한 것입니다. 새벽 2시에 깨어난 사람도 즉시 실행할 수 있어야 합니다.

## [결제 API] 에러율 급증 런북

### 증상
- 알림: payment-api error rate > 5%
- 영향: 결제 완료 불가

### 1단계: 현황 파악 (2분)
- Grafana 대시보드 확인: grafana.internal/d/payment
- 최근 배포 여부 확인: `kubectl rollout history deployment/payment-api`

### 2단계: 빠른 완화 (5분)
- 최근 배포가 원인이면: `kubectl rollout undo deployment/payment-api`
- DB 커넥션 고갈이면: 앱 재시작 후 DBA 연락

### 3단계: 에스컬레이션
- 10분 내 해결 안 되면 팀 리드 호출

다음 단계

• RCA (Root Cause Analysis) 방법론 →
• Post-mortem 작성 가이드 →