Cisco Network Operations Dashboard Design: Health, SLA และ Incident KPIs

Cisco Network Operations Dashboard Design คือแนวทางออกแบบหน้าจอศูนย์ปฏิบัติการเครือข่าย (NOC) ให้เห็นสถานะอุปกรณ์ ความเสี่ยง และคุณภาพบริการจากข้อมูลจริง แทนการพึ่งพาเพียงไฟสถานะสีเขียวหรือแดง บทความนี้ใช้ เครือข่ายสถานีขนส่งจำลอง เป็นตัวอย่าง ไม่ใช่ข้อมูลของระบบจริง

เป้าหมาย: ออกแบบ Dashboard ที่ตอบคำถามได้ว่า อุปกรณ์ใดมีปัญหา ผู้ใช้ได้รับผลกระทบเท่าใด เหตุการณ์ใดต้องแก้ก่อน และหลักฐานใดรองรับรายงาน SLA

1. ทำไม Network Operations ต้องมี Dashboard

1.1 Dashboard ที่ดีต้องช่วยตัดสินใจ

Dashboard ควรตอบโจทย์ Detect → Triage → Investigate → Resolve → Report โดยแยกภาพรวมสำหรับผู้บริหารออกจากมุมตรวจสอบเชิงเทคนิคของ Network Engineer และหลีกเลี่ยงการแสดงกราฟจำนวนมากโดยไม่มีการระบุความสำคัญ

1.2 กลุ่มผู้ใช้งาน

ผู้ใช้	คำถามสำคัญ	ตัวชี้วัด
NOC Operator	อุปกรณ์ใดมี Alarm ต้องรับงานก่อน	Critical alarms, affected sites, acknowledged status
Network Engineer	ต้นเหตุอยู่ที่ Interface, Routing หรืออุปกรณ์	Error rate, utilization, log timeline
Maintenance Supervisor	งานค้างและการตอบสนองเป็นอย่างไร	MTTA, MTTR, open incidents, PM overdue
Service Manager	บริการเป็นไปตาม SLA หรือไม่	Availability, breach count, reporting period

หลักการ: แสดงเวลาอัปเดตล่าสุด หน่วยวัด ขอบเขตข้อมูล และสถานะข้อมูลขาดหายทุกหน้าจอ

2. Data Architecture สำหรับ Cisco Network Monitoring

2.1 แยก Collection, Storage, Correlation และ Visualization

โครงสร้างที่แนะนำแยกส่วนเก็บข้อมูลออกจากส่วนแสดงผล เพื่อให้เปลี่ยน Dashboard ได้โดยไม่กระทบระบบเฝ้าระวังหลัก

Cisco Switch / Router
  |-- SNMPv3 polling / traps --> Collector --> Time-series DB
  |-- Syslog -----------------> Log receiver --> Log storage
  |-- Flow telemetry ---------> Flow collector --> Flow storage
  |-- SSH read-only ----------> Scheduled audit --> Evidence store
                                                |
                                        Correlation / Alerting
                                                |
                                         Dashboard + Ticketing

2.2 เครื่องมือที่อาจเลือกใช้

Prometheus + Grafana เหมาะกับ Metric และกราฟแนวโน้มเมื่อมี Exporter ที่รองรับ, Zabbix เหมาะกับ Device Monitoring และ Trigger, ส่วน Graylog หรือระบบ Log Management ใช้วิเคราะห์ Syslog ทั้งนี้ความสามารถขึ้นกับเวอร์ชัน การตั้งค่า และ Licensing ของแต่ละผลิตภัณฑ์

2.3 กำหนดช่วงเวลาเก็บข้อมูล

ตัวอย่างนโยบาย: Poll Interface ทุก 60 วินาที, Health ทุก 5 นาที, เก็บ Metric ละเอียด 30 วันและข้อมูลสรุป 12 เดือน โดยต้องประเมินจำนวนอุปกรณ์ ปริมาณข้อมูล ความจุ Storage และข้อกำหนดองค์กรก่อนใช้งานจริง

3. Dashboard Layout: ภาพรวมถึงการวิเคราะห์เชิงลึก

3.1 NOC Overview

