Cisco Network Service Level Management: SLA, SLO, Availability และ MTTR

Networking / Cisco / Network Operations

การบริหารระดับการให้บริการเครือข่ายไม่ใช่เพียงการนับเวลาที่อุปกรณ์เสีย แต่เป็นการกำหนดขอบเขตบริการ การวัดผล การตอบสนองเหตุขัดข้อง และการรายงานผลอย่างตรวจสอบย้อนหลังได้ บทความนี้อธิบายแนวทางสร้าง SLA และ SLO สำหรับ Cisco Switch/Router ในองค์กร รวมถึงระบบที่ต้องให้บริการต่อเนื่อง เช่น เครือข่ายสถานีขนส่ง

ขอบเขต: บทความเป็นตัวอย่างเชิงวิศวกรรมและการปฏิบัติงาน ตัวเลขเป้าหมายและเวลาตอบสนองต้องได้รับอนุมัติตามสัญญาและ TOR จริงก่อนใช้งาน

สารบัญ

1. Service Level Management คืออะไร
2. SLA, SLO และ SLI ต่างกันอย่างไร
3. กำหนด Service Scope และ Service Window
4. Availability, MTTR, MTBF และ KPI
5. Incident Priority และ Escalation Matrix
6. Incident Workflow และ Cisco CLI
7. Monitoring และหลักฐานประกอบ SLA
8. Monthly Service Report และ Dashboard
9. กรณีศึกษาเครือข่ายสถานีขนส่ง
10. Hands-on Lab
11. Governance, Security และข้อควรระวัง
12. คำถามที่พบบ่อย
13. สรุป

1. Cisco Network Service Level Management คืออะไร

Network Service Level Management คือกระบวนการกำหนด วัด ติดตาม และปรับปรุงคุณภาพการให้บริการเครือข่ายตามความคาดหวังที่ตกลงกันไว้ โดยพิจารณาทั้งความพร้อมใช้งานของระบบ ความรวดเร็วในการตอบสนองและแก้ไขเหตุขัดข้อง คุณภาพการสื่อสาร และความถูกต้องของรายงาน

1.1 มุมมองจากอุปกรณ์สู่บริการ

การที่ Cisco Switch มีสถานะ up ไม่ได้หมายความว่าบริการปลายทางใช้งานได้เสมอไป เช่น Switch อาจทำงานปกติแต่ DHCP, Default Gateway หรือเส้นทาง WAN มีปัญหา จึงควรกำหนดตัวชี้วัดทั้งระดับอุปกรณ์และระดับบริการ

1.2 ผู้เกี่ยวข้อง

• Service Owner: กำหนดความต้องการและยอมรับระดับบริการ
• Network Operations: เฝ้าระวัง รับแจ้งเหตุ และประสานงานแก้ไข
• Field Engineer: ตรวจสอบอุปกรณ์และสายสัญญาณหน้างาน
• Vendor/ISP: รับช่วงแก้ไขตามขอบเขตสัญญา
• Service Manager: ติดตาม KPI, Escalation และรายงานผล

2. SLA, SLO และ SLI ต่างกันอย่างไร

คำศัพท์	ความหมาย	ตัวอย่าง
SLA	ข้อตกลงระดับบริการระหว่างผู้ให้บริการกับผู้รับบริการ	บริการ Support 8×5 พร้อมเงื่อนไขการตอบสนองและการรายงาน
SLO	เป้าหมายคุณภาพบริการที่ต้องการบรรลุ	Availability ≥ 99.5% ในช่วงเวลาที่ตกลง
SLI	ตัวชี้วัดที่วัดได้จริง	สัดส่วนเวลาที่บริการตอบสนองสำเร็จจากการตรวจวัด

ข้อควรระวัง: SLA อาจรวมข้อกำหนดด้านขอบเขตงาน ข้อยกเว้น บทลงโทษ และการนับเวลา ไม่ใช่เพียงตัวเลข Availability ส่วน SLO เป็นเป้าหมาย และ SLI เป็นค่าที่ตรวจวัดได้

2.1 ตัวอย่าง SLI ระดับบริการ

