คุณตรวจจับปัญหาก่อนที่ผู้ใช้จะร้องเรียนได้อย่างไร?

Question

Accepted Answer

เป้าหมายคือการจับปัญหา **ก่อนถึง page** — เพื่อค้นพบการเสื่อมสภาพในขณะที่ยังมีช่องว่างเหลือพอจะรองรับมัน นั่นหมายถึงการเฝ้าดู **leading indicator** การกำหนด **SLO พร้อม error budget** และการ probe ระบบเชิงรุกแทนที่จะรอให้มันล้มเหลว

## SLO และ error budget

**SLO** เปลี่ยนความน่าเชื่อถือให้เป็นตัวเลข (เช่น 99.9% ของคำขอสำเร็จ) ส่วน 0.1% ที่เหลือคือ **error budget** ของคุณ การติดตาม **burn rate** ทำให้คุณแจ้งเตือนได้เมื่อใช้ budget เร็วเกินไป — นานก่อนที่คุณจะละเมิด SLO จริง ๆ และผู้ใช้สังเกตเห็น

```text
SLO 99.9% → 0.1% error budget/month (~43 min of downtime)
burn rate rising fast → you'll exhaust it in 2 days → alert NOW, while it's fixable
```

## การ probe เชิงรุก ไม่ใช่แค่ metric เชิงรับ

```text
SYNTHETIC MONITORING  scripted checks hit critical paths on a schedule
                      (login, checkout) → fails even at 3am with zero real traffic
HEALTH CHECKS         /healthz endpoints + dependency checks → load balancer
                      pulls bad instances before users hit them
RUM (real-user mon.)  measure latency/errors from actual browsers/devices →
                      catches issues only some users/regions see
```

Synthetic monitoring ทรงพลังเพราะมันไม่รอผู้ใช้ — มันออกแรงทดสอบระบบอย่างต่อเนื่อง ดังนั้น checkout ที่พังจะถูกพบตอนตี 3 ไม่ใช่ตอนที่คนเร่งรีบยามเช้ามาบ่น

## Leading indicator และแนวโน้ม

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

```text
LEADING INDICATORS   saturation (CPU/mem climbing), queue depth growing,
                     connection-pool nearing limit, latency CREEPING up
ANOMALY DETECTION    flag deviation from the normal baseline / seasonality
TREND ALERTS         "disk will fill in 4h at this rate" → act before it's full
```

p99 ที่ค่อย ๆ ไต่ขึ้นหรือ queue ที่โตขึ้นคือสัญญาณเตือน การลงมือทำกับการคืบคลานนี้ทำให้คุณป้องกัน outage ที่การคืบคลานนั้นกำลังมุ่งหน้าไป

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

การ monitor เชิงรับหมายความว่าผู้ใช้เป็นระบบแจ้งเตือนของคุณ — กว่าที่พวกเขาจะร้องเรียน incident ก็เกิดขึ้นแล้วและ error budget ของคุณก็ถูกใช้ไปแล้ว การตรวจจับเชิงรุก (SLO burn rate, synthetic, health check, RUM, leading indicator, การแจ้งเตือนแนวโน้ม/ความผิดปกติ) ซื้อเวลานำให้คุณ คุณแก้ queue ที่กำลังอิ่มตัวหรือ latency ที่กำลังคืบคลานก่อนที่มันจะกลายเป็น page ตอนตี 2 และลูกค้าที่โกรธ เวลานำนั้นคือความแตกต่างระหว่างการแก้แบบเงียบ ๆ กับ outage