ระบบล่มแต่ผู้ใช้รู้ก่อนทีม IT: ตั้ง monitoring และ alert ให้เตือนเรื่องที่ควรตื่นมาแก้

เช้าวันจันทร์ ฝ่ายบริการลูกค้าส่งข้อความเข้ากลุ่มว่ามีคนโทรมาแจ้งตั้งแต่เจ็ดโมงว่าเข้าระบบไม่ได้ ทีม IT เปิด dashboard ดู ทุกเครื่องยังเขียว CPU ปกติ disk ยังเหลือ และไม่มี alert สักตัวดังตลอดคืน

เหตุการณ์แบบนี้ไม่ได้แปลว่าองค์กรไม่มีระบบ monitoring ส่วนใหญ่มี และมีเยอะด้วย ปัญหาคือมันวัดสิ่งที่วัดง่าย ไม่ได้วัดสิ่งที่ผู้ใช้เจอ อีกด้านหนึ่งของปัญหาเดียวกันคือทีมที่ได้รับ alert วันละหลายร้อยข้อความ จนเลิกอ่าน และพลาดข้อความเดียวที่สำคัญจริง

บทความนี้เขียนให้คนที่ต้องตัดสินใจว่าระบบขององค์กรจะวัดอะไร เตือนเมื่อไร และเตือนใคร เราจะเล่าวิธีคิดที่ใช้แยก alert ที่ควรปลุกคนตอนตีสามออกจาก alert ที่รอถึงเช้าได้ และจุดที่องค์กรไทยมักสะดุดตอนส่ง alert ให้ถึงมือคนจริง

ช่วงที่บทความนี้ครอบคลุมคือก่อนเหตุจะถูกประกาศ ส่วนการตัดสินใจหลังประกาศเหตุแล้ว เราเขียนไว้ในบทความ DR Plan ที่รอดวันจริง: ใครตัดสินใจ ใครสื่อสาร ตอนระบบล่ม

วัดจากฝั่งผู้ใช้ก่อน แล้วค่อยวัดฝั่งเครื่อง

ระบบ monitoring ส่วนใหญ่เริ่มจากสิ่งที่เครื่องมือเก็บให้อัตโนมัติ เช่น CPU หน่วยความจำ และพื้นที่ disk ค่าเหล่านี้มีประโยชน์ตอนหาสาเหตุ แต่บอกได้น้อยมากว่าผู้ใช้กำลังเจออะไร ระบบที่ CPU ต่ำอาจกำลังตอบ error ทุกคำขอ เพราะเชื่อมต่อฐานข้อมูลไม่ได้ ระบบที่ CPU สูงอาจทำงานปกติดีทุกอย่าง

หนังสือ Site Reliability Engineering ของ Google แยกเรื่องนี้เป็นสองคำถาม คือ อะไรเสีย (symptom) กับ ทำไมถึงเสีย (cause) ตัวอย่างในหนังสือคือ ระบบตอบ HTTP 500 เป็น symptom ส่วนฐานข้อมูลปฏิเสธการเชื่อมต่อเป็น cause หนังสือแนะนำให้ alert ที่ปลุกคนผูกกับ symptom เป็นหลัก และใช้ข้อมูลภายในระบบไว้หาสาเหตุ (อ้างอิง: Google SRE Book, Monitoring Distributed Systems)

สัญญาณฝั่งผู้ใช้ที่หนังสือเล่มเดียวกันเสนอให้เริ่มวัด มีสี่ตัว เรียกว่า four golden signals

• Latency เวลาที่ระบบใช้ตอบคำขอ โดยแยกคำขอที่สำเร็จออกจากคำขอที่ล้มเหลว เพราะ error ที่ตอบเร็วจะดึงค่าเฉลี่ยให้ดูดีเกินจริง

• Traffic ปริมาณความต้องการที่เข้ามา เช่น จำนวนคำขอต่อวินาที

• Errors สัดส่วนคำขอที่ล้มเหลว ทั้งที่ระบบรายงานเองและที่ต้องตีความ เช่น ตอบกลับสำเร็จแต่เนื้อหาผิด

