เป้าหมายคือ รู้ว่าระบบของคุณไม่แข็งแรงก่อนที่ผู้ใช้จะมาบอกคุณ observability ที่ดีช่วยให้คุณตอบคำถามที่คุณไม่ได้คาดไว้ล่วงหน้า ไม่ใช่แค่เช็ค dashboard ชุดเดิมๆ ในฐานะ tech lead คุณตั้งค่าสิ่งนี้ไว้ ก่อน เกิดเหตุ ไม่ใช่ระหว่างเกิดเหตุ
เป้าหมายคือ รู้ว่าระบบของคุณไม่แข็งแรงก่อนที่ผู้ใช้จะมาบอกคุณ observability ที่ดีช่วยให้คุณตอบคำถามที่คุณไม่ได้คาดไว้ล่วงหน้า ไม่ใช่แค่เช็ค dashboard ชุดเดิมๆ ในฐานะ tech lead คุณตั้งค่าสิ่งนี้ไว้ ก่อน เกิดเหตุ ไม่ใช่ระหว่างเกิดเหตุ
ส่ง 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 fatigue คือต้นเหตุที่ทำให้เหตุการณ์จริงถูกพลาดไป เพิ่ม health checks และ dashboard ที่แสดง golden signals ได้ในพริบตา
ทีมที่เฝ้าดูระบบเฉพาะหลังเกิดเหตุคือการบินตาบอด พวกเขารู้เรื่อง outage จากลูกค้าที่โกรธและ debug ด้วยการเดา การลงทุนกับ observability ตั้งแต่ต้นจะเปลี่ยนปริศนาตอนตีสามให้กลายเป็นการวินิจฉัยใน 5 นาที ลด downtime และปลดปล่อยทีมให้ไปส่งงานแทนที่จะดับเพลิง