Enterprise Network Operations Runbook: Cisco Maintenance และ Disaster Recovery

Networking / Cisco / Network Operations

Enterprise Network Operations Runbook: คู่มือ Incident Response, Preventive Maintenance, Configuration Compliance และ Disaster Recovery

เครือข่ายองค์กรที่ออกแบบดีต้องมีขั้นตอนปฏิบัติงานที่ชัดเจนด้วย บทความนี้นำเสนอ Network Operations Runbook สำหรับทีม Network Engineer และ Maintenance โดยใช้ตัวอย่าง Cisco Switch/Router ครอบคลุมการรับแจ้งเหตุ ตรวจสอบสาเหตุ แก้ไข กู้คืน ทดสอบ และจัดทำหลักฐานส่งมอบงาน

ขอบเขต: ตัวอย่างคำสั่งเน้น Cisco IOS/IOS XE และต้องปรับให้ตรงรุ่นอุปกรณ์ สิทธิ์ผู้ดูแล และนโยบายองค์กรก่อนใช้งานจริง คำสั่งที่เปลี่ยนสถานะระบบต้องผ่านการอนุมัติ

สารบัญ

1. Network Operations Runbook คืออะไร
2. ขอบเขตและโครงสร้างทีม
3. Incident Response Workflow
4. Cisco CLI สำหรับ Initial Triage
5. กรณีศึกษา Incident
6. Preventive Maintenance
7. Configuration Compliance
8. Change Management และ Rollback
9. Disaster Recovery
10. Monitoring และ KPI
11. แบบฟอร์มและหลักฐานงาน
12. Lab และ Acceptance Test
13. FAQ และบทสรุป

1. Network Operations Runbook คืออะไร

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

Runbook, SOP และ Work Instruction ต่างกันอย่างไร

• SOP: ขั้นตอนมาตรฐานระดับกระบวนการ เช่น การจัดการ Incident และ Change
• Runbook: ขั้นตอนตอบสนองสถานการณ์เฉพาะ เช่น Uplink Down หรือ Switch ไม่ตอบสนอง
• Work Instruction (WI): คำแนะนำละเอียดระดับงาน เช่น วิธีเก็บ Running Configuration หรือเปลี่ยนอุปกรณ์ Spare

เอกสารที่ใช้งานจริงควรมี Document ID, Version, Owner, Approval, Last Reviewed, Scope, Prerequisites, Procedure, Verification, Rollback และ Evidence เพื่อควบคุมคุณภาพและตรวจสอบย้อนหลังได้

2. กำหนดขอบเขตบริการและความรับผิดชอบ

ตัวอย่างองค์กรมี Core Switch 2 ตัว, Distribution Switch 2 ตัว, Access Switch หลายตัว, Edge Router 2 ตัว และระบบ Monitoring/Syslog แยกจาก Production Network

บทบาท	ความรับผิดชอบ	ผลลัพธ์ที่ต้องส่งมอบ
Service Desk / NOC	รับ Alarm, เปิด Ticket, ตรวจสอบผลกระทบ	Incident ID และ Timeline
Network Engineer	Triage, วิเคราะห์ Root Cause, เสนอ Recovery	CLI Evidence และ Recovery Plan
Field Engineer	ตรวจ Physical Link, Power, Optic, Patch Cord	ผลตรวจหน้างานและภาพประกอบ
Change Approver	อนุมัติ Change Window และความเสี่ยง	Change Record
Incident Manager	ประสานงานและสรุปเหตุการณ์	Incident Report / Postmortem

ข้อสำคัญ: SLA Response Time, Restoration Target, On-call Schedule และ Escalation Contact ต้องกำหนดตามสัญญาจริง ไม่ควรนำค่าตัวอย่างไปอ้างเป็นข้อผูกพันของระบบ Production

3. Incident Response Workflow: จาก Alarm ถึงปิด Ticket

1. Detect: รับแจ้งจาก Monitoring, Syslog, ผู้ใช้งาน หรือเจ้าหน้าที่หน้างาน
2. Record: บันทึกเวลา อุปกรณ์ ตำแหน่ง อาการ และบริการที่ได้รับผลกระทบ
3. Classify: ประเมิน Severity ตาม Impact และ Urgency
4. Triage: ตรวจสอบ Physical, Interface, VLAN, STP, Routing และ Services ตามลำดับ
5. Contain: ลดผลกระทบโดยไม่ทำให้หลักฐานสูญหาย และหลีกเลี่ยงการเปลี่ยน Config โดยไม่มีอนุมัติ
6. Recover: ใช้ Recovery Procedure ที่ได้รับอนุมัติ
7. Verify: ตรวจ Service End-to-End, Monitoring และความเสถียรหลังแก้ไข
8. Close: บันทึก Root Cause, Actions, Evidence และ Preventive Action