• Saturation ระบบเต็มแค่ไหน วัดจากทรัพยากรที่ตึงที่สุดของระบบนั้น

อีกชั้นที่องค์กรมักขาดคือการวัดจากภายนอก เรียกว่า black-box monitoring คือให้เครื่องมือเรียกหน้าเว็บหรือ API ของคุณจากนอกเครือข่ายเป็นระยะ เหมือนผู้ใช้คนหนึ่ง ถ้า network ขาออกหรือ DNS มีปัญหา เครื่องมือที่อยู่ในเครือข่ายเดียวกับระบบจะมองไม่เห็นเลย ผู้ให้บริการ cloud ที่เราใช้งานอยู่มีบริการแบบนี้ในตัว เช่น uptime check ของ Google Cloud Monitoring และ Health Checks ของ Cloudflare

alert ที่ควรปลุกคน กับ alert ที่รอถึงเช้าได้

ความผิดพลาดที่พบบ่อยที่สุดคือส่งทุกอย่างไปช่องเดียวกัน ด้วยความเร่งด่วนเท่ากัน disk ใช้ไป 80% ถูกส่งเข้ากลุ่มเดียวกับระบบชำระเงินล่ม ผลคือทีมเรียนรู้เร็วมากว่าข้อความส่วนใหญ่ในกลุ่มนั้นไม่ต้องทำอะไร และเริ่มปิดเสียง อาการนี้มีชื่อเรียกว่า alert fatigue

ทางแก้เริ่มจากแบ่ง alert เป็นอย่างน้อยสองระดับ page คือเหตุที่ต้องมีคนลุกมาดูทันที ส่วน ticket คืองานที่เปิดไว้ให้ทีมจัดการในเวลาทำการ ของที่ไม่เข้าทั้งสองระดับ ควรเป็นกราฟใน dashboard ไม่ใช่ข้อความที่ส่งหาใคร

คำถามที่ใช้ตัดสินว่าเงื่อนไขหนึ่งควรเป็น page หรือไม่ หนังสือ SRE ของ Google เสนอไว้เป็นชุด เราสรุปแก่นได้ว่า เงื่อนไขนั้นต้องเร่งด่วน ต้องลงมือแก้ได้ ต้องกระทบผู้ใช้อยู่หรือกำลังจะกระทบ และต้องใช้การตัดสินใจของคน ถ้างานนั้นทำตามสคริปต์ได้ทุกครั้ง ควรทำให้เป็นอัตโนมัติแทนการปลุกคน (อ้างอิง: Google SRE Book)

การทดสอบง่าย ๆ ที่เราใช้คือย้อนดู page ของเดือนที่ผ่านมาทีละรายการ แล้วถามว่าคนที่ถูกปลุกได้ทำอะไรหรือเปล่า ถ้าคำตอบคือเปิดดูแล้วปิดไป รายการนั้นควรลดระดับ หรือแก้เงื่อนไขให้แคบลง

ผูก alert กับ SLO แทนตัวเลข CPU

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

• SLI (Service Level Indicator) ตัวชี้วัดที่วัดจริง เช่น สัดส่วนคำขอที่ตอบสำเร็จภายในเวลาที่กำหนด

• SLO (Service Level Objective) เป้าหมายภายในที่ทีมตั้งให้ SLI เช่น 99.9% ในรอบ 30 วัน

• SLA (Service Level Agreement) คำมั่นในสัญญากับผู้ใช้หรือผู้ว่าจ้าง ซึ่งมักตั้งหลวมกว่า SLO เพื่อให้มีระยะเผื่อ

เรื่อง SLA ในสัญญาดูแลระบบ เราเขียนแยกไว้ในบทความ ก่อนเซ็นสัญญาดูแลระบบรายปี ต้องดูอะไรให้ไม่โดนลอยแพ ส่วนนี้ขอพูดเฉพาะการใช้ SLO ตั้ง alert

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

