On-call 운영

On-call

On-call은 서비스 장애가 발생했을 때 즉시 대응할 수 있는 당직 체계다. 24시간 365일 서비스를
운영하면 언제든 장애가 터질 수 있는데, 그때 "누가 받을 건데?"를 미리 정해두는 것이다.

개발자 한 명이 항상 대기하는 게 아니라, 팀원들이 돌아가면서 담당하는 Rotation 구조로 운영한다.

---

핵심 구성 요소

개념	설명
Rotation	팀원들이 순서대로 돌아가며 담당
Primary	1차 대응자. 알림을 가장 먼저 받는다
Secondary	Primary가 응답 없을 때 대신 받는 백업
Escalation Policy	Primary → Secondary → Manager 순서로 에스컬레이션하는 규칙

Escalation Policy가 없으면 Primary가 못 받았을 때 알림이 그냥 사라진다. 반드시 있어야 한다.

---

핵심 지표

On-call 품질을 측정하는 지표가 두 가지 있다.

지표	풀네임	의미
MTTA	Mean Time To Acknowledge	알림 발생 → 담당자가 인지할 때까지 평균 시간
MTTR	Mean Time To Resolve	알림 발생 → 완전히 해결될 때까지 평균 시간

MTTA가 길다는 건 알림을 못 받거나 늦게 확인한다는 뜻이다. MTTR이 길다는 건 인지는 했는데 해결이
느리다는 뜻이다. 둘 다 추적해야 어디서 병목인지 보인다.

---

On-call 피로

On-call 자체보다 On-call 피로(Fatigue)가 더 큰 문제다. 피로가 쌓이면 알림을 무시하거나,
번아웃이 오거나, 팀 전체 사기가 떨어진다.

주요 원인은 세 가지다.

1. 노이즈 알림
진짜 장애가 아닌데 울리는 알림. 알림이 자주 오면 "또 오겠지"라는 학습된 무기력이 생긴다. Alerting
설계를 잘못하면 여기서 막힌다.

2. 불공평한 로테이션
특정 사람만 자꾸 당직을 서거나, 야간 당직이 한쪽에 몰리면 반드시 문제가 된다. 자동화된 스케줄링
도구(PagerDuty, OpsGenie 등)를 쓰는 이유가 여기 있다.

3. 보상 없음
야간에 2시간 대응하고 아무 보상이 없으면 지속 불가능하다. 보상 체계가 없는 On-call은 팀 이탈로
이어진다.

---

Runbook

Runbook은 장애 대응 절차서다. "이 알림이 오면 이렇게 해라"를 미리 적어두는 것이다.

On-call 담당자가 해당 서비스를 잘 모르는 경우가 있다. 로테이션으로 돌아가다 보면 내 영역이 아닌
서비스 당직을 서야 할 수도 있기 때문이다. Runbook이 잘 정비돼 있으면 모르는 서비스도 절차대로
대응할 수 있다.

좋은 Runbook의 조건:

• 알림 이름과 1:1로 매핑되어 있다

• 진단 명령어가 복붙 가능한 형태로 있다

• "이 단계에서 모르겠으면 누구한테 연락해라"가 명시되어 있다

  ---

  정리

  On-call은 그냥 폰 들고 대기하는 게 아니다. Rotation, Escalation Policy, Runbook이 제대로 갖춰져야
  지속 가능한 운영이 된다. MTTA/MTTR로 측정하고, 피로 원인을 주기적으로 점검하는 게 SRE의
  역할이다.

  결국 On-call을 잘한다는 건 "장애를 빨리 끄는 것"이 아니라 "장애가 와도 팀이 지치지 않는 구조를
  만드는 것"이다.