정확해도 해로운 알림이 있다

한 줄 요약

알림의 성공 기준은 '문제를 감지했는가'가 아니라 '사람이 지금 무언가를 해야 하는가'다. 이 기준을 통과하지 못하는 알림은 정확해도 해롭다.

왜 이게 필요했나

사고가 날 때마다 규칙을 하나씩 추가하면 2년 뒤에는 규칙이 300개가 되고 슬랙에는 하루 400건이 쌓인다. 온콜은 밤에 세 번 깨어나 세 번 다 아무것도 하지 않고 다시 잔다. 하루 400건 중 실제 조치로 이어진 것이 4건이면 정밀도는 1% 다.

이 상태에서 사람이 학습하는 최적 전략은 '일단 무시하고 나중에 확인'이다. 그것이 합리적이기 때문에 더 위험하다. 알림을 하나 더 추가해서 해결되는 문제가 아니다.

어떻게 동작하나

원칙은 하나다. 사용자가 겪는 증상에만 호출을 건다. CPU 90% 는 증상이 아니다. CPU 가 90% 인데 응답 시간이 정상이면 아무 일도 일어나지 않은 것이고, CPU 가 40% 인데 응답이 5초씩 걸리면 심각한 사고다. 원인 지표에 호출을 걸면 두 경우 모두 틀린다.

호출을 걸 것: 가용성, 지연(임계 초과 비율), 처리량 급감, 신선도, 정확성. 걸지 말 것: CPU, 메모리, 디스크 IOPS, 파드 재시작 횟수, 스레드 풀 사용률, GC 시간, 레플리카 수. 예외는 둘뿐이다. 되돌릴 수 없고 선행 시간이 필요한 것(디스크 여유, 인증서 만료, 쿼터 소진), 그리고 관측 체계 자체의 고장(up == 0 or absent(up))이다. 이 알림이 없으면 나머지 알림이 조용히 죽는다.

임계값도 설명할 수 있어야 한다. "오류율 5% 넘으면 알림"의 5% 는 어디서 왔는가. 대부분 아무 데서도 오지 않았다. 설명할 수 없는 임계값은 사고가 날 때마다 조금씩 올라간다.

for: 는 표현식이 참인 상태가 그 시간만큼 연속으로 유지되어야 발화하고, 중간에 한 번이라도 거짓이면 타이머가 0 으로 초기화된다. 그래서 "오탐이 많으니 for 를 30분으로 늘리자"는 안티패턴이다. 탐지가 30분 늦어지고, 사고가 25분 만에 끝나면 알림이 아예 울리지 않는다. 올바른 순서는 ① 긴 창 rate 로 평활화 ② 짧은 창 AND 로 진행 중 확인 ③ for 는 마지막에 2~5분만이다.

현장에서 만나는 모습

라우팅은 3단계다. 페이지(지금 깨어나야 함), 티켓(업무 시간), 대시보드(알림을 만들지 않음). 4단계는 없다. "일단 슬랙 채널에만 보내자"는 절충안은 최악이다 — 아무도 책임지지 않고 아무도 끄지 않는다.

그룹핑에서 가장 흔한 실수는 group_by 에 instance 를 넣는 것이다. 파드 수만큼 알림이 온다. 그리고 severity=page 인데 runbook_url 이 없으면 CI 가 빌드를 깨야 한다. 새벽 3시에 깨어난 사람은 창의력을 발휘할 상태가 아니다. 다만 링크만 있고 내용이 비어 있는 런북은 링크가 없는 것보다 나쁘다.

목표치는 숫자로 정해 둔다. 12시간 교대 기준 페이지 평균 2건 이하, 페이지의 조치 전환율 70% 이상. 이 두 숫자를 넘어가면 알림을 추가할 것이 아니라 삭제할 때다. 3개월 연속 조치로 이어지지 않은 페이지는 강등하거나 삭제하고, 사일런스가 30일 이상 유지된 알림은 삭제한다. 사일런스는 알림이 틀렸다는 가장 정직한 신호다.

다음 실습에서 할 것

증상과 원인을 분류하고, 알림 규칙에 필수 필드를 채우고, 라우팅과 억제와 그룹핑을 정의하고, 런북을 실제로 채운 뒤, 마지막에는 결함 있는 규칙을 CI 에서 잡아내는 검사기를 직접 만듭니다.