Cisco Network Preventive Maintenance & Health Check: PM Checklist และ Cisco CLI

Networking | Cisco | Network Operations | Preventive Maintenance

การตรวจสุขภาพเครือข่ายเป็นงานที่ต้องทำอย่างสม่ำเสมอ ไม่ใช่รอให้ Switch หรือ Router หยุดทำงานก่อนจึงเริ่มตรวจสอบ บทความนี้อธิบายการสร้าง Preventive Maintenance (PM) สำหรับ Cisco IOS/IOS XE พร้อมคำสั่งตรวจสอบ เกณฑ์วิเคราะห์ แนวทางบันทึกหลักฐาน และตัวอย่างรายงานที่ใช้ได้กับงานดูแลเครือข่ายองค์กรหรือสถานีขนส่ง

ขอบเขต: ตัวอย่างเป็นการตรวจแบบ Read-Only เป็นหลัก คำสั่งและรูปแบบ Output อาจต่างกันตามรุ่นฮาร์ดแวร์และเวอร์ชันซอฟต์แวร์ ควรตรวจสอบคู่มือของอุปกรณ์จริงก่อนใช้งาน

สารบัญ

1. เป้าหมายและขอบเขตของ PM
2. วางแผนรอบการตรวจ W1/M1/M3/M6/Y1
3. เตรียมความพร้อมและเก็บ Baseline
4. ตรวจ Interface, Error และ Utilization
5. ตรวจ CPU, Memory และ Log
6. ตรวจ Power, Fan และ Temperature
7. ตรวจ VLAN, STP และ EtherChannel
8. ตรวจ Routing และ Reachability
9. ตรวจ Firmware และ Lifecycle
10. PM Checklist และการประเมินผล
11. Hands-on Lab
12. Maintenance Report และ Escalation
13. คำถามที่พบบ่อย
14. สรุป

1. Cisco Network Preventive Maintenance คืออะไร

Preventive Maintenance (PM) คือการตรวจสภาพและประสิทธิภาพของอุปกรณ์เครือข่ายตามแผน เพื่อค้นหาความผิดปกติก่อนพัฒนาเป็น Incident เช่น Interface Error เพิ่มต่อเนื่อง, อุณหภูมิสูง, Power Supply เสียหนึ่งชุด หรือ Firmware มีความเสี่ยงด้านความปลอดภัย

PM, Health Check และ Corrective Maintenance ต่างกันอย่างไร

• PM: งานตรวจตามรอบและบันทึกผลเทียบเกณฑ์มาตรฐาน
• Health Check: ตรวจสุขภาพอุปกรณ์ ณ เวลาหนึ่ง หรือหลังเหตุการณ์/การเปลี่ยนแปลง
• Corrective Maintenance (CM): งานแก้ไขเมื่อพบ Defect หรืออุปกรณ์ทำงานผิดปกติ
• Predictive Maintenance: ใช้ข้อมูลย้อนหลังเพื่อคาดการณ์ความเสื่อมหรือความเสี่ยง

หลักสำคัญคือ PM ต้องสร้างหลักฐานที่เปรียบเทียบกับครั้งก่อนหน้าได้ ไม่ใช่เพียงบันทึกว่า “Normal” โดยไม่มีข้อมูลรองรับ

2. ออกแบบ PM Schedule: W1, M1, M3, M6 และ Y1

ตารางนี้เป็น ตัวอย่างแผน ต้องปรับตาม SLA, Criticality, ข้อกำหนดผู้ผลิต และข้อจำกัดด้าน Maintenance Window ของแต่ละหน่วยงาน

รอบ	รายการหลัก	ผลลัพธ์
W1 — รายสัปดาห์	Availability, Interface Status, Critical Syslog, CPU/Memory	Weekly Health Snapshot
M1 — รายเดือน	Interface Errors, Utilization Trend, Power/Fan/Temperature, Backup Status	Monthly PM Checklist
M3 — ทุก 3 เดือน	STP/Trunk/EtherChannel, Routing, Config Drift, Capacity Trend	Quarterly Technical Review
M6 — ทุก 6 เดือน	Firmware Advisory, Security Hardening, Restore Test ใน Lab, Spare Readiness	Risk & Recovery Review
Y1 — รายปี	Lifecycle/EoS, Hardware Refresh, DR Exercise, SLA/Capacity Review	Annual Network Assessment

การแบ่งความสำคัญของอุปกรณ์

