알림

서비스가 망가졌다는 사실을 만드는 쪽보다 쓰는 쪽이 먼저 아는 시절이 길었습니다. 그래프를 아무리 많이 띄워 두어도 보고 있는 사람이 없으면 그래프는 아무 말도 하지 않습니다. 새벽 두 시에 문서 저장이 전부 실패하기 시작해도 아침에 누군가 출근해 화면을 켜기 전까지 회사 안의 누구도 모릅니다.

그래서 사고의 시작은 대개 바깥에서 들어왔습니다. 고객 문의가 서너 건 쌓이면 상담 담당자가 개발팀에 묻고, 개발팀이 그제야 기록을 뒤집니다. 그사이 흐른 일곱 시간치 실패는 누가 화면 앞에 있었다면 첫 오 분에 보였을 신호였습니다.

신호가 없어서 생긴 일은 아니었습니다. 메트릭은 분당 요청 수와 실패율을 1초 단위로 쌓고 있었고, 로깅은 실패한 요청마다 이유를 한 줄씩 남기고 있었습니다. 둘 다 정확했지만 둘 다 사람이 찾아와 봐 주기를 기다리는 방식입니다. 기록을 남기는 일과 사람을 부르는 일은 서로 다른데, 관측 수단 가운데 뒤쪽을 맡는 것이 없었습니다. 그 자리를 메우려고 조건을 시스템에 미리 적어 두고 걸리면 먼저 연락이 가게 만든 것이 알림입니다.

알림이 메우는 것은 신호가 쌓인 시점과 사람이 알아차린 시점 사이의 빈 구간이고, 그 길이가 그대로 피해의 크기가 됩니다. 일곱 시간 뒤에 알면 일곱 시간치가 쌓이고, 오 분 뒤에 알면 오 분치만 쌓입니다.

구간을 줄이려면 사람의 판단을 미리 글로 적어 두어야 합니다. 규칙 하나는 보통 네 부분으로 이뤄집니다.

1. 무엇을 볼지 — 감시할 값을 고릅니다. 저장 요청의 실패율처럼 사용자가 실제로 겪는 것에 가까울수록 좋습니다. 서버 한 대의 메모리 사용량이 90퍼센트라는 사실은 사용자가 아무 불편을 못 느끼는 동안에도 참일 수 있습니다.
2. 어디부터 문제인지 — 그 값의 어느 선을 넘으면 문제로 볼지 정합니다. 팀이 지키기로 정한 서비스 품질 목표인 SLO가 있으면 그 선을 그대로 가져옵니다. 저장 성공률을 99.9퍼센트로 정해 두었다면 실패율 0.1퍼센트가 기준선이 됩니다.
3. 얼마나 이어져야 하는지 — 순간적으로 튄 값 하나로는 부르지 않습니다. 배포 직후 실패율이 몇 초 치솟았다 가라앉는 일은 흔합니다. 그래서 조건에 시간을 붙입니다. 실패율 1퍼센트가 5분 넘게 이어지면, 같은 방식입니다.
4. 누구에게 어떻게 — 누구에게 갈지, 답이 없으면 다음에 누구를 부를지 정합니다. 그 시간의 당번을 정해 둔 것이 온콜이고, 당번이 받지 않을 때 위로 넘기는 절차가 에스컬레이션입니다.

셋째가 빠지면 배포할 때마다 전화가 오고, 넷째가 빠지면 연락은 갔는데 받은 사람이 없게 됩니다. 조율할 것은 늘 같습니다. 선을 낮게 잡으면 문제가 아닌 것까지 부르고, 높게 잡으면 진짜 문제를 놓칩니다. 화재경보기와 같은 문제라, 연기 한 줄기에 울리게 하면 요리할 때마다 울려 결국 배터리를 빼게 됩니다. 알림도 똑같이 꺼집니다. 사람이 끄는 대신 무시하는 습관이 생길 뿐입니다.

