Alerting 설계
Alert Fatigue (알림 피로)
나쁜 알림 설계의 가장 큰 부작용이다.
알림이 너무 많으면
→ 팀원이 알림에 무감각해짐
→ 진짜 중요한 알림도 무시하게 됨
→ 실제 장애를 늦게 발견
→ 서비스 다운
알림의 신뢰도를 유지하는 것 자체가 SRE의 중요한 역할이다.
나쁜 알림 vs 좋은 알림
❌ 나쁜 알림
CPU가 75%를 넘을 때마다 즉시 알림을 보낸다.
순간적인 스파이크에도 울리고, 하루에 수십 번 발생할 수 있다.
✅ 좋은 알림
CPU가 75%를 5분 이상 지속할 때 알림을 보낸다.
10분 쿨다운으로 같은 알림이 반복되지 않는다.
좋은 알림의 5가지 원칙
| 원칙 | 설명 |
|---|---|
| Actionable | 받으면 바로 조치할 수 있어야 한다 |
| Symptom-based | 사용자 영향 기준으로 설정한다 |
| 노이즈 제거 | 쿨다운, 지속시간 조건으로 불필요한 알림을 차단한다 |
| 심각도 구분 | Critical은 즉시 대응, Warning은 나중에 확인 |
| Runbook 연결 | 알림마다 대응 절차 문서를 링크한다 |
Symptom-based vs Cause-based
가장 중요한 원칙이다.
❌ Cause-based (원인 기반)
"DB 슬로우 쿼리가 10개 발생했다"
→ 내부 수치일 뿐, 사용자가 지금 불편한지 모른다
✅ Symptom-based (증상 기반)
"결제 성공률이 95% 아래로 떨어졌다"
→ 사용자가 실제로 결제를 못 하고 있다
사용자가 느끼는 증상을 기준으로 설계해야 한다.
Runbook이 뭔가
알림마다 연결해두는 대응 절차 문서다.
알림: "결제 오류율 2% 초과"
Runbook:
1. 결제 서비스 로그 확인
2. 외부 PG사 상태 페이지 확인
3. 이상 없으면 DB 커넥션 확인
4. 해결 안 되면 온콜 담당자 호출
Runbook이 있으면 처음 보는 알림도 절차대로 대응할 수 있다.
없으면 매번 "이거 어떻게 처리하지?"부터 시작한다.
정리
| 나쁜 알림 | 좋은 알림 | |
|---|---|---|
| 기준 | 내부 수치 | 사용자 영향 |
| 빈도 | 잦음 | 꼭 필요할 때만 |
| 중복 | 없음 | 쿨다운 적용 |
| 대응 | 즉흥적 | Runbook 따라 처리 |
