ในหน้านี้
วงจรอินเทอร์เน็ตสำรองหลุดมาสองสัปดาห์แล้ว ไม่มีใครรู้เพราะวงจรหลักยังทำงาน วันที่วงจรหลักขาด ทุกอย่างจึงดับพร้อมกัน และทีม IT รู้จากโทรศัพท์ของผู้จัดการ
นี่คือสิ่งที่เกิดขึ้นเมื่อไม่มี Monitoring: ทีม IT รู้ปัญหาหลังผู้ใช้ ระบบ Monitoring กลับลำดับนั้น มันบอกว่าวงจรสำรองล่ม ดิสก์ NVR ใกล้เต็ม อุณหภูมิในตู้กำลังขึ้น หรือ UPS กำลังวิ่งด้วยแบตเตอรี่ ก่อนที่จะกลายเป็นปัญหาของทุกคน และมันเก็บข้อมูลย้อนหลังไว้วางแผนว่าเมื่อไหร่ต้องเพิ่มแบนด์วิดท์หรือดิสก์
ติดตามอะไรบ้าง
| หมวด | สิ่งที่ติดตาม |
|---|---|
| ความพร้อมใช้งาน | อุปกรณ์ Online/Offline สถานะพอร์ต Uplink วงจรอินเทอร์เน็ตทุกวงจร |
| ประสิทธิภาพ | แบนด์วิดท์ Uplink และ WAN, Latency, Packet Loss, Error/Discard บนพอร์ต |
| ทรัพยากร | CPU, Memory ของ Firewall และสวิตช์ ดิสก์ของเซิร์ฟเวอร์และ NVR |
| สภาพแวดล้อม | อุณหภูมิและความชื้นในห้องเซิร์ฟเวอร์ สถานะ UPS และแบตเตอรี่ |
| PoE | การใช้ PoE Budget ของสวิตช์ |
| Wi-Fi | จำนวนผู้ใช้ต่อ AP, Channel Utilization |
| ใบรับรองและไลเซนส์ | วันหมดอายุ SSL Certificate และไลเซนส์ความปลอดภัยของอุปกรณ์ |
แถวสุดท้ายมักถูกลืม ไลเซนส์ Firewall ที่หมดอายุอาจทำให้ IPS และ Web Filter หยุดอัปเดตแบบเงียบๆ โดยไม่มีใครสังเกต
เครื่องมือแต่ละตัวทำอะไร
ICMP (Ping) ตอบคำถามเดียว: อุปกรณ์ยังอยู่ไหม ง่ายที่สุดและเป็นจุดเริ่มต้นที่ดี
SNMP อ่านค่าจากสวิตช์ Firewall UPS และเครื่องพิมพ์: แบนด์วิดท์ CPU สถานะแบตเตอรี่ ใช้ SNMPv3 ที่มีการยืนยันตัวตนและเข้ารหัส SNMP v1/v2c ที่ใช้ Community "public" เหมือนเปิดประตูให้ใครก็อ่านการตั้งค่าได้
Syslog ให้อุปกรณ์ส่ง Log เหตุการณ์มาเก็บที่ส่วนกลาง เมื่อมีเรื่องเกิดขึ้นคุณมีประวัติให้สืบ แม้อุปกรณ์จะรีบูตและ Log ในเครื่องหายไปแล้ว
NetFlow / sFlow / IPFIX ตอบคำถาม "ใครกินแบนด์วิดท์" เมื่อเน็ตช้าทุกบ่าย มันบอกได้ว่าเป็น Windows Update การสำรองข้อมูลขึ้น Cloud หรือมีคนดูบอล
API / Cloud Dashboard อุปกรณ์ Cloud-managed มักมีการติดตามในตัวที่ใช้ได้ทันที
เลือกเครื่องมือ
| ประเภท | ตัวอย่าง | หมายเหตุ |
|---|---|---|
| Open source | Zabbix, LibreNMS, Prometheus + Grafana | ไม่มีค่าไลเซนส์ แต่ต้องมีคนตั้งค่าและดูแล |
| เชิงพาณิชย์ | PRTG, SolarWinds และอื่นๆ | ติดตั้งเร็ว ไลเซนส์ตามจำนวน Sensor หรืออุปกรณ์ |
| Vendor Cloud | Dashboard ของยี่ห้อสวิตช์/AP/Firewall | ละเอียดเฉพาะยี่ห้อนั้น มองไม่เห็นยี่ห้ออื่น |
ส่วนใหญ่เราเห็นองค์กรใช้สองแบบรวมกัน: Dashboard ของยี่ห้อสำหรับรายละเอียด Wi-Fi และ Zabbix หรือเครื่องมือคล้ายกันสำหรับทุกอย่างที่เหลือ รวมถึง UPS และเซนเซอร์อุณหภูมิ
ตัวอย่างที่คิดให้ดู: ติดตาม 60 อุปกรณ์ต้องใช้อะไรบ้าง
สำนักงานใหญ่พร้อมสองสาขา: Firewall 2 เครื่อง Switch 14 ตัว Access Point 30 ตัว UPS 3 เครื่อง NVR 2 เครื่อง Server 4 เครื่อง สายอินเทอร์เน็ต 3 วงจร และเซนเซอร์อุณหภูมิ 2 ตัว ราว 60 อุปกรณ์
- การดึงข้อมูล (Polling) แต่ละอุปกรณ์มีค่าที่ควรเก็บราว 20–60 ค่า (พอร์ต CPU อุณหภูมิ แบต) ดึงนาทีละครั้งคือราว 3,000 ค่าต่อนาที หรือ 50 ค่าต่อวินาที Virtual Machine เล็กๆ 2–4 vCPU และ RAM 8 GB รับได้สบาย
- ประวัติ เก็บข้อมูลละเอียดราว 90 วัน และแนวโน้มรายชั่วโมงหนึ่งถึงสองปี สำหรับขนาดนี้ใช้ดิสก์ไม่ถึง 100 GB
- Bandwidth การดึง SNMP จาก 60 อุปกรณ์ใช้แค่ไม่กี่สิบ kbps แม้จะผ่าน VPN ของสาขาก็ไม่มีใครสังเกตเห็น
- Wi-Fi อ่านข้อมูล AP 30 ตัวจาก Controller หรือ Cloud Dashboard ของผู้ผลิต แทนการดึงทีละตัว และส่งเฉพาะเหตุการณ์สำคัญเข้าเครื่องมือส่วนกลาง
ส่วนที่ยากไม่ใช่ Server แต่คือบ่ายหนึ่งที่ต้องจัดชื่ออุปกรณ์ให้เป็นระเบียบ เปิด SNMPv3 และตัดสินว่าใครรับการแจ้งเตือนอะไร
การแจ้งเตือน: น้อยแต่ตรง
ระบบที่ส่ง 200 ข้อความต่อวันจะถูกปิดเสียงภายในสัปดาห์เดียว เราเรียกว่า Alert Fatigue และเป็นเหตุผลอันดับหนึ่งที่ Monitoring ล้มเหลว
- แจ้งเฉพาะสิ่งที่ต้องมีคนลงมือแก้
- แบ่งระดับ: Warning (เช่น ดิสก์ 80%) และ Critical (ดิสก์ 95%, Uplink ล่ม)
- ส่งไปช่องทางที่ทีมดูจริง: อีเมล LINE WhatsApp Telegram
- ใช้ Dependency: ถ้า Firewall สาขาล่ม ไม่ต้องแจ้งอุปกรณ์ 40 ตัวที่อยู่หลังมัน
- กำหนดว่าใครรับผิดชอบ และต้องตอบภายในกี่นาที
เกณฑ์เริ่มต้นที่ใช้ได้จริง
ใช้เป็นร่างแรก แล้วปรับหลังจากมีข้อมูลจริงหนึ่งเดือน:
| การตรวจ | เตือน (Warning) | วิกฤต (Critical) |
|---|---|---|
| สายอินเทอร์เน็ตหรือ WAN | Packet Loss เกิน 2% นาน 5 นาที | สายล่ม 1 นาที |
| การใช้งานสาย | เกิน 80% นาน 15 นาที | เกิน 95% นาน 15 นาที |
| ดิสก์ (Server, NAS, NVR) | เต็ม 80% | เต็ม 95% หรือ NVR หยุดบันทึก |
| UPS | กำลังใช้แบต | เวลาที่เหลือต่ำกว่า 10 นาที |
| อุณหภูมิห้อง Server | เกิน 27 °C | เกิน 32 °C |
| ใบรับรอง ไลเซนส์ | 30 วันก่อนหมดอายุ | 7 วันก่อนหมดอายุ |
| พอร์ตสวิตช์ | Error เพิ่มขึ้นบน Uplink | Uplink ล่ม |
สังเกตช่วงเวลา การแจ้งเตือนจากค่าผิดปกติครั้งเดียวคือสิ่งที่สร้างเสียงรบกวน สภาพที่ค้างอยู่ห้าหรือสิบห้านาทีมักเป็นเรื่องจริง
เริ่มต้นในหกขั้น
- ทำบัญชีอุปกรณ์ทั้งหมด พร้อม IP และตำแหน่ง
- เปิด SNMPv3 และ Syslog บนอุปกรณ์ อนุญาตเฉพาะเซิร์ฟเวอร์ Monitoring
- ติดตั้งเซิร์ฟเวอร์ Monitoring (VM หรือเครื่องเล็ก) ใน VLAN Management
- เพิ่มอุปกรณ์สำคัญก่อน: Firewall, Core Switch, วงจร WAN, UPS, NVR
- ตั้งการแจ้งเตือน และทดสอบว่าไปถึงจริง
- ทบทวนรายงานแนวโน้มทุกเดือน
ขั้นที่ 4 สำคัญ อย่าพยายามเพิ่มทุกอย่างในวันแรก อุปกรณ์ห้าตัวที่ถูกติดตามอย่างดี มีค่ากว่า 200 ตัวที่ไม่มีใครดู
สิ่งที่ทำให้ Monitoring ไม่ได้ผล
ติดตั้งแล้วไม่มีใครดูคือที่เจอบ่อยที่สุด ถัดมาคือเซิร์ฟเวอร์ Monitoring ที่ไม่มี UPS: ไฟดับมันดับพร้อมทุกอย่าง และแจ้งเตือนไม่ได้ในเวลาที่ต้องการที่สุด และไม่ติดตาม UPS กับอุณหภูมิ ซึ่งจากประสบการณ์ของเรา เป็นสาเหตุหลักของอุปกรณ์เสียในลาว
มีอีกสามอย่างที่เราเจอบ่อย ตรวจแค่จากภายใน: ถ้าสายอินเทอร์เน็ตล่ม Server Monitoring ก็ส่งการแจ้งเตือนออกไม่ได้ จึงควรเพิ่มการตรวจจากภายนอก บริการ Ping จาก Cloud หรือ Modem 4G สำหรับส่งแจ้งเตือน การแจ้งเตือนไปที่โทรศัพท์คนเดียว พอคนนั้นลาพักก็ไม่มีอะไรเกิดขึ้น และไม่มี Maintenance Window ทุกครั้งที่รีบูตตามแผนก็แจ้งทุกคน จนทุกคนชินกับการไม่สนใจแจ้งเตือน
Dashboard สำหรับผู้บริหาร
ผู้บริหารไม่ต้องการเห็นกราฟ 50 อัน ตัวเลขห้าตัวนี้พอ:
| ตัวชี้วัด | บอกอะไร |
|---|---|
| Uptime ของอินเทอร์เน็ตและระบบสำคัญ (%) | ความพร้อมใช้งานในเดือน |
| จำนวนเหตุการณ์ Critical และเวลาแก้ไขเฉลี่ย | ประสิทธิภาพของทีม IT |
| แบนด์วิดท์สูงสุดเทียบกับความจุ | ต้องเพิ่มวงจรไหม |
| จำนวนครั้งที่วิ่งด้วยไฟ UPS | คุณภาพไฟฟ้าของสถานที่ |
| ไลเซนส์และการรับประกันที่ใกล้หมดอายุ | งบที่ต้องเตรียม |
รายงานรายเดือนแบบนี้ทำให้ทีม IT ของบโดยมีตัวเลขรองรับแทนความรู้สึก "UPS วิ่งด้วยแบต 23 ครั้งเดือนนี้" มีน้ำหนักกว่า "ไฟที่นี่ไม่ดี" มาก
สำหรับองค์กรในลาว
ถ้ามีทีม IT ภายใน เริ่มจาก Zabbix หรือเครื่องมือ Open source คล้ายกัน ถ้าทีมเล็กหรือไม่มี บริการ Managed Monitoring คุ้มกว่าพยายามดูแลเอง
ให้ความสำคัญกับ UPS อุณหภูมิ และวงจรอินเทอร์เน็ตก่อน สามอย่างนี้คือจุดที่เราเห็นปัญหามากที่สุดในลาว สาขาต่างแขวงให้ติดตามจากเวียงจันทน์ผ่าน VPN หรือ SD-WAN และเขียนข้อความแจ้งเตือนเป็นภาษาที่ทีมอ่านเข้าใจทันที ส่งผ่านแอปที่เขาเปิดทุกวัน
หมายเหตุเรื่องช่องทางแจ้งเตือน: LINE Notify ที่ระบบเก่าหลายแห่งใช้ส่งแจ้งเตือนเข้ากลุ่ม LINE ปิดบริการไปในปี 2025 ถ้าการแจ้งเตือนของคุณใช้ทางนั้น มันหยุดไปแล้ว ให้ย้ายไปใช้ Bot ผ่าน LINE Messaging API, Telegram, WhatsApp หรืออีเมล แล้วส่งแจ้งเตือนทดสอบเพื่อยืนยัน ไม่ว่าจะเลือกเครื่องมือใด ให้ใช้รุ่น LTS (Long-Term Support) ในระบบจริง แทนรุ่นที่ Support สั้นที่ออกมาระหว่างนั้น
เริ่มจากอุปกรณ์ห้าตัว
บอกเราว่าอุปกรณ์ห้าตัวไหนที่ถ้าดับแล้วธุรกิจคุณหยุด (ส่วนใหญ่คือ Firewall, Core Switch, วงจรอินเทอร์เน็ต, UPS และ NVR หรือเซิร์ฟเวอร์หลัก) เราจะเสนอวิธีติดตามและแจ้งเตือนเฉพาะห้าตัวนั้นก่อน แล้วค่อยขยาย
- #monitoring
- #snmp
- #syslog
- #netflow
- #zabbix
- #alerting
- #nms
