EP7 — Infrastructure Monitoring & Alerting: ระบบที่มีกราฟสวย แต่ไม่มีใครดู
“ระบบไม่เคยล่มแบบไม่มีสัญญาณเตือน
แต่ล่มเพราะไม่มีใครเห็นสัญญาณนั้น”
🔹 บทนำ: ทุกองค์กรมี Monitoring แต่ทำไมยังล่มบ่อย?
วันนี้แทบทุกองค์กรมี Monitoring
ไม่ว่าจะเป็น Dashboard, Graph, Alert, Log, หรือ Notification
แต่เมื่อเกิดเหตุจริง เช่น
-
Server ล่ม
-
Storage เต็ม
-
Application ช้า
-
Database ค้าง
-
Network packet loss
-
Service ไม่ตอบสนอง
คำถามที่มักตามมาคือ
“ทำไมไม่มีใครรู้ก่อน?”
ทั้งที่ความจริงคือ
ระบบรู้… แต่คนไม่รู้
🔹 ทำไม Monitoring & Alerting ถึงเป็นงาน System Security ที่ถูกลืม?
✔ 1) มีระบบ แต่ไม่มีคนเป็นเจ้าของ
Monitoring ถูกติดตั้งตอนแรก
แต่ไม่มีใครรับผิดชอบดูแลต่อ
-
Alert ส่งไปอีเมลที่ไม่มีคนอ่าน
-
Dashboard เปิดเฉพาะตอนผู้บริหารถาม
-
ไม่มีใครรู้ว่า Alert ไหนสำคัญจริง
✔ 2) Alert เยอะเกินไป จนไม่มีใครสนใจ (Alert Fatigue)
ทุกอย่างแจ้งเตือนหมด
CPU 70% ก็เตือน
Disk ขยับก็เตือน
สุดท้ายคนเรียนรู้ว่า
“ไม่ต้องสนใจ เดี๋ยวก็หาย”
✔ 3) Monitoring ถูกมองว่าเป็นแค่ “เครื่องมือดูสถานะ”
หลายองค์กรใช้ Monitoring แค่ดูว่า
ระบบ “Up หรือ Down”
แต่ไม่ได้ใช้เพื่อ:
-
มองแนวโน้ม (Trend)
-
ป้องกันเหตุล่วงหน้า
-
ตรวจพฤติกรรมผิดปกติ
✔ 4) ไม่มีการเชื่อม Monitoring กับ Incident Response
Alert มาแล้ว → ใครทำอะไรต่อ?
ไม่มี Runbook
ไม่มี Escalation
ไม่มี SLA
สุดท้าย Alert กลายเป็น “เสียงรบกวน”
✔ 5) ผู้บริหารเห็นกราฟ แต่ไม่เห็นความเสี่ยง
Dashboard ดูสวย
แต่ไม่ได้ตอบคำถามว่า
“ถ้าระบบล่มวันนี้ ธุรกิจจะกระทบแค่ไหน?”
🔹 ปัญหาที่พบจริงในองค์กรไทย
❌ ระบบล่มตอนกลางคืน แต่ไม่มีใครรู้
เพราะ Alert ส่งเข้า Email IT กลางคืนที่ไม่มี on-call
❌ Storage เต็มมานาน แต่ไม่มี Threshold ที่ meaningful
เตือนตอน 95% → ช้าเกินไป
❌ Monitoring มี แต่ไม่มี Log
รู้ว่าล่ม แต่ไม่รู้ว่าล่มเพราะอะไร
❌ Monitoring แยกส่วน
Network คนละจอ
Server คนละจอ
App คนละจอ
ไม่มีใครเห็นภาพรวม
🔹 Monitoring ที่ดี ต้องตอบ “คำถามธุรกิจ” ไม่ใช่แค่คำถามเทคนิค
Monitoring ที่มีคุณค่า ต้องตอบได้ว่า:
-
ระบบไหนกระทบธุรกิจมากที่สุด
-
อะไรคือสัญญาณเตือนก่อนล่ม
-
ถ้า Alert นี้เกิด ใครต้องรับผิดชอบ
-
ต้องแก้ภายในกี่นาที
-
เกิดบ่อยแค่ไหน และแนวโน้มเป็นอย่างไร
ถ้าตอบไม่ได้ → Monitoring ยังไม่สมบูรณ์
🔹 องค์ประกอบของ Monitoring & Alerting ที่ใช้งานได้จริง
1) Monitoring Coverage ที่ครบ
-
Infrastructure (CPU, RAM, Disk, Network)
-
Application / Service
-
Database
-
Cloud Resource
-
Security Event (Login, Error, Abuse)
2) Threshold ที่มีความหมาย
-
ไม่ใช่ค่า default
-
ต้องอิงจากพฤติกรรมจริงของระบบ
-
แยกระหว่าง Warning กับ Critical
3) Alert Routing ที่ชัดเจน
-
Alert ไหนส่งให้ใคร
-
กลางวัน / กลางคืน
-
Escalate เมื่อไร
4) Runbook สำหรับ Alert สำคัญ
-
Alert นี้ต้องทำอะไร
-
ตรวจอะไรก่อน
-
ติดต่อใคร
-
แก้ชั่วคราวอย่างไร
5) Dashboard สำหรับ “ผู้บริหาร”
ไม่ใช่กราฟเทคนิค
แต่เป็น:
-
Service health
-
Impact ต่อธุรกิจ
-
Incident trend
-
Risk indicator
🔹 Monitoring ในมุม System Security
Monitoring ไม่ใช่แค่เรื่อง Availability
แต่เป็นด่านสำคัญของ System Security เช่น:
-
Login ผิดปกติ
-
Resource ถูกใช้งานผิดพฤติกรรม
-
Service ถูกโจมตีแบบช้า ๆ
-
Internal misuse
-
Misconfiguration
หลาย Incident ถูกพบได้ “ตั้งแต่ยังไม่เป็นข่าว”
ถ้ามี Monitoring ที่ดีพอ
🔹 วิธีเริ่มต้น Monitoring สำหรับองค์กรที่ยังไม่พร้อม
✔ 1) เลือกระบบที่กระทบธุรกิจมากที่สุดก่อน
ไม่ต้อง monitor ทุกอย่าง
✔ 2) ลด Alert ให้เหลือเฉพาะ Critical
ดีกว่ามีเยอะแล้วไม่มีใครดู
✔ 3) ตั้ง Alert ให้ “ต้องมีคนรับผิดชอบ”
ไม่ใช่แค่แจ้งเตือน
✔ 4) Review Alert รายไตรมาส
อะไรไม่เคยมีค่า → ตัดทิ้ง
🔹 สรุป EP7
Monitoring ไม่ได้ล้มเหลวเพราะเครื่องมือ
แต่ล้มเหลวเพราะ “ไม่มีคนดู และไม่มีคนตัดสินใจ”
“กราฟสวยไม่ได้ช่วยอะไร
ถ้าไม่มีใครมองมันในเวลาที่ควรมอง”
EP7 จึงเป็นอีกหนึ่งบทของ
System Security ที่ถูกลืม
ที่องค์กรต้องกลับมาให้ความสำคัญ หากไม่อยากรู้ปัญหาตอนที่สายเกินไป