การตรวจสอบและแจ้งเตือนเว็บไซต์: ความพร้อมใช้งาน ใบรับรอง ฟอร์ม และความผิดปกติของบอท

การตรวจสอบและแจ้งเตือนเว็บไซต์: ความพร้อมใช้งาน ใบรับรอง ฟอร์ม และความผิดปกติของบอท

สรุปก่อน: รูปแบบทั่วไปของเหตุการณ์เว็บไซต์ไม่ใช่ “พัง” แต่คือ “พังมาหลายวันแล้วไม่มีใครรู้” เป้าหมายของการตรวจสอบคือลดเวลาค้นพบจากระดับสัปดาห์เหลือระดับนาที: การตรวจสอบ 5 ประเภท ได้แก่ ตรวจสอบความพร้อมใช้งานทุก 1-5 นาที แจ้งเตือนก่อนใบรับรองหมดอายุ 30 วัน ตรวจสอบการส่งฟอร์มด้วยตนเองทุก 15-60 นาที ตรวจความผิดปกติของจำนวนหน้าที่ถูกจัดเก็บแบบเทียบสัปดาห์ และตรวจสอบผลการสำรองข้อมูลทุกวัน พร้อมการแจ้งเตือน 3 ระดับ P0/P1/P2 ตั้งค่าให้ครบในครั้งเดียวตอนส่งมอบเว็บไซต์ใหม่

1. เวลาที่ใช้ค้นพบเป็นตัวกำหนดขนาดของความเสียหาย

ขีดขอบเขตก่อน:การดูแลรายเดือน อธิบายว่างานประจำเดือนต้องทำอะไรบ้าง การซ้อมกู้คืนข้อมูลสำรอง อธิบายว่าข้อมูลสำรองกู้คืนได้หรือไม่วินิจฉัยการติดดัชนี อธิบายวิธีตรวจหาความผิดปกติของจำนวนหน้าที่ถูกจัดเก็บ บทความนี้พูดถึงเพียงคำถามพื้นฐานข้อหนึ่ง นั่นคือ การกระทำเหล่านี้มีเกณฑ์ในการถูกค้นพบและถูกกระตุ้นมาจากไหน หากไม่มีการตรวจสอบ การบำรุงรักษาก็เดินแบบไม่เห็นทาง เมื่อมีการตรวจสอบ การแจ้งเตือนจึงชี้ไปยังความผิดพลาดที่เจาะจงได้

เหตุการณ์ส่วนใหญ่ของเว็บไซต์องค์กรไม่ใช่หายนะ แต่เป็นแบบเรื้อรัง: ใบรับรองหมดอายุทำให้ทั้งเว็บเปิดไม่ได้ ฟอร์มล้มเหลวเงียบ ๆ มาหนึ่งสัปดาห์ จำนวนหน้าที่ถูกจัดเก็บลดฮวบโดยไม่มีใครรู้ แต่ละกรณีมีความเสียหายที่ตารางเดียวอธิบายได้ชัดเจน

สถานการณ์เหตุการณ์	เวลาที่มักค้นพบเมื่อไม่มีการตรวจสอบ	เวลาที่ค้นพบเมื่อมีการตรวจสอบ	ผลกระทบโดยตรง
ใบรับรองหมดอายุ	1–7 วัน	แจ้งเตือนก่อนหมดอายุ 30 วัน	ทั้งเว็บเข้าไม่ได้ ลูกค้าหาย
ฟอร์มล้มเหลวเงียบ ๆ	3-14 วัน	แจ้งเตือนทันทีเมื่อตรวจสอบด้วยตนเองล้มเหลว 2 ครั้งติดกัน	สูญเสียลีดทั้งหมดโดยไม่รู้ตัว
เว็บไซต์ถูกฝังโค้ดอันตราย	หลายสัปดาห์	แจ้งเตือนความผิดปกติของจำนวนหน้าที่ถูกจัดเก็บและเนื้อหา	ผลการค้นหาคำแบรนด์ถูกปนเปื้อน
จำนวนหน้าที่ถูกจัดเก็บลดลงอย่างรวดเร็ว	1–2 เดือน	แจ้งเตือนเมื่อเทียบสัปดาห์เกินเกณฑ์	ทราฟฟิกลดลงต่อเนื่องโดยไม่มีใครจัดการ
โฮสต์ล่ม	หลายชั่วโมงถึงหลายวัน	แจ้งเตือนเมื่อตรวจสอบการเชื่อมต่อล้มเหลว 2 ครั้งติดกัน	ลีดถูกตัดขาด