ตัวอย่างการจัดระดับเหตุการณ์

Severity	ตัวอย่างผลกระทบ	แนวทางตอบสนอง
Critical	Core Network ล่มหรือบริการสำคัญหยุดทั้งระบบ	ประกาศ Major Incident และ Escalate ทันที
High	หลาย VLAN หรือหลายพื้นที่ใช้งานไม่ได้	ประสานทีมที่เกี่ยวข้องและติดตามอย่างใกล้ชิด
Medium	อุปกรณ์หรือพอร์ตบางส่วนมีปัญหา	ตรวจสอบและแก้ตามลำดับความสำคัญ
Low	Alarm ไม่กระทบบริการหรือปัญหาเชิงเอกสาร	วางแผนแก้ไขตามรอบงาน

4. Cisco CLI สำหรับ Initial Triage แบบ Read-Only

เริ่มจากคำสั่ง show ที่ไม่เปลี่ยน Configuration เพื่อเก็บสภาพระบบก่อนดำเนินการใด ๆ

show clock
show version
show inventory
show interfaces status
show interfaces description
show interfaces counters errors
show logging
show ip interface brief
show vlan brief
show interfaces trunk
show spanning-tree summary
show etherchannel summary
show ip route
show ip ospf neighbor
show standby brief
show cdp neighbors detail
show lldp neighbors detail

หมายเหตุ: บางคำสั่งไม่รองรับทุก Platform เช่น Router อาจไม่มี show interfaces status หรืออุปกรณ์บางรุ่นไม่ได้เปิด CDP/LLDP ให้เลือกคำสั่งตาม Capability และ Policy

แนวทางแปลผล

สิ่งที่พบ	ตรวจสอบเพิ่มเติม	ข้อควรระวัง
Interface down/down	Power, Cable, SFP, Remote Port, Err-disable	อย่ารีบสั่ง shutdown/no shutdown
CRC/Input Errors เพิ่ม	Optic, Cable, Duplex, Transceiver, Baseline	พิจารณา Counter Delta ไม่ใช่ค่า Total อย่างเดียว
OSPF Neighbor หาย	IP, Area, Authentication, MTU, Timers, Link	หลีกเลี่ยง Clear Process โดยไม่มีอนุมัติ
STP Topology Changes สูง	Loop, Flapping, Edge Port, Root Bridge	การเปลี่ยน STP อาจกระทบหลาย VLAN
HSRP Active เปลี่ยน	Tracking, Interface, Priority, Preempt	ตรวจทั้ง Active และ Standby

5. ตัวอย่าง Incident Runbook ที่นำไปประยุกต์ใช้ได้

Case A: Access Switch Uplink Down

Symptom: ผู้ใช้งานในโซนเดียวกันไม่สามารถเข้าถึง Gateway ได้

show interfaces description
show interfaces GigabitEthernet1/0/24
show interfaces status
show interfaces trunk
show logging

Verification: เปรียบเทียบ Port Mapping, สถานะปลายทาง, VLAN Allowed List และ Error Counter หากพบ Link Down ให้ตรวจ Patch Cord, SFP และอุปกรณ์ปลายทางก่อนเปลี่ยน Configuration

Recovery: เปลี่ยนสายหรือโมดูลตาม WI และสิทธิ์หน้างาน ทดสอบ Link, VLAN และ Application จาก Client ที่ได้รับผลกระทบ

Case B: OSPF Neighbor Down หลัง Maintenance

show ip ospf neighbor
show ip ospf interface
show ip interface brief
show ip route
show logging

Hypothesis: Area ไม่ตรง, IP/Subnet ผิด, Authentication ไม่ตรง, MTU หรือ Network Type แตกต่างกัน ตรวจ Change Log และ Compare Configuration ก่อนตัดสินใจ Rollback

Case C: Intermittent Packet Loss

show interfaces counters errors
show interfaces GigabitEthernet1/0/24
show processes cpu sorted
show logging

