ตั้ง Uptime Monitoring ให้แจ้งเตือนเฉพาะเรื่องที่สำคัญ

ระบบแจ้งเตือนที่ส่ง noise มากเกินไปจะถูกปิดเสียงภายในไม่กี่สัปดาห์ และหลังจากนั้นมันก็ไม่ต่างอะไรกับการไม่มีระบบแจ้งเตือนเลย เป้าหมายจึงไม่ใช่ "เตือนให้ครบ" แต่คือ "เตือนเฉพาะเรื่องที่ต้องมีคนลงมือทำ"

ตรวจจากข้างนอก ไม่ใช่จากในเครื่องตัวเอง

monitor ที่รันอยู่บนเครื่องเดียวกับแอปจะตายพร้อมแอป ให้ยิงตรวจจากภายนอกอย่างน้อยสองภูมิภาค เพื่อแยกให้ออกระหว่าง "ระบบล่ม" กับ "เส้นทางเครือข่ายจากจุดตรวจจุดเดียวมีปัญหา"

ตรวจเส้นทางที่ผู้ใช้ใช้จริง

หน้า landing page ตอบ 200 ไม่ได้แปลว่าระบบทำงาน เพราะมันอาจเป็นไฟล์ static ที่ CDN ตอบให้ ควรมี endpoint ที่แตะของจริง

GET /healthz    → แอปยังมีชีวิต ตอบเร็ว ไม่แตะ dependency
GET /readyz     → เชื่อมฐานข้อมูลและ cache ได้จริง
POST /api/login → เส้นทางธุรกิจสำคัญ ตรวจเป็นรอบห่างกว่า

แยกสองอย่างแรกออกจากกันเสมอ เพราะการรวมทุกอย่างไว้ใน endpoint เดียว ทำให้ dependency ตัวเดียวล่มแล้ว orchestrator รีสตาร์ตแอปที่ยังปกติดีทิ้งไปโดยไม่จำเป็น

อย่าเตือนจากความล้มเหลวครั้งเดียว

network hiccup เกิดขึ้นได้ตลอด ตั้งเงื่อนไขให้ต้องล้มเหลวติดกันหลายรอบจากหลายจุดตรวจก่อนจะเตือน เช่นล้มเหลว 3 รอบติดจาก 2 ภูมิภาค ที่ระยะห่างรอบละ 30 วินาที ซึ่งแปลว่าจะรู้ตัวช้าลงราวหนึ่งนาทีครึ่ง แลกกับ alert ปลอมที่หายไปเกือบหมด

แบ่งระดับความเร่งด่วนให้ชัด

• ต้องปลุก — ผู้ใช้ใช้งานไม่ได้ในวงกว้าง หรือข้อมูลกำลังสูญหาย
• รอเช้าได้ — ประสิทธิภาพตกแต่ยังใช้งานได้ พื้นที่ดิสก์เหลือ 20%
• แค่บันทึกไว้ — งาน batch ล้มเหลวรอบเดียวแล้ว retry สำเร็จ

ทุก alert ที่ปลุกคนกลางดึกต้องตอบได้ว่า "ตื่นมาแล้วทำอะไรได้บ้าง" ถ้าคำตอบคือรอดูเฉยๆ มันไม่ควรเป็น alert ระดับปลุก

เตือนก่อนที่ certificate จะหมดอายุ

เว็บล่มเพราะ TLS certificate หมดอายุยังเป็นสาเหตุยอดนิยมอยู่จนถึงทุกวันนี้ ตั้งเตือนล่วงหน้า 30 วันและ 7 วัน แม้จะมีระบบต่ออายุอัตโนมัติแล้วก็ตาม เพราะสิ่งที่ต้องเฝ้าคือ "การต่ออายุอัตโนมัติทำงานอยู่จริงไหม" ไม่ใช่ตัววันหมดอายุอย่างเดียว