สรุปสั้น ๆ: สิ่งที่การตรวจสอบซื้อมาด้วยเงินไม่ใช่ซอฟต์แวร์ แต่คือเวลาที่ใช้ค้นพบ เมื่อลดจากระดับสัปดาห์เหลือระดับนาที ความเสียหายจากลีดก็เปลี่ยนจาก “หายทั้งชุด” เป็น “หลุดไม่กี่รายการ” นี่คือความหมายทั้งหมด

2. ตารางรวมการตรวจสอบ 5 ประเภทและเกณฑ์

การตรวจสอบ 5 ประเภทครอบคลุมเส้นทางสำคัญทั้งหมดของเว็บไซต์ B2B เกณฑ์สามารถคัดลอกไปใช้ได้เลย

ประเภทการตรวจสอบ	สิ่งที่ตรวจสอบ	ความถี่และเกณฑ์ที่แนะนำ	เงื่อนไขการแจ้งเตือน
ความพร้อมใช้งาน	สถานะ HTTP และเวลาตอบสนอง	ตรวจสอบทุก 1-5 นาที อย่างน้อย 2 โหนดภายนอก	ล้มเหลว 2 ครั้งติดกัน; เวลาตอบสนองเกิน 5 วินาที 3 ครั้งติดกัน
ใบรับรองและโดเมน	อายุ SSL การหมดอายุของโดเมน บันทึก DNS	ตรวจสอบทุกวัน แจ้งเตือนล่วงหน้าทีละระดับที่ 30/14/7 วันก่อนหมดอายุ	เหลือเวลาไม่ถึง 30 วันก่อนหมดอายุ; บันทึก DNS เปลี่ยนแปลง
ฟอร์มและอีเมล	ตรวจสอบเส้นทางการส่งด้วยตนเอง อีเมลตีกลับ	ส่งตรวจสอบด้วยตนเองทุก 15-60 นาที	ไม่ได้รับการส่งตรวจสอบด้วยตนเอง 2 ครั้งติดกัน; อัตราอีเมลตีกลับเกิน 2%
บอทและจำนวนหน้าที่ถูกจัดเก็บ	สถานะการดึง URL หลัก จำนวนหน้าที่ถูกจัดทำดัชนี	ตรวจสอบจำนวนการจัดทำดัชนีและข้อผิดพลาด sitemap สัปดาห์ละครั้ง	จำนวนการจัดทำดัชนีลดลงเกิน 20% เมื่อเทียบสัปดาห์ก่อน; sitemap มีข้อผิดพลาดใหม่
การสำรองข้อมูลและการอัปเดต	ผลลัพธ์งานสำรองข้อมูล, การทดสอบหลังอัปเดต	ตรวจสอบการสำรองข้อมูลทุกวัน; ตรวจหน้าจอขาวภายใน 1 ชั่วโมงหลังอัปเดตคอมโพเนนต์	การสำรองข้อมูลล้มเหลว; หน้าแรกหรือหน้าแบบฟอร์มตอบกลับผิดปกติหลังอัปเดต

ตารางนี้คือหัวใจของทั้งบท ส่วนหัวข้อถัดไปจะลงรายละเอียดการตั้งค่า เกณฑ์ตัดสินว่าตั้งค่าครบหรือไม่ก็ง่ายมาก: ไล่ถามทีละแถวว่า “ใครดู ดูบ่อยแค่ไหน ผิดปกติแล้วแจ้งใคร” ถ้าสามคำถามนี้ตอบไม่ได้ข้อใดข้อหนึ่ง แถวนั้นก็เท่ากับยังไม่ได้ตั้งค่า