สำหรับบริการเชื่อมต่อระบบจำหน่ายตั๋ว อาจกำหนด SLI เป็น อัตราความสำเร็จของการเชื่อมต่อจากอุปกรณ์ปลายทางไปยังระบบที่จำเป็น โดยแยกจากสถานะ Port ของ Switch และระบุวิธีเก็บข้อมูลให้ชัดเจน

3. กำหนด Service Scope, Coverage และ Service Window

3.1 ความหมายของ 8×5 และ 24×7

รูปแบบ	ความหมายทั่วไป	ประเด็นที่ต้องระบุในสัญญา
8×5	ให้บริการ 8 ชั่วโมงต่อวัน 5 วันต่อสัปดาห์	วันทำการ เวลาเริ่ม-สิ้นสุด วันหยุด และการรับแจ้งนอกเวลา
24×7	ให้บริการทุกชั่วโมงทุกวัน	ระดับความพร้อมของทีม การเฝ้าระวัง การเข้าพื้นที่ และการส่งต่อเวร

สำคัญ: 8×5 ไม่ได้แปลว่าอุปกรณ์ต้องทำงานเพียง 8 ชั่วโมงต่อวัน และไม่ได้หมายความว่ามีเจ้าหน้าที่แก้ไขเหตุภาคสนามตลอด 24 ชั่วโมง การรับแจ้งเหตุ การตอบสนอง และการเข้าหน้างานต้องแยกนิยามให้ชัดเจน

3.2 Service Catalog สำหรับ Cisco Switch

บริการ	รวมในขอบเขตหรือไม่	ตัวอย่างรายละเอียด
Incident Troubleshooting	ตามสัญญา	ตรวจสอบ Link, VLAN, STP, Routing และ Power
Preventive Maintenance	ตามสัญญา	ตรวจสุขภาพอุปกรณ์ Firmware และ Configuration
Configuration Backup	ตามสัญญา	สำรองไฟล์และตรวจสอบความสมบูรณ์
Hardware Replacement	ต้องระบุ	อะไหล่ Spare, RMA, ผู้รับผิดชอบจัดซื้อ
ISP/WAN Fault	ขึ้นกับผู้รับผิดชอบ	ประสานผู้ให้บริการและติดตาม Ticket

3.3 Service Boundary

จัดทำ Responsibility Matrix แยกความรับผิดชอบระหว่าง Network Team, System/Application Team, ISP และผู้รับเหมาดูแลอุปกรณ์ เพื่อไม่ให้เหตุขัดข้องถูกนับผิดบริการ

4. วิธีคำนวณ Availability, MTTR, MTBF และ KPI

4.1 Availability

Availability (%) = (Eligible Service Time - Counted Downtime)
                   / Eligible Service Time × 100

ตัวอย่าง: ช่วงบริการที่มีสิทธินับ 160 ชั่วโมงต่อเดือน มี Downtime ที่นับตาม SLA 2 ชั่วโมง

Availability = (160 - 2) / 160 × 100 = 98.75%

ต้องกำหนดให้ชัดว่า Planned Maintenance, เหตุสุดวิสัย และเหตุจากระบบภายนอกนับเป็น Downtime หรือเป็น Exclusion ตามสัญญาหรือไม่ ห้ามตัดออกเองโดยไม่มีเกณฑ์ที่อนุมัติ

4.2 MTTR — Mean Time to Repair/Restore

ในรายงานควรระบุว่า MTTR หมายถึง Mean Time to Repair หรือ Mean Time to Restore เพราะจุดสิ้นสุดอาจต่างกัน เช่น บริการกลับมาใช้งานได้ก่อนเปลี่ยนอุปกรณ์ถาวร

MTTR = ผลรวมระยะเวลาการซ่อมหรือกู้คืนตามนิยาม / จำนวนเหตุที่นำมาคำนวณ

ตัวอย่าง 3 เหตุ ใช้เวลา 30, 60 และ 90 นาที ได้ MTTR = 60 นาที

4.3 MTBF — Mean Time Between Failures

MTBF = เวลาทำงานที่อยู่ในขอบเขตการวัด / จำนวนความขัดข้อง