Google SRE Workbook เสนอค่าเริ่มต้นสำหรับ SLO 99.9% ไว้เป็นตาราง page เมื่อใช้ budget ไป 2% ภายใน 1 ชั่วโมง (burn rate 14.4) page เมื่อใช้ไป 5% ภายใน 6 ชั่วโมง (burn rate 6) และเปิด ticket เมื่อใช้ไป 10% ภายใน 3 วัน (burn rate 1) แต่ละเงื่อนไขต้องผ่านทั้งช่วงเวลายาวและช่วงเวลาสั้นพร้อมกัน เพื่อให้ alert หยุดดังเร็วหลังปัญหาจบ (อ้างอิง: Google SRE Workbook, Alerting on SLOs)

ตัวเลขชุดนี้เป็นจุดเริ่ม ไม่ใช่คำตอบสำเร็จรูป Workbook เองก็ระบุว่าเป็นค่าเริ่มต้นที่ต้องปรับตามระบบ ข้อดีของวิธีนี้คือ ปัญหาเล็กที่ไม่กระทบผู้ใช้ในภาพรวมจะไม่ปลุกใคร ส่วนปัญหาที่กินผู้ใช้จำนวนมากในเวลาสั้นจะถูกจับได้เร็ว

alert ต้องไปถึงคน ไม่ใช่แค่ถูกส่งออกไป

จุดที่ถูกทดสอบน้อยที่สุดในระบบ monitoring คือช่วงสุดท้าย ระหว่างเครื่องมือส่ง alert ออกไป กับคนที่ควรได้รับจริง ๆ อ่านมัน สำหรับองค์กรในไทย มีสองกรณีเฉพาะที่ควรตรวจ

จุดที่ควรตรวจก่อนคือ LINE Notify บริการที่ใช้ส่งข้อความเข้ากลุ่ม LINE ได้ด้วย token เดียว และถูกใช้ส่ง alert อยู่ในหลายระบบ LINE ประกาศยุติบริการนี้เมื่อวันที่ 31 มีนาคม 2025 (พ.ศ. 2568) และแนะนำให้ย้ายไปใช้ Messaging API ผ่าน LINE Official Account แทน (ที่มา: LINE Notify, ประกาศยุติบริการ) ถ้าระบบของคุณยังมีสคริปต์ที่เรียก LINE Notify อยู่ alert ที่ผ่านช่องทางนั้นอาจหายไปเงียบ ๆ โดยไม่มีใครสังเกต ข้อควรรู้ของ Messaging API คือข้อความที่ส่งนับรวมในโควตารายเดือนของ LINE Official Account ซึ่งจำนวนฟรีขึ้นกับแพ็กเกจที่ใช้

อีกจุดคือ SMS และโทรศัพท์จากเครื่องมือของผู้ให้บริการ cloud ต่างประเทศ ตัวอย่างเช่น action group ของ Azure Monitor ส่งได้ทั้งอีเมล SMS โทรศัพท์ และ push แต่ในรายชื่อประเทศที่รองรับ SMS และโทรศัพท์ ซึ่งเราตรวจเมื่อกันยายน 2026 (พ.ศ. 2569) ยังไม่มีประเทศไทย Microsoft แนะนำให้ใช้ webhook ต่อไปยังผู้ให้บริการ SMS ภายนอกที่รองรับแทน (ที่มา: Microsoft Learn, Azure Monitor action groups) ทีมที่ตั้งค่าเบอร์โทรไว้แล้วคิดว่าเสร็จ อาจยังไม่เคยได้รับ SMS จริงสักข้อความ

ทั้งสองกรณีมีทางแก้เดียวกัน คือทดสอบเส้นทางทั้งเส้นเป็นรอบ ยิง alert ทดสอบจากเครื่องมือจริง แล้วดูว่าไปถึงโทรศัพท์ของคนเวรภายในเวลาที่คาดหรือไม่ Azure Monitor มีปุ่มทดสอบ action group ให้ในตัว ส่วนเครื่องมืออื่นทำได้ด้วยการสร้างเงื่อนไขทดสอบที่รู้ว่าจะเกิด อีกข้อที่ควรมีคือช่องทางสำรองอย่างน้อยหนึ่งช่อง เพื่อไม่ให้การแจ้งเตือนทั้งหมดขึ้นกับบริการเดียว

ข้อความ alert ต้องบอกคนรับว่าต้องทำอะไรต่อ