สาม รายละเอียดการตั้งค่าด้านความพร้อมใช้งานและโดเมนใบรับรอง

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

รายการตั้งค่า	แนวทางที่แนะนำ	ข้อผิดพลาดที่พบบ่อย
โหนดโพรบ	อย่างน้อย 2 โหนดภายนอก ต่างภูมิภาค (เช่น 1 โหนดต่างประเทศ 1 โหนดในประเทศ)	โพรบอยู่เครื่องเดียวกับเว็บที่มอนิเตอร์ พอเว็บล่มโพรบก็เงียบไปด้วย
เส้นทางที่ตรวจ	หน้าแรกบวกหน้าแบบฟอร์มและหน้าสินค้าหลักอีกหน้าหนึ่ง	ตรวจแค่หน้าแรก แคช CDN บังปัญหาของหน้าภายในไว้
เงื่อนไขตัดสิน	แจ้งเตือนเมื่อล้มเหลวติดกัน 2 ครั้ง เกณฑ์เวลาตอบสนอง 5 วินาที	แจ้งเตือนตั้งแต่ล้มเหลวครั้งแรก เครือข่ายกระตุกก็ส่งเสียงรบกวนทุกวัน
ช่วงเวลาตรวจ	1–5 นาที; เว็บสำคัญใช้ 1 นาที	ตรวจทุก 30 นาที เว็บล่มไปชั่วโมงกว่าจะดัง

ตารางเวลาของใบรับรองและโดเมนเป็นรายการที่ประหยัดแรงที่สุดและได้ผลแน่นอนที่สุดในทั้งบท เพราะเป็นการ “แจ้งล่วงหน้า” ไม่ใช่ “แจ้งหลังเกิดเหตุ”

รายการตรวจสอบ	จุดเวลาที่แจ้งเตือน	การดำเนินการ
อายุใบรับรอง SSL	แจ้งเตือนครั้งหนึ่งเมื่อเหลือ 30 วัน 14 วัน และ 7 วันก่อนหมดอายุ	ตรวจสอบว่างานต่ออายุอัตโนมัติยังทำงานอยู่หรือไม่ (ใบรับรอง Let’s Encrypt ต่ออายุทุก 90 วัน)
โดเมนหมดอายุ	แจ้งเตือนครั้งหนึ่งเมื่อเหลือ 60 วัน และ 30 วันก่อนหมดอายุ	ยืนยันว่าบัญชีผู้จดทะเบียนและวิธีต่ออายุใช้ได้ เปิดต่ออายุอัตโนมัติ
การเปลี่ยนแปลงระเบียน DNS	แจ้งเตือนทันทีที่มีการเปลี่ยนแปลง	ตรวจสอบการเปลี่ยนแปลงระเบียน A และ MX ที่ไม่ได้วางแผนไว้ทันที

การแจ้งเตือนการเปลี่ยนแปลง DNS มักถูกตัดออก แต่จริง ๆ แล้วมันคือสัญญาณแรกของการจี้โดเมน: การแปลงชื่อถูกเปลี่ยนทาง ตัวเว็บไม่มีอะไรผิดปกติ แต่ทราฟฟิกกลับไปที่อื่น รายการนี้มีต้นทุนเกือบศูนย์ต่อวัน คุ้มค่าที่จะตั้งไว้

สี่ ฟอร์ม อีเมล และการจัดทำดัชนีของบอต

ตรรกะของการมอนิเตอร์ฟอร์มไม่ใช่ “หน้าเว็บเปิดได้ไหม” แต่เป็น “ส่งแล้วของถึงปลายทางไหม” หน้าที่ปกติแต่เส้นทางส่งต่อขาด คือความล้มเหลวที่ซ่อนลึกและแพงที่สุดของเว็บ B2B——ลูกค้าคิดว่าส่งคำถามไปแล้ว แต่ฝั่งคุณไม่ได้รับสักฉบับ

