핵심 인사이트 (3줄 요약)
- 본질: 온콜(On-Call)은 지정된 엔지니어가 일정 기간 동안 프로덕션 시스템의 장애·알림에 대응하는 당번 체계이며, SRE 팀 운영의 핵심 실천이다.
- 가치: 온콜 없이는 "누가 대응할 것인가"가 불분명하여 장애 시 혼란이 발생하지만, 온콜 로테이션을 통해 책임자가 명확하고 대응 시간(MTTA)이 최소화된다.
- 판단 포인트: 온콜 부담이 과도하면 번아웃·이직이 발생하므로, 온콜 빈도(주 1회 이하)·인터럽트 비율(25% 이하)·보상 정책이 지속 가능성의 핵심이다.
Ⅰ. 개요 및 필요성
┌───────────────────────────────────────────────────────┐
│ 온콜 프로세스 │
├───────────────────────────────────────────────────────┤
│ 1. [알림 발생] — Prometheus → PagerDuty │
│ 2. [온콜 엔지니어 호출] — 5분 내 응답 │
│ 3. [초기 대응] — 상황 파악·영향 범위 판단 │
│ 4. [에스컬레이션] — 필요 시 2차 온콜·팀 호출 │
│ 5. [해결] — 장애 복구·사용자 통보 │
│ 6. [사후 분석] — Postmortem 작성 │
└───────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: 온콜은 병원의 당직 의사이다. 24시간 환자(시스템)를 돌볼 의사가 항상 있어야 하고, 로테이션으로 번갈아 근무한다.
Ⅱ. 아키텍처 및 핵심 원리
건강한 온콜 지표
| 지표 | 건강 기준 |
|---|
| 로테이션 주기 | 1~2주 |
| 야간 호출 | 주당 2회 이하 |
| 인터럽트 비율 | 25% 이하 |
| MTTA | 5분 이내 |
| Postmortem | 모든 주요 장애 후 작성 |
- 📢 섹션 요약 비유: 인터럽트 25% 이하는 "근무 시간의 75%는 프로젝트 작업, 25%만 장애 대응"이다.
Ⅲ. 비교 및 연결
| 비교 | 온콜 없음 | 온콜 있음 |
|---|
| 대응 | 혼란 (누가?) | 명확한 책임자 |
| 시간 | 느림 | MTTA 단축 |
| 번아웃 | 특정인 과부하 | 로테이션 분산 |
Ⅳ. 실무 적용 및 기술사 판단
온콜 도구
- PagerDuty: 알림 라우팅·에스컬레이션.
- OpsGenie (Atlassian): 온콜 스케줄·알림.
- Incident.io: 사고 관리 + 온콜.
- Slack/Teams: 실시간 커뮤니케이션.
Ⅴ. 기대효과 및 결론
온콜 관리는 SRE 팀의 지속 가능한 장애 대응 체계이며, Toil 감소·자동화와 함께 엔지니어 번아웃을 예방하는 핵심이다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|
| 온콜 | 장애 대응 당번 |
| PagerDuty | 알림·에스컬레이션 도구 |
| MTTA | 알림 인지 시간 |
| Postmortem | 장애 사후 분석 |
| Toil | 온콜에서 발생하는 반복 작업 |
📈 관련 키워드 및 발전 흐름도
[수동 모니터링 + 전화 (2000s)]
│
▼
[PagerDuty (2009~) — 자동 알림·에스컬레이션]
│
▼
[SRE 온콜 문화 (Google SRE Book, 2016)]
│
▼
[AIOps 자동 대응 (2020~)]
│
▼
[현재: AI Incident Response — 자동 진단·자가 치유]
👶 어린이를 위한 3줄 비유 설명
- 온콜은 병원의 당직 의사예요. 밤에도 **환자(시스템)**를 돌볼 사람이 있어야 해요.
- 한 사람만 계속 당직하면 지치니까, 번갈아(로테이션) 근무해요.
- 당직 의사 덕분에 환자가 위급할 때 빠르게 치료받을 수 있답니다!