에스컬레이션

새벽 두 시에 결제가 안 된다는 알림을 받은 당번이 가장 먼저 부딪히는 것은 기술 문제가 아니었습니다. 로그를 삼십 분 뒤져도 원인이 안 보일 때, 자고 있는 팀장을 깨워도 되는지를 혼자 정해야 했습니다. 깨웠다가 별것 아닌 일로 드러나면 민망하고, 안 깨우고 버티다 아침까지 끌면 피해가 불어납니다. 이 고민을 하는 시간만큼 복구가 밀린다는 것이 문제였습니다.

그래서 장애는 자주 같은 모양으로 커졌습니다. 당번이 혼자 두 시간을 붙들고 있다가 출근한 동료가 십 분 만에 원인을 짚는 일이 반복됐습니다. 아침 회의에서 "왜 안 불렀어요" 라는 말이 나오면 당번은 "부를 만한 일인지 몰라서요" 라고 답했습니다. 부를 기준이 글로 없었으니 양쪽 다 틀린 말이 아니었습니다.

에스컬레이션은 이 판단을 사람의 눈치에서 걷어내 규칙으로 옮긴 절차입니다. 누구를 언제 부를지를 사고가 나기 전에 정해 두고, 조건에 걸리면 부르는 것이 아니라 부르게 되어 있는 상태로 만듭니다. 새벽에 남을 깨우는 일이 개인의 결정이 아니라 약속의 이행이 되면 아무도 망설이지 않습니다.

순서는 감지·1차 대응·조건 확인·인계·해제의 다섯 단계입니다.

1. 감지 — 알림이 당번 한 사람에게 갑니다. 인시던트, 그러니까 서비스에 실제로 영향을 준 사고로 판정되는 순간부터 시계가 돕니다.
2. 1차 대응 — 당번이 약속된 시간 안에 응답하고 원인을 좁혀 봅니다. 보통 알림 뒤 5분 안에 "제가 봅니다" 라고 답하는 것까지가 여기 들어갑니다.
3. 조건 확인 — 넘길지 말지를 감이 아니라 시계와 영향 범위로 정합니다. 페이지덱은 30분 안에 원인을 좁히지 못했거나 영향받는 고객사가 다섯 곳을 넘으면 무조건 다음 사람을 부르게 해 두었습니다.
4. 인계 — 전화로 깨웁니다. 채팅에 이름을 붙여 적어 두는 것은 인계가 아닙니다. 상대가 잠든 채로 놓칠 수 있는 방법은 전부 인계로 치지 않습니다. 넘기면서 세 가지를 붙입니다. 지금 무슨 일이 벌어지고 있는지, 지금까지 무엇을 해 봤는지, 무엇을 부탁하는지입니다.
5. 해제 — 받은 사람이 "제가 받았습니다" 라고 답하기 전까지 넘긴 사람은 손을 놓지 않습니다. 이 단계가 없으면 둘 다 상대가 보고 있으려니 하는 공백이 생깁니다.

어느 단계에서 시작할지는 심각도가 정합니다. 심각도는 사고가 서비스에 끼치는 영향의 크기를 등급으로 매긴 값입니다. 전체 사용자가 저장을 못 하는 상황은 3번 단계를 건너뛰고 처음부터 여러 사람을 동시에 부릅니다.

참여자는 세 층이고, 층이 바뀌는 시점은 시간과 영향 범위가 정합니다.

1. 1차는 온콜 당번입니다. 정해진 기간에 장애 연락을 받기로 한 사람이고, 모든 알림이 여기서 시작합니다.
2. 2차는 그 영역을 잘 아는 사람입니다. 결제면 결제를 만든 개발자, 데이터베이스면 그쪽을 오래 본 사람입니다. 30분 규칙에 걸리면 여기로 갑니다.
3. 3차는 결정을 내릴 수 있는 사람입니다. 서비스를 잠시 내릴지, 고객에게 먼저 알릴지 같은 판단은 기술로 풀리지 않습니다.

옆으로 부르는 자리도 있습니다. SLA, 즉 고객과 계약으로 약속해 둔 서비스 수준이 걸린 고객사가 영향을 받으면 세일즈나 고객 담당자를 같은 시점에 부릅니다. 복구와 통보는 다른 일이고, 복구하는 사람이 통보까지 맡으면 둘 다 늦어집니다.

"30분 룰 걸렸습니다. 태오 님 호출할게요."

원인을 못 좁혔으니 규칙대로 2차를 부른다는 뜻입니다. 부르는 쪽이 미안해할 일이 아니라는 신호이기도 합니다.

"제 선에서 안 되는 게 확실해져서 규원 님께 바로 올렸어요."

기술이 아니라 결정이 필요한 상황으로 판단해 층을 건너뛰었다는 말입니다.

"아직 안 올렸고, 15분 뒤에도 못 좁히면 올리겠습니다."

지금 상태와 다음에 무엇을 할지를 함께 알리는 말입니다.

페이지덱에서는 금요일 저녁에 문서 저장이 간헐적으로 실패한 적이 있습니다. 당번이 알림을 받고 15분 만에 원인을 저장 서버 쪽으로 좁혔지만 30분이 지나도 왜 그런지는 나오지 않았습니다. 규칙대로 태오를 깨웠고, 태오가 20분 뒤에 원인을 찾았습니다. 그사이 수아는 계약상 통보 의무가 있는 고객사 세 곳에 상황을 알렸습니다.

복구된 뒤 지현은 30분이라는 숫자가 맞는지를 다시 봤습니다. 이 숫자는 고정된 값이 아니라 팀이 겪은 사고들의 기록에서 나옵니다. 최근 여섯 건 중 네 건이 20분 안에 원인이 잡혔다면 기준을 20분으로 당겨도 되고, 매번 45분씩 걸렸다면 30분 규칙은 사람을 괜히 깨우는 규칙이 됩니다.

에스컬레이션을 실패 신고로 읽는 경우가 가장 많습니다. 남을 부른다는 것이 못 풀었다는 뜻으로 들리니 자연스러운 오해입니다. 하지만 이 절차가 재는 것은 사람의 실력이 아니라 시간입니다. 30분은 누구나 걸릴 수 있는 시간이고, 규칙은 그 시간이 지나면 혼자 두지 않겠다는 약속입니다. 부르는 것을 흠으로 여기는 팀에서는 당번이 규칙을 넘기고 버티기 시작하고, 그러면 장애 하나하나가 실제보다 길어집니다.

넘기면 내 손을 떠난다고 여기는 것도 흔한 오해입니다. 보통의 업무 인계가 그렇게 돌아가니 같은 그림으로 읽는 겁니다. 실제로는 받은 사람이 확인하기 전까지 원래 담당이 그대로 붙어 있고, 받은 뒤에도 그동안의 맥락을 아는 사람으로 남습니다. 넘긴 즉시 손을 놓는 팀에서는 두 사람 다 화면을 안 보는 십 분이 생기고, 그 십 분은 MTTR에 그대로 더해집니다. MTTR 은 장애가 시작된 뒤 복구까지 걸린 평균 시간입니다.