วิธีมอนิเตอร์	แนวทาง	การตัดสินและการแจ้งเตือน
ส่งทดสอบด้วยตัวเอง	ใช้สคริปต์หรือเครื่องมือบุคคลที่สามส่งคำถามทดสอบทุก 15–60 นาที	ผ่านเมื่อได้รับคำถามทดสอบและฟิลด์ครบถ้วน; ล้มเหลวติดกัน 2 ครั้งแจ้งเตือน P0
ตรวจสอบฝั่งผู้รับ	ตั้งชื่ออีเมลทดสอบตามรูปแบบคงที่ (เช่น test+เวลาประทับ@โดเมน) เพื่อให้กรองและตรวจสอบง่าย	ถ้าไม่ถึงตามเวลาที่กำหนด แปลว่าขาดตอนที่ชั้นอีเมล
มอนิเตอร์อีเมลตีกลับ	มอนิเตอร์การแจ้งเตือนอีเมลตีกลับของอีเมลผู้ส่ง	อัตราตีกลับเกิน 2% ให้ตรวจสอบการตั้งค่า SPF, DKIM, DMARC
ลิงก์เสียและการตรวจซ้ำการนำส่ง	เดินจริงผ่านฟอร์มทุกไตรมาส	เทียบกับผลตรวจอัตโนมัติ เพื่อไม่ให้สคริปต์ตรวจสอบเองล้มเหลวโดยไม่รู้ตัว

การมอนิเตอร์การเก็บข้อมูลของ crawler และการจัดทำดัชนีไม่จำเป็นต้องทำบ่อย สัปดาห์ละครั้งก็เพียงพอ ดูสามตัวชี้วัด: สถานะการดึงข้อมูลของ URL สำคัญ (หน้าแรก หน้าสินค้าหลัก หน้าสอบถาม) จำนวนข้อผิดพลาดในการดึงข้อมูลหลังส่ง sitemap และจำนวนหน้าที่ถูกจัดทำดัชนีเทียบสัปดาห์ก่อน จำนวนที่ถูกจัดทำดัชนีมีความผันผวนตามธรรมชาติ ถ้าลดลงไม่เกิน 20% เทียบสัปดาห์ก่อนไม่ต้องกังวล ถ้าเกิน 20% หรือลดลงต่อเนื่องสองสัปดาห์จึงควรแจ้งเตือน วิธีตรวจสอบสถานะการดึงข้อมูลที่ผิดปกติมีขั้นตอนครบถ้วนใน วินิจฉัยการติดดัชนี บทความหนึ่ง การมอนิเตอร์มีหน้าที่แค่ส่งสัญญาณ “ถึงเวลาตรวจแล้ว” ให้ตรงเวลาเท่านั้น ส่วนผลงานสำรองข้อมูลแค่ตรวจสอบทุกวันว่าสำเร็จหรือไม่ ส่วนความสามารถในการกู้คืนนั้นอาศัยการซ้อม ไม่ใช่การมอนิเตอร์

ห้า การจัดระดับการแจ้งเตือน ช่องทาง และการจัดการแจ้งเตือนเท็จ

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

ระดับ	เกณฑ์ตัดสิน	ช่องทางและข้อกำหนดการตอบสนอง
P0	เว็บไซต์เข้าไม่ได้เกิน 5 นาที ฟอร์มส่งไม่สำเร็จติดต่อกัน 2 ครั้ง พบสัญญาณถูกฝังมัลแวร์	โทรหรือบอทแชทเรียกคนเข้าเวรโดยตรง ตอบสนองภายใน 30 นาที
P1	ใบรับรองเหลืออายุไม่ถึง 14 วัน จำนวนหน้าที่ถูกจัดทำดัชนีลดลงเกิน 20% เทียบสัปดาห์ก่อน เวลาตอบสนองเกิน 5 วินาทีต่อเนื่อง	แจ้งทางอีเมลและกลุ่มแชท ดำเนินการภายใน 24 ชั่วโมง
P2	ใบรับรองเหลืออายุ 30 วัน สำรองข้อมูลล้มเหลวครั้งเดียวแต่กู้คืนได้วันถัดไป ตัวชี้วัดแนวโน้มที่ค่อยๆ เปลี่ยน	ใส่ในรายงานสัปดาห์ ทบทวนในที่ประชุม

