คุณเลือก threshold ของการแจ้งเตือนอย่างไรเพื่อหลีกเลี่ยง alert fatigue และ false positive?

Question

IT Interview Practice · Accepted Answer

กฎหลักคือ **แจ้งเตือนที่อาการ ไม่ใช่ที่สาเหตุ** และ **ส่ง page เฉพาะสิ่งที่ลงมือแก้ได้และเร่งด่วน** การแจ้งเตือนที่ส่งเสียงรบกวนทุกคืนจะถูกปิดเสียงหรือถูกเพิกเฉย — ดังนั้นความเสี่ยงที่แท้จริงไม่ใช่การพลาดการแจ้งเตือน แต่คือคนที่อยู่เวร on-call ที่ชินชาจนหลับผ่านการแจ้งเตือนตัวจริงไป

## อาการเหนือสาเหตุ

แจ้งเตือนที่ **SLO ที่ส่งผลต่อผู้ใช้** (error rate, latency, availability) ไม่ใช่ที่สาเหตุภายในอย่าง "CPU > 80%" CPU สูงอาจไม่มีผลใด ๆ สิ่งที่สำคัญคือผู้ใช้ได้รับผลกระทบหรือไม่

```text
BAD  (cause)     CPU > 80% for 5m            → fires constantly, often no impact
GOOD (symptom)   error-rate SLO burn is fast → fires only when users hurt
```

## การแจ้งเตือนแบบ burn-rate หลายหน้าต่าง

threshold คงที่เพียงค่าเดียวจะไม่ไวเกินไปก็ช้าเกินไป แทนที่จะเป็นเช่นนั้น ให้แจ้งเตือนตามความเร็วที่คุณกำลังเผาผลาญ **error budget** โดยใช้สองหน้าต่าง เพื่อให้การเผาผลาญเร็วส่ง page ทันที ส่วนการเผาผลาญช้าจะส่ง page ก็ต่อเมื่อเกิดต่อเนื่องเท่านั้น

```yaml
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # fast window: catch big outages
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # short window: confirm it's still happening
  for: 2m
  labels: { severity: page }
```

หน้าต่างสั้นป้องกันการส่ง page สำหรับปัญหาที่แก้ไขตัวเองไปแล้ว ส่วนหน้าต่างยาวป้องกันการส่ง page จากความผิดปกติชั่วครู่

## Page vs ticket vs dashboard

```text
PAGE       actionable + urgent  → wake a human now (SLO at risk, checkout down)
TICKET     actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD  informational         → no alert, just visible (per-endpoint traffic)
```

หากการแจ้งเตือนหนึ่งลงมือแก้ไม่ได้ มันก็ไม่ควรส่ง page — เปลี่ยนให้เป็น ticket หรือ panel บน dashboard แทน จากนั้น **ปรับจูนไปตามเวลา** ทบทวนทุก page แล้วลบอันที่ไม่มีใครลงมือทำอะไรกับมันทิ้งไป

## ทำไมจึงสำคัญ

Alert fatigue เป็นความเสี่ยงด้านความน่าเชื่อถือ ไม่ใช่แค่เรื่องน่ารำคาญ มนุษย์จะกรองช่องทางที่เต็มไปด้วยเสียงรบกวนออกจากใจ ดังนั้นยิ่งคุณส่ง false positive มากเท่าใด โอกาสที่จะพลาด outage จริง ๆ ก็ยิ่งมากขึ้น การแจ้งเตือนที่อาการด้วยหน้าต่าง burn-rate และสงวน page ไว้สำหรับสิ่งที่เร่งด่วนและลงมือแก้ได้ ทำให้ทุก page มีความหมาย — ซึ่งเป็นสิ่งที่ทำให้ on-call ตอบสนองได้อย่างว่องไว

อาการเหนือสาเหตุ

การแจ้งเตือนแบบ burn-rate หลายหน้าต่าง

Page vs ticket vs dashboard

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง