정확한 경보가 쌓이면 부정확한 경보가 된다

한 줄 요약

경보의 품질은 정확도가 아니라 행동 가능성으로 잰다. 울릴 때마다 사람이 할 일이 없는 경보는, 하나하나가 정확해도 전체로는 거짓말이 된다.

왜 이게 필요했나

경보를 늘리는 일은 쉽다. 사고가 날 때마다 "이걸 미리 알았더라면" 하는 지표가 하나씩 생기고, 그 지표에 임계값을 걸면 다음 회의에서 할 말이 생긴다. 그렇게 1년이 지나면 규칙 파일에 경보가 80개 쌓인다.

문제는 그다음이다. 야간 당직자의 휴대폰이 밤에 스무 번 울리고, 그중 열아홉 번은 아침에 보니 아무 일도 아니었다. 사람은 학습한다 — 다음부터는 알림을 보고도 바로 일어나지 않는다. 그리고 스물한 번째, 진짜 장애가 같은 소리로 온다.

이것이 경보 피로다. 개별 경보의 정확도를 아무리 올려도 해결되지 않는다. 호출의 총량이 문제이기 때문이다. Google SRE Book 은 이것을 두고 "모니터링 시스템의 출력은 사람이 감당할 수 있어야 한다" 고 적는다. 감당 가능성은 규칙 하나하나가 아니라 합으로 결정된다.

어떻게 동작하나

해결의 뼈대는 두 가지다.

첫째, 증상으로 경보하고 원인으로 조사한다. 사용자가 겪는 것 — 요청이 실패한다, 느리다, 결과가 틀리다 — 은 몇 가지뿐이다. 반면 그 증상을 만드는 원인은 수십 가지다. 원인마다 경보를 달면 수십 개의 호출이 생기지만, 증상에 경보를 달면 몇 개로 줄어든다. 원인 지표는 없애는 것이 아니라 대시보드와 조사 도구로 내린다. 사람이 깨어난 뒤에 보는 것과, 사람을 깨우는 것은 다른 자리다.

둘째, 경보에 지속 시간을 준다. 조건이 한 번 참이 됐다고 바로 울리면, 잠깐 튀는 값이 그대로 호출이 된다. for 를 5분으로 두면 5분 이상 유지된 것만 울린다. 이 손잡이 하나로 호출 수가 한 자릿수로 떨어지는 일이 흔하다 — 다만 그만큼 탐지가 늦어지므로, 얼마나 늦어도 되는지는 에러 버짓이 답한다.

경보를 고를 때 물어야 할 질문은 하나로 줄일 수 있다. 이 알림을 받은 사람이 지금 할 수 있는 일이 있는가. 없다면 그것은 호출이 아니라 티켓이거나 대시보드 패널이다.

| 성격 | 보내는 곳 | 예 |
| --- | --- | --- |
| 지금 사람이 개입해야 한다 | 호출(page) | 사용자 요청의 오류 비율이 목표를 넘고 있다 |
| 이번 주 안에 처리하면 된다 | 티켓 | 6시간 뒤 디스크가 찬다 |
| 조사할 때 본다 | 대시보드 | p99 지연, 큐 깊이, 인스턴스별 CPU |

지속 시간만으로는 부족한 자리도 있다. 조건이 5분 유지되기를 기다리면 작은 사고는 놓치고 큰 사고는 늦게 안다. 그래서 SLO 기반 경보는 지속 시간 대신 소진 속도를 쓴다 — 지금 속도로 예산을 얼마나 빨리 먹고 있는지를 짧은 창과 긴 창으로 함께 보고, 둘이 동시에 넘을 때만 울린다. 짧은 창이 빠른 탐지를, 긴 창이 잡음 제거를 맡는 구조다.

경보에는 예산을 두는 것이 좋다. 한 사람이 한 주에 받는 호출이 두 건을 넘지 않게 하겠다는 식의 약속이다. 예산이 있으면 새 경보를 더할 때마다 "무엇을 뺄 것인가" 를 함께 묻게 되고, 그 질문이 규칙 파일이 자라는 속도를 늦춘다. 예산을 넘었을 때는 규칙을 고치는 대신 시스템을 고치는 쪽이 답일 때가 많다 — 자주 울리는 경보는 대개 자주 나는 고장을 정직하게 알려 주고 있다.

그리고 경보마다 두 가지를 강제한다. 하나는 런북 링크다. 새벽 세 시에 처음 보는 경보를 받은 사람이 무엇을 확인하고 무엇을 되돌릴지 그 링크 하나로 알 수 있어야 한다. 다른 하나는 소유자다. 아무도 책임지지 않는 경보는 아무도 지우지 못해서 영원히 남는다. 분기마다 경보 회고를 열어 "지난 90일 동안 한 번도 울리지 않았거나, 울렸는데 아무 조치도 하지 않은 경보" 를 목록으로 뽑아 지우는 팀이 규칙 파일을 작게 유지한다.

현장에서 만나는 모습

어느 팀의 규칙 파일에는 "요청 수가 평소보다 적다" 는 경보가 있었다. 의도는 좋았다 — 트래픽이 끊기면 장애일 수 있으니까. 그런데 새벽에는 원래 트래픽이 적다. 그 경보는 12시간 중 609분, 즉 절반 가까이 참이었고, 당직자는 그 알림을 자동으로 무시하도록 필터를 만들어 두고 있었다. 있으나 마나 한 것이 아니라, 필터를 만드는 습관을 길러 주었다는 점에서 해로웠다.

반대쪽 사례도 있다. p99 지연이 0.5초를 넘으면 울리는 경보는 지속 시간이 없어서 12시간에 예순다섯 번 울렸다. for: 5m 을 붙이자 여덟 번이 됐고, for: 15m 에서는 한 번이 됐다. 규칙의 조건은 한 글자도 바뀌지 않았다. 바뀐 것은 "얼마나 지속돼야 사람을 깨울 만한가" 에 대한 팀의 합의뿐이다.

다음 실습에서 할 것

원인 기준 경보 네 개를 규칙 파일로 쓰고, 백필된 12시간 자료에 대해 각각이 몇 번 울렸을지 직접 세는 도구를 만든다. 지속 시간을 0분·5분·15분으로 바꿔 호출 수가 어떻게 줄어드는지 재고, 증상 기준 경보 하나와 비교한다. 그다음 원인 경보가 울린 시간 중 사용자가 아무 일도 겪지 않은 시간이 몇 분인지 세어, 그 숫자를 근거로 무엇을 호출로 남기고 무엇을 내릴지 표로 정하고, 마지막에 호출용 규칙 파일만 따로 만들어 검사를 통과시킨다.