알람이 너무 많으면 알람이 없는 것과 같다
노이즈로 가득 찬 알람 채널을 정리하며 임계값 재설정 기준을 다시 잡은 기록
사건의 발단
슬랙 #alerts 채널에 하루 400건 넘는 알람이 쌓이기 시작한 건 올해 초였다. 처음엔 그냥 넘겼다. 막상 장애가 났을 때 팀원 둘이 “알람은 봤는데 늘 저러니까”라고 했다. 그게 끝이었다.
원인은 단순했다.
- CPU 임계값 70% → 배포 때마다 스파이크, 매일 수십 건
- p99 레이턴시 500ms → 야간 배치 돌 때마다 위반
- 디스크 80% → 로그 rotate 전 매일 새벽 3시 발화
모두 “언젠가 문제가 될 수 있어서” 넣어둔 값들이었다. 2~3년 전 서비스 초기 기준 그대로.
재설정 기준
“이 알람이 울렸을 때 내가 지금 당장 뭔가를 해야 하는가.” 이 질문 하나로 걸렀다.
남긴 것
- 에러율 1% 초과 2분 지속 → 실제 서비스 영향권
- 디스크 95% → 거기서부터 진짜 위험
- 외부 API 타임아웃 연속 5회 → 즉시 대응 필요
삭제하거나 severity 낮춘 것
- CPU 70% → 90% 5분 지속으로 올리고, 단발성은 info 로 강등
- p99 500ms → 800ms 로 올리고, 비즈니스 시간대 외엔 mute
- 디스크 80% → 완전 제거, 95% 하나만 유지
작업 후 하루 알람 건수: 400건 → 18건. 채널을 다시 보게 됐다.
한 가지 더 했다. 임계값 옆에 코멘트를 달았다.
# 왜 이 값인가: 에러율 1%는 DAU 기준 약 500명 영향. 그 이하는 노이즈.
# 마지막 검토: 2026-04-10 / 담당: mings값을 정한 근거가 없으면 6개월 뒤 또 흐릿해진다. 숫자보다 맥락이 중요하다.
다음 한 가지
분기마다 임계값 코멘트에 “마지막 검토” 날짜를 갱신하는 것, 달력에 박아두기로 했다. 지난번에 “도구 정리 회의” 말만 했던 것처럼 되지 않으려면.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.