사전 온콜
개념

온콜

gabury1고친 사람 github-actions[bot]

온콜은 서비스 장애를 곧바로 맡기로 미리 정해 둔 당번입니다. 업무 시간이 끝난 뒤에 난 장애도 정해진 사람에게 호출이 갑니다. 그래서 밤에 난 장애가 아침까지 방치되지 않습니다.

쉽고 빠른 이해

온콜은 장애가 났을 때 연락을 받기로 정해 둔 당번입니다. 새벽 세 시에 결제가 멎으면 이번 주 당번의 휴대폰이 울립니다.

이게 없으면 장애를 누가 맡을지 매번 그때 정해야 합니다. 서로 미루는 사이에 시간이 흐릅니다. 아무도 못 챙긴 채 아침을 맞기도 합니다.

어떻게 도는가:

  1. 누가 언제 당번인지를 미리 표로 짜 둡니다
  2. 감시하던 값이 조건을 벗어나면 그때의 당번에게 호출이 갑니다
  3. 당번이 정해진 시간 안에 응답하지 않으면 다음 사람에게 넘어갑니다

대가는 당번이 그 기간 동안 생활을 묶어 둬야 한다는 것입니다. 호출이 잦으면 잠을 못 잡니다. 고칠 것 없는 호출이 쌓이면 진짜 호출까지 흘려보내게 됩니다.

상세

이 절은 온콜이 무엇을 미리 정하는 제도인지부터 봅니다. 그다음 호출이 당번에게 닿는 경로와 당번표를 짜는 방식을 봅니다. 마지막으로 당번이 쥐고 있어야 하는 것과 이 제도가 사람을 갉는 대목을 봅니다.

온콜은 그 당번 한 사람을 가리키기도 하고, 당번을 돌리는 제도 전체를 가리키기도 합니다. 이 글에서는 사람을 말할 때 당번, 제도를 말할 때 온콜이라고 부릅니다.

미리 정하는 세 가지

온콜은 장애가 났을 때 누가 연락을 받을지를 미리 정해 두는 제도입니다. 원래는 의사나 소방처럼 근무 시간이 아니어도 부르면 나오기로 한 당번을 가리키는 말입니다. 서비스 운영에서도 같은 뜻으로 씁니다.

미리 정하는 것은 셋입니다. 누가 받는지, 언제부터 언제까지 받는지, 그리고 그 사람에게 연락이 닿지 않으면 다음에 누구에게 가는지입니다.

미리 정해 두지 않으면 장애가 난 순간에 사람을 찾는 일부터 시작해야 합니다. 새벽에는 누가 깨어 있는지 모릅니다. 연락이 닿아도 그 사람에게 서버를 만질 권한이 없을 수 있습니다. 당번을 정해 두면 사람을 찾는 이 단계가 통째로 사라집니다.

고장을 알아챈 뒤 사람이 손을 대기까지 걸리는 시간은 평균 복구 시간을 이루는 한 구간입니다. 온콜은 그 구간을 짧게 잡아 두려고 세우는 장치입니다.

모든 서비스가 당번을 두지는 않습니다. 밤에 멈춰도 다음 날 아침에 고치면 되는 서비스라면, 사람을 묶어 두는 비용이 멎어 있는 동안의 손해보다 큽니다. 온콜은 멈춘 시간이 그대로 손해로 쌓이는 서비스에 둡니다.

호출이 당번에게 닿는 경로

호출은 사람이 직접 거는 것이 아니라 감시 체계에서 자동으로 옵니다. 값을 재는 모니터링이 조건을 벗어난 값을 찾습니다.

조건을 벗어났다는 판정 자체가 경보입니다. 그 경보를 그때의 당번에게 실어 나르는 것이 알림입니다. 당번에게 나가는 이 알림을 이 글에서는 호출이라고 부릅니다.

당번이 정해진 시간 안에 응답하지 않으면 호출은 거기서 멈추지 않고 다음 사람에게 넘어갑니다. 이렇게 넘기는 규칙이 에스컬레이션입니다.

flowchart TD
    A["모니터링이 값을 잰다"] --> B["조건을 벗어났나"]
    B -->|"조건 안"| A
    B -->|"조건 밖"| C["경보를 올린다"]
    C --> G["알림으로 당번에게 내보낸다"]
    G --> D["정해진 시간 안에 응답했나"]
    D -->|"응답"| E["당번이 손을 대기 시작한다"]
    D -->|"무응답"| F["다음 사람에게 넘긴다"]
    F --> D