การจัดการแจ้งเตือนเท็จมีกฎตายตัวข้อหนึ่ง: รายการมอนิเตอร์ที่แจ้งเตือนเท็จบ่อยในช่วงสามเดือนติดต่อกัน ต้องปรับค่า threshold หรือปิดไป ไม่มีทางเลือกที่สาม ทุกกฎการแจ้งเตือนต้องมีผู้รับผิดชอบ ถ้ากฎไหนแจ้งเตือนแล้วไม่มีใครรับ เท่ากับไม่ได้ตั้งค่า แหล่งแจ้งเตือนเท็จที่พบบ่อยและวิธีจัดการ: ล้มเหลวครั้งเดียวจากเครือข่ายกระตุก (แก้ด้วยการตัดสินจาก 2 ครั้งติดกัน) หน้าในเว็บตรวจไม่เจอเพราะ CDN cache (เพิ่มจุดตรวจจับที่หน้าฟอร์ม) ผู้ให้บริการอีเมลตีว่าเมลทดสอบเป็นสแปม (เพิ่มอีเมลทดสอบลง whitelist)

หก การเข้าเวรตอบสนองและเช็กลิสต์ก่อนเปิดเว็บใหม่

เมื่อการแจ้งเตือนดังแล้วต้องทำอะไร ต้องกำหนดไว้ก่อนเกิดเหตุ การดำเนินการสามระดับเรียงตามเวลา:

ระดับการตอบสนอง	เงื่อนไขที่กระตุ้น	การดำเนินการ	กรอบเวลาที่ตั้งไว้
ระดับหนึ่ง	จุดเดียวล้มเหลว กู้คืนได้เร็ว	รีสตาร์ทเซอร์วิส ย้อนกลับการอัปเดตล่าสุด	ภายใน 15 นาที
ระดับสอง	ระดับหนึ่งไม่ได้ผลหรือความเสียหายขยายวง	สลับไปใช้หน้า static cache ไว้ให้เข้าถึงจากภายนอกได้	ภายใน 1 ชั่วโมง
ระดับสาม	ซ่อมไม่เสร็จในระยะสั้น	หยุดเดา ประกาศแจ้งและส่งต่อให้ทีมสนับสนุนภายนอก	ภายใน 4 ชั่วโมง

การจัดคนเข้าเวรตอบคำถามเดียวก็พอ: ใครจัดการได้ตอนกลางคืน เว็บ B2B ไม่จำเป็นต้องมีคนเข้าเวร 24 ชั่วโมง แต่การแจ้งเตือนระดับ P0 ต้องมีคนอย่างน้อยหนึ่งคนที่ถูกปลุกตอนกลางคืนได้และมีสิทธิ์เข้าถึงเซิร์ฟเวอร์ ถ้าไม่มีคนนี้ ต่อให้ตั้งค่ามอนิเตอร์ครบแค่ไหนก็แค่ “รู้ตอนเช้าวันรุ่งขึ้น”

ตอนส่งมอบเว็บไซต์ใหม่ ตั้งค่าการมอนิเตอร์ให้ครบในครั้งเดียว โดยรายการคงที่คือมอนิเตอร์ 5 รายการบวกผู้รับแจ้งเตือน 3 คน

รายการที่ต้องมีตอนส่งมอบ	เนื้อหา
มอนิเตอร์ 5 รายการ	ความพร้อมใช้งาน, โดเมนและใบรับรอง, การส่งฟอร์ม, รายงานสรุปการถูกจัดทำดัชนีรายสัปดาห์, ผลการสำรองข้อมูล ตั้งค่าตามเกณฑ์ในหัวข้อที่ 2
ผู้รับ 3 คน	คนเข้าเวร P0, หัวหน้าฝ่ายเทคนิค P1, ผู้ประสานงานประจำ P2 โดยเชื่อมช่องทางของแต่ละคนให้ครบ และซ้อมแจ้งเตือนจริงหนึ่งครั้ง

เจ็ด ใช้ข้อมูลการแจ้งเตือนย้อนกลับมาปรับปรุง และเมื่อไหร่ที่ไม่ต้องสร้างระบบเอง