MTBF เหมาะกับการติดตามความเชื่อถือได้ของอุปกรณ์ที่ซ่อมกลับมาใช้ซ้ำ แต่ไม่ควรใช้แทนการวัดความพร้อมใช้งานของบริการทั้งหมด

4.4 KPI ที่ควรติดตาม

KPI	แนวทางวัด	ข้อควรระวัง
Availability	เวลาบริการที่ใช้งานได้ / เวลาที่นับ	ต้องนิยาม Service Window และ Exclusion
Response Time	รับ Ticket ถึงเริ่มตอบสนองตามนิยาม	ไม่ใช่เวลาแก้ไขเสร็จ
Restore Time	เริ่มเหตุถึงบริการกลับมาใช้งาน	แยก Workaround จาก Permanent Fix
Repeat Incident Rate	เหตุซ้ำ / เหตุทั้งหมด	กำหนดช่วงเวลาการนับเหตุซ้ำ
PM Completion	งาน PM เสร็จตามกำหนด / งาน PM ที่ครบกำหนด	แยกงานเลื่อนที่อนุมัติ

5. Incident Priority และ Escalation Matrix

5.1 ประเมิน Priority จาก Impact และ Urgency

ระดับตัวอย่าง	ผลกระทบ	แนวทางดำเนินการ
P1 Critical	บริการสำคัญหลายสถานีหยุดทำงานหรือมีผลกระทบกว้าง	เปิด Major Incident ประสานทีมที่เกี่ยวข้องทันที
P2 High	บริการสถานีหนึ่งหยุดทำงานหรือระบบสำรองล้มเหลว	เร่งตรวจสอบและติดตามจน Restore
P3 Medium	Port หรืออุปกรณ์บางส่วนมีปัญหาแต่มีทางเลือกใช้งาน	จัดคิวแก้ไขตาม SLA
P4 Low	คำขอทั่วไปหรือความผิดปกติที่ยังไม่กระทบบริการ	ดำเนินการตามรอบบริการ

ระดับ Priority ข้างต้นเป็น ตัวอย่าง ไม่ใช่ข้อกำหนดของ Cisco หรือ SLA สากล ต้องปรับให้ตรงความสำคัญของบริการและสัญญาจริง

5.2 ตัวอย่าง Escalation Matrix

ขั้น	ผู้รับผิดชอบ	หน้าที่
L1	Monitoring / Service Desk	เปิด Ticket ตรวจ Alarm เก็บเวลาและหลักฐานเบื้องต้น
L2	Network Engineer / Field Engineer	ตรวจ Cisco CLI, สายสัญญาณ, Uplink และกู้คืนบริการ
L3	Senior Engineer / Vendor	วิเคราะห์ปัญหาซับซ้อน ประสาน TAC หรือ ISP
Management	Service Owner / Incident Manager	ตัดสินใจด้านผลกระทบ การสื่อสารและการอนุมัติ Change

5.3 ตัวอย่าง Response Target เพื่อออกแบบ SLA

อาจตั้งเป้าภายใน เช่น P1 ตอบรับ 15 นาที, P2 30 นาที, P3 2 ชั่วโมงทำการ และ P4 ภายในวันทำการถัดไป แต่ ตัวเลขเหล่านี้เป็นเพียงตัวอย่างการออกแบบ ไม่ใช่ SLA ที่มีผลผูกพันจนกว่าจะได้รับอนุมัติ

6. Incident Workflow และ Cisco CLI Troubleshooting

6.1 ขั้นตอนมาตรฐาน

1. Detect: รับ Alarm หรือรับแจ้งผู้ใช้งาน
2. Log: บันทึก Ticket ID, เวลาที่ตรวจพบ, อุปกรณ์และบริการที่ได้รับผลกระทบ
3. Classify: กำหนด Priority, Impact, Urgency และ Service Owner
4. Diagnose: ตรวจสอบหลักฐานโดยเริ่มจากคำสั่ง Read-Only
5. Escalate: ส่งต่อเมื่อเกินขอบเขตหรือมีความเสี่ยงต่อ SLA
6. Restore: ดำเนินการตาม Runbook ที่อนุมัติและตรวจสอบผล
7. Close: บันทึกสาเหตุ เวลาคืนบริการ และหลักฐานยืนยัน
8. Review: วิเคราะห์แนวโน้มและป้องกันเหตุซ้ำ