ควรแยก Critical เช่น Core/Distribution Switch, OCC/DC หรือระบบชำระเงิน ออกจาก Standard เช่น Access Switch ทั่วไป โดยกำหนดความถี่ตรวจและเวลา Escalation ต่างกันตามผลกระทบจริง

3. Pre-PM Checklist และการเก็บ Baseline

ข้อมูลที่ต้องทราบก่อนเริ่มงาน

• Device ID, Site, Hostname, Model, Serial Number และ Management IP
• หน้าที่อุปกรณ์, Critical Uplink, Port Mapping และ Network Diagram ล่าสุด
• เวอร์ชัน IOS/IOS XE, Config Baseline, ประวัติ Incident และผล PM ครั้งก่อน
• สิทธิ์เข้าถึง, ผู้ประสานงาน, ช่องทาง Escalation และข้อกำหนด SLA

คำสั่งเก็บข้อมูลเบื้องต้น

show clock
show version
show inventory
show interfaces status
show ip interface brief
show logging
show running-config

ข้อควรระวัง: show running-config อาจมีข้อมูลอ่อนไหว เช่น Username, Shared Secret หรือ IP ภายใน ต้องจัดเก็บอย่างจำกัดสิทธิ์และปกปิดข้อมูลก่อนแนบรายงาน

Baseline ที่ควรบันทึก

เก็บค่า Uptime, Interface Error Counter, CPU/Memory, Temperature, Log ที่เกี่ยวข้อง และเวลาที่ตรวจสอบ เพื่อเปรียบเทียบแนวโน้มในรอบถัดไป โดยอย่าใช้ Counter สะสมเพียงค่าเดียวตัดสินว่าปัญหากำลังเกิดขึ้น

4. ตรวจ Interface Errors, Discards และ Bandwidth Utilization

คำสั่ง Cisco CLI

show interfaces status
show interfaces GigabitEthernet1/0/1
show interfaces counters errors
show interfaces description
show interfaces trunk

คำสั่ง show interfaces counters errors มีให้ใช้ในหลายรุ่นของ Catalyst แต่ไม่ใช่ทุกแพลตฟอร์ม หากไม่รองรับให้ใช้ show interfaces หรือคำสั่งเฉพาะรุ่นแทน

ตัวชี้วัดสำคัญ

Metric	ความหมายที่ควรตรวจ	แนวทางวิเคราะห์
CRC / Input Errors	ความผิดพลาดขณะรับ Frame	ตรวจสาย, Connector, SFP, Noise และ Duplex
Output Errors / Discards	ปัญหาส่งข้อมูลหรือ Queue Drop	ตรวจ Congestion, QoS, Buffer และ Speed
Link Flap	Port Up/Down ซ้ำ	ตรวจ Syslog, สาย, SFP, Power และอุปกรณ์ปลายทาง
Utilization	อัตราการใช้ Bandwidth	ดู Peak, Percentile และระยะเวลาที่ใช้สูง
Speed/Duplex	ค่าการเจรจา Link	เทียบค่าทั้งสองฝั่งและข้อกำหนด Transceiver

ตัวอย่างคำนวณ Utilization

ลิงก์ 1 Gbps มีอัตรารับข้อมูลเฉลี่ย 650 Mbps ในช่วง 5 นาที:

Utilization (%) = (Traffic bps / Interface Speed bps) x 100
                = (650,000,000 / 1,000,000,000) x 100
                = 65%

ข้อสังเกต: ค่า 65% ไม่ได้แปลว่าปกติหรือผิดปกติโดยอัตโนมัติ ต้องพิจารณา Latency, Packet Loss, Queue Drops, Peak Burst และข้อกำหนด SLA ร่วมกัน

วิธีตรวจ Counter อย่างถูกต้อง

เก็บ Snapshot สองช่วงเวลาแล้วคำนวณ Delta = Counter หลัง − Counter ก่อน และหารด้วยระยะเวลาที่ผ่านไป การ Reset Counter ด้วย clear counters อาจกระทบหลักฐานการวิเคราะห์ จึงไม่ควรใช้ใน PM ปกติโดยไม่มีอนุมัติ

5. ตรวจ CPU, Memory, Uptime และ System Log

show processes cpu sorted
show processes memory sorted
show version
show logging

การแปลผล CPU และ Memory