การมอนิเตอร์ไม่ใช่แค่ระบบดับเพลิง แต่ยังเป็นตัวตรวจจับจุดที่ควรปรับปรุงด้วย ทุกไตรมาสให้ทบทวนหนึ่งครั้ง ดูตัวเลขสามตัว ได้แก่ จำนวนแจ้งเตือนทั้งหมด สัดส่วนที่เป็นเหตุขัดข้องจริง และประเภทปัญหาที่เกิดซ้ำ ถ้าสัดส่วนเหตุขัดข้องจริงต่ำกว่า 30% แปลว่ากฎแจ้งเตือนส่งเสียงรบกวนเกินไป ต้องปรับให้เงียบลง ถ้าปัญหาประเภทเดียวกันเกิดซ้ำตั้งแต่สองครั้งขึ้นไปในหนึ่งไตรมาส ก็ควรยกระดับจาก “รอแจ้งเตือนแล้วค่อยรู้” เป็น “แก้ถาวร” เช่น ถ้าการส่งอีเมลสะดุดซ้ำ ๆ ก็ควรเปลี่ยนวิธีส่งอีเมลแทนที่จะปล่อยให้กฎแจ้งเตือนนั้นค้างอยู่ การทบทวนชุดนี้สามารถรวมไว้ในหัวข้อฉบับรายไตรมาสของการบำรุงรักษารายเดือน เพื่อให้ดำเนินการเป็นประจำ

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

FAQ คำถามที่พบบ่อย

เว็บไซต์เล็กก็ต้องตั้งมอนิเตอร์ไหม?

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

เครื่องมือมอนิเตอร์แบบฟรีเพียงพอไหม?

ส่วนใหญ่เพียงพอ แพ็กเกจฟรีของบริการตรวจสอบจากภายนอกมักให้ความถี่ 1–5 นาทีและการตรวจจากหลายโหนด ซึ่งผ่านเกณฑ์ความอ่านง่ายในหัวข้อที่สอง มีข้อจำกัดสองอย่างที่ต้องระวัง แพ็กเกจฟรีมีโหนดน้อย บางครั้งโหนดเดียวอาจแจ้งเตือนผิดพลาด ต้องใช้กฎ “ล้มเหลวติดกัน 2 ครั้ง” มากรอง และแพ็กเกจฟรีมักรองรับแค่การตรวจสอบผ่าน HTTP การตรวจสอบการส่งฟอร์มด้วยตัวเองต้องเขียนสคริปต์เองหรือใช้ความสามารถตรวจสอบด้วยสคริปต์ของแพ็กเกจแบบเสียเงิน เกณฑ์ตัดสินงบประมาณ คือ ถ้าค่ามอนิเตอร์ต่อปีต่ำกว่าความเสียหายจากเหตุใบรับรองหมดอายุหนึ่งครั้ง ก็คุ้มที่จะตั้ง

แจ้งเตือนเยอะจนคนชาไปแล้วทำยังไง

จัดระเบียบตามกฎลด false positive: กฎที่แจ้งเตือนผิดบ่อยติดต่อกันสามเดือน ให้ปรับ threshold หรือปิดไปเลย; แต่ละกฎต้องมีเจ้าภาพ ถ้าไม่มีใครรับผิดชอบก็เอาลงทันที จากนั้นแยกช่องทางตามระดับความสำคัญ — P0 เท่านั้นที่เข้าแจ้งเตือนแบบทันทีและรุนแรง P1 เข้าอีเมลและกลุ่ม P2 เข้าแค่รายงานรายสัปดาห์ เกณฑ์ตัดสินว่าจัดระเบียบเรียบร้อยแล้วหรือยัง: ช่องทาง P0 ไม่มี false positive ติดต่อกันสองสัปดาห์ และไม่มีเหตุการณ์จริงที่ถูกมองข้าม

จำนวนหน้าที่ถูก index ลดลงต้องตั้ง alert ด้วยไหม?