บันทึกค่าก่อนและหลังช่วงเวลาเดียวกันเพื่อดู Error Rate ตรวจ Latency, Loss, Utilization และอุปกรณ์ทั้งสองฝั่ง หากมี QoS หรือ WAN Provider ให้ตรวจ Policy และหลักฐานร่วมกัน ไม่สรุปจาก Ping เพียงครั้งเดียว

Case D: Suspicious Configuration Change

เมื่อ Configuration แตกต่างจาก Approved Baseline ให้เก็บ Running Configuration, AAA Logs, Syslog, Change Ticket และเวลาอุปกรณ์ จากนั้นตรวจว่ามีการอนุมัติหรือไม่ หากสงสัยการเข้าถึงโดยไม่ได้รับอนุญาตให้ประสานทีม Security และรักษาหลักฐานก่อนแก้ไข

6. Preventive Maintenance (PM) สำหรับ Cisco Network

PM ควรเน้น Health Check, Trend Analysis, Backup Verification และ Risk Reduction ไม่ใช่การ Reboot อุปกรณ์ตามรอบโดยไม่มีเหตุผล

รอบ	กิจกรรม	หลักฐาน
Daily	Alarm, Reachability, Interface Status, Critical Syslog	Dashboard / Alarm Log
Weekly	Interface Error Trend, Uplink Utilization, HSRP/OSPF State	Trend Report
Monthly	Configuration Backup, Inventory, NTP, AAA, Compliance Sampling	Backup Index / Audit Report
Quarterly	Restore Drill ใน Lab, Spare Readiness, Capacity Review	Test Record / Spare Checklist
Annually	DR Exercise, Lifecycle Review, Runbook Review	DR Report / Approved Revision

PM Checklist ตัวอย่าง

• ตรวจ Device Hostname, Serial Number, Model และ Software Version เทียบ Inventory
• ตรวจ Power Supply, Fan, Temperature และ Hardware Alarm ตามรุ่นอุปกรณ์
• ตรวจ Interface Errors และ Uplink Utilization เทียบ Historical Baseline
• ตรวจ Routing/Redundancy State และ Syslog ที่ผิดปกติ
• ตรวจว่า Backup ล่าสุดอ่านได้และจัดเก็บในพื้นที่ที่ได้รับอนุญาต
• บันทึก Findings, Risk, Corrective Action, Owner และ Due Date

7. Configuration Compliance และ Drift Detection

Configuration Baseline คือชุดค่าที่ได้รับอนุมัติสำหรับแต่ละ Device Role เช่น Access, Distribution, Core และ Edge ส่วน Configuration Drift คือความแตกต่างระหว่างสถานะจริงกับ Baseline

หัวข้อที่ควรตรวจ

• Management Security: SSH, AAA, Privilege, Authorized Accounts และ Access Control
• Logging: Syslog Destination, Timestamp และ NTP
• Layer 2: VLAN, Trunk, STP Root, Port Security ตาม Design
• Layer 3: Routing Neighbor, Default Route, HSRP/VRRP และ ACL
• Configuration Integrity: Compare Running/Startup Config และ Approved Backup

show running-config
show startup-config
show ip ssh
show ntp associations
show logging
show ip ospf neighbor
show standby brief

ใช้เครื่องมือเช่น Ansible, Git และ Configuration Backup System ช่วยเปรียบเทียบค่าที่ได้รับอนุมัติ แต่ต้อง Mask Password, Community String, Keys และ Sensitive Data ก่อนนำผลไปเก็บใน Repository หรือส่งต่อ

ข้อควรระวัง: การมีคำสั่งหนึ่งอยู่ใน Running Config ไม่ได้ยืนยันว่า Control นั้นมีประสิทธิผล ต้องตรวจ Operational State และทดสอบตามขอบเขตที่ได้รับอนุญาตด้วย

8. Change Management, MOP และ Rollback Plan

การเปลี่ยนแปลง Configuration ควรมี Method of Procedure (MOP) ซึ่งระบุ Current State, Target State, Impact, Pre-check, Implementation, Post-check, Rollback Trigger และผู้อนุมัติ

ลำดับ Change ที่แนะนำ

