ระบบมอนิเตอร์เว็บไซต์ของเรา: เกณฑ์แจ้งเตือนด้านความพร้อมใช้งาน ประสิทธิภาพ ข้อผิดพลาด และใบรับรอง
1. การมอนิเตอร์ความพร้อมใช้งาน: ตรวจสอบทุก 5 นาที ล้มเหลวติดกันจึงนับ
การมอนิเตอร์ความพร้อมใช้งานเป็นชั้นพื้นฐานที่สุด: เว็บไซต์เปิดได้หรือไม่ หลายคนใช้การตรวจสอบครั้งเดียวแล้วแจ้งเตือน ผลคือเครือข่ายกระตุกครั้งเดียวก็ปลุกคนทั้งทีม ผ่านไปหนึ่งสัปดาห์ทุกคนก็ปิดการแจ้งเตือน วิธีที่ถูกต้องคือต้องล้มเหลวติดกันจึงนับเป็นเรื่อง ตรวจสอบล้มเหลวติดกัน 2 ครั้งส่งข้อความสีเหลืองเข้ากลุ่ม ล้มเหลวติดกัน 3 ครั้งจึงส่ง SMS และโทรศัพท์ ช่วงห่างการตรวจสอบ 5 นาที จุดตรวจสอบอย่างน้อย 3 จุดทั่วโลก (เช่น สหรัฐอเมริกาฝั่งตะวันออก ยุโรป เอเชียแปซิฟิก) เพื่อหลีกเลี่ยงการแจ้งเตือนผิดจากจุดตรวจสอบเดียว
URL ที่จะมอนิเตอร์อย่ามอนิเตอร์แค่หน้าแรก หน้าแรกอาจยังทำงานได้เพราะแคช แต่หน้าสินค้าหรือฟอร์มสอบถามอาจล่มไปแล้ว อย่างน้อยให้มอนิเตอร์ 3 URL: หน้าแรก หน้ารายละเอียดสินค้าหนึ่งหน้า และปลายทางส่งฟอร์มสอบถาม หากอันใดอันหนึ่งล่มก็นับเป็นความล้มเหลวด้านความพร้อมใช้งาน เครื่องมือใช้ UptimeRobot เวอร์ชันฟรีก็เพียงพอ 50 ช่องมอนิเตอร์ ช่วงห่าง 5 นาที จุดตรวจสอบหลายจุดทั่วโลก
| รายการที่มอนิเตอร์ | ช่วงเวลาตรวจ | เกณฑ์เหลือง | เกณฑ์แดง | ช่องทางแจ้งเตือน |
|---|---|---|---|---|
| สถานะ HTTP หน้าแรก | 5 นาที | ไม่ใช่ 200 ติดกัน 2 ครั้ง | ไม่ใช่ 200 ติดกัน 3 ครั้ง | ข้อความกลุ่ม → SMS โทรศัพท์ |
| หน้ารายละเอียดสินค้า | 5 นาที | ไม่ใช่ 200 ติดกัน 2 ครั้ง | ไม่ใช่ 200 ติดกัน 3 ครั้ง | ข้อความกลุ่ม → SMS โทรศัพท์ |
| ปลายทางฟอร์มสอบถาม | 10 นาที | 5xx ติดกัน 2 ครั้ง | 5xx ติดกัน 3 ครั้ง | ข้อความกลุ่ม → SMS โทรศัพท์ |
| พอร์ต TCP 22/3306 | 5 นาที | เข้าถึงไม่ได้ | — | ข้อความกลุ่ม (เฉพาะเวลาทำงาน) |
| ใบรับรอง SSL | 24 ชั่วโมง | เหลือ 30 วัน | เหลือ 15 วัน | อีเมล → WeCom |
ตัวอย่างสถานการณ์: เว็บไซต์ที่ออกสู่ตลาดต่างประเทศใช้ UptimeRobot มอนิเตอร์หน้าแรก โดยตั้งค่าให้แจ้งเตือนเมื่อล้มเหลวติดต่อกัน 3 ครั้ง คืนหนึ่งจุดตรวจวัดในสิงคโปร์ล้มเหลวติดต่อกัน 3 ครั้ง แต่จุดตรวจวัดในสหรัฐอเมริกาตะวันออกและยุโรปทำงานปกติ นี่คือปัญหาเครือข่ายภายในสิงคโปร์ ไม่ใช่เว็บไซต์ล่ม ถ้าใช้การแจ้งเตือนจากการตรวจวัดครั้งเดียว คนที่เข้าเวรจะถูกปลุกตอนตี 2 พอลุกขึ้นมาดูกลับพบว่าเว็บไซต์ปกติดี ครั้งต่อไปก็จะไม่เชื่ออีก การใช้จุดตรวจวัดหลายจุดร่วมกับความล้มเหลวติดต่อกันช่วยลดอัตราการแจ้งเตือนผิดพลาดให้เหลือน้อยที่สุด
ความพร้อมใช้งานและ RTO/RPO การกู้คืนจากภัยพิบัติ เป็นชุดที่ต้องใช้คู่กัน: เมื่อการแจ้งเตือนความพร้อมใช้งานทำงาน ก็ให้ดำเนินการตามขั้นตอนการกู้คืน เมื่อโหนด CDN ขัดข้องจะตัดสินอย่างไร ดูที่CDN เร่งความเร็วทั่วโลก。
2. การติดตามประสิทธิภาพ: จับตา LCP ไม่ใช่คะแนนรวม
ข้อผิดพลาดที่พบบ่อยที่สุดในการติดตามประสิทธิภาพคือการจับตาคะแนนรวม คะแนน Google PageSpeed ผันผวนมาก หน้าเดียวกันเช้าวัดได้ 85 คะแนน บ่ายวัดได้ 65 คะแนน ความผันผวนแบบนี้แจ้งเตือนไปก็ไม่มีความหมาย สิ่งที่ต้องจับตาจริงๆ คือตัวชี้วัดหลัก 3 ตัวของ Core Web Vitals โดยเฉพาะ LCP (Largest Contentful Paint) เพราะส่งผลโดยตรงต่อการรับรู้ของผู้ใช้และอันดับ SEO
การแจ้งเตือนประสิทธิภาพอย่าใช้เกณฑ์เดียว ต้องใช้ระยะเวลาต่อเนื่อง LCP เกิน 2.5 วินาทีเป็นครั้งคราวอาจเป็นเพราะผู้ใช้บางคนเน็ตไม่ดี ต่อเนื่องเกิน 10 นาทีถึงจะเป็นปัญหาจริง เกณฑ์เหลือง LCP เกิน 2.5 วินาทีต่อเนื่อง 10 นาที เกณฑ์แดง LCP เกิน 4 วินาทีต่อเนื่อง 15 นาที เครื่องมือใช้ BrowserStack SpeedCurve หรือข้อมูลสาธารณะของ Chrome User Experience Report ดูแนวโน้มรายเดือน
| ตัวชี้วัด | เกณฑ์ผ่าน | เกณฑ์เหลือง | เกณฑ์แดง | คำอธิบาย |
|---|---|---|---|---|
| LCP Largest Contentful Paint | ≤2.5 วินาที | >2.5 วินาทีต่อเนื่อง 10 นาที | >4 วินาทีต่อเนื่อง 15 นาที | สำคัญที่สุด ส่งผลโดยตรงต่อ SEO และ conversion |
| INP การตอบสนองต่อการโต้ตอบ | ≤ 200 มิลลิวินาที | >200 มิลลิวินาทีต่อเนื่อง 10 นาที | >500 มิลลิวินาทีต่อเนื่อง 15 นาที | ต้องจับตาอาการหน่วงตอนส่งฟอร์ม |
| CLS การเลื่อนตำแหน่ง | ≤ 0.1 | >0.1 ต่อเนื่อง 10 นาที | >0.25 ต่อเนื่อง 15 นาที | เกิดจากโฆษณาหรือรูปที่ lazy load |
| TTFB เวลาตอบสนองไบต์แรก | ≤600 มิลลิวินาที | >600 มิลลิวินาทีต่อเนื่อง 10 นาที | >1.5 วินาทีต่อเนื่อง 15 นาที | แบ็กเอนด์ช้าหรือปัญหาฐานข้อมูล |
| อัตราข้อผิดพลาดทั้งเว็บ | <1% | >1% ต่อเนื่อง 5 นาที | >5% ต่อเนื่อง 10 นาที | แยกนับ 5xx กับ 4xx |
ตัวอย่างสถานการณ์: เว็บหนึ่งวันหนึ่งตอนเช้า LCP เพิ่มจาก 1.8 วินาทีเป็น 3.5 วินาที ต่อเนื่อง 20 นาทีแล้วกลับมาปกติเอง ตรวจ log พบว่าเป็น slow query ของฐานข้อมูล เพราะ cron job ของปลั๊กอินตัวหนึ่งรัน full table scan ปัญหาแบบนี้ถ้าไม่แจ้งเตือน ใน 20 นาทีนั้นผู้ใช้ที่ส่ง inquiry จะ timeout เสียออร์เดอร์ไปเลย คุณค่าของการติดตามประสิทธิภาพคือการจับความเสื่อมสภาพชั่วขณะแบบนี้ วิธีปรับ Core Web Vitals ดูที่เกณฑ์ Core Web Vitals และลำดับความสำคัญในการปรับ。
3. อัตราข้อผิดพลาดและ log: แยกดู 5xx กับ 4xx
การติดตามอัตราข้อผิดพลาดต้องแยกเป็นสองประเภท: 5xx คือข้อผิดพลาดฝั่งเซิร์ฟเวอร์ ต้องแจ้งเตือน ส่วน 4xx คือข้อผิดพลาดฝั่งไคลเอนต์ ส่วนใหญ่ไม่ต้องสนใจ ถ้ารวมสองประเภทนับด้วยกัน จะแจ้งเตือนมากเกินไป หรือปัญหาจริงถูกกลบไป อัตรา 5xx เกิน 1% ต่อเนื่อง 5 นาทีแจ้งเหลือง เกิน 5% ต่อเนื่อง 10 นาทีแจ้งแดง ส่วน 4xx ติดตามแค่ 404 ที่พุ่งขึ้น เพราะ 404 เยอะแสดงว่ามีลิงก์ภายนอกเสียหรือตอนเปลี่ยนเว็บแล้วตั้ง 301 ตกไป
การติดตามข้อผิดพลาดใช้เครื่องมืออย่าง Sentry ซึ่งเก็บ JS error ฝั่งหน้าบ้านและ exception ฝั่งหลังบ้านอัตโนมัติ จัดกลุ่มตาม error เว็บอิสระไม่จำเป็นต้องตามทุก error แต่ต้องจับตาความถี่ของ TOP 3 error ถ้า error ตัวหนึ่งจู่ๆ จากสัปดาห์ละ 1 ครั้งเป็นชั่วโมงละ 10 ครั้ง แสดงว่าการ deploy เอา bug เข้ามา วิธีวิเคราะห์ log ดูที่การวิเคราะห์ log ของ AI crawler。
| ประเภทความผิด | ค่าพื้นฐานปกติ | เกณฑ์เหลือง | เกณฑ์แดง | วิธีจัดการ |
|---|---|---|---|---|
| 5xx ข้อผิดพลาดฝั่งเซิร์ฟเวอร์ | <0.5% | >1% ต่อเนื่อง 5 นาที | >5% ต่อเนื่อง 10 นาที | ตรวจ log หลังบ้าน rollback หรือเพิ่มทรัพยากร |
| 404 ไม่พบหน้า | <1% | พุ่งขึ้น 3 เท่าต่อเนื่อง 1 ชั่วโมง | พุ่งขึ้น 10 เท่า | ตรวจลิงก์ภายนอกและการตั้ง 301 |
| JS error ฝั่งหน้าบ้าน | <10 ครั้ง/วัน | >50 ครั้ง/วัน | >200 ครั้ง/วัน | จัดกลุ่มด้วย Sentry แล้วตรวจสอบ |
| ส่งฟอร์ม inquiry ไม่สำเร็จ | <1% | >3% ต่อเนื่อง 10 นาที | >10% | ตรวจสอบ SMTP และการซิงค์ CRM |
| เชื่อมต่อฐานข้อมูลไม่สำเร็จ | 0 ครั้ง | ครั้งเดียว | ติดต่อกัน 3 ครั้ง | ตรวจสอบสถานะ MySQL ทันที |
ตัวอย่างสถานการณ์: เว็บหนึ่งปล่อยเวอร์ชันใหม่แล้ว มีข้อผิดพลาด JS ใน Sentry เพิ่มจาก 3 ครั้งต่อวันกระโดดเป็น 200 ครั้งต่อวัน ตรวจโค้ดพบว่าสคริปต์ของตำแหน่งโฆษณาแห่งหนึ่งเกิดข้อผิดพลาดบน Safari ส่งผลกระทบต่อการส่งฟอร์ม ถ้า bug แบบนี้ไม่แจ้งเตือน ลูกค้าที่ใช้ Safari ก็จะสูญเสียโอกาสส่งคำถามไปเลย การติดตามความถี่ข้อผิดพลาดของ Sentry สามารถจับความผิดปกติแบบนี้ได้ภายใน 24 ชั่วโมงหลังปล่อยเวอร์ชัน
สี่ การติดตามใบรับรองและการสำรองข้อมูล: สองสิ่งที่ถูกลืมบ่อยที่สุด
ใบรับรองหมดอายุเป็น “อุบัติเหตุระดับต่ำ” ที่พบบ่อยที่สุดของเว็บไซต์อิสระ 90% ของใบรับรองหมดอายุไม่ใช่ปัญหาเทคนิค แต่เป็นเพราะลืมต่ออายุ การติดตามต้องตั้งสองชั้น: เหลือ 30 วันส่งอีเมลเตือน เหลือ 15 วันแจ้งเตือนผ่าน WeCom อย่ารอจนเหลือ 3 วันค่อยเตือน เพราะตอนนั้นอีเมลของผู้ให้บริการจดทะเบียนโดเมนอาจเข้าไปอยู่ในกล่องสแปมแล้ว หรือ DNS มีปัญหาแก้ไม่ทัน ใช้การติดตามใบรับรองของ UptimeRobot หรือสคริปต์ที่เขียนเองตรวจสอบทุกวัน
ตัวงานสำรองข้อมูลเองก็ต้องถูกติดตามด้วย ถ้าสคริปต์สำรองข้อมูลรันล้มเหลวโดยที่คุณไม่รู้ พอเกิดปัญหาจริงถึงจะพบว่าการสำรองข้อมูลครั้งล่าสุดคือสองสัปดาห์ก่อน กฎแจ้งเตือนสามข้อ: งานสำรองข้อมูลคืนค่า exit code ไม่เป็น 0 ให้แจ้งเตือน; ขนาดไฟล์สำรองข้อมูลลดลงกระทันหัน 30% เทียบกับวันก่อนให้แจ้งเตือน (อาจเชื่อมต่อฐานข้อมูลไม่ได้); อายุไฟล์สำรองข้อมูลล่าสุดเกิน 24 ชั่วโมงให้แจ้งเตือน รายละเอียดกลยุทธ์การสำรองข้อมูลดูที่การสำรองและกู้คืนเว็บไซต์。
| รายการที่มอนิเตอร์ | ความถี่ในการตรวจสอบ | เกณฑ์เหลือง | เกณฑ์แดง | ช่องทางแจ้งเตือน |
|---|---|---|---|---|
| จำนวนวันที่เหลือของใบรับรอง SSL | ทุกวัน | เหลือ 30 วัน | เหลือ 15 วัน | อีเมล → WeCom |
| Exit code ของงานสำรองข้อมูล | ทุกครั้งที่เสร็จ | ไม่เป็น 0 | — | WeCom แจ้งทันที |
| ขนาดไฟล์สำรองข้อมูล | ทุกวัน | ลดลง 30% เทียบกับวันก่อน | ลดลง 70% เทียบกับวันก่อน | WeCom |
| อายุไฟล์สำรองข้อมูล | ทุกวัน | >24 ชั่วโมง | >48 ชั่วโมง | WeCom |
| อัตราการใช้งานดิสก์ | ทุกชั่วโมง | >80% | >90% | WeCom |
| CPU/หน่วยความจำ | ทุก 5 นาที | >80% ต่อเนื่อง 10 นาที | >95% ต่อเนื่อง 10 นาที | WeCom |
เตือนแบบสวนทางความคิด: อย่าใช้ช่องทางแจ้งเตือนเพียงช่องทางเดียว อีเมลเข้าไปในกล่องสแปมง่าย WeCom อาจไม่มีใครดูช่วงลาพักร้อน SMS และโทรศัพท์เป็นด่านสุดท้าย การแจ้งเตือนสำคัญ (เว็บล่ม ใบรับรองใกล้หมดอายุ) ต้องใช้ SMS และโทรศัพท์ ส่วนการแจ้งเตือนทั่วไปใช้กลุ่ม WeCom พร้อมตั้งกลไกยกระดับ: การแจ้งเตือนสีแดงถ้าไม่มีใครจัดการภายใน 15 นาที ให้ยกระดับไปหาผู้รับผิดชอบด้านเทคนิคโดยอัตโนมัติ รายการตรวจสอบประจำวันดูที่งาน 6 อย่างที่ต้องทำทุกเดือนในช่วงดูแลเว็บไซต์。
หลังสร้างระบบติดตามเสร็จ ให้ทบทวนการแจ้งเตือนเดือนละครั้ง: เดือนที่ผ่านมาแจ้งเตือนสีเหลืองกี่ครั้ง สีแดงกี่ครั้ง และมีกี่ครั้งที่เป็นการแจ้งเตือนผิดพลาด เกณฑ์ที่มีอัตราแจ้งเตือนผิดพลาดเกิน 30% ต้องเข้มงวดขึ้นหรือปรับใหม่ เป้าหมายของการติดตามไม่ใช่ครอบคลุมทุกความเป็นไปได้ แต่คือการปลุกคนได้ทันทีเมื่อเกิดปัญหาจริง ซึ่งต้องอาศัยการตัดกฎที่แจ้งเตือนผิดพลาดทุกวันออกอย่างจริงจัง
FAQ คำถามที่พบบ่อย
เว็บไซต์อิสระใช้เครื่องมืออะไรติดตาม แผนฟรีเพียงพอไหม?
แจ้งเตือนเยอะเกินไปจนทีมไม่สนใจ ทำอย่างไรดี?
การติดตามความพร้อมใช้งานควรตรวจทุกกี่นาที?
การติดตามใบรับรอง SSL ควรตั้งค่าเกณฑ์อย่างไร?
การติดตามประสิทธิภาพควรจับตาตัวชี้วัดใด คะแนน PageSpeed ต้องจับตาหรือไม่?
จะมอนิเตอร์งานสำรองข้อมูลล้มเหลวยังไง?
ทิ้งท้าย
ความล้มเหลวที่พบบ่อยที่สุดของระบบมอนิเตอร์ไม่ใช่การไม่มีมอนิเตอร์ แต่คือมอนิเตอร์เยอะเกินจนไม่มีใครดู ตอนเพิ่งตั้งระบบมอนิเตอร์เสร็จอยากจับทุกอย่าง ทั้ง CPU, หน่วยความจำ, ดิสก์, เครือข่าย, ทุก URL, ทุก error พอผ่านไปหนึ่งสัปดาห์การแจ้งเตือนเยอะจนทีมชา จนการแจ้งเตือนสีแดงของเรื่องจริงจมอยู่ในเสียงรบกวนสีเหลือง คุณค่าของมอนิเตอร์อยู่ที่ “ปลุกคนตอนวิกฤต” ไม่ใช่ความครอบคลุม
ลงมือสามขั้น ข้อแรก ตั้งเกณฑ์สองระดับคือเหลืองกับแดงในสี่มิติ (ความพร้อมใช้งาน, ประสิทธิภาพ, error, ใบรับรอง) สีเหลืองแจ้งแค่ในกลุ่มไม่ปลุก สีแดงถึงส่ง SMS และโทร ข้อสอง ใช้เครื่องมือฟรีประกอบกันให้รันได้ UptimeRobot บวก Sentry บวกสคริปต์ใบรับรอง ต้นทุนต่อเดือน 0 บาท ข้อสาม ทบทวนการแจ้งเตือนเดือนละครั้ง ตัดกฎที่มีอัตราแจ้งเตือนผิดเกิน 30% ทิ้ง มอนิเตอร์เป็นระบบที่มีชีวิต ไม่ใช่ตั้งเสร็จแล้วจบ — มันต้องให้คุณตัดแต่งอย่างต่อเนื่อง
ประโยคที่จำได้ง่ายๆ: เป้าหมายของมอนิเตอร์ไม่ใช่ครอบคลุมทุกความเป็นไปได้ แต่คือปลุกคนได้ทันทีเมื่อเกิดเรื่องจริง — การแจ้งเตือนเยอะจนทีมปิดเสียง อันตรายกว่าไม่มีมอนิเตอร์