ต้อง แต่ต้องผ่อน threshold จำนวนหน้าที่ถูก index มีความผันผวนตามธรรมชาติ ลดลงไม่เกิน 20% เมื่อเทียบสัปดาห์ต่อสัปดาห์ถือว่าปกติ ไม่ต้องแจ้งเตือน; ถ้าเกิน 20% หรือลดลงติดต่อกันสองสัปดาห์จึงจะ trigger P1 การ monitor มีหน้าที่แค่ส่งสัญญาณว่า “ควรไปตรวจแล้ว” ส่วนการตรวจสอบการ crawl และ index มีขั้นตอนแยกต่างหาก สังเกตว่าการ monitor จำนวนหน้าที่ถูก index ทำสัปดาห์ละครั้งก็พอ จ้องตัวเลขทุกวันมีแต่จะสร้างความกังวล ไม่ได้ช่วยให้พบปัญหาจริงเร็วขึ้น

การ monitor กับงานบำรุงรักษารายเดือนเกี่ยวข้องกันอย่างไร?

การ monitor มีหน้าที่ค้นหา การบำรุงรักษามีหน้าที่จัดการ สองอย่างนี้เป็นความสัมพันธ์แบบ trigger ไม่ใช่แทนกัน การบำรุงรักษารายเดือนคืองานประจำตามจังหวะที่กำหนด ส่วนการ monitor คือยามเฝ้าระวังตลอดเวลาระหว่างการบำรุงรักษาสองครั้ง — certificate หมดอายุระหว่างวันบำรุงรักษา ฟอร์มเสียระหว่างวันบำรุงรักษา ล้วนต้องอาศัยการ monitor ที่ส่งเสียงก่อน ในทางปฏิบัติให้ใช้ alert จากการ monitor เป็นข้อมูลนำเข้าประจำของการประชุมบำรุงรักษา: เดือนที่ผ่านมามีอะไรดัง อะไรถูกจัดการ อะไรกลายเป็นรายการที่ต้องซ่อม ไล่ดูทีละข้อ

ถ้า alert ดังตอนกลางคืนแล้วไม่มีคนจัดการทำอย่างไร?

แสดงว่าการจัดเวรขาดไป ก่อนอื่นตอบคำถามว่า “ใครจัดการตอนกลางคืนได้” ต้องมีอย่างน้อยหนึ่งคนที่มีสิทธิ์เข้าถึงเซิร์ฟเวอร์และถูกปลุกผ่านช่องทาง P0 ได้ ถ้าหาไม่ได้จริง ๆ ก็ตั้งค่า automated action สำหรับ P0 ไว้ — restart service อัตโนมัติ สลับไปหน้า static cache อัตโนมัติ จากนั้นเขียนขั้นตอนตอบสนองสามระดับเป็นเอกสาร: restart/rollback ภายใน 15 นาที สลับไปหน้า static ภายใน 1 ชั่วโมง ส่งต่อ support ภายนอกภายใน 4 ชั่วโมง เว็บที่พึ่งคนไม่ได้ชั่วคราว ปล่อยให้ผ่อน threshold P0 เป็น “ล่มติดต่อกัน 10 นาที” ยังดีกว่าตั้ง alert ที่ดังแล้วไม่มีใครสนใจ

ทิ้งท้าย

คุณค่าทั้งหมดของระบบ monitoring สรุปเป็นสูตรเดียวได้: ความเสียหายเท่ากับระยะเวลาที่ล่มคูณความเสียหายต่อหน่วยเวลา monitoring บีบเวลาส่วนแรกจากชั่วโมงเหลือไม่กี่นาที ตั้ง monitoring ห้าประเภทให้ครบตาม threshold ในหัวข้อที่สอง เชื่อม alert สามระดับกับเจ้าภาพ ลด false positive ทุกไตรมาส — ทำสามอย่างนี้จบ อุบัติเหตุของเว็บก็ลดระดับจาก “หายนะ” เหลือแค่ “สิ่งที่ต้องทำ”

จำเกณฑ์ตัดสินข้อเดียวก็พอ: monitoring ที่ซื้อมาไม่ใช่ซอฟต์แวร์ แต่คือเวลาที่ใช้ค้นพบ; กฎแจ้งเตือนที่ไม่มีใครรับผิดชอบ เท่ากับไม่ได้ตั้งไว้