여기서 응답은 고쳤다는 뜻이 아니라 호출을 받았다는 뜻입니다. 이 신호가 있어야 호출 체계가 다음 사람을 부르는 것을 멈춥니다.

당번표를 짜는 방식

누가 언제 당번인지는 표로 미리 적어 둡니다. 교대 주기와 겹침을 어떻게 잡느냐에 따라 표의 모양이 갈립니다.

방식 어떻게 돌리나 어디가 아픈가
주 단위 교대 한 사람이 일주일을 맡고 다음 주에 넘긴다 그 주에 호출이 몰리면 한 사람이 다 받는다
1차·2차 이중 당번 1차가 먼저 받고, 응답이 없거나 손이 모자라면 2차가 받는다 대기하는 사람이 둘로 늘어난다
시간대별 분산 서로 다른 시간대의 팀이 자기 낮 시간에만 받는다 팀이 여러 시간대에 흩어져 있어야 쓸 수 있다

어느 방식이든 당번이 바뀌는 때에 인수인계가 필요합니다. 아직 안 끝난 장애가 무엇인지, 그리고 대응 중이라 잠시 울리지 않게 꺼 둔 경보가 무엇인지를 넘겨야 합니다. 넘기지 않으면 다음 당번은 같은 것을 처음부터 다시 판단하게 됩니다.

당번이 쥐고 있어야 하는 것

당번으로 정해졌다는 말은 연락을 받는다는 뜻만이 아닙니다. 받은 뒤에 실제로 손을 댈 수 있어야 당번입니다. 대개 셋이 필요합니다.

  • 대응 절차를 적어 둔 문서 — 장애 유형마다 무엇을 먼저 확인하고 무엇을 만지는지 적어 둔 것을 런북이라고 부릅니다
  • 시스템을 고칠 권한 — 재시작과 설정 변경, 배포 되돌리기를 그때 누구의 승인을 받지 않고도 할 수 있어야 합니다
  • 상태를 볼 수 있는 화면과 기록 — 대시보드와 로그에 새벽에도 들어갈 수 있어야 합니다

셋 중 하나라도 빠지면 당번은 호출을 받고도 결국 다른 사람을 깨우게 됩니다. 그러면 미리 정해 둔 순서가 아니라 그때그때 아는 사람을 찾는 일로 돌아갑니다.

사람을 갉는 대목

온콜은 사람의 시간을 담보로 서 있는 제도입니다. 당번인 동안에는 연락이 닿는 곳에 머물러야 합니다. 잠든 사이에도 깨어날 준비를 해 둬야 합니다.

고칠 것이 없는데 울리는 호출이 쌓이면 이 담보가 빨리 닳습니다. 그런 호출을 여러 번 받으면 사람은 호출 자체를 덜 믿게 됩니다. 진짜 호출에도 늦게 일어납니다. 이 상태를 알림 피로라고 부릅니다.

그래서 온콜을 굴리는 팀은 한 번의 당번 동안 받은 호출 건수를 세어 둡니다. 그 수가 견딜 만한 선을 넘으면 당번을 더 세우는 쪽이 아니라 호출을 내는 조건을 손보는 쪽으로 갑니다. 사람이 손을 대지 않아도 되는 호출은 자동 처리로 내리거나 아예 끕니다.

장애가 끝난 뒤에는 사후 분석을 열어 그 호출이 왜 사람을 깨워야 했는지를 다시 봅니다.

관련 항목

온콜 당번이 거치는 사고 대응 단계

탐지 · 사고 대응 · 완화 · 사후 분석 · 사고 지휘 체계 · 근본 원인

온콜 호출을 만들어 내고 넘기는 규칙

모니터링 · 알림 · 경보 · 에스컬레이션 · 심각도 · 알림 라우팅

온콜 당번이 대응에 쓰는 도구와 문서

런북 · 대시보드 · 관측성 · 로그 · 자동화 · 호출기

온콜 부담을 재는 지표

평균 복구 시간 · 평균 고장 시간 · 서비스 수준 목표 · 오류 예산 · 골든 시그널

온콜이 사람에게 남기는 부담

알림 피로 · 잡음 · 헛호출 · 번아웃

온콜을 굴리는 조직과 방식

인프라와 SRE · 데브옵스 · 사고 관리 · 당번표 · 교대 근무

다른 이름: on-call · oncall