ภูมิหลังของปัญหา: แม้จะแยกช่องทางการแจ้งเตือน Critical กับ Warning ออกจากกัน และนำการรับสายโทรศัพท์มาใช้เมื่อเกิดการแจ้งเตือน Critical แล้ว แต่การพุ่งสูงของการแจ้งเตือน Warning ที่มากกว่า 10,000 รายการต่อเดือน กลับทำให้เกิดการเพิกเฉยต่อการแจ้งเตือนและเพิ่มความเหนื่อยล้าของการทำ On-call
ข้อมูลเชิงลึกสำคัญ: การแจ้งเตือนที่มากเกินไปทำให้ระบบกลายเป็นเพียงตัวเช็กสุขภาพของเมสเซนเจอร์ และบั่นทอนความสามารถในการมองเห็นสถานะของระบบ จึงเสนอให้วัด 'อัตราการตอบสนองต่อการแจ้งเตือน' โดยใช้ Slack emoji (👀, ✅) เป็นตัวชี้วัดหลักสำหรับการลดการแจ้งเตือน
กระบวนการแก้ไข:
ปรับแก้และลบการแจ้งเตือนที่เจตนาในการตั้งค่าเดิมไม่สอดคล้องกับสภาพแวดล้อมปัจจุบันอีกต่อไป (เช่น ค่า threshold สำหรับการเพิ่มขนาด EBS volume ที่ไม่ตรงกัน)
ลบการแจ้งเตือนที่ไร้ความหมายซึ่งไม่สามารถทราบเจตนาของผู้ทำงานก่อนหน้าได้อย่างเด็ดขาด
ผลลัพธ์เพิ่มเติม: หลังจากกำจัด noise ของการแจ้งเตือนแล้ว ก็พบว่าสาเหตุของ iowait ที่สูงบนเซิร์ฟเวอร์บางเครื่องมาจากการตั้งค่า ZFS recordsize ที่สูงเกินจริงเมื่อเทียบกับ workload จริง และได้ปรับให้กลับมาเหมาะสม
ผลลัพธ์: การแจ้งเตือนประเภท Warning ลดลง 95.7% (10,553 รายการต่อเดือน → 453 รายการ) การรับสายโทรศัพท์จาก Critical ในช่วงดึก/วันหยุดลดลงมากกว่า 70% แก้ปัญหาการนอนไม่พอของ On-call และช่วยยกระดับทั้งความพร้อมใช้งานและความสามารถในการมองเห็นของระบบอย่างแท้จริง
3 ความคิดเห็น
บันทึกล็อก เมตริก และการแจ้งเตือน เป็นสิ่งที่จำเป็นต้องมีแนวปฏิบัติในการปรับจูนเป็นระยะครับ
รู้สึกว่าชื่อเล่นนี้คุ้น ๆ อยู่แล้ว ที่แท้ก็เป็นคนที่เคยเขียนบทความสนุก ๆ จากเอาต์พุตของ cron มาก่อนนี่เองครับ บทความนี้ก็อ่านเพลินมากเช่นกัน :D
ดีใจที่คุณอ่านอย่างสนุกนะครับ ขอบคุณครับ