ปรัชญาการตั้ง Alert

การเก็บ metric สวยหรูแค่ไหนก็ไร้ค่า ถ้าตอนระบบพังไม่มีใครรู้ Alerting คือส่วนที่เปลี่ยน monitoring จาก "dashboard ที่ไม่มีใครดู" เป็น "ระบบที่ปลุกคนถูกเวลา" แต่ alert ที่ตั้งผิดวิธีจะแย่กว่าไม่มี alert เสียอีก

ศัตรูหมายเลข 1: Alert Fatigue

Alert fatigue = ภาวะที่คนถูก alert ปลุกบ่อยจนเกินไป (โดยเฉพาะ alert ที่ไม่สำคัญ/false positive) จนเริ่ม "ชินชา" และเพิกเฉย — สุดท้ายพอ alert ที่สำคัญจริงเด้ง ก็ถูกกวาดทิ้งไปกับ noise ทั้งหมด นี่คือสาเหตุที่ระบบล่มยาวทั้งที่ "มี alert แล้ว"

ทุก alert ที่ปลุกคนตอนตี 3 แล้วปรากฏว่า "ไม่เป็นไร" คือการทำลายความเชื่อใจใน alert ทีละนิด กฎเหล็ก:

ทุก alert ที่ทำให้คนต้องตื่นมาดู ต้อง (1) เป็นเรื่องจริง (2) เร่งด่วน (3) ทำอะไรได้ ถ้าขาดข้อใดข้อหนึ่ง มันไม่ควรเป็น alert ที่ปลุกคน

หลักการทอง: Alert on Symptoms, not Causes

นี่คือหลักการสำคัญที่สุดของการ alert สมัยใหม่:

• Symptom-based (ดี) → alert เมื่อ ผู้ใช้ได้รับผลกระทบ เช่น "error rate > 1%", "p99 latency > 1s", "checkout success ตก"
• Cause-based (ระวัง) → alert ที่ สาเหตุที่เป็นไปได้ เช่น "CPU > 90%", "pod restart", "disk I/O สูง"

ทำไม symptom ดีกว่า?

CPU 95% แต่ผู้ใช้ยังใช้งานได้ปกติ ทุกอย่างเร็ว
   → ตั้ง alert ที่ CPU = ปลุกคนมาดูของที่ไม่เป็นปัญหา (false positive)

ผู้ใช้เจอ error เพียบ แต่ CPU แค่ 40% (ปัญหาอยู่ที่ DB)
   → ตั้ง alert ที่ CPU = พลาด incident จริง (false negative)

Symptom alerts จับ "ผู้ใช้เดือดร้อน" ได้ทุกสาเหตุ ไม่ว่าต้นตอจะเป็นอะไร — นี่คือสิ่งที่ต้องปลุกคน ส่วน cause metrics (CPU, disk, pool) เก็บไว้ใช้ ตอน debug หลังถูกปลุกแล้ว ไม่ใช่เอามาปลุก (ยกเว้น cause ที่นำไปสู่หายนะแน่ๆ เช่น "disk จะเต็มใน 4 ชม." ซึ่งควร alert เพราะกันไว้ก่อน)

องค์ประกอบของ alert ที่ดี

alert rule ที่ดีมี 4 ส่วน:

1. เงื่อนไข (condition) — อิง symptom + SLO เช่น error rate > 1%
2. ระยะเวลา (for/duration) — ต้องเป็นจริงต่อเนื่องกี่นาที (กัน noise ชั่วขณะ) เช่น for: 5m
3. ความรุนแรง (severity) — page (ปลุก) vs ticket (ไว้ดูพรุ่งนี้)
4. runbook link — ลิงก์ไปเอกสารว่า "ถ้า alert นี้เด้ง ให้ทำอะไร" (บทที่ 51)

# ตัวอย่าง Prometheus alert rule
groups:
  - name: api-slo
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.01
        for: 5m                       # ต้องเกิน 1% ต่อเนื่อง 5 นาที
        labels:
          severity: page              # ปลุกคน
        annotations:
          summary: "error rate เกิน 1% ({{ $value | humanizePercentage }})"
          runbook: "https://wiki/runbooks/high-error-rate"

แยกให้ชัด: Page vs Ticket

ไม่ใช่ทุก alert ต้องปลุกคน — จัดระดับให้เหมาะ:

ระดับ	ความหมาย	ตัวอย่าง	ช่องทาง
Page (P1)	ปลุกทันที ต้องแก้เดี๋ยวนี้	ระบบล่ม, error rate พุ่ง, SLO จะพัง	โทร/PagerDuty/Opsgenie
Ticket (P2/P3)	ไม่เร่ง ดูในเวลางาน	disk 70%, cert หมดใน 20 วัน	Slack/email/Jira
Info	แค่บันทึกไว้	deploy สำเร็จ	log/dashboard

ถ้าทุก alert ถูกตั้งเป็น "page" คุณกำลังสร้าง alert fatigue โดยตรง — ของที่รอได้ถึงเช้าต้องไม่ปลุกคนตอนตี 3

เทคนิคขั้นสูง: Multi-window Burn-rate Alert

จากบท SLO เรามี error budget และ burn rate — วิธี alert ที่ Google แนะนำคือดู burn rate สองช่วงเวลาพร้อมกัน เพื่อได้ทั้งความไวและความแม่น:

• ช่วงสั้น (เช่น 5m) → ตอบสนองเร็ว จับปัญหาเฉียบพลัน
• ช่วงยาว (เช่น 1h) → ยืนยันว่าไม่ใช่ spike ชั่วคราว ลด false positive

alert เมื่อ: burn_rate(1h) > 14.4  AND  burn_rate(5m) > 14.4
→ แปลว่ากำลังไหม้ budget เร็วมากจนจะหมดใน ~2 วัน และมันเกิดจริงต่อเนื่อง

วิธีนี้ทำให้ alert ผูกกับผลกระทบต่อ SLO โดยตรง ไม่ใช่ threshold มั่วๆ — alert ก็เลยมีความหมายทุกครั้ง

Checklist ก่อนสร้าง alert ใหม่

ถามตัวเอง 5 ข้อ:

1. ✅ มันสะท้อน ผู้ใช้เดือดร้อน (symptom) ไหม?
2. ✅ ถ้าเด้งตอนตี 3 มัน เร่งด่วนพอ ให้ตื่นไหม? (ถ้าไม่ → ticket)
3. ✅ คนที่ถูกปลุก ทำอะไรได้ ไหม? (ถ้าไม่ → ไม่ควร alert)
4. ✅ มี runbook บอกวิธีแก้ไหม?
5. ✅ ตั้ง for: กัน noise ชั่วขณะแล้วยัง?

ถ้าตอบ "ไม่" ข้อใดข้อหนึ่ง → อย่าเพิ่งสร้าง alert นั้น

สรุป

• Alert fatigue คือศัตรูตัวจริง — alert ที่ไม่สำคัญทำลายความเชื่อใจใน alert ที่สำคัญ
• Alert on symptoms, not causes — ปลุกคนเมื่อ ผู้ใช้เดือดร้อน ไม่ใช่เมื่อ CPU สูง
• ทุก alert ที่ปลุกคนต้อง: จริง + เร่งด่วน + ทำอะไรได้ + มี runbook
• แยก Page (ปลุก) กับ Ticket (ไว้ดูทีหลัง) ให้ชัด
• ขั้นสูง: multi-window burn-rate ผูก alert กับ SLO โดยตรง

🎉 จบ Module 1! คุณเข้าใจ ภาษา ของ monitoring แล้ว ต่อไปลงมือจริงกับ Metrics — เริ่มที่สถาปัตยกรรม Prometheus