คุณตั้งค่า monitoring และ observability อย่างไรเพื่อจับปัญหาได้แต่เนิ่นๆ?

Question

Accepted Answer

เป้าหมายคือ **รู้ว่าระบบของคุณไม่แข็งแรงก่อนที่ผู้ใช้จะมาบอกคุณ** observability ที่ดีช่วยให้คุณตอบคำถามที่คุณไม่ได้คาดไว้ล่วงหน้า ไม่ใช่แค่เช็ค dashboard ชุดเดิมๆ ในฐานะ tech lead คุณตั้งค่าสิ่งนี้ไว้ *ก่อน* เกิดเหตุ ไม่ใช่ระหว่างเกิดเหตุ

## สามเสาหลัก

- **Metrics** — time series เชิงตัวเลขราคาถูก (request rate, error rate, latency, queue depth) เยี่ยมสำหรับดูแนวโน้ม, การ alert และ SLOs
- **Logs** — บันทึกเหตุการณ์ละเอียดเพื่อบอกว่า *ทำไม* บางอย่างจึงเกิดขึ้น ทำให้มันเป็น **structured** (JSON) และแนบ **correlation ID** เพื่อให้คุณตามรอย request เดียวข้ามหลาย service ได้
- **Traces** — เส้นทางของ request เดียวข้ามหลาย service แสดงว่าเวลาถูกใช้ไปที่ไหนจริงๆ จำเป็นอย่างยิ่งในระบบ distributed

## alert ที่อาการ ไม่ใช่ที่สัญญาณรบกวน

ส่ง page ตามสิ่งที่ **ผู้ใช้รู้สึก** ไม่ใช่ตามความกระตุกภายใน ยึด alert ไว้กับ **SLOs** เช่น error rate, latency (p95/p99) และ availability การพุ่งขึ้นของ CPU ไม่ใช่เหตุการณ์ แต่ checkout ล้มเหลวกับผู้ใช้ 2% คือเหตุการณ์

| alert เมื่อ | อย่า page เมื่อ |
| --- | --- |
| error rate ทะลุ SLO | CPU พุ่งครั้งเดียว |
| p99 latency เกินงบ | request ช้าหนึ่งรายการ |
| health check ล้มเหลว | disk อยู่ที่ 60% |

## ทำให้ alert นำไปปฏิบัติได้

ทุก alert ควร **เร่งด่วน เป็นเรื่องจริง และนำไปปฏิบัติได้** — มันระบุว่าอะไรผิดและชี้ไปยังขั้นตอนถัดไป alert ที่ดังตลอดเวลาจะฝึกให้ทีมเพิกเฉยต่อมัน **alert fatigue** คือต้นเหตุที่ทำให้เหตุการณ์จริงถูกพลาดไป เพิ่ม **health checks** และ dashboard ที่แสดง golden signals ได้ในพริบตา

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

ทีมที่เฝ้าดูระบบเฉพาะหลังเกิดเหตุคือการบินตาบอด พวกเขารู้เรื่อง outage จากลูกค้าที่โกรธและ debug ด้วยการเดา การลงทุนกับ observability ตั้งแต่ต้นจะเปลี่ยนปริศนาตอนตีสามให้กลายเป็นการวินิจฉัยใน 5 นาที ลด downtime และปลดปล่อยทีมให้ไปส่งงานแทนที่จะดับเพลิง

alert เมื่อ	อย่า page เมื่อ
error rate ทะลุ SLO	CPU พุ่งครั้งเดียว
p99 latency เกินงบ	request ช้าหนึ่งรายการ
health check ล้มเหลว	disk อยู่ที่ 60%