IT Disaster Recovery Plan: วางแผนกู้คืนระบบ IT หลังภัยพิบัติอย่างมืออาชีพ

IT Disaster Recovery Plan: วางแผนกู้คืนระบบ IT หลังภัยพิบัติอย่างมืออาชีพ

ไม่มีใครอยากให้เกิดภัยพิบัติ แต่คำถามไม่ใช่ “จะเกิดหรือไม่” แต่เป็น “เมื่อเกิดขึ้น เราพร้อมแค่ไหน” ไม่ว่าจะเป็นน้ำท่วม ไฟไหม้ ransomware attack หรือ hardware failure ระบบ IT ขององค์กรอาจหยุดทำงานได้ทุกเมื่อ IT Disaster Recovery Plan (DRP) คือแผนที่กำหนดขั้นตอนในการกู้คืนระบบ IT ให้กลับมาทำงานได้เร็วที่สุด โดยสูญเสียข้อมูลน้อยที่สุด

จากสถิติของ FEMA พบว่า 40% ของธุรกิจที่ประสบภัยพิบัติร้ายแรงโดยไม่มี DR plan จะปิดกิจการภายใน 1 ปี และอีก 25% ปิดภายใน 2 ปี ในขณะที่องค์กรที่มี DRP ที่ดีสามารถกลับมา operate ได้ภายในไม่กี่ชั่วโมง ความแตกต่างระหว่าง “มี” กับ “ไม่มี” DR plan จึงเป็นความแตกต่างระหว่าง “อยู่รอด” กับ “ปิดตัว”

บทความนี้จะพาคุณเข้าใจ IT Disaster Recovery ทุกมิติ ตั้งแต่แนวคิดพื้นฐาน RTO/RPO การประเมินความเสี่ยง กลยุทธ์ backup และ replication ไปจนถึงวิธีเขียน DRP ที่ใช้ได้จริง พร้อมตัวอย่างและ template สำหรับองค์กรไทย

RTO และ RPO: ตัวเลขที่กำหนดทุกอย่างใน DR

ก่อนจะวางแผน Disaster Recovery ต้องเข้าใจ 2 ตัวเลขที่สำคัญที่สุดก่อน เพราะตัวเลขเหล่านี้จะกำหนดว่าต้องลงทุนเท่าไหร่และใช้เทคโนโลยีอะไร

RTO — Recovery Time Objective

RTO คือระยะเวลาสูงสุดที่ระบบสามารถหยุดทำงานได้ก่อนที่ธุรกิจจะได้รับผลกระทบรุนแรง ตัวอย่างเช่น ถ้า RTO ของระบบ e-commerce คือ 2 ชั่วโมง หมายความว่าหลังเกิดเหตุ ต้องกู้คืนระบบให้ทำงานได้ภายใน 2 ชั่วโมง ถ้าเกินกว่านี้ ธุรกิจจะสูญเสียรายได้และความเชื่อมั่นของลูกค้า RTO ยิ่งสั้น ค่าใช้จ่ายยิ่งสูง เพราะต้องมี infrastructure สำรองที่พร้อมใช้งานทันที

RPO — Recovery Point Objective

RPO คือปริมาณข้อมูลสูงสุดที่ยอมรับได้ว่าจะสูญเสียไป วัดเป็นระยะเวลา ตัวอย่างเช่น ถ้า RPO คือ 1 ชั่วโมง หมายความว่ายอมรับได้ที่จะสูญเสียข้อมูลที่เปลี่ยนแปลงภายใน 1 ชั่วโมงสุดท้ายก่อนเกิดเหตุ ถ้า backup ทำทุก 6 ชั่วโมง RPO คือ 6 ชั่วโมง ถ้าต้องการ RPO เป็น 0 (ไม่ยอมเสียข้อมูลเลย) ต้องใช้ synchronous replication ซึ่งมีค่าใช้จ่ายสูงมาก

กำหนด RTO/RPO ตามประเภทของระบบ

ไม่ใช่ทุกระบบต้องมี RTO/RPO เท่ากัน ระบบ Tier 1 (mission-critical เช่น ERP, core banking, e-commerce) ควรมี RTO ไม่เกิน 1-4 ชั่วโมง RPO ไม่เกิน 15 นาที ระบบ Tier 2 (important เช่น email, CRM, HR system) RTO 4-24 ชั่วโมง RPO 1-4 ชั่วโมง ระบบ Tier 3 (non-critical เช่น intranet, archive) RTO 1-7 วัน RPO 24 ชั่วโมง การจัดลำดับความสำคัญช่วยจัดสรรงบประมาณ DR ได้อย่างเหมาะสม

การประเมินความเสี่ยง (Risk Assessment)

ขั้นตอนแรกของการทำ DRP คือการประเมินว่าภัยคุกคามอะไรบ้างที่อาจทำให้ระบบ IT หยุดทำงาน และแต่ละภัยคุกคามมีโอกาสเกิดและผลกระทบมากน้อยแค่ไหน