คนที่ถูกปลุกตอนตีสามมีสมาธิน้อยกว่าตอนกลางวันมาก ถ้าข้อความที่ได้รับมีแค่ชื่อ metric กับตัวเลข เช่น error_rate_5m > 0.02 เขาต้องเสียเวลาหลายนาทีแรกไปกับการเดาว่าบริการไหนเสีย กระทบใคร และควรเปิดอะไรดูก่อน เวลาช่วงนี้นับรวมอยู่ในเวลาที่ผู้ใช้ใช้ระบบไม่ได้ทั้งหมด

alert ระดับ page ที่ดีควรตอบคำถามเหล่านี้ได้ในตัวข้อความ บริการไหนมีอาการอะไร เริ่มเมื่อไร กระทบผู้ใช้กลุ่มไหนหรือสัดส่วนเท่าไร และลิงก์ไปยัง dashboard กับ runbook ของบริการนั้น runbook ไม่ต้องยาว ขอแค่บอกว่าควรตรวจอะไรเป็นอันดับแรก ใครคือเจ้าของบริการ และเมื่อไรต้องยกระดับเป็นเหตุ ถ้า alert ข้อไหนเขียน runbook ไม่ได้เพราะไม่รู้ว่าคนรับควรทำอะไร ข้อนั้นมักเป็นสัญญาณว่ามันไม่ควรเป็น page ตั้งแต่แรก

เกณฑ์การยกระดับจาก alert ไปเป็นเหตุที่ต้องเปิดแผนรับมือ ควรเขียนเป็นตัวเลขชุดเดียวกับที่ใช้ใน DR Plan เพื่อให้คนรับ page รู้ว่าตัวเองกำลังอยู่ในจุดที่ต้องโทรปลุกคนอื่นแล้วหรือยัง ไม่ใช่ตัดสินจากความรู้สึกคนเดียวตอนกลางดึก

ใครรับ alert ตอนตีสาม

alert ที่ออกแบบดีทุกข้อ ไม่มีประโยชน์ถ้าตอนตีสามไม่มีใครรับ คำถามนี้ต้องตอบเป็นชื่อคนและตาราง ไม่ใช่คำว่า ทีม IT

หนังสือ SRE ของ Google มีตัวเลขอ้างอิงเรื่องนี้หลายตัว เวลาตอบสนองที่ใช้กันทั่วไปคือ 5 นาทีสำหรับบริการที่ผู้ใช้ใช้งานตรงหรือเร่งด่วนมาก และ 30 นาทีสำหรับระบบที่รอได้มากกว่า ภาระที่รับไหวคือไม่เกิน 2 เหตุต่อเวร 12 ชั่วโมง และทีมที่อยู่สถานที่เดียวต้องมีอย่างน้อย 8 คน จึงจะเข้าเวรตลอด 24 ชั่วโมงแบบมีคนหลักและคนสำรองได้ (อ้างอิง: Google SRE Book, Being On-Call)

ข้อที่ต้องพูดให้ชัดคือ ตัวเลขชุดนี้มาจากองค์กรขนาด Google ถ้าองค์กรของคุณไม่มีคนแปดคนสำหรับเวรระบบเดียว ไม่ควรฝืนทำตาม ถ้าระบบของคุณเป็นระบบภายในที่ใช้งานเฉพาะเวลาทำการ การมีเวรในเวลาทำการ บวกกับ alert ระดับ page เพียงไม่กี่ข้อสำหรับเหตุที่รอถึงเช้าไม่ได้ อาจพอแล้ว ส่วนที่ไม่ควรตัดคือการกำหนดชื่อคนรับ page ในแต่ละช่วง และคนสำรองเมื่อคนแรกไม่ตอบ

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

ข้อโต้แย้งที่ได้ยินบ่อย: ตั้ง alert เยอะไว้ก่อน ปลอดภัยกว่า

เหตุผลเบื้องหลังข้อนี้เข้าใจได้ ไม่มีใครอยากเป็นคนที่ไม่ได้ตั้ง alert ตัวที่จะจับเหตุครั้งถัดไปได้ และทีมที่เคยพลาดเหตุใหญ่มักตอบสนองด้วยการเพิ่มเงื่อนไข

ปัญหาคือ alert ไม่ได้มีต้นทุนเป็นศูนย์ Google SRE Workbook ใช้สองค่าในการประเมิน alert คือ precision สัดส่วนของ alert ที่เป็นเหตุสำคัญจริง และ recall สัดส่วนของเหตุสำคัญที่ถูกจับได้ (อ้างอิง: Google SRE Workbook) การเพิ่ม alert แบบไม่เลือกดัน recall ขึ้นได้จริง แต่ precision จะลดลง และเมื่อ precision ต่ำพอ คนจะเลิกเชื่อ alert ทั้งหมด รวมถึงข้อที่ถูกต้องด้วย

ทางที่ได้ผลกว่าคือเพิ่ม recall ด้วยการวัดให้ถูกจุด ไม่ใช่วัดให้มากจุด alert ที่ผูกกับ symptom ฝั่งผู้ใช้หนึ่งข้อ จับเหตุได้หลายสาเหตุในคราวเดียว โดยไม่ต้องมี alert แยกสำหรับทุกสาเหตุที่นึกออก

ถ้าวันนี้ยังไม่มีอะไรเลย จะเริ่มตรงไหน

ลำดับที่เราแนะนำสำหรับระบบที่ยังไม่มี monitoring เป็นเรื่องเป็นราว หรือมีแต่เชื่อไม่ได้ มีดังนี้ ลำดับนี้ครอบคลุมจุดหลัก ไม่ได้ครบทุกกรณี

1. เลือกบริการที่ผู้ใช้ใช้บ่อยที่สุดหนึ่งถึงสามบริการ ตั้ง uptime check จากภายนอกให้ครบก่อน

2. วัด error rate และ latency ของบริการเหล่านั้นจากฝั่งคำขอ ไม่ใช่จากฝั่งเครื่อง

3. ตั้ง SLO ที่ทีมกับเจ้าของบริการตกลงกันได้ แม้จะเป็นตัวเลขคร่าว ๆ ในรอบแรก

4. ย้าย alert ที่มีอยู่เข้าสองระดับ page กับ ticket และลบข้อที่ไม่เคยมีใครทำอะไรกับมัน

5. กำหนดชื่อคนรับ page และคนสำรอง แล้วทดสอบว่า alert ไปถึงโทรศัพท์ของคนเหล่านั้นจริง

6. ทบทวนรายการ page ทุกเดือน ข้อไหนปลุกคนแล้วไม่ต้องทำอะไร ให้แก้หรือลดระดับ

ถ้าระบบของคุณยังอยู่ระหว่างจัดซื้อ เงื่อนไขเรื่อง monitoring ควรเขียนลงในขอบเขตงานตั้งแต่แรก รวมถึงว่าบัญชีของเครื่องมือ monitoring อยู่ในชื่อใคร เราเล่าหลักคิดเรื่องนี้ไว้ในบทความ เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้

สรุป

ระบบ monitoring ที่ดีไม่ได้วัดจากจำนวนกราฟหรือจำนวน alert แต่วัดจากคำถามเดียว คือเมื่อผู้ใช้เริ่มเจอปัญหา ทีมของคุณรู้ก่อนหรือไม่ ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ตั้ง alert ระดับ page จากสิ่งที่ผู้ใช้เจอ แล้วทดสอบว่ามันไปถึงโทรศัพท์ของคนเวรจริง สองข้อนี้ไม่ต้องรอซื้อเครื่องมือใหม่ และปิดช่องที่ใหญ่ที่สุดได้ก่อน

หากองค์กรของคุณมีระบบ monitoring อยู่แล้วแต่ทีมเริ่มไม่เชื่อ alert หรือยังไม่แน่ใจว่าจะเริ่มวัดจากตรงไหน และอยากให้มีคนช่วยทบทวน เรายินดีคุยด้วย ไม่มีกำหนดเวลาบังคับ และไม่ต้องรีบตัดสินใจ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่กำลังทบทวนระบบแจ้งเตือน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าสิ่งที่มีอยู่เพียงพอแล้ว เราจะบอกตรง ๆ