แถวแรกควรมี Sites Up/Down, Devices Reachable, Critical Alerts, Active Incidents, SLA Status พร้อมเวลาที่ข้อมูลอัปเดตล่าสุด

3.2 Network Health และ Interface Trends

แผง	ข้อมูล	การใช้งาน
Site Status	จำนวนไซต์ปกติ/มีผลกระทบ/ไม่ทราบสถานะ	ระบุพื้นที่กระทบ
Device Health	Reachability, CPU, Memory, Temperature	ตรวจสอบความเสี่ยงของอุปกรณ์
Uplink Utilization	Inbound/Outbound Mbps และ % ของความเร็วที่ยืนยันแล้ว	วิเคราะห์ความจุ
Interface Errors	CRC, drops, discards, link flaps	หาแนวโน้มปัญหา
Incident Timeline	Alarm, acknowledgement, recovery	ประกอบ RCA
SLA Summary	Availability และเวลาหยุดให้บริการ	รายงานบริการ

3.3 Drill-down และตัวกรอง

ควรกรองได้ตาม สายงาน/พื้นที่, สถานี, Device Role, Device ID, Severity, ช่วงเวลา และคลิกจาก Site Overview ไป Device Detail แล้วต่อไป Interface Detail ได้โดยไม่สูญเสียบริบท

4. Device Inventory และ Data Model

4.1 กำหนดรหัสอุปกรณ์ให้คงที่

อย่าใช้ IP Address เป็น Primary Key เพียงอย่างเดียว เพราะอาจเปลี่ยนได้ ควรมี device_id ที่ไม่ซ้ำ พร้อมไซต์ ตำแหน่ง อุปกรณ์รุ่น และเจ้าของบริการ

device_id	site_id	role	management_ip	criticality
YL-LAB-SW01	YL-LAB	Access Switch	192.0.2.11	High
YL-LAB-SW02	YL-LAB	Distribution Switch	192.0.2.12	Critical
PK-LAB-R01	PK-LAB	WAN Router	192.0.2.21	Critical

หมายเหตุ: ช่วง IP 192.0.2.0/24 เป็นที่อยู่สำหรับเอกสารตัวอย่าง ไม่ใช่ IP ที่ต้องนำไปตั้งค่าบนอุปกรณ์จริง

4.2 ตัวอย่าง Event Schema

timestamp_utc,site_id,device_id,interface_id,event_type,severity,source,correlation_id
2026-10-29T01:00:00Z,YL-LAB,YL-LAB-SW01,Gi1/0/24,LINK_DOWN,critical,syslog,INC-1001

ข้อมูลควรมี event_time และ ingest_time แยกกัน เพื่อวิเคราะห์ความล่าช้าของการส่ง Log และความคลาดเคลื่อนของนาฬิกา

5. Device Health Metrics ที่ต้องติดตาม

5.1 Availability และ Reachability

การ Ping ไม่ผ่านไม่ได้แปลว่าอุปกรณ์เสียเสมอไป เพราะอาจถูกบล็อก ICMP จึงควรใช้หลายสัญญาณ เช่น SNMP Polling, Management SSH, Syslog และสถานะบริการประกอบกัน

5.2 CPU, Memory, Environment และ Power

ติดตาม CPU/Memory เป็นแนวโน้ม ไม่ควรใช้ Threshold เดียวกับ Cisco ทุกรุ่น เนื่องจาก Hardware, IOS/IOS XE และลักษณะงานต่างกัน ควรอ้างอิง Baseline ของรุ่นที่ใช้งานและคำแนะนำผู้ผลิต

5.3 Data Freshness

ถ้า Collector หยุดทำงาน Dashboard อาจแสดงค่าล่าสุดเหมือนยังปกติ จึงต้องมีสถานะ Unknown/Stale เมื่อข้อมูลเก่ากว่ากำหนด และแยกจากสถานะ Healthy อย่างชัดเจน

6. Interface Trends และ Capacity Planning

6.1 คำนวณ Bandwidth Utilization

คำนวณจากการเปลี่ยนแปลงของ Octet Counter ระหว่างสองเวลาที่เก็บข้อมูล:

Traffic (bps) = (delta_octets * 8) / delta_seconds
Utilization (%) = Traffic_bps / interface_speed_bps * 100