1. เปิด Change Ticket และตรวจ Impact/Dependency
2. สำรอง Configuration พร้อมตรวจความสมบูรณ์ของไฟล์
3. บันทึก Pre-change Output และ Service Baseline
4. ยืนยัน Maintenance Window และช่องทางสื่อสารสำรอง
5. ดำเนินการทีละอุปกรณ์หรือทีละกลุ่มตาม Approved MOP
6. ตรวจ Routing, Redundancy, Interface, Application และ Monitoring
7. Rollback หากเข้าเกณฑ์ที่กำหนดและได้รับอนุมัติตามกระบวนการ
8. อัปเดต As-built Diagram, Baseline และ Change Log

Rollback ไม่ใช่แค่คัดลอก Config เก่ากลับไป: ต้องพิจารณาความต่างของ Hardware, Software, Interface Naming, VLAN Database และสถานะระบบขณะเกิดเหตุด้วย การ Restore อาจกระทบการเชื่อมต่อและต้องทดสอบใน Lab ก่อน

9. Disaster Recovery (DR) สำหรับ Network Infrastructure

Disaster Recovery คือการเตรียมคืนบริการเมื่อเกิดเหตุรุนแรง เช่น Core Switch เสียหาย, อุปกรณ์เครือข่ายสูญหาย, Site ขาดการเชื่อมต่อ หรือ Configuration เสียหาย

RTO และ RPO

• RTO (Recovery Time Objective): ระยะเวลาสูงสุดที่องค์กรยอมรับได้ก่อนบริการต้องกลับมาทำงาน
• RPO (Recovery Point Objective): ปริมาณข้อมูลหรือการเปลี่ยนแปลงล่าสุดที่ยอมรับการสูญเสียได้ เช่น ช่วงเวลาระหว่าง Backup

RTO/RPO ต้องได้รับการกำหนดจาก Business Impact Analysis ไม่ควรอ้างว่ามีเป้าหมายใดโดยไม่มีการอนุมัติ

DR Runbook: Replace Failed Switch

1. ยืนยัน Fault ด้วย Monitoring, Console, Power และ Hardware Indicator
2. ตรวจผลกระทบและเส้นทางสำรองที่ยังทำงานอยู่
3. บันทึก Serial, Model, Port Mapping และ Firmware ของอุปกรณ์เดิม
4. เลือก Spare ที่เข้ากันได้กับ Software, License, Module และ Port Requirement
5. เตรียม Golden Configuration ที่ตรวจสอบแล้วและปรับ Device-specific Parameters
6. เปลี่ยนอุปกรณ์ตามขั้นตอน Safety/Change Approval
7. ตรวจ Physical Link, VLAN, Routing, Redundancy, Monitoring และ Application
8. อัปเดต Asset Inventory, Backup, Diagram และ Incident Record

ข้อควรระวัง: อย่าเสียบ Spare ที่ยังมี Configuration จากระบบอื่นเข้ากับ Production โดยไม่ตรวจสอบ เพราะอาจเกิด Duplicate IP, STP Root Change, VLAN Leakage หรือ Routing Conflict

10. Monitoring, Alerting และ Network Operations KPI

ระบบ Monitoring ควรรวม SNMPv3, Syslog, NTP, Interface Metrics, Device Availability และ Configuration Events โดยแยก Alarm ที่ต้องดำเนินการทันทีออกจาก Event เพื่อการวิเคราะห์แนวโน้ม

KPI	ความหมาย	วิธีใช้
MTTA	Mean Time to Acknowledge	วัดความเร็วในการรับทราบ Incident
MTTR	Mean Time to Restore/Repair ตามนิยามองค์กร	วัดประสิทธิภาพการคืนบริการ
Availability	สัดส่วนเวลาที่บริการพร้อมใช้งาน	ติดตาม SLA/SLO ที่กำหนด
Change Success Rate	สัดส่วน Change ที่ผ่านเกณฑ์โดยไม่ต้อง Rollback	ประเมินคุณภาพ MOP
Backup Success Rate	สัดส่วน Backup ที่สำเร็จและตรวจสอบได้	ประเมินความพร้อม DR

การตั้ง Threshold ต้องอ้างอิง Baseline และความสำคัญของบริการ ไม่ควรใช้ค่าเดียวกับทุก Interface หรือทุก Site

11. Template เอกสารสำหรับทีม Network Operations

Incident Record

Incident ID:
Detected Time / Time Zone:
Affected Site / Device / Service:
Severity / Business Impact:
Reported Symptom:
Initial Evidence:
Hypothesis / Root Cause:
Actions Taken / Approval Reference:
Recovery Time:
Verification Result:
Prevention / Follow-up Owner:
Ticket Closed By:

Change Record

Change ID:
Requestor / Approver:
Affected Devices:
Reason / Risk Assessment:
Maintenance Window:
Pre-change Backup Location:
Implementation Steps:
Rollback Steps / Trigger:
Post-change Acceptance Criteria:
Actual Result / Evidence:
Documentation Updated:

PM Report

PM ID / Schedule:
Device Inventory Verified:
Hardware Health:
Interface / Routing / Redundancy Status:
Syslog / Alarm Review:
Backup / Compliance Result:
Abnormal Findings:
Corrective Work Order:
Engineer / Reviewer / Date:

กำหนดสิทธิ์เข้าถึงเอกสารและระยะเวลาจัดเก็บตามนโยบายองค์กร โดยเฉพาะ Configuration Backup, IP Plan และข้อมูลบัญชีผู้ดูแล

12. Hands-on Lab: ฝึก Incident และ Recovery ในระบบจำลอง

เป้าหมาย: ฝึกตรวจสอบ Uplink Down และการกู้คืนบริการโดยไม่รบกวนเครือข่ายจริง ใช้ Cisco Packet Tracer, CML หรืออุปกรณ์ Lab ที่ได้รับอนุญาต

Topology ตัวอย่าง

PC-A --- SW-ACCESS --- SW-DIST --- R-GW
          VLAN 10       Trunk      Gateway

ขั้นตอนฝึก

1. ตั้งค่า VLAN 10 และยืนยันว่า PC-A ติดต่อ Gateway ได้
2. เก็บ Baseline: Interface Status, Trunk, VLAN, Ping และ Configuration
3. ใน Lab เท่านั้น ให้ผู้ฝึกอีกคนจำลอง Uplink Fault โดยไม่บอกตำแหน่ง
4. ใช้คำสั่ง Read-Only เพื่อระบุ Fault Domain และรวบรวม Evidence
5. เขียน Hypothesis และ Recovery Proposal ก่อนแก้ไข
6. คืนค่าระบบตาม MOP ที่กำหนด และยืนยันการสื่อสาร End-to-End
7. จัดทำ Incident Record, Timeline และข้อเสนอ Prevention

Acceptance Criteria

• ระบุจุดเสียและหลักฐานที่เกี่ยวข้องได้
• ไม่เปลี่ยน Configuration นอกขอบเขตที่ได้รับอนุญาต
• บริการกลับมาทำงานและตรวจสอบได้จากปลายทางจริง
• มี Incident Timeline, Root Cause และ Follow-up Action ครบถ้วน

13. FAQ และบทสรุป

ต้องมี Network Monitoring ก่อนเขียน Runbook หรือไม่

ไม่จำเป็น สามารถเริ่มจาก Device Inventory, Topology, Incident Checklist และ CLI Verification ได้ก่อน แล้วเชื่อม Monitoring เมื่อระบบพร้อม

PM ควร Reboot Cisco Switch ทุกเดือนหรือไม่

ไม่ควรถือเป็นกิจกรรมมาตรฐานโดยอัตโนมัติ การ Reboot มีผลกระทบต่อบริการ ควรดำเนินการเมื่อมีเหตุผลทางเทคนิคและได้รับอนุมัติเท่านั้น

Configuration Backup เท่ากับ Disaster Recovery หรือไม่

ไม่เท่ากัน Backup เป็นเพียงองค์ประกอบหนึ่งของ DR ยังต้องมี Compatible Spare, License, Network Documentation, Restore Procedure และการทดสอบกู้คืน

จะเริ่มใช้ Runbook ในทีมขนาดเล็กอย่างไร

เริ่มจาก 3 เหตุการณ์ที่พบบ่อยที่สุด เช่น Uplink Down, Device Unreachable และ Routing Neighbor Down จากนั้นทบทวน Runbook หลัง Incident และ PM แต่ละครั้ง

สรุป: Enterprise Network Operations Runbook ช่วยให้การดูแลเครือข่ายมีมาตรฐาน ตรวจสอบย้อนหลังได้ ลดความเสี่ยงจากการแก้ไขโดยไม่มีแผน และเพิ่มความพร้อมในการกู้คืนบริการ ทั้ง Incident Response, Preventive Maintenance, Configuration Compliance, Change Management และ Disaster Recovery ควรเชื่อมกันเป็นกระบวนการเดียว