ใครเป็นผู้รับผิดชอบ

และต้องตรวจสอบอะไรบ้าง

เพื่อให้สามารถกู้คืนระบบได้

แม้ผู้เชี่ยวชาญตัวจริงจะไม่อยู่หน้างาน

---

② ทำไม DR Plan อย่างเดียวไม่พอ

หลายองค์กรมี

Disaster Recovery Plan

แต่ไม่มี

Recovery Runbook

เมื่อเกิดเหตุจริง

ทีมงานจึงพบปัญหา

❌ ไม่รู้ต้องเริ่มตรงไหน

❌ ทำงานไม่เป็นลำดับ

❌ ลืมขั้นตอนสำคัญ

❌ ใช้เวลานานเกินไป

Runbook จึงเป็นคู่มือปฏิบัติการที่สำคัญมาก

---

③ เป้าหมายของ Recovery Runbook

Runbook ที่ดีควรทำให้

✅ ลด Human Error

✅ ลด Recovery Time

✅ ทำงานแทนผู้เชี่ยวชาญได้

✅ ใช้งานได้จริงในภาวะวิกฤต

✅ ผ่านการ Audit

---

④ Recovery Runbook ต่างจาก Documentation อย่างไร

Documentation

อธิบายว่า

ระบบทำงานอย่างไร

แต่ Runbook

อธิบายว่า

ต้องทำอะไรเมื่อเกิดปัญหา

ดังนั้น

Runbook

จึงเป็นเอกสารเชิงปฏิบัติการ

ไม่ใช่เอกสารเชิงเทคนิคทั่วไป

---

⑤ ส่วนประกอบสำคัญของ Runbook

ทุก Runbook

ควรมี

✅ วัตถุประสงค์

✅ ขอบเขต

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

✅ ผู้รับผิดชอบ

✅ Checklist

✅ วิธีตรวจสอบผลลัพธ์

---

⑥ ระบุระดับความรุนแรง

ควรกำหนด

Severity Level

เช่น

Critical

High

Medium

Low

เพื่อช่วยให้ทีมงานตัดสินใจได้เร็วขึ้น

---

⑦ กำหนดผู้รับผิดชอบ

ทุกขั้นตอน

ต้องมี

Owner

ชัดเจน

ตัวอย่าง

• Infrastructure Team
• Network Team
• Security Team
• Application Team

เพื่อลดความสับสนในช่วงวิกฤต

---

⑧ Runbook สำหรับ Active Directory

ตัวอย่างหัวข้อที่ควรมี

AD Recovery

• ตรวจสอบ Domain Controller
• ตรวจสอบ DNS
• ตรวจสอบ Replication
• Restore System State
• Validate Authentication

---

⑨ Runbook สำหรับ Hyper-V

ควรมี

Hyper-V Recovery

เช่น

• ตรวจสอบ Cluster
• ตรวจสอบ CSV
• Restore VM
• Validate Application

เป็นลำดับ

---

⑩ Runbook สำหรับ Storage

ควรครอบคลุม

Storage Failure

เช่น

• Disk Failure
• Storage Pool Failure
• SAN Failure
• Replication Failure

เพื่อให้ทีมงานตอบสนองได้ทันที

---

⑪ Runbook สำหรับ Network

ตัวอย่าง

Network Outage

ขั้นตอน

• ตรวจสอบ Core Switch
• ตรวจสอบ Routing
• ตรวจสอบ Firewall
• ตรวจสอบ WAN

เรียงตามลำดับ

---

⑫ Runbook สำหรับ Ransomware

องค์กรยุคใหม่

ควรมี

Cyber Recovery Runbook

โดยเฉพาะ

ขั้นตอน

• Isolation
• Investigation
• Recovery
• Validation

อย่างชัดเจน

---

⑬ ใช้ Checklist ทุกครั้ง

ในสถานการณ์วิกฤต

คนมักลืมรายละเอียด

ดังนั้น

Runbook

ควรมี

Checklist

ทุกขั้นตอน

เพื่อป้องกันความผิดพลาด

---

⑭ ใส่ Screenshot และ Diagram

Runbook ที่ดี

ไม่ควรมีแต่ข้อความ

ควรมี

✅ Diagram

✅ Screenshot

✅ Topology

ช่วยให้ทีมงานเข้าใจได้เร็วขึ้น

---

⑮ เก็บ Runbook ไว้ที่ไหน

ข้อผิดพลาดที่พบได้บ่อย

คือ

เก็บ Runbook

ไว้บนระบบเดียวกับ Production

เมื่อระบบล่ม

Runbook ก็หายไปด้วย

ควรมี

Offline Copy

หรือ

Secure Cloud Copy

เสมอ

---

⑯ ทดสอบ Runbook เป็นประจำ

Runbook

ควรได้รับการทดสอบ

อย่างน้อยปีละ

1-2 ครั้ง

เพื่อให้มั่นใจว่า

ยังใช้งานได้จริง

และสอดคล้องกับระบบปัจจุบัน

---

⑰ ปรับปรุงหลังทุก Incident

ทุกครั้งที่เกิดเหตุ

ควรนำบทเรียนที่ได้

มาปรับปรุง Runbook

ทันที

เพื่อให้เอกสารทันสมัยอยู่เสมอ

---

⑱ ข้อผิดพลาดที่พบบ่อย

❌ ไม่มี Runbook

❌ Runbook เก่าเกินไป

❌ ไม่มี Owner

❌ ไม่มี Checklist

❌ ไม่เคยทดสอบ

❌ ไม่มี Offline Copy

❌ ไม่มี Diagram

---

⑲ แนวทางที่องค์กรระดับโลกนิยมใช้

องค์กรระดับ Enterprise

มักใช้

Recovery Runbook

ร่วมกับ

DR Plan

Tabletop Exercise

Automation

Continuous Improvement

เพื่อเพิ่มความพร้อมขององค์กร

---

⑳ สรุป

Enterprise Recovery Runbook เป็นเครื่องมือสำคัญที่ช่วยให้ทีมงานสามารถกู้คืนระบบได้อย่างเป็นระบบ แม้ในสถานการณ์ที่ผู้เชี่ยวชาญไม่สามารถเข้าถึงหน้างานได้ เอกสารที่ดีต้องมีขั้นตอนชัดเจน มีผู้รับผิดชอบ มี Checklist และได้รับการทดสอบอย่างสม่ำเสมอ

จากประสบการณ์ของ comsiam องค์กรที่สามารถฟื้นฟูระบบได้เร็วที่สุดไม่ใช่องค์กรที่มีเทคโนโลยีดีที่สุดเสมอไป แต่เป็นองค์กรที่มี Runbook ที่ชัดเจนและทีมงานเข้าใจขั้นตอนการทำงานจริง และ comsiam มักแนะนำให้สร้าง Runbook สำหรับทุกระบบสำคัญตั้งแต่ Active Directory, Hyper-V, Storage, Network ไปจนถึง Cyber Recovery เพื่อให้พร้อมรับมือกับทุกสถานการณ์

คำถามชวนคิด

หากผู้ดูแลระบบหลักขององค์กรไม่สามารถติดต่อได้ในวันที่เกิดวิกฤต ทีมงานที่เหลือจะสามารถกู้คืนระบบทั้งหมดได้จากเอกสารที่มีอยู่ในปัจจุบันหรือไม่?