6.2 Cisco CLI สำหรับการตรวจสอบเบื้องต้น

show clock
show version
show interfaces status
show interfaces description
show interfaces counters errors
show logging
show spanning-tree summary
show etherchannel summary
show ip interface brief
show ip route

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

6.3 ตัวอย่างตรวจ Uplink

show interfaces GigabitEthernet1/0/24
show interfaces GigabitEthernet1/0/24 counters errors
show interfaces trunk
show spanning-tree interface GigabitEthernet1/0/24 detail
show logging | include LINK|LINEPROTO

ตรวจสอบ Link State, Error Counters, Trunk VLAN, STP State และ Syslog ร่วมกันก่อนสรุป Root Cause ไม่ควร Shutdown/No Shutdown Port โดยไม่มีการประเมินผลกระทบ

6.4 Timeline ที่ต้องเก็บ

เวลา	เหตุการณ์	หลักฐาน
09:10	Monitoring พบ Uplink Down	Alert ID และ Syslog
09:13	L1 เปิด Ticket	Ticket Created Timestamp
09:20	L2 เริ่มตรวจสอบ	Engineer Acknowledgement
09:45	บริการกลับมาใช้งาน	Monitoring และ User Confirmation
10:05	บันทึก Root Cause เบื้องต้น	Incident Record

ตัวอย่างนี้มีเวลาจากการตรวจพบจนบริการกลับมาใช้งาน 35 นาที แต่เวลา Response/Restore ที่ใช้คิด SLA ต้องยึดจุดเริ่มและจุดสิ้นสุดตามข้อตกลงจริง

7. Monitoring และ Evidence Collection สำหรับ SLA

7.1 แหล่งข้อมูล

• SNMPv3: สถานะ Interface, Counter และทรัพยากรอุปกรณ์
• Syslog: เหตุการณ์ Link, Authentication และการเปลี่ยนแปลง Configuration
• ICMP/TCP Probe: ตรวจ Reachability และการตอบสนองของบริการ
• NetFlow/Telemetry: แนวโน้ม Traffic และความหนาแน่นของระบบ
• Ticketing System: เวลารับแจ้ง การตอบสนอง การส่งต่อ และการปิดเหตุ

7.2 หลักฐานที่ควรเก็บ

ควรบันทึก Device ID, Site, Interface, Timestamp, Time Zone, Event ID, Incident ID, ผลตรวจสอบก่อน-หลัง, ผู้อนุมัติ และผู้ดำเนินการ พร้อมตั้ง NTP ให้เวลาของอุปกรณ์และระบบ Monitoring สอดคล้องกัน

7.3 หลีกเลี่ยง False Positive

กำหนดการยืนยัน Alarm ซ้ำตามความเหมาะสม เช่น ตรวจจากหลาย Probe หรือกำหนด Hold-Down ที่เหมาะสม แต่ต้องไม่ทำให้เหตุจริงถูกตรวจพบช้าเกินข้อกำหนด SLA และควรแยก Monitoring Outage ออกจาก Service Outage

8. Monthly Service Report และ KPI Dashboard

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

1. Executive Summary และสถานะ SLA
2. Service Scope, Coverage และช่วงเวลารายงาน
3. Availability แยก Site/Service
4. Incident Summary แยก Priority และ Root Cause
5. Response/Restore Performance และ MTTR
6. Preventive Maintenance และ Change Summary
7. Top Recurring Problems และ Risk Register
8. Corrective/Preventive Actions พร้อม Owner และ Due Date

8.2 ตัวอย่าง KPI Scorecard

Metric	เป้าหมายตัวอย่าง	ผลจริงสมมติ	สถานะ
Availability	≥ 99.5%	99.7%	ผ่าน
P1 Response Compliance	100%	100%	ผ่าน
PM Completion	≥ 95%	92%	ไม่ผ่าน
Configuration Backup Success	100%	98%	ไม่ผ่าน

ข้อมูลในตารางเป็นข้อมูลสมมติ เพื่อสาธิตการจัดทำรายงาน ไม่ใช่ผลการดำเนินงานจริงของหน่วยงานใด