지켜보는 일을 사람이 직접 하는 것이 가장 오래된 방법입니다. 주요 지표를 한 화면에 모아 둔 대시보드를 벽에 띄워 두고 눈에 띄면 손을 대는 식입니다. 근무 시간에는 잘 작동하고, 숫자 하나가 아니라 화면 전체를 읽을 수 있어 규칙으로 적기 어려운 이상함도 잡힙니다. 무너지는 것은 밤과 주말입니다.

정기 점검으로 대신하는 방법도 있습니다. 매일 아침 지난 24시간 요약을 메일로 받는 식이고, 서서히 나빠지는 값에는 오히려 낫습니다. 응답 시간이 한 달에 걸쳐 0.4초에서 1.1초로 늘어나는 변화는 어느 날에도 선을 넘지 않아 알림으로는 잡히지 않습니다. 대신 지금 터진 일에는 늦습니다.

조건을 사람이 정하는 대신 기계가 찾게 하는 방법이 이상 탐지입니다. 평소 값의 모양을 학습해 두고 벗어나면 알립니다. 금요일 저녁 접속이 평일의 절반으로 떨어지는 것은 정상이지만 화요일 오후에 절반이 되면 문제라는 판단을 고정된 선 하나로는 못 합니다. 약점은 왜 불렀는지가 흐리다는 점입니다. 실패율 1퍼센트를 넘겼다는 말은 받는 즉시 뜻이 통하지만, 평소와 다르다는 말은 받은 사람이 처음부터 다시 봐야 합니다.

발생한 예외를 같은 것끼리 묶어 주는 에러 트래킹도 사람을 부르는 기능을 갖고 있습니다. 새로운 종류의 오류가 처음 나타났을 때처럼 값의 크기로는 적기 어려운 조건을 다룹니다.

"이거 알림 안 왔어요? 30분째 실패율이 8퍼센트인데요."

감시 규칙이 아예 없거나 선이 너무 높게 잡혀 있다는 지적입니다.

"이 알림은 노이즈예요. 이번 주에만 열네 번 왔고 전부 자동으로 회복됐어요."

규칙을 지우거나 지속 시간 조건을 붙이자는 제안입니다.

"새벽에 부를 만한 건지 보고 정합시다. 아니면 아침에 보는 목록으로 내려요."

지금 손대야 하는 일과 내일 봐도 되는 일을 나누자는 뜻입니다.

페이지덱에서는 태오가 온콜 당번을 마칠 때마다 그 주에 울린 것을 훑습니다. 전화까지 간 네 건 중 실제로 손을 댄 것이 한 건이었다면, 나머지 셋은 규칙이 잘못 잡힌 것으로 보고 조건을 고치거나 새벽에 울리지 않게 내립니다. 반대로 고객 문의로 먼저 들어온 장애 대응 건이 있으면 왜 규칙에 안 걸렸는지 확인하고 새 규칙을 답니다.

많이 걸어 둘수록 안전하다고 생각하기 쉽습니다. 감시망을 촘촘히 하는 일이니 그럴듯합니다. 실제로는 반대로 움직입니다. 하루에 마흔 건이 오면 받는 사람은 열어 보지 않고 제목만 보고 넘기게 되고, 그 습관이 붙은 뒤에는 진짜 한 건도 같이 넘어갑니다. 그대로 두면 사고가 났을 때 연락은 정확히 갔는데 아무도 읽지 않은 기록만 남습니다. 그래서 잘 굴러가는 팀은 규칙 수가 아니라 사람을 부른 것 중 실제로 손을 댄 비율을 셉니다.

연락이 갔으니 대응이 끝났다고 여기는 것도 흔합니다. 갔다는 사실과 받았다는 사실은 다르고, 받았다는 사실과 고쳤다는 사실은 또 다릅니다. 알림은 시작을 알릴 뿐이고 그다음은 인시던트로 넘어갑니다. 누가 맡을지, 상태를 어디에 적을지, 끝나면 무엇을 남길지는 알림 밖의 약속입니다.