[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-monitoring-alerting-what-to-page-on-th":3,"blog-post-monitoring-alerting-what-to-page-on-th":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"monitoring คือการเฝ้าดูค่าที่รู้ล่วงหน้าว่าต้องดู เช่น error rate หรือ latency แล้วเตือนเมื่อค่าผิดเกณฑ์ ส่วน observability คือความสามารถของระบบที่จะให้ทีมตั้งคำถามใหม่ที่ไม่ได้เตรียมไว้ แล้วหาคำตอบได้จากข้อมูลที่ระบบเก็บ เช่น log metric และ trace ในทางปฏิบัติ monitoring บอกว่ามีอะไรผิดปกติ ส่วน observability ช่วยตอบว่าทำไม","8owkmppffa3gvfh","monitoring กับ observability ต่างกันอย่างไร",{"answer":9,"id":10,"question":11},"SLI คือตัวชี้วัดที่วัดจริง เช่น สัดส่วนคำขอที่ตอบสำเร็จ SLO คือเป้าหมายภายในที่ทีมตั้งให้ตัวชี้วัดนั้น เช่น 99.9% ในรอบ 30 วัน ส่วน SLA คือคำมั่นที่เขียนในสัญญากับผู้ใช้หรือผู้ว่าจ้าง ซึ่งมักตั้งหลวมกว่า SLO เพื่อให้ทีมรู้ตัวและแก้ไขได้ก่อนจะผิดสัญญา","zlo4upafpwh7gkn","SLI SLO และ SLA ต่างกันอย่างไร",{"answer":13,"id":14,"question":15},"alert fatigue คืออาการที่ทีมได้รับการแจ้งเตือนมากเกินไป จนเริ่มเพิกเฉยหรือปิดเสียง เพราะข้อความส่วนใหญ่ไม่ต้องลงมือทำอะไร ผลที่อันตรายคือ alert ที่สำคัญจริงถูกมองข้ามไปพร้อมกับข้อความอื่น ทางแก้คือแยกระดับ alert และลบเงื่อนไขที่ไม่เคยนำไปสู่การลงมือแก้","0y6i8ts8br9zdwl","alert fatigue คืออะไร",{"answer":17,"id":18,"question":19},"LINE ยุติบริการ LINE Notify เมื่อวันที่ 31 มีนาคม 2025 และแนะนำให้ใช้ Messaging API ผ่าน LINE Official Account แทน ข้อความที่ส่งผ่าน Messaging API นับรวมในโควตารายเดือนของบัญชี ซึ่งจำนวนฟรีขึ้นกับแพ็กเกจ ควรตรวจว่าระบบเดิมไม่มีสคริปต์ที่ยังเรียก LINE Notify อยู่ และไม่ควรให้ LINE เป็นช่องทางแจ้งเตือนเพียงช่องเดียว","4vyganvlll7pt5q","LINE Notify ปิดบริการแล้ว ถ้ายังอยากส่ง alert เข้า LINE ต้องใช้อะไร",{"answer":21,"id":22,"question":23},"MTTD (Mean Time to Detect) คือเวลาเฉลี่ยตั้งแต่ปัญหาเริ่มเกิดจนทีมรู้ตัว ส่วน MTTR มักหมายถึงเวลาเฉลี่ยจนระบบกลับมาใช้งานได้ ระบบ monitoring ที่ออกแบบดีช่วยลด MTTD ได้โดยตรง ควรตกลงกันในทีมก่อนว่า MTTR ในองค์กรของคุณนับจากจุดไหนถึงจุดไหน เพราะแต่ละที่นิยามต่างกัน","vnzf09g7qdqsmtp","MTTD กับ MTTR คืออะไร",{"answer":25,"id":26,"question":27},"เริ่มจากถามว่าระบบนั้นต้องใช้งานนอกเวลาทำการจริงหรือไม่ ถ้าไม่ การมีเวรในเวลาทำการและ alert ระดับ page เพียงไม่กี่ข้อสำหรับเหตุที่รอถึงเช้าไม่ได้อาจเพียงพอ ถ้าระบบมีผู้ดูแลภายนอกตามสัญญา ให้ส่ง alert ถึงผู้ดูแลนั้นโดยตรง และตรวจว่าเวลาตอบสนองในสัญญาครอบคลุมนอกเวลาทำการด้วย","xrj65kwtsorv1tn","องค์กรที่ไม่มีคนพอเข้าเวร 24 ชั่วโมง ควรจัดการ alert อย่างไร",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"1qpo4wvsj3al6vp","ufwv9b5qnvaj3vt","ระบบล่มแต่ผู้ใช้รู้ก่อนทีม IT: ตั้ง monitoring และ alert ให้เตือนเรื่องที่ควรตื่นมาแก้","วิธีคิดเรื่องระบบ monitoring และ alert สำหรับองค์กร ตั้งแต่วัดจากฝั่งผู้ใช้ แยก alert ที่ควรปลุกคนออกจากที่รอถึงเช้าได้ ผูก alert กับ SLO ไปจนถึงจุดที่องค์กรไทยมักสะดุด อย่าง LINE Notify ที่ปิดบริการแล้ว และการกำหนดคนรับ alert ตอนตีสาม","\u003Cp>เช้าวันจันทร์ ฝ่ายบริการลูกค้าส่งข้อความเข้ากลุ่มว่ามีคนโทรมาแจ้งตั้งแต่เจ็ดโมงว่าเข้าระบบไม่ได้ ทีม IT เปิด dashboard ดู ทุกเครื่องยังเขียว CPU ปกติ disk ยังเหลือ และไม่มี alert สักตัวดังตลอดคืน\u003C\u002Fp>\u003Cp>เหตุการณ์แบบนี้ไม่ได้แปลว่าองค์กรไม่มีระบบ monitoring ส่วนใหญ่มี และมีเยอะด้วย ปัญหาคือมันวัดสิ่งที่วัดง่าย ไม่ได้วัดสิ่งที่ผู้ใช้เจอ อีกด้านหนึ่งของปัญหาเดียวกันคือทีมที่ได้รับ alert วันละหลายร้อยข้อความ จนเลิกอ่าน และพลาดข้อความเดียวที่สำคัญจริง\u003C\u002Fp>\u003Cp>บทความนี้เขียนให้คนที่ต้องตัดสินใจว่าระบบขององค์กรจะวัดอะไร เตือนเมื่อไร และเตือนใคร เราจะเล่าวิธีคิดที่ใช้แยก alert ที่ควรปลุกคนตอนตีสามออกจาก alert ที่รอถึงเช้าได้ และจุดที่องค์กรไทยมักสะดุดตอนส่ง alert ให้ถึงมือคนจริง\u003C\u002Fp>\u003Cp>ช่วงที่บทความนี้ครอบคลุมคือก่อนเหตุจะถูกประกาศ ส่วนการตัดสินใจหลังประกาศเหตุแล้ว เราเขียนไว้ในบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fdr-plan-roles-and-decisions-during-an-outage\">DR Plan ที่รอดวันจริง: ใครตัดสินใจ ใครสื่อสาร ตอนระบบล่ม\u003C\u002Fa>\u003C\u002Fp>\u003Ch2>วัดจากฝั่งผู้ใช้ก่อน แล้วค่อยวัดฝั่งเครื่อง\u003C\u002Fh2>\u003Cp>ระบบ monitoring ส่วนใหญ่เริ่มจากสิ่งที่เครื่องมือเก็บให้อัตโนมัติ เช่น CPU หน่วยความจำ และพื้นที่ disk ค่าเหล่านี้มีประโยชน์ตอนหาสาเหตุ แต่บอกได้น้อยมากว่าผู้ใช้กำลังเจออะไร ระบบที่ CPU ต่ำอาจกำลังตอบ error ทุกคำขอ เพราะเชื่อมต่อฐานข้อมูลไม่ได้ ระบบที่ CPU สูงอาจทำงานปกติดีทุกอย่าง\u003C\u002Fp>\u003Cp>หนังสือ Site Reliability Engineering ของ Google แยกเรื่องนี้เป็นสองคำถาม คือ อะไรเสีย (symptom) กับ ทำไมถึงเสีย (cause) ตัวอย่างในหนังสือคือ ระบบตอบ HTTP 500 เป็น symptom ส่วนฐานข้อมูลปฏิเสธการเชื่อมต่อเป็น cause หนังสือแนะนำให้ alert ที่ปลุกคนผูกกับ symptom เป็นหลัก และใช้ข้อมูลภายในระบบไว้หาสาเหตุ (อ้างอิง: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fsre.google\u002Fsre-book\u002Fmonitoring-distributed-systems\u002F\">Google SRE Book, Monitoring Distributed Systems\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>สัญญาณฝั่งผู้ใช้ที่หนังสือเล่มเดียวกันเสนอให้เริ่มวัด มีสี่ตัว เรียกว่า four golden signals\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>Latency เวลาที่ระบบใช้ตอบคำขอ โดยแยกคำขอที่สำเร็จออกจากคำขอที่ล้มเหลว เพราะ error ที่ตอบเร็วจะดึงค่าเฉลี่ยให้ดูดีเกินจริง\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Traffic ปริมาณความต้องการที่เข้ามา เช่น จำนวนคำขอต่อวินาที\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Errors สัดส่วนคำขอที่ล้มเหลว ทั้งที่ระบบรายงานเองและที่ต้องตีความ เช่น ตอบกลับสำเร็จแต่เนื้อหาผิด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Saturation ระบบเต็มแค่ไหน วัดจากทรัพยากรที่ตึงที่สุดของระบบนั้น\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>อีกชั้นที่องค์กรมักขาดคือการวัดจากภายนอก เรียกว่า black-box monitoring คือให้เครื่องมือเรียกหน้าเว็บหรือ API ของคุณจากนอกเครือข่ายเป็นระยะ เหมือนผู้ใช้คนหนึ่ง ถ้า network ขาออกหรือ DNS มีปัญหา เครื่องมือที่อยู่ในเครือข่ายเดียวกับระบบจะมองไม่เห็นเลย ผู้ให้บริการ cloud ที่เราใช้งานอยู่มีบริการแบบนี้ในตัว เช่น uptime check ของ Google Cloud Monitoring และ Health Checks ของ Cloudflare\u003C\u002Fp>\u003Ch2>alert ที่ควรปลุกคน กับ alert ที่รอถึงเช้าได้\u003C\u002Fh2>\u003Cp>ความผิดพลาดที่พบบ่อยที่สุดคือส่งทุกอย่างไปช่องเดียวกัน ด้วยความเร่งด่วนเท่ากัน disk ใช้ไป 80% ถูกส่งเข้ากลุ่มเดียวกับระบบชำระเงินล่ม ผลคือทีมเรียนรู้เร็วมากว่าข้อความส่วนใหญ่ในกลุ่มนั้นไม่ต้องทำอะไร และเริ่มปิดเสียง อาการนี้มีชื่อเรียกว่า alert fatigue\u003C\u002Fp>\u003Cp>ทางแก้เริ่มจากแบ่ง alert เป็นอย่างน้อยสองระดับ page คือเหตุที่ต้องมีคนลุกมาดูทันที ส่วน ticket คืองานที่เปิดไว้ให้ทีมจัดการในเวลาทำการ ของที่ไม่เข้าทั้งสองระดับ ควรเป็นกราฟใน dashboard ไม่ใช่ข้อความที่ส่งหาใคร\u003C\u002Fp>\u003Cp>คำถามที่ใช้ตัดสินว่าเงื่อนไขหนึ่งควรเป็น page หรือไม่ หนังสือ SRE ของ Google เสนอไว้เป็นชุด เราสรุปแก่นได้ว่า เงื่อนไขนั้นต้องเร่งด่วน ต้องลงมือแก้ได้ ต้องกระทบผู้ใช้อยู่หรือกำลังจะกระทบ และต้องใช้การตัดสินใจของคน ถ้างานนั้นทำตามสคริปต์ได้ทุกครั้ง ควรทำให้เป็นอัตโนมัติแทนการปลุกคน (อ้างอิง: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fsre.google\u002Fsre-book\u002Fmonitoring-distributed-systems\u002F\">Google SRE Book\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>การทดสอบง่าย ๆ ที่เราใช้คือย้อนดู page ของเดือนที่ผ่านมาทีละรายการ แล้วถามว่าคนที่ถูกปลุกได้ทำอะไรหรือเปล่า ถ้าคำตอบคือเปิดดูแล้วปิดไป รายการนั้นควรลดระดับ หรือแก้เงื่อนไขให้แคบลง\u003C\u002Fp>\u003Ch2>ผูก alert กับ SLO แทนตัวเลข CPU\u003C\u002Fh2>\u003Cp>เมื่อรู้แล้วว่าควรวัดจากฝั่งผู้ใช้ คำถามถัดมาคือเท่าไรถึงเรียกว่าแย่พอจะปลุกคน คำตอบที่ใช้ได้ยาวคือเอาไปผูกกับเป้าหมายระดับบริการ ซึ่งมีสามคำที่มักมาด้วยกัน\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>SLI (Service Level Indicator) ตัวชี้วัดที่วัดจริง เช่น สัดส่วนคำขอที่ตอบสำเร็จภายในเวลาที่กำหนด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>SLO (Service Level Objective) เป้าหมายภายในที่ทีมตั้งให้ SLI เช่น 99.9% ในรอบ 30 วัน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>SLA (Service Level Agreement) คำมั่นในสัญญากับผู้ใช้หรือผู้ว่าจ้าง ซึ่งมักตั้งหลวมกว่า SLO เพื่อให้มีระยะเผื่อ\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>เรื่อง SLA ในสัญญาดูแลระบบ เราเขียนแยกไว้ในบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fma-sla-contract-checklist-before-signing\">ก่อนเซ็นสัญญาดูแลระบบรายปี ต้องดูอะไรให้ไม่โดนลอยแพ\u003C\u002Fa> ส่วนนี้ขอพูดเฉพาะการใช้ SLO ตั้ง alert\u003C\u002Fp>\u003Cp>ถ้า SLO คือ 99.9% ส่วนที่เหลือ 0.1% คือ error budget หรือปริมาณความผิดพลาดที่ยอมรับได้ในรอบนั้น แทนที่จะเตือนทุกครั้งที่มี error เราดูว่า error budget กำลังถูกใช้เร็วแค่ไหน ค่านี้เรียกว่า burn rate ถ้า burn rate เท่ากับ 1 แปลว่าใช้ budget หมดพอดีตอนสิ้นรอบ\u003C\u002Fp>\u003Cp>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 หยุดดังเร็วหลังปัญหาจบ (อ้างอิง: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fsre.google\u002Fworkbook\u002Falerting-on-slos\u002F\">Google SRE Workbook, Alerting on SLOs\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>ตัวเลขชุดนี้เป็นจุดเริ่ม ไม่ใช่คำตอบสำเร็จรูป Workbook เองก็ระบุว่าเป็นค่าเริ่มต้นที่ต้องปรับตามระบบ ข้อดีของวิธีนี้คือ ปัญหาเล็กที่ไม่กระทบผู้ใช้ในภาพรวมจะไม่ปลุกใคร ส่วนปัญหาที่กินผู้ใช้จำนวนมากในเวลาสั้นจะถูกจับได้เร็ว\u003C\u002Fp>\u003Ch2>alert ต้องไปถึงคน ไม่ใช่แค่ถูกส่งออกไป\u003C\u002Fh2>\u003Cp>จุดที่ถูกทดสอบน้อยที่สุดในระบบ monitoring คือช่วงสุดท้าย ระหว่างเครื่องมือส่ง alert ออกไป กับคนที่ควรได้รับจริง ๆ อ่านมัน สำหรับองค์กรในไทย มีสองกรณีเฉพาะที่ควรตรวจ\u003C\u002Fp>\u003Cp>จุดที่ควรตรวจก่อนคือ LINE Notify บริการที่ใช้ส่งข้อความเข้ากลุ่ม LINE ได้ด้วย token เดียว และถูกใช้ส่ง alert อยู่ในหลายระบบ LINE ประกาศยุติบริการนี้เมื่อวันที่ 31 มีนาคม 2025 (พ.ศ. 2568) และแนะนำให้ย้ายไปใช้ Messaging API ผ่าน LINE Official Account แทน (ที่มา: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fnotify-bot.line.me\u002Fclosing-announce\">LINE Notify, ประกาศยุติบริการ\u003C\u002Fa>) ถ้าระบบของคุณยังมีสคริปต์ที่เรียก LINE Notify อยู่ alert ที่ผ่านช่องทางนั้นอาจหายไปเงียบ ๆ โดยไม่มีใครสังเกต ข้อควรรู้ของ Messaging API คือข้อความที่ส่งนับรวมในโควตารายเดือนของ LINE Official Account ซึ่งจำนวนฟรีขึ้นกับแพ็กเกจที่ใช้\u003C\u002Fp>\u003Cp>อีกจุดคือ SMS และโทรศัพท์จากเครื่องมือของผู้ให้บริการ cloud ต่างประเทศ ตัวอย่างเช่น action group ของ Azure Monitor ส่งได้ทั้งอีเมล SMS โทรศัพท์ และ push แต่ในรายชื่อประเทศที่รองรับ SMS และโทรศัพท์ ซึ่งเราตรวจเมื่อกันยายน 2026 (พ.ศ. 2569) ยังไม่มีประเทศไทย Microsoft แนะนำให้ใช้ webhook ต่อไปยังผู้ให้บริการ SMS ภายนอกที่รองรับแทน (ที่มา: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fazure-monitor\u002Falerts\u002Faction-groups\">Microsoft Learn, Azure Monitor action groups\u003C\u002Fa>) ทีมที่ตั้งค่าเบอร์โทรไว้แล้วคิดว่าเสร็จ อาจยังไม่เคยได้รับ SMS จริงสักข้อความ\u003C\u002Fp>\u003Cp>ทั้งสองกรณีมีทางแก้เดียวกัน คือทดสอบเส้นทางทั้งเส้นเป็นรอบ ยิง alert ทดสอบจากเครื่องมือจริง แล้วดูว่าไปถึงโทรศัพท์ของคนเวรภายในเวลาที่คาดหรือไม่ Azure Monitor มีปุ่มทดสอบ action group ให้ในตัว ส่วนเครื่องมืออื่นทำได้ด้วยการสร้างเงื่อนไขทดสอบที่รู้ว่าจะเกิด อีกข้อที่ควรมีคือช่องทางสำรองอย่างน้อยหนึ่งช่อง เพื่อไม่ให้การแจ้งเตือนทั้งหมดขึ้นกับบริการเดียว\u003C\u002Fp>\u003Ch2>ข้อความ alert ต้องบอกคนรับว่าต้องทำอะไรต่อ\u003C\u002Fh2>\u003Cp>คนที่ถูกปลุกตอนตีสามมีสมาธิน้อยกว่าตอนกลางวันมาก ถ้าข้อความที่ได้รับมีแค่ชื่อ metric กับตัวเลข เช่น error_rate_5m > 0.02 เขาต้องเสียเวลาหลายนาทีแรกไปกับการเดาว่าบริการไหนเสีย กระทบใคร และควรเปิดอะไรดูก่อน เวลาช่วงนี้นับรวมอยู่ในเวลาที่ผู้ใช้ใช้ระบบไม่ได้ทั้งหมด\u003C\u002Fp>\u003Cp>alert ระดับ page ที่ดีควรตอบคำถามเหล่านี้ได้ในตัวข้อความ บริการไหนมีอาการอะไร เริ่มเมื่อไร กระทบผู้ใช้กลุ่มไหนหรือสัดส่วนเท่าไร และลิงก์ไปยัง dashboard กับ runbook ของบริการนั้น runbook ไม่ต้องยาว ขอแค่บอกว่าควรตรวจอะไรเป็นอันดับแรก ใครคือเจ้าของบริการ และเมื่อไรต้องยกระดับเป็นเหตุ ถ้า alert ข้อไหนเขียน runbook ไม่ได้เพราะไม่รู้ว่าคนรับควรทำอะไร ข้อนั้นมักเป็นสัญญาณว่ามันไม่ควรเป็น page ตั้งแต่แรก\u003C\u002Fp>\u003Cp>เกณฑ์การยกระดับจาก alert ไปเป็นเหตุที่ต้องเปิดแผนรับมือ ควรเขียนเป็นตัวเลขชุดเดียวกับที่ใช้ใน DR Plan เพื่อให้คนรับ page รู้ว่าตัวเองกำลังอยู่ในจุดที่ต้องโทรปลุกคนอื่นแล้วหรือยัง ไม่ใช่ตัดสินจากความรู้สึกคนเดียวตอนกลางดึก\u003C\u002Fp>\u003Ch2>ใครรับ alert ตอนตีสาม\u003C\u002Fh2>\u003Cp>alert ที่ออกแบบดีทุกข้อ ไม่มีประโยชน์ถ้าตอนตีสามไม่มีใครรับ คำถามนี้ต้องตอบเป็นชื่อคนและตาราง ไม่ใช่คำว่า ทีม IT\u003C\u002Fp>\u003Cp>หนังสือ SRE ของ Google มีตัวเลขอ้างอิงเรื่องนี้หลายตัว เวลาตอบสนองที่ใช้กันทั่วไปคือ 5 นาทีสำหรับบริการที่ผู้ใช้ใช้งานตรงหรือเร่งด่วนมาก และ 30 นาทีสำหรับระบบที่รอได้มากกว่า ภาระที่รับไหวคือไม่เกิน 2 เหตุต่อเวร 12 ชั่วโมง และทีมที่อยู่สถานที่เดียวต้องมีอย่างน้อย 8 คน จึงจะเข้าเวรตลอด 24 ชั่วโมงแบบมีคนหลักและคนสำรองได้ (อ้างอิง: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fsre.google\u002Fsre-book\u002Fbeing-on-call\u002F\">Google SRE Book, Being On-Call\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>ข้อที่ต้องพูดให้ชัดคือ ตัวเลขชุดนี้มาจากองค์กรขนาด Google ถ้าองค์กรของคุณไม่มีคนแปดคนสำหรับเวรระบบเดียว ไม่ควรฝืนทำตาม ถ้าระบบของคุณเป็นระบบภายในที่ใช้งานเฉพาะเวลาทำการ การมีเวรในเวลาทำการ บวกกับ alert ระดับ page เพียงไม่กี่ข้อสำหรับเหตุที่รอถึงเช้าไม่ได้ อาจพอแล้ว ส่วนที่ไม่ควรตัดคือการกำหนดชื่อคนรับ page ในแต่ละช่วง และคนสำรองเมื่อคนแรกไม่ตอบ\u003C\u002Fp>\u003Cp>ถ้าระบบมีผู้ดูแลภายนอกตามสัญญา ให้ตรวจว่าเวลาตอบสนองในสัญญาใช้กับช่วงนอกเวลาทำการด้วยหรือไม่ และ alert ถูกส่งไปถึงผู้ดูแลภายนอกโดยตรง หรือต้องรอให้พนักงานขององค์กรเห็นก่อนแล้วค่อยโทรแจ้ง ช่องว่างตรงนี้อาจกินเวลามากกว่าเวลาแก้ปัญหาจริง\u003C\u002Fp>\u003Ch2>ข้อโต้แย้งที่ได้ยินบ่อย: ตั้ง alert เยอะไว้ก่อน ปลอดภัยกว่า\u003C\u002Fh2>\u003Cp>เหตุผลเบื้องหลังข้อนี้เข้าใจได้ ไม่มีใครอยากเป็นคนที่ไม่ได้ตั้ง alert ตัวที่จะจับเหตุครั้งถัดไปได้ และทีมที่เคยพลาดเหตุใหญ่มักตอบสนองด้วยการเพิ่มเงื่อนไข\u003C\u002Fp>\u003Cp>ปัญหาคือ alert ไม่ได้มีต้นทุนเป็นศูนย์ Google SRE Workbook ใช้สองค่าในการประเมิน alert คือ precision สัดส่วนของ alert ที่เป็นเหตุสำคัญจริง และ recall สัดส่วนของเหตุสำคัญที่ถูกจับได้ (อ้างอิง: \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fsre.google\u002Fworkbook\u002Falerting-on-slos\u002F\">Google SRE Workbook\u003C\u002Fa>) การเพิ่ม alert แบบไม่เลือกดัน recall ขึ้นได้จริง แต่ precision จะลดลง และเมื่อ precision ต่ำพอ คนจะเลิกเชื่อ alert ทั้งหมด รวมถึงข้อที่ถูกต้องด้วย\u003C\u002Fp>\u003Cp>ทางที่ได้ผลกว่าคือเพิ่ม recall ด้วยการวัดให้ถูกจุด ไม่ใช่วัดให้มากจุด alert ที่ผูกกับ symptom ฝั่งผู้ใช้หนึ่งข้อ จับเหตุได้หลายสาเหตุในคราวเดียว โดยไม่ต้องมี alert แยกสำหรับทุกสาเหตุที่นึกออก\u003C\u002Fp>\u003Ch2>ถ้าวันนี้ยังไม่มีอะไรเลย จะเริ่มตรงไหน\u003C\u002Fh2>\u003Cp>ลำดับที่เราแนะนำสำหรับระบบที่ยังไม่มี monitoring เป็นเรื่องเป็นราว หรือมีแต่เชื่อไม่ได้ มีดังนี้ ลำดับนี้ครอบคลุมจุดหลัก ไม่ได้ครบทุกกรณี\u003C\u002Fp>\u003Col>\u003Cli>\u003Cp>เลือกบริการที่ผู้ใช้ใช้บ่อยที่สุดหนึ่งถึงสามบริการ ตั้ง uptime check จากภายนอกให้ครบก่อน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>วัด error rate และ latency ของบริการเหล่านั้นจากฝั่งคำขอ ไม่ใช่จากฝั่งเครื่อง\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ตั้ง SLO ที่ทีมกับเจ้าของบริการตกลงกันได้ แม้จะเป็นตัวเลขคร่าว ๆ ในรอบแรก\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ย้าย alert ที่มีอยู่เข้าสองระดับ page กับ ticket และลบข้อที่ไม่เคยมีใครทำอะไรกับมัน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>กำหนดชื่อคนรับ page และคนสำรอง แล้วทดสอบว่า alert ไปถึงโทรศัพท์ของคนเหล่านั้นจริง\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ทบทวนรายการ page ทุกเดือน ข้อไหนปลุกคนแล้วไม่ต้องทำอะไร ให้แก้หรือลดระดับ\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Fol>\u003Cp>ถ้าระบบของคุณยังอยู่ระหว่างจัดซื้อ เงื่อนไขเรื่อง monitoring ควรเขียนลงในขอบเขตงานตั้งแต่แรก รวมถึงว่าบัญชีของเครื่องมือ monitoring อยู่ในชื่อใคร เราเล่าหลักคิดเรื่องนี้ไว้ในบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\">เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้\u003C\u002Fa>\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>สรุป\u003C\u002Fh2>\u003Cp>ระบบ monitoring ที่ดีไม่ได้วัดจากจำนวนกราฟหรือจำนวน alert แต่วัดจากคำถามเดียว คือเมื่อผู้ใช้เริ่มเจอปัญหา ทีมของคุณรู้ก่อนหรือไม่ ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ตั้ง alert ระดับ page จากสิ่งที่ผู้ใช้เจอ แล้วทดสอบว่ามันไปถึงโทรศัพท์ของคนเวรจริง สองข้อนี้ไม่ต้องรอซื้อเครื่องมือใหม่ และปิดช่องที่ใหญ่ที่สุดได้ก่อน\u003C\u002Fp>\u003Cp>หากองค์กรของคุณมีระบบ monitoring อยู่แล้วแต่ทีมเริ่มไม่เชื่อ alert หรือยังไม่แน่ใจว่าจะเริ่มวัดจากตรงไหน และอยากให้มีคนช่วยทบทวน เรายินดีคุยด้วย ไม่มีกำหนดเวลาบังคับ และไม่ต้องรีบตัดสินใจ\u003C\u002Fp>\u003Cp>หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล contact@superdev.tech สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่กำลังทบทวนระบบแจ้งเตือน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าสิ่งที่มีอยู่เพียงพอแล้ว เราจะบอกตรง ๆ\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002F1qpo4wvsj3al6vp\u002Fcover_cover_ehaiq31tsc.webp","25 กันยายน 2569","2026-09-25 11:10:14.564Z",117,"Enterprise","enterprise","monitoring-alerting-what-to-page-on","\u002Fblogs\u002Fmonitoring-alerting-what-to-page-on",4,false,0,"",[47,48,49,50,51,52],"ระบบ monitoring","alert fatigue","SLI SLO SLA","error budget","on-call","LINE Notify"]