8.3 แนวทางออกแบบ Dashboard

Dashboard ควรแสดง Service Health, Active P1/P2, SLA Breach Risk, MTTR Trend, Repeat Incidents, PM Due และ Site Availability โดยสามารถกดตรวจสอบย้อนกลับไปยัง Ticket และหลักฐานต้นทางได้

9. กรณีศึกษา: Cisco Switch ในระบบเครือข่ายสถานีขนส่ง

สมมติองค์กรมี Cisco Switch ประจำหลายสถานี รองรับระบบอุปกรณ์หน้าสถานีและเชื่อมต่อกลับศูนย์กลาง ทีมงานต้องแยก เวลาที่เครือข่ายให้บริการจริง ออกจาก ช่วงเวลาที่ทีม Support ตามสัญญา

9.1 ออกแบบบริการ 8×5

ตัวอย่าง Service Desk ทำการวันจันทร์–ศุกร์ 08:00–17:00 โดยมีช่วงพักตามข้อกำหนดองค์กรและคิดเวลาบริการ 8 ชั่วโมงต่อวัน ต้องระบุการรับแจ้งนอกเวลา การส่งต่อเหตุ P1 และการเข้าพื้นที่อย่างชัดเจน หากสถานีเปิดให้บริการยาวกว่าช่วง Support ต้องมีแผนรองรับเหตุที่เกิดนอกช่วงเวลา

9.2 ตัวอย่างเหตุขัดข้อง

Symptom: ระบบปลายทางในสถานีหนึ่งติดต่อศูนย์กลางไม่ได้ Investigation: ตรวจพบ Uplink Port มี CRC Error เพิ่มขึ้นต่อเนื่อง Action: ประสานทีมภาคสนามตรวจสายและ Transceiver ตาม Change/Incident Procedure Verification: Error Counter หยุดเพิ่มและ Application Connectivity กลับมาปกติ

9.3 การรายงาน

บันทึกผลกระทบจริง เวลาเริ่มและสิ้นสุดตามนิยาม SLA ผู้รับผิดชอบ และผลยืนยันจากระบบปลายทาง ห้ามสรุปว่า Network Service Restore แล้วจากสถานะ Port Up เพียงอย่างเดียว

10. Hands-on Lab: สร้าง SLA Report จากข้อมูล Incident

10.1 เป้าหมาย

คำนวณ Availability และ MTTR จากข้อมูลจำลอง โดยไม่เชื่อมต่อหรือเปลี่ยน Configuration ของอุปกรณ์ Production

10.2 ตัวอย่าง CSV

incident_id,site,priority,restore_minutes,counted_downtime_minutes
INC001,ST01,P2,35,35
INC002,ST02,P3,25,25
INC003,ST01,P1,60,60

10.3 Python สำหรับคำนวณ KPI

import csv
from pathlib import Path

SERVICE_MINUTES = 20 * 8 * 60  # สมมติ 20 วันทำการ เดือนละ 8 ชั่วโมง
records = []

with Path("incidents.csv").open(encoding="utf-8-sig", newline="") as f:
    for row in csv.DictReader(f):
        row["restore_minutes"] = int(row["restore_minutes"])
        row["counted_downtime_minutes"] = int(row["counted_downtime_minutes"])
        records.append(row)

downtime = sum(r["counted_downtime_minutes"] for r in records)
restore_total = sum(r["restore_minutes"] for r in records)

if downtime > SERVICE_MINUTES:
    raise ValueError("Downtime exceeds service window; review overlap and scope")

availability = (SERVICE_MINUTES - downtime) / SERVICE_MINUTES * 100
mttr = restore_total / len(records) if records else 0

print(f"Availability: {availability:.2f}%")
print(f"MTTR: {mttr:.1f} minutes")

ผลลัพธ์ข้อมูลตัวอย่าง: Downtime รวม 120 นาที จาก Service Window 9,600 นาที ได้ Availability 98.75% และ MTTR 40 นาที

ข้อจำกัดสำคัญของตัวอย่าง