ประเภทของภัยพิบัติ

ภัยพิบัติที่กระทบ IT แบ่งเป็น 3 กลุ่มใหญ่ ภัยธรรมชาติ เช่น น้ำท่วม (ความเสี่ยงสูงสำหรับองค์กรในกรุงเทพฯ) แผ่นดินไหว ไฟไหม้ พายุ ภัยจากมนุษย์ เช่น ransomware attack, data breach, sabotage, human error ที่ลบข้อมูลสำคัญ ความล้มเหลวทางเทคนิค เช่น hardware failure, software bug, power outage, ISP outage สำหรับองค์กรในไทย ภัยที่พบบ่อยที่สุดคือ น้ำท่วม ransomware และ power outage

Business Impact Analysis (BIA)

BIA เป็นกระบวนการที่วิเคราะห์ว่าแต่ละระบบมีผลกระทบต่อธุรกิจอย่างไรเมื่อหยุดทำงาน ต้องตอบคำถามว่า ถ้าระบบนี้ล่ม 1 ชั่วโมง รายได้หายเท่าไหร่ ลูกค้าได้รับผลกระทบกี่ราย มีค่าปรับจากสัญญา SLA หรือไม่ มีผลกระทบต่อ compliance หรือไม่ BIA ช่วยจัดลำดับความสำคัญของระบบ ซึ่งนำไปกำหนด RTO/RPO ที่เหมาะสม

กลยุทธ์ Backup สำหรับ Disaster Recovery

Backup เป็นรากฐานของทุก DR plan ไม่ว่าจะใช้เทคโนโลยีอะไร backup ที่ดีต้องเชื่อถือได้ กู้คืนได้จริง และเก็บไว้ในที่ปลอดภัย

กฎ 3-2-1 Backup

กฎทองของ backup ที่ใช้มานานและยังคงเป็นมาตรฐาน 3 copies ของข้อมูล (original + 2 backup) 2 media types ที่แตกต่างกัน (เช่น disk + tape หรือ local + cloud) 1 copy อยู่ offsite (คนละ location กับ primary) เพื่อป้องกัน site-level disaster เช่น ถ้า data center ถูกน้ำท่วม offsite backup ยังปลอดภัย ปัจจุบันหลายองค์กรขยายเป็น 3-2-1-1-0 โดยเพิ่ม 1 copy ที่เป็น immutable (แก้ไขหรือลบไม่ได้) เพื่อป้องกัน ransomware และ 0 errors จาก backup verification

Backup Types: Full, Incremental, Differential

Full Backup สำรองข้อมูลทั้งหมดทุกครั้ง กู้คืนง่ายที่สุดแต่ใช้เวลาและ storage มากที่สุด Incremental Backup สำรองเฉพาะข้อมูลที่เปลี่ยนแปลงตั้งแต่ backup ครั้งล่าสุด ประหยัด storage มากที่สุดแต่กู้คืนซับซ้อนกว่า ต้อง restore full + ทุก incremental ตามลำดับ Differential Backup สำรองข้อมูลที่เปลี่ยนตั้งแต่ full backup ล่าสุด กู้คืนง่ายกว่า incremental (ใช้แค่ full + differential ล่าสุด) แต่ใช้ storage มากกว่า กลยุทธ์ที่นิยมคือทำ full backup สัปดาห์ละครั้ง + incremental ทุกวัน

ตารางเปรียบเทียบ DR Strategies

การเขียน IT Disaster Recovery Plan ที่ใช้ได้จริง

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

โครงสร้างของ DRP

DRP ที่ดีควรมีองค์ประกอบหลักดังนี้ Executive Summary สรุปสั้นๆ ว่า plan นี้ครอบคลุมอะไร Scope and Objectives ระบุระบบที่ครอบคลุม RTO/RPO targets Contact List รายชื่อและเบอร์โทรของทุกคนที่เกี่ยวข้อง ทั้ง internal team, vendor, ISP, cloud provider Activation Criteria กำหนดว่าเหตุการณ์แบบไหนถึงจะ activate DR plan Recovery Procedures ขั้นตอนกู้คืนแต่ละระบบ เขียนแบบ step-by-step ที่คนไม่ชำนาญก็ทำได้ Communication Plan แจ้งใครบ้าง ช่องทางไหน ข้อความอย่างไร

Recovery Procedures ต้องละเอียดและทดสอบแล้ว

ส่วนที่สำคัญที่สุดคือ Recovery Procedures ต้องเขียนละเอียดแบบ step-by-step เช่น “Login เข้า AWS Console ด้วย DR admin account → ไป EC2 → Launch Instance จาก AMI-xxxx → Attach EBS volume snap-xxxx → Configure Security Group sg-xxxx → Update Route 53 DNS record” ทุกขั้นตอนต้องระบุชื่อ resource, ID, credentials ไม่ใช่เขียนแบบกว้างๆ ว่า “กู้คืน server” เพราะเมื่อเกิดเหตุจริงจะ panic ทำให้ลืมรายละเอียด

