알림은 그래프가 아니라 런북을 가리켜야 한다

한 줄 요약

패널에서 알림을 만들 수 있다는 것과 그 알림이 쓸모 있다는 것은 다른 이야기다. 쓸모를 정하는 것은 임계값이 아니라 for 와 runbook_url 이다.

왜 이게 필요했나

5xx 비율은 요청 하나만 실패해도 튄다. 트래픽이 적은 새벽이면 한 건의 실패가 몇 퍼센트가 되기도 한다. 임계값을 넘는 순간 사람을 부르면 하루에 몇 번씩 울리고, 그러면 사람은 알림을 무시하게 된다.

알림이 죽는 방식은 늘 이것이다. 꺼지는 게 아니라 무시당한다. 그리고 무시당하는 알림 채널에는 진짜 장애도 함께 묻힌다.

for 는 이 문제를 정면으로 푼다. "10분 동안 계속 넘으면" 이라고 쓰면 잠깐 튄 값은 지나간다. 사람을 부르는 알림에 for 가 없다면 그 알림은 언젠가 반드시 무시당한다.

어떻게 동작하나

Grafana 의 알림 규칙은 조각 여러 개가 이어진 모양이다.

| 조각 | 하는 일 |
|---|---|
| 쿼리(A) | 데이터소스에서 값을 가져온다 |
| 임계(B) | 그 값이 기준을 넘는지 판정한다 |
| condition | 어느 조각의 결과로 판정할지 |
| for | 얼마나 오래 계속 넘어야 부를지 |
| annotations | 사람이 읽을 것 — 요약과 런북 주소 |

쿼리만 있고 임계가 없으면 그건 알림이 아니라 지표다. 언제 울릴지가 정해지지 않기 때문이다.

그리고 이 전부를 파일로 쓸 수 있다.

apiVersion: 1groups:  - orgId: 1    name: shop-api    folder: Lab    interval: 1m    rules:      - uid: shopapi5xx        title: ShopApiHighErrorRate        condition: B        for: 10m        annotations:          summary: 5xx 비율이 10분 넘게 0.5% 를 넘었습니다          runbook_url: file:///root/graf/runbook.md

UI 에서 만든 알림 규칙은 대시보드와 똑같은 운명을 맞는다 — 이 Grafana 안에만 남는다.

알림에 대시보드 링크를 걸면

호출을 받은 사람이 링크를 누르면 그래프가 뜬다. 그래프는 무엇이 이상한지만 말하고 무엇을 하라는 말하지 않는다. 새벽 3시에 필요한 것은 그림이 아니라 순서다.

런북은 짧아도 된다. 세 절이면 대개 충분하다.

| 절 | 담는 것 |
|---|---|
| 무엇이 깨졌나 | 이 알림이 무슨 뜻인지 한두 줄. 사용자에게 무슨 일이 일어나고 있는지 |
| 먼저 볼 것 | 실제로 칠 수 있는 명령이나 쿼리. "상태를 확인한다" 는 도움이 안 된다 |
| 되돌리는 법 | 원인을 찾기 전에 먼저 할 조치. 대개는 최근 배포를 되돌리는 것 |

런북을 알림보다 먼저 쓰는 편이 낫다. 그러면 "이게 울렸을 때 사람이 지금 무엇을 하나" 에 답할 수 없는 알림이 애초에 안 만들어진다.

흔한 착각

"알림이 많을수록 안전하다." 알림 하나가 늘 때마다 나머지 전부의 신뢰도가 조금씩 깎인다. 예산은 개수가 아니라 주의력이다.

"심각도만 나누면 된다." severity: warning 을 붙여 두고 아무도 안 보는 채널로 보내는 것은 알림을 만든 게 아니라 로그를 하나 더 만든 것이다.

실무에서 진짜 중요한 것

알림을 만들 때 물을 것은 하나다 — "이게 울리면 사람이 지금 무엇을 하나?"

답이 "일단 지켜본다" 면 그건 알림이 아니라 대시보드 패널이다. 답이 있다면 그 답을 런북에 적고, 알림이 그 문서를 가리키게 한다. 그 두 줄이 호출받은 사람의 처음 5분을 바꾼다.