โค้ดนี้เหมาะกับการฝึกเท่านั้น เพราะนำ Downtime ทุกเหตุรวมกันโดยตรง ระบบจริงต้องจัดการ เหตุซ้อนเวลา, เหตุข้าม Service Window, เหตุหลาย Site, Planned Exclusions, การวัดระดับบริการ และเวลาที่นับตามสัญญา ก่อนสรุป SLA

10.4 แบบฝึกทบทวน

1. เหตุ P1 เริ่มก่อนเวลาเปิด Service Window 20 นาที จะเริ่มนับ SLA เมื่อใด?
2. เหตุสองรายการเกิดพร้อมกันบนบริการเดียวกัน ควรนับ Downtime อย่างไร?
3. เหตุที่ Switch Up แต่ Application ใช้งานไม่ได้ ควรปิด Ticket หรือไม่?

เฉลย

1. ยึดนิยามเวลาตาม SLA/TOR และหลักฐานที่ตกลงกัน ไม่ใช้กฎเดียวกับทุกสัญญา
2. คำนวณช่วงเวลาที่บริการหยุดจริงโดยไม่บวกเวลาซ้ำ และแยกตาม Service/Site
3. ไม่ควรปิดจนตรวจสอบบริการปลายทางและได้รับการยืนยันตามเกณฑ์ปิดเหตุ

11. Governance, Security และข้อควรระวัง

• Evidence Integrity: รักษา Log ต้นฉบับและเวลาที่ตรวจสอบย้อนหลังได้
• Least Privilege: ใช้บัญชี Monitoring แบบ Read-Only เมื่อทำได้
• Data Protection: จำกัดการเข้าถึง Log, Ticket, IP Address และ Configuration Backup
• Change Control: การแก้ไข Configuration ต้องมีการประเมินผลกระทบ Backup และ Rollback
• Time Synchronization: ใช้ NTP และกำหนด Time Zone ของรายงาน
• Contract Alignment: ยืนยันเกณฑ์ SLA, Exclusion, Penalty และการอนุมัติจากผู้มีอำนาจ
• Continuous Improvement: วิเคราะห์ Root Cause และติดตาม Corrective Action หลัง Incident

12. คำถามที่พบบ่อย

12.1 SLA 8×5 หมายความว่า Switch ทำงานแค่วันละ 8 ชั่วโมงหรือไม่?

ไม่ใช่ โดยทั่วไปหมายถึงช่วงเวลาการให้บริการสนับสนุนตามสัญญา อุปกรณ์อาจต้องทำงานต่อเนื่อง 24 ชั่วโมง และต้องกำหนดการรับแจ้งเหตุหรือ On-Call นอกเวลาต่างหาก

12.2 Response Time กับ Resolution Time ต่างกันอย่างไร?

Response Time คือเวลาจนเริ่มตอบสนองตามนิยาม ส่วน Resolution/Restore Time คือเวลาจนแก้ไขหรือคืนบริการได้ตามเกณฑ์ที่กำหนด

12.3 Availability 99.9% แปลว่าระบบไม่ล่มเลยหรือไม่?

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

12.4 ควรใช้ข้อมูลจาก Monitoring หรือ Ticket ในการคิด SLA?

ควรใช้ร่วมกัน โดย Monitoring ให้หลักฐานสถานะเชิงเทคนิค ส่วน Ticket ให้ข้อมูลการรับแจ้ง การตอบสนอง การอนุมัติ และการคืนบริการ ทั้งสองแหล่งต้องมีกระบวนการกระทบยอดข้อมูล

13. สรุป: เปลี่ยนการดูแล Cisco Network ให้เป็นบริการที่วัดผลได้

การบริหาร Cisco Network ด้วย SLA, SLO และ SLI ทำให้ทีมวิศวกรสามารถกำหนดความคาดหวัง วัด Availability และ MTTR ติดตาม Incident Escalation และสื่อสารผลการดำเนินงานด้วยหลักฐานที่ตรวจสอบได้ หัวใจสำคัญคือการกำหนด Service Scope, Service Window และจุดเริ่ม-สิ้นสุดการนับเวลาให้ชัดเจนก่อนนำ KPI ไปใช้จริง

บทความถัดไป: Cisco Network Preventive Maintenance & Health Check — PM Checklist, Interface Errors, Environmental Monitoring, Firmware Review และ Maintenance Report