การทดสอบ DR Plan: ทำไมต้องซ้อม

DRP ที่ไม่เคยทดสอบก็เหมือนไม่มี DR plan เลย เพราะคุณไม่มีทางรู้ว่ามันจะทำงานได้จริงหรือไม่จนกว่าจะลอง

ประเภทของ DR Test

Tabletop Exercise เป็นการซ้อมบนโต๊ะ ทีมมานั่งคุยกันว่า ถ้าเกิดเหตุการณ์ X จะทำอย่างไร ใช้เวลาน้อย ค่าใช้จ่ายต่ำ แต่ไม่ได้ทดสอบ technical procedures จริง Simulation Test จำลองสถานการณ์แต่ไม่ได้ failover จริง ทดสอบว่า backup กู้คืนได้หรือไม่ network config ถูกต้องหรือเปล่า Full Failover Test ทดสอบ failover จริงไปยัง DR site ทดสอบทุก component เป็นวิธีที่ให้ความมั่นใจสูงสุด แต่มีความเสี่ยงและค่าใช้จ่ายสูง ควรทำอย่างน้อยปีละ 1 ครั้ง

สิ่งที่ต้องวัดจากการทดสอบ

ทุกครั้งที่ทดสอบต้องวัดผลเทียบกับ target Actual RTO กู้คืนได้จริงภายในเวลาที่กำหนดหรือไม่ Actual RPO ข้อมูลที่กู้คืนได้ เป็นข้อมูลเมื่อกี่ชั่วโมงก่อนเหตุ Data Integrity ข้อมูลที่กู้คืนมาถูกต้องครบถ้วนหรือไม่ Application Functionality ระบบกู้คืนมาแล้วทำงานได้ปกติหรือไม่ จด lessons learned ทุกปัญหาที่พบ แก้ไข DRP แล้วทดสอบอีกครั้ง

Cloud-based DR: กู้คืนด้วย Cloud

Cloud เปลี่ยนเกม DR อย่างสิ้นเชิง เพราะไม่ต้องลงทุนสร้าง DR site แค่ใช้ cloud infrastructure ที่จ่ายตามการใช้งาน

DRaaS — Disaster Recovery as a Service

DRaaS เป็นบริการที่ replicate ระบบทั้งหมดไปยัง cloud แบบต่อเนื่อง เมื่อเกิดเหตุ สามารถ failover ไปใช้ระบบบน cloud ได้ทันที ผู้ให้บริการ DRaaS จัดการ infrastructure, monitoring, failover automation ให้ทั้งหมด องค์กรแค่จ่ายรายเดือน ตัวอย่าง DRaaS เช่น Zerto, Veeam Cloud Connect, AWS Elastic Disaster Recovery, Azure Site Recovery

Multi-Region Deployment

สำหรับองค์กรที่อยู่บน cloud อยู่แล้ว การทำ multi-region deployment เป็น DR strategy ที่มีประสิทธิภาพสูง deploy application ใน 2 regions (เช่น Singapore + Tokyo สำหรับ AWS) ใช้ database replication แบบ cross-region ตั้ง Route 53 health checks + failover routing เมื่อ primary region ล่ม DNS จะ route traffic ไป secondary region อัตโนมัติ RTO ต่ำมาก (วินาที-นาที) แต่ค่าใช้จ่ายจะสูงขึ้นเท่าตัว

ทิ้งท้าย: DR Plan ไม่ใช่ทางเลือก แต่เป็นสิ่งจำเป็น

IT Disaster Recovery Plan เป็นสิ่งที่ทุกองค์กรต้องมี ไม่ว่าจะเล็กหรือใหญ่ การลงทุนเรื่อง DR อาจดูเหมือนเป็นค่าใช้จ่ายที่ “ไม่จำเป็น” จนกว่าจะเกิดเหตุจริง แล้วจะพบว่ามันคือการลงทุนที่คุ้มค่าที่สุดที่เคยทำ

เริ่มจากขั้นตอนง่ายๆ ทำ Business Impact Analysis จัดลำดับความสำคัญของระบบ กำหนด RTO/RPO ตั้งค่า backup ตามกฎ 3-2-1 แล้วเขียน recovery procedures ที่ชัดเจน สิ่งที่สำคัญที่สุดคือ ทดสอบ DR plan เป็นประจำ อย่างน้อยปีละ 2 ครั้ง เพราะ DR plan ที่ไม่เคยทดสอบก็เหมือนไม่มี

อ่านเพิ่มเติมเกี่ยวกับ Server Clustering และ RAID Configuration ที่ siamlancard.com หรือติดตามเนื้อหา IT จาก icafeforex.com และ siam2r.com