ควรใช้ 64-bit Interface Counters (ifHCInOctets/ifHCOutOctets) สำหรับลิงก์ความเร็วสูง และตรวจจับ Counter Reset, Wrap, Device Reboot หรือการเปลี่ยนความเร็วลิงก์ก่อนคำนวณ

6.2 ตัวอย่างการคำนวณ

ลิงก์ 1 Gbps มีปริมาณรับข้อมูลเพิ่ม 4,500,000,000 octets ภายใน 60 วินาที คิดเป็น 600 Mbps หรือ 60% Utilization ของความเร็ว 1 Gbps (สมมติ Counter ถูกต้องและไม่มี Reset)

6.3 Error, Discard และ Flap

แสดง CRC/Input Errors, Output Drops, Discards, Interface Flaps โดยใช้ Rate ต่อช่วงเวลา ไม่ใช้ค่า Counter สะสมอย่างเดียว และควรตรวจสอบความแตกต่างของ Counter ตามแพลตฟอร์ม

6.4 การตั้ง Threshold

ตัวอย่างเพื่อเริ่ม Pilot: Warning เมื่อ Uplink Utilization เฉลี่ย 5 นาทีเกิน 70% และ Critical เมื่อเกิน 85% ต่อเนื่อง 10 นาที แต่ ไม่ใช่มาตรฐานสากล ต้องปรับตาม Baseline, Burst, QoS และความต้องการบริการจริง

7. Incident KPIs, Availability และ SLA Reporting

7.1 KPI Definitions

KPI	นิยาม	ข้อควรระวัง
MTTA	เวลาเฉลี่ยตั้งแต่เปิดเหตุถึงรับทราบ	กำหนด Start/Stop ให้ชัด
MTTR	เวลาเฉลี่ยตั้งแต่เริ่มเหตุถึงคืนบริการตามนิยาม	อย่าสับสนกับเวลาปิด Ticket
Availability	(เวลาบริการที่กำหนด - Downtime ที่นับ) / เวลาบริการที่กำหนด × 100	ยึด SLA Contract และ Exclusion
Incident Count	จำนวนเหตุการณ์ที่ไม่ซ้ำ	ต้อง Correlate Alarm
Repeat Incident Rate	เหตุซ้ำตามเกณฑ์ Problem Management	กำหนดช่วงเวลาและกลุ่มปัญหา

7.2 ตัวอย่าง SLA 8×5

สมมติรอบรายงานมี 22 วันทำการ × 8 ชั่วโมง = 176 ชั่วโมง และมี Downtime ที่นับตามสัญญา 30 นาที:

Availability = (176 - 0.5) / 176 * 100 = 99.7159%

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

7.3 แยก Device Uptime ออกจาก Service Availability

อุปกรณ์ตัวหนึ่ง Down แต่ HSRP หรือเส้นทางสำรองยังให้บริการได้ อาจไม่ถือเป็น Service Downtime ในบาง SLA ดังนั้น Dashboard ควรแสดง Device Availability และ Service Availability แยกกัน

8. Alert Prioritization และ Event Correlation

8.1 Severity ตามผลกระทบ

ควรจัดระดับจาก Impact × Urgency ไม่ใช่ประเภท Syslog อย่างเดียว เช่น Uplink หลักขัดข้องแต่เส้นทางสำรองทำงานอยู่ อาจต่างจากสถานีที่สูญเสียการเชื่อมต่อทั้งหมด

ระดับ	ตัวอย่าง	การดำเนินการ
P1 Critical	หลายสถานีไม่สามารถให้บริการ	เปิด Incident ทันทีและ Escalate ตาม Runbook
P2 High	สถานีหนึ่งกระทบหรือ Redundancy หาย	มอบหมาย Engineer ตรวจสอบ
P3 Medium	Error rate สูงต่อเนื่องแต่บริการยังใช้ได้	ติดตาม Trend และวางแผนแก้ไข
P4 Low	ข้อมูลประกอบหรือ Maintenance Notice	บันทึกและทบทวนตามรอบ

8.2 Correlation เพื่อลด Alert Storm

ถ้า Distribution Switch Down แล้ว Access Switch หลายตัวติดต่อไม่ได้ ให้ผูก Alarm เป็น Incident เดียวเมื่อมีหลักฐานด้าน Topology และเวลา โดยยังเก็บ Raw Event เพื่อการสืบค้นย้อนหลัง

8.3 Alert Lifecycle

Detected → Acknowledged → Investigating → Mitigated → Resolved → Closed ต้องมี Owner, Timestamp, Evidence และ Reason ทุกการเปลี่ยนสถานะ ควรแยก Silence สำหรับงานบำรุงรักษาออกจากการปิด Alarm ถาวร

9. Cisco CLI สำหรับยืนยันข้อมูล Dashboard

9.1 ตรวจสอบสถานะอุปกรณ์และ Interface

show version
show clock detail
show interfaces status
show interfaces counters errors
show interfaces GigabitEthernet1/0/24
show logging
show processes cpu sorted
show memory statistics

ข้อควรระวัง: คำสั่งและรูปแบบผลลัพธ์ต่างกันตามรุ่น Cisco IOS/IOS XE ให้ตรวจสอบด้วย show ? และคู่มือแพลตฟอร์มก่อนใช้งาน

9.2 ตรวจสอบ SNMPv3 และ Syslog

show snmp user
show snmp group
show snmp
show logging

ควรตรวจสอบว่าการ Polling, Authentication และ Log Delivery ทำงานจริง โดยใช้บัญชีแบบ Read-Only และไม่เปิดเผย SNMP Credentials ใน Log หรือ Dashboard

9.3 ยืนยันเวลาของเหตุการณ์

ตั้งค่า Time Synchronization ตามนโยบายองค์กร ตรวจสอบ Timezone และ NTP ของอุปกรณ์และ Collector เพื่อให้ Incident Timeline สามารถนำมาเทียบกันได้

10. ตัวอย่างการสร้าง Dashboard และ Query

10.1 ออกแบบ Metric Labels

ตัวอย่าง Metric ที่กำหนดขึ้นสำหรับ Lab ไม่ใช่ข้อมูลจริงจาก Cisco:

network_device_reachable{site="YL-LAB",device="SW01"} 1
network_interface_utilization_ratio{site="YL-LAB",device="SW01",interface="Gi1/0/24",direction="in"} 0.60

10.2 ตัวอย่าง PromQL

ตัวอย่าง Query เมื่อ Collector ส่ง Metric ตามชื่อที่ออกแบบไว้:

100 * avg by (site, device, interface) (network_interface_utilization_ratio{direction="in"})
count by (site) (network_device_reachable == 0)

ต้องสร้าง Exporter หรือ Collector ที่ส่ง Metric ดังกล่าวก่อน Query จึงจะทำงานได้ และต้องมีการแจ้งเตือนข้อมูลขาดหายด้วย

10.3 Incident Dashboard Data Source

ข้อมูล Incident ควรมาจาก Ticketing System ที่มีประวัติการเปลี่ยนสถานะ ไม่ควรใช้ Syslog Event Count แทนจำนวน Incident โดยตรง

10.4 ตัวอย่าง JSON Record

{"incident_id":"INC-1001","site_id":"YL-LAB","severity":"P2","status":"Investigating","detected_at":"2026-10-29T01:00:00Z"}

11. Security, Governance และ Data Quality

11.1 Least Privilege และการจัดการ Credentials

ใช้ SNMPv3 AuthPriv เมื่อรองรับและกำหนดค่าอย่างถูกต้อง แยก Monitoring Account ออกจาก Administrator Account เก็บ Secret ใน Vault/Secret Manager และใช้ TLS กับ Web Dashboard รวมถึงกำหนด RBAC สำหรับ Viewer, Operator และ Administrator

11.2 Auditability และ Data Retention

เก็บประวัติการเปลี่ยน Alert Rule, Dashboard, Threshold และ Incident State พร้อมผู้แก้ไขและเวลา กำหนดระยะเก็บข้อมูลตามความเสี่ยง ความจำเป็น และข้อกำหนดขององค์กร

11.3 ป้องกันข้อมูลผิดพลาด

ตรวจสอบ Duplicate Events, Clock Skew, Counter Reset, Missing Samples, Incorrect Interface Speed และอุปกรณ์ที่ถูกย้ายไซต์ เพราะข้อมูลผิดเพียงจุดเดียวอาจทำให้ KPI และ SLA คลาดเคลื่อน

12. Hands-on Lab: Dashboard สำหรับเครือข่าย 3 สถานี

12.1 สถานการณ์จำลอง

กำหนดสถานี LAB-A, LAB-B, LAB-C แต่ละสถานีมี Cisco Switch 2 ตัวและ Uplink อย่างน้อย 1 เส้น สร้างข้อมูลทดสอบจาก Lab ที่ได้รับอนุญาตหรือ Dataset จำลอง โดยไม่เชื่อมต่อ Production

12.2 ขั้นตอนฝึก

จัดทำ Device Inventory พร้อม Site ID และ Device ID
กำหนด Metric: Reachability, CPU, Uplink Traffic, Errors และ Log Events
กำหนด Data Freshness และ Alert Threshold พร้อมเหตุผล
ออกแบบ Overview และ Drill-down ระดับสถานี/อุปกรณ์
สร้างเหตุการณ์จำลอง Uplink Down และ CPU High แล้วตรวจสอบ Event Correlation
สร้าง Incident Record พร้อม Acknowledge/Resolve Timestamp
คำนวณ MTTA, MTTR และ Availability จากข้อมูลตัวอย่าง
บันทึกผล Acceptance Test และข้อบกพร่องที่พบ

12.3 Acceptance Test

Test ID	สถานการณ์	ผลที่คาดหวัง
AT-01	Device ไม่ตอบ Polling	ขึ้น Down หรือ Unknown ตามกฎ และมี Timestamp
AT-02	Collector หยุดส่งข้อมูล	แสดง Stale/Unknown ไม่ใช่ Healthy
AT-03	Uplink เกิน Threshold ต่อเนื่อง	เกิด Alert หลังผ่าน Duration ที่กำหนด
AT-04	หลาย Alarm จาก Root Cause เดียว	มี Incident หลักและ Event ที่เชื่อมโยง
AT-05	ปิด Incident	KPI อัปเดตจาก Timestamp ที่ตรวจสอบได้
AT-06	จำลอง Failover สำเร็จ	แยก Device Down ออกจาก Service Down

12.4 ตัวอย่าง Maintenance Report

รายงานประจำเดือนควรมี Scope, Reporting Window, Device Count, Data Coverage, SLA, Top Incidents, Capacity Risks, Pending Actions, Owner และ Due Date พร้อมลิงก์หลักฐานและวันที่ออกรายงาน

13. คำถามที่พบบ่อยและสรุป

Dashboard ใช้แทน Network Monitoring System ได้หรือไม่?

ไม่ได้ Dashboard เป็นชั้นแสดงผลและวิเคราะห์ ต้องมีระบบเก็บ Metric/Log, Alert Engine และกระบวนการ Incident Management ที่ทำงานได้แม้ไม่มีผู้เปิดหน้าจอ

ควรใช้ SNMPv3, Syslog หรือ NetFlow?

ใช้ร่วมกันตามความต้องการ: SNMPv3 สำหรับสถานะและ Counter, Syslog สำหรับ Event, NetFlow สำหรับมุมมอง Traffic Flow ทั้งนี้ต้องตรวจสอบการรองรับและผลกระทบต่ออุปกรณ์

ควรเริ่มต้นกี่ KPI?

เริ่มจาก KPI ที่นำไปสู่การตัดสินใจได้จริง เช่น Service Availability, Critical Incidents, MTTA, MTTR, Uplink Utilization และ Data Freshness แล้วค่อยขยายเมื่อข้อมูลมีคุณภาพเพียงพอ

สรุป

Network Operations Dashboard ที่ดีต้องเชื่อมโยง Device Health, Network Performance, Incident Workflow และ Service SLA โดยมีข้อมูลที่ตรวจสอบย้อนกลับได้ การจัดลำดับ Alarm ที่สะท้อนผลกระทบจริง และกลไกแยกข้อมูลขาดหายออกจากสถานะปกติ จึงจะช่วยลดเวลาแก้ปัญหาและยกระดับการให้บริการได้อย่างเป็นระบบ

บทความถัดไป: Cisco Network Monitoring Automation with Python — SNMPv3 Polling, Syslog Parsing, KPI Aggregation และ Automated Reports