ดูทั้งค่าเฉลี่ย ระยะเวลาที่ใช้งานสูง และแนวโน้มเมื่อเทียบ Baseline การใช้ CPU สูงชั่วคราวขณะมี Control Plane Event อาจไม่ใช่ปัญหา แต่การใช้สูงต่อเนื่องพร้อม Packet Drop หรือ Routing Instability ต้องเปิด Incident วิเคราะห์

Syslog ที่ควรติดตาม

• LINK/LINEPROTO: Port เปลี่ยนสถานะหรือ Flapping
• STP: Topology Change, Loop หรือ Guard Event
• Power/Fan/Temperature: สัญญาณผิดปกติด้านฮาร์ดแวร์
• AAA/Login: Authentication Failure หรือพฤติกรรมเข้าถึงผิดปกติ
• Routing: Neighbor Down, Adjacency Change หรือ Route Flap

ตรวจสอบว่า NTP และ Syslog Collector ทำงานปกติ เพราะ Timestamp ที่คลาดเคลื่อนจะทำให้การวิเคราะห์เหตุการณ์ผิดลำดับ

6. ตรวจ Power Supply, Fan และ Temperature

show environment all
show power
show inventory

คำสั่งขึ้นอยู่กับรุ่น เช่น Catalyst บางรุ่นใช้ show environment หรือคำสั่งตรวจ Stack/Power เฉพาะแพลตฟอร์ม ให้ยืนยันจาก CLI Help และเอกสารรุ่นนั้น

รายการตรวจหน้างาน

• Power Supply ทุกชุดมีสถานะตาม Design และไม่มี Alarm
• Fan ทำงานปกติ ช่องระบายอากาศไม่ถูกปิดกั้น
• Temperature อยู่ในช่วงที่ผู้ผลิตกำหนดสำหรับรุ่นนั้น
• Rack, UPS, สายไฟ, Grounding และ Fiber Patch Cord อยู่ในสภาพเหมาะสม
• อุปกรณ์ที่ออกแบบ Redundant Power ต้องทดสอบสถานะทั้งสองแหล่งจ่ายตามขั้นตอนที่อนุมัติ

ห้าม ถอด Power, SFP หรือสาย Uplink เพื่อทดสอบในระบบ Production โดยไม่มี Maintenance Window, Impact Assessment และ Rollback Plan

7. ตรวจ Layer 2: VLAN, STP และ EtherChannel

show vlan brief
show interfaces trunk
show spanning-tree summary
show spanning-tree root
show etherchannel summary
show mac address-table dynamic

ประเด็นที่ต้องตรวจ

• VLAN ที่ใช้งานตรงกับ IP/VLAN Plan และไม่เกิด VLAN ที่ไม่ทราบเจ้าของ
• Allowed VLAN บน Trunk ถูกต้องและไม่มี Native VLAN Mismatch
• STP Root Bridge อยู่ที่อุปกรณ์ที่ออกแบบไว้ ไม่เกิด Topology Change ผิดปกติ
• EtherChannel Member มีสถานะ Bundled ตามที่ควรเป็น
• ไม่มี MAC Flapping หรือ BPDU Guard Event ที่ไม่ได้รับการแก้ไข

หากพบความต่างจาก Baseline ให้บันทึกเป็น Finding ก่อนพิจารณาเปลี่ยน Configuration ไม่ควรแก้ทันทีระหว่าง Read-Only PM

8. ตรวจ Layer 3: Gateway, Routing และ Reachability

show ip interface brief
show ip route
show ip ospf neighbor
show standby brief
ping 192.168.99.1
traceroute 192.168.99.1

คำสั่ง OSPF และ HSRP ใช้เฉพาะเมื่ออุปกรณ์มีฟีเจอร์ดังกล่าว ส่วน IP 192.168.99.1 เป็นตัวอย่าง Lab ให้เปลี่ยนเป็นปลายทางที่องค์กรอนุญาตให้ทดสอบ

เกณฑ์ Verification

• Gateway/SVI สำคัญอยู่ในสถานะที่ถูกต้อง
• Routing Neighbor ตรงกับ Topology ที่ออกแบบ
• Default Route และ Route สำคัญมี Next Hop ถูกต้อง
• HSRP Active/Standby ตรงกับ Design และ Tracking ทำงานตามที่กำหนด
• Management Reachability ผ่าน แต่ต้องไม่ใช้ Ping อย่างเดียวสรุปว่าบริการ Application ปกติ

9. Firmware Review, Security Advisory และ End-of-Support

show version
show boot
show inventory

ขั้นตอนตรวจ Firmware

1. บันทึก Model, Hardware Revision, IOS/IOS XE Version และ Boot Image
2. ตรวจสถานะการสนับสนุนของรุ่นและ Software Train จากแหล่งข้อมูล Cisco อย่างเป็นทางการ
3. เทียบ Security Advisory/CVE ที่เกี่ยวข้องกับรุ่นและฟีเจอร์ที่เปิดใช้งานจริง
4. ประเมินความเสี่ยงจาก Exposure, Exploitability, Criticality และ Mitigation
5. เสนอ Change Request สำหรับการอัปเกรดพร้อม Backup, Compatibility Test, Rollback และ Maintenance Window

ข้อสำคัญ: PM ไม่เท่ากับการ Upgrade Firmware ทันที การอัปเกรดเป็นงานเปลี่ยนแปลงระบบที่ต้องผ่านการอนุมัติและทดสอบตามรุ่นอุปกรณ์

10. ตัวอย่าง Cisco Network PM Checklist

Check ID	รายการตรวจ	หลักฐาน	ผลตัวอย่าง
PM-01	Hostname, Model, IOS Version	show version	PASS
PM-02	Critical Uplink Status	show interfaces status	PASS
PM-03	CRC/Error Delta	Interface Counter Snapshot	OBSERVE
PM-04	CPU/Memory Trend	show processes	PASS
PM-05	Power/Fan/Temperature	Environment Output	PASS
PM-06	STP/Trunk/EtherChannel	show spanning-tree / trunk	PASS
PM-07	Routing/HA State	show ip route / standby	N/A
PM-08	Firmware Advisory	Version + Advisory Review	FOLLOW-UP
PM-09	Config Backup Validity	Backup Job + Hash	PASS
PM-10	Syslog/NTP Health	Log & Time Check	PASS

นิยามผลการตรวจ

PASS = ผ่านเกณฑ์ที่กำหนด, FAIL = ไม่ผ่านและต้องเปิด Defect/Incident, OBSERVE = พบแนวโน้มผิดปกติต้องติดตาม, FOLLOW-UP = ต้องดำเนินงานเพิ่มเติม, N/A = ไม่เกี่ยวข้องกับอุปกรณ์นี้

ไม่ควรใช้เกณฑ์เดียวกับทุกแพลตฟอร์ม เช่น CPU 70% หรือ Interface Utilization 80% เป็นค่าตัดสินตายตัว ควรอิง Baseline, Workload, Capacity และข้อกำหนดผู้ผลิต

11. Hands-on Lab: ตรวจสุขภาพ Cisco Switch แบบ Read-Only

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

Switch SW01 มี Management IP 192.168.99.11 และ Uplink GigabitEthernet1/0/24 ทีม PM ต้องตรวจสุขภาพโดยไม่เปลี่ยน Configuration

ขั้นตอนปฏิบัติ

1. ตรวจสอบ Device ID, การอนุญาตเข้าถึง และบันทึกเวลาเริ่ม PM
2. เชื่อมต่อ SSH ผ่าน Management Network ที่ได้รับอนุญาต
3. รันคำสั่ง Read-Only ตามชุดด้านล่างและบันทึก Output
4. เปรียบเทียบกับผล PM ครั้งก่อนและ Network Baseline
5. สรุป PASS/OBSERVE/FAIL และเปิด Work Order สำหรับรายการผิดปกติ

show clock
show version
show interfaces GigabitEthernet1/0/24
show interfaces status
show processes cpu sorted
show processes memory sorted
show logging
show spanning-tree summary
show etherchannel summary
show environment all

ตัวอย่างการวิเคราะห์

หาก Uplink มี CRC สะสม 120 ครั้ง และตรวจซ้ำ 15 นาทีต่อมาพบ 185 ครั้ง ให้บันทึก CRC Delta = 65 ครั้ง/15 นาที พร้อมตรวจสาย, SFP, สถานะฝั่งตรงข้าม และ Log ก่อนสรุปสาเหตุ ทั้งนี้ Counter อาจ Reset หรือ Wrap ได้ จึงต้องตรวจเวลาที่อุปกรณ์เริ่มนับและบริบทด้วย

เกณฑ์จบ Lab

มี Evidence ครบ, แยกข้อเท็จจริงออกจากข้อสันนิษฐาน, ระบุผู้รับผิดชอบ Follow-up และไม่เปลี่ยนสถานะอุปกรณ์โดยไม่จำเป็น

12. Maintenance Report, Defect Tracking และ Escalation

โครงสร้างรายงาน PM

Field	ตัวอย่าง
Work Order	PM-NET-2026-001
Site / Device	Station-01 / SW01
PM Schedule	M1
Inspection Time	2026-10-29 09:00 ICT (ตัวอย่าง)
Overall Result	OBSERVE
Finding	Uplink CRC Delta เพิ่มต่อเนื่อง
Evidence	CLI Snapshot, Interface Counter, Syslog
Action	ตรวจ Physical Layer และประสานทีมหน้างาน
Owner / Due Date	Network Maintenance / ตาม SLA
Verification	ตรวจ Counter Delta ซ้ำหลังแก้ไข

Escalation เมื่อพบความผิดปกติ

1. Critical: Core/Uplink Down, ระบบสำคัญหยุดให้บริการ, Redundancy สูญเสียจนเกิดความเสี่ยงสูง → เปิด Incident และแจ้งศูนย์ควบคุมตาม SLA
2. Major: Error เพิ่มต่อเนื่อง, อุณหภูมิผิดปกติ, Routing Flap → ประเมินผลกระทบและส่งต่อผู้เชี่ยวชาญ
3. Minor: เอกสารไม่ตรง, Firmware Review ค้าง, Port Label ไม่ครบ → เปิด Defect/Improvement ติดตามตามรอบ

ข้อควรระวังในการปิด Work Order

ควรปิดงานเมื่อบันทึกผลตรวจครบถ้วนและมีหลักฐานแนบ หากยังพบ Defect ให้เชื่อมโยง Incident/Corrective Work Order และระบุสถานะติดตามอย่างชัดเจน ไม่ควรระบุว่า “PM Passed” หากยังมี Critical Finding ที่ไม่ได้รับการจัดการ

13. คำถามที่พบบ่อย (FAQ)

PM Cisco Switch จำเป็นต้อง Restart เครื่องหรือไม่

ไม่จำเป็นสำหรับการตรวจสุขภาพตามปกติ และไม่ควร Restart อุปกรณ์ Production เพื่อทำ PM โดยไม่มีเหตุผลทางเทคนิคและการอนุมัติ

ควรตรวจทุก Port หรือเฉพาะ Uplink

ควรตรวจสถานะทุก Port ตาม Baseline และให้ความสำคัญกับ Critical Uplink, Trunk, EtherChannel และ Port ที่เชื่อมต่อระบบสำคัญเป็นพิเศษ

ทำ PM อัตโนมัติด้วย Python หรือ Ansible ได้หรือไม่

ได้ โดยใช้ SSH Read-Only Commands รวบรวม Output, เปรียบเทียบ Baseline และสร้าง Report แต่ต้องมี Credential Management, Rate Limiting, Error Handling และการตรวจผลโดยผู้รับผิดชอบ

พบ Interface Error แต่ระบบยังใช้งานได้ ต้องเปิด Incident หรือไม่

ขึ้นอยู่กับ Error Rate, แนวโน้ม, Criticality และเกณฑ์ SLA หาก Error เพิ่มต่อเนื่องควรเปิด Finding หรือ Incident ตามกระบวนการ แม้บริการยังไม่หยุดทำงาน

14. สรุป: PM ที่ดีต้องวัดผลได้และป้องกันปัญหาได้จริง

การดูแล Cisco Network อย่างเป็นระบบควรเริ่มจาก Asset Inventory → PM Schedule → Read-Only Health Check → Baseline Comparison → Finding → Corrective Action → Verification → Report เพื่อให้ทีม Network Operations เห็นความเสี่ยงล่วงหน้า ลด Downtime และใช้ข้อมูลสนับสนุนการวางแผน Spare Parts, Firmware และ Capacity

สำหรับองค์กรที่มีหลายสถานีหรือหลายสาขา การใช้ Checklist และรูปแบบรายงานเดียวกันจะช่วยให้ทีมหน้างานกับศูนย์ควบคุมสื่อสารกันได้ชัดเจนขึ้น และตรวจสอบคุณภาพงานย้อนหลังได้

อ่านต่อ: Cisco Network Fault Management & Root Cause Analysis — Event Correlation, Incident Timeline, Fault Isolation และ Problem Management