On-Call 관리 및 에스컬레이션 정책

On-call 관리는 사건 발생 시 적절한 엔지니어에게 신속하게 연락하고, 해결 중 의사소통을 조율하며, 해결 후 피로도를 관리하는 운영 규율이다. 2026년 기준, On-call이 부실하면 MTTR이 3-5배 악화된다.

설명

“누가 지금 on-call 상태인가?”와 “이 사건을 누가 해결할 수 있나?”는 중요한 질문이다. 조직이 커질수록 답이 명확하지 않으면 사건 대응이 지연된다.

On-Call 역할 정의

1. Primary On-Call (일차 대응)

책임:

사건 감지 후 5분 내 응답
초기 진단 및 상황 파악
Slack에 상황 공유 및 팀 소집 판단
간단한 사건 직접 해결 또는 전문가 호출

로테이션: 주 1회 (1주씩 담당)

추가 보상: 주급 + 20% 또는 compensation time (회사 정책)

2. Secondary On-Call (이차 지원)

책임:

Primary가 응답 불가 또는 30분 내 진전 없을 시 자동 호출
기술 심화 지원
다른 팀 간 조율 (데이터 엔지니어 ↔ 인프라 팀)

로테이션: 주 1회 (1주씩 담당)

추가 보상: 주급 + 10%

3. Manager On-Call (관리 대응)

책임:

P1 사건 (서비스 전체 다운) → 자동 호출
의사결정 필요 (예: 고객에게 공지할 것인가?)
리소스 동원 (팀 외 지원 필요?)
장시간 사건의 에스컬레이션

로테이션: 월 1회 (1개월씩 담당)

에스컬레이션 정책 (Escalation Policy)

Level 1: 자동 Alert + 알림

Prometheus Alert fires
    ↓ (자동)
Slack #data-team 채널에 메시지
    ↓
Alert 요약: "airflow_task_fail_rate > 50% for 5 min"
Resource: "dag-customer-etl"
Severity: "P2"
Runbook: "customer-etl-failure"

[Acknowledge]  [Investigate]  [Resolve]

누구를 위한: 업무 시간 중 경미한 사건

응답 목표: 10분

Level 2: Primary On-Call 페이지

Level 1 Alert로부터 10분 경과 + Slack ACK 없음
    ↓
Primary On-Call 호출 (SMS + Phone Call)
    ↓
Escalation details:
- Incident ID: INC-2026-04-25-001
- Service: data-pipeline
- Severity: P2
- Recent context: "Deployment 10 min ago"

누구를 위한: 중간 심각도 + 업무 시간 외

응답 목표: 5분 (SMS), 15분 (전화)

Level 3: Secondary On-Call 에스컬레이션

Primary On-Call이 응답 불가 또는 30분 진전 없음
    ↓
Secondary On-Call 호출 (SMS + Phone Call)
    ↓
Primary와 자동 병렬 호출 (회선 분할)

누구를 위한: 복잡한 사건 또는 기술 심화 필요

응답 목표: 10분

Level 4: Manager Escalation

사건 60분 경과 + 아직 해결 안 됨
    또는
P1 사건 (서비스 전체 다운)
    ↓
Manager On-Call 자동 호출
    ↓
의사결정:
- 고객 공지할 것인가?
- 다른 팀 동원할 것인가? (인프라, 보안)
- 롤백할 것인가?

누구를 위한: P1 또는 복합 사건

응답 목표: 5분

On-Call 로테이션 관리

로테이션 구조 (팀 크기: 5명)

주 1: Alice (Primary), Bob (Secondary)
주 2: Charlie (Primary), David (Secondary)
주 3: Eve (Primary), Alice (Secondary)
주 4: Bob (Primary), Charlie (Secondary)
주 5: David (Primary), Eve (Secondary)

특수 경우:

휴가 중: 다른 팀원이 대체
사건 중 피로: “피로 면제” 사용 (다음 로테이션 건너뜀)
경험 부족: 경험자와 함께 페어로 온콜 (teaching rotation)

페어 온콜 (Pair On-Call)

신규 팀원 또는 복잡한 시스템:

Primary On-Call (경험자) + Secondary On-Call (신규)
    ↓
신규는 경험자를 따라다니며 학습
    ↓
피드백 세션: "뭐를 배웠나? 뭐가 어려웠나?"
    ↓
2-3회 페어 후 독립 온콜

온콜 피로도 관리 (On-Call Burnout Prevention)

1. 충분한 보상

Primary On-Call: 주급 + 20% 추가 또는 compensationtime (company choice)
Secondary On-Call: 주급 + 10%
Manager On-Call: 주급 + 30% 또는 월 2일 추가 휴가

2. 사건 후 회복 시간 (Post-Incident Recovery)

사건 직후 스트레스를 관리:

긴급 사건 (2시간 이상 대응)
    ↓
다음날 업무 감량 (1일 휴무 또는 반일 근무)

3. 온콜 경험 피드백 루프

매달 온콜 담당자와 회의:

1:1 Meeting (Manager ↔ On-Call)

Q: "이번 달 어떻게 지냈나?"
A: "사건은 3건 있었고, 새벽 3시 호출이 힘들었어."

Q: "뭐가 잘 됐나?"
A: "급속한 복구, 좋은 Runbook이 있었어."

Q: "뭐가 개선될 수 있을까?"
A: "Alert 정확성 개선, 그럼 false positive 줄어들 듯."

→ Action items:
   - Alert tuning (높은 우선순위)
   - Runbook 개선 (중간)

4. 온콜 회전 필수 (No single point of failure)

❌ 나쁜 패턴:
Bob이 3달 연속 온콜 (복잡한 시스템 담당)
    → Bob이 나가면 아무도 할 수 없음
    → Bob이 피로도로 실수 → 사건 심화

✅ 좋은 패턴:
모든 엔지니어가 2-4주에 한 번 온콜
    → 지식 분산
    → 평등한 피로도
    → 신규도 빠르게 배움

도구 통합 (PagerDuty, Rootly, Opsgenie)

PagerDuty

# PagerDuty 에스컬레이션 정책
escalation_policies:
  - name: "Data Platform"
    level_1:
      - user: alice
        delay: 0  # 즉시
      - user: bob
        delay: 15m  # Alice 응답 없으면 15분 후 Bob
    level_2:
      - user: charlie
        delay: 30m  # 둘 다 응답 없으면 30분 후 Charlie
    level_3:
      - user: manager
        delay: 60m  # 1시간 후 Manager

Rootly

# Rootly 에스컬레이션 정책
escalations:
  - name: "Data ETL Failure"
    steps:
      - delay: 0
        notify: slack_channel #data-team
        message: "ETL failure detected in customer-etl"
      - delay: 10m
        notify: sms
        targets: [alice_phone, bob_phone]
        message: "ETL still failing, on-call needed"
      - delay: 25m
        notify: phone_call
        targets: [alice, bob]
        message: "Critical escalation"

온콜 숙련도 곡선 (Ramp-Up Timeline)

기간	목표	지원
주 1-2	간단한 alert 이해	Senior pair로 모든 사건 함께 대응
주 3-4	자주 나타나는 사건 독립 해결	Slack에서 실시간 멘토링
주 5-8	P2 사건까지 독립 대응, P1은 도움 요청	On-demand 리뷰
주 9+	모든 사건 독립 대응	Post-incident review 참여

반패턴

한 사람만 가능한 시스템: Bob만 알면 Bob이 나가면 끝 → 지식 공유 강제, 페어 온콜 실시
보상 없는 온콜: “월급에 포함된 책임”이라고 생각 → 피로도 증가, 이직 위험
에스컬레이션 정책 부재: “누가 호출해야 하지?” 현장 판단 → Runbook 필수, 자동 에스컬레이션 구성
사건 후 피드백 무시: 같은 실수 반복 → Postmortem 필수, Action items 추적

JYP Garden

탐색기

On-Call 관리 및 에스컬레이션 정책

On-Call 관리 및 에스컬레이션 정책

설명

On-Call 역할 정의

1. Primary On-Call (일차 대응)

2. Secondary On-Call (이차 지원)

3. Manager On-Call (관리 대응)

에스컬레이션 정책 (Escalation Policy)

Level 1: 자동 Alert + 알림

Level 2: Primary On-Call 페이지

Level 3: Secondary On-Call 에스컬레이션

Level 4: Manager Escalation

On-Call 로테이션 관리

로테이션 구조 (팀 크기: 5명)

페어 온콜 (Pair On-Call)

온콜 피로도 관리 (On-Call Burnout Prevention)

1. 충분한 보상

2. 사건 후 회복 시간 (Post-Incident Recovery)

3. 온콜 경험 피드백 루프

4. 온콜 회전 필수 (No single point of failure)

도구 통합 (PagerDuty, Rootly, Opsgenie)

PagerDuty

Rootly

온콜 숙련도 곡선 (Ramp-Up Timeline)

반패턴

관련 개념

그래프 뷰

목차