알람이 너무 많으면 알람이 없는 것과 같다
임계값을 낮게 잡아 알람 홍수가 난 뒤, 숫자 하나 바꾸는 데 왜 이렇게 오래 걸렸나.
사건 경위
올해 초 특정 서비스 에러율 알람이 하루 40~60건 울렸다. 처음 며칠은 Slack 을 봤다. 일주일 뒤엔 채널을 뮤트했다. 한 달 뒤엔 진짜 장애가 났는데 아무도 몰랐다.
문제는 임계값이 아니었다. 정확히는 임계값을 “일단 낮게” 잡은 관성이었다.
- 최초 설정: 에러율 0.5% 이상 1분 지속 → PagerDuty 호출
- 실제 베이스라인: 정상 트래픽에서도 0.3~0.7% 오르내림
- 결과: 알람 = 배경 소음
임계값을 낮게 잡는 건 “우리는 꼼꼼하다”는 착각에서 나온다. 막상 운영해보면 그건 꼼꼼한 게 아니라 판단 위임 거부다.
다시 정한 방식
두 가지 기준으로 재작업했다.
1. 베이스라인 먼저 측정
최근 28일 P95 에러율을 뽑았다. 그 값의 2배를 1차 임계값으로 삼았다. 근거 없이 0.5% 같은 라운드 넘버를 쓰지 않는다.
- 서비스 A: 베이스라인 0.6% → 임계값 1.2%, 5분 지속
- 서비스 B: 베이스라인 0.05% → 임계값 0.15%, 3분 지속
서비스마다 다르다. 당연하다.
2. 알람 피로도 지표를 같이 추적
주간 알람 건수, 그 중 실제 대응이 필요했던 비율(Signal Rate)을 같이 기록했다. 목표는 Signal Rate 70% 이상. 낮으면 임계값을 올린다. 이 숫자가 없으면 튜닝이 감에만 의존하게 된다.
조정 후 2주 결과:
- 알람 건수: 주 280건 → 주 34건
- Signal Rate: 12% → 81%
- 놓친 실제 장애: 0건
숫자만 보면 성공처럼 보이는데, 불편한 사실이 하나 있다. 이 작업을 6개월 전에 할 수 있었다. 알람 홍수 직후에 바로 건드렸어야 했는데, “나중에 시간 나면” 을 6번 반복하다 진짜 장애를 맞았다.
다음 한 가지
알람 Signal Rate 가 2주 연속 60% 미만이면, 그 주 안에 임계값 재검토를 캘린더에 박아 둔다. 나중으로 미루는 루프를 끊는 방법은 결국 일정 강제뿐이다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.