alert fatigue와 false positive를 피하려면 alert 임계값을 어떻게 정하나요?

Question

IT Interview Practice · Accepted Answer

핵심 규칙: **원인이 아니라 증상에 alert를 걸고**, **조치 가능하고 긴급한 것에만 page를 보낸다**. 매일 밤 울리는 노이즈 alert는 음소거되거나 무시됩니다 — 그래서 진짜 위험은 alert가 없는 것이 아니라, 둔감해진 on-call이 진짜 alert를 자면서 놓치는 것입니다.

## 원인보다 증상

"CPU > 80%" 같은 내부 원인이 아니라 **사용자 대면 SLO**(error rate, latency, availability)에 alert를 거세요. 높은 CPU는 무해할 수 있고, 중요한 건 사용자가 영향을 받는지 여부입니다.

```text
나쁨 (원인)     CPU > 80% 5m 동안          → 끊임없이 발화, 종종 영향 없음
좋음 (증상)     error-rate SLO burn이 빠름  → 사용자가 아플 때만 발화
```

## 다중 창 burn-rate alert

단일 정적 임계값은 너무 예민하거나 너무 느립니다. 대신 **error budget**을 얼마나 빠르게 소진하는지에 alert를 걸되, 두 개의 창을 사용해 빠른 소진은 즉시 page하고 느린 소진은 지속될 때만 page합니다.

```yaml
# Page: 1h 동안 월 budget의 2% 소진 AND 5m 동안 여전히 소진 중
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # 빠른 창: 큰 outage 포착
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # 짧은 창: 여전히 발생 중인지 확인
  for: 2m
  labels: { severity: page }
```

짧은 창은 이미 스스로 해결된 문제에 page하는 것을 막고, 긴 창은 잠깐의 흔들림에 page하는 것을 막습니다.

## Page vs ticket vs dashboard

```text
PAGE       조치 가능 + 긴급   → 지금 사람을 깨움 (SLO 위험, checkout 다운)
TICKET     조치 가능, 비긴급  → 업무 시간에 수정 (disk 70%, cert 20일 남음)
DASHBOARD  정보성            → alert 없음, 그저 보이게 (endpoint별 traffic)
```

alert가 조치 불가능하면 page해서는 안 됩니다 — ticket이나 dashboard 패널로 만드세요. 그리고 **시간이 지나며 튜닝**하세요: 모든 page를 검토하고 아무도 조치하지 않은 것은 삭제합니다.

## 왜 중요한가

alert fatigue는 단순한 성가심이 아니라 reliability 위험입니다: 사람은 노이즈가 많은 채널을 정신적으로 걸러내므로, false positive를 많이 보낼수록 진짜 outage를 놓칠 가능성이 커집니다. burn-rate 창으로 증상에 alert를 걸고, page를 조치 가능한 긴급함에만 남겨두면 모든 page가 의미 있게 유지됩니다 — 그것이 on-call의 반응성을 유지하는 비결입니다.

원인보다 증상

다중 창 burn-rate alert

Page vs ticket vs dashboard

왜 중요한가

관련 질문