กู้คืนระบบเว็บไซต์แบรนด์: นิยาม RTO/RPO ขั้นตอนกู้คืน และการซ้อมประจำปี
หนึ่ง RTO กับ RPO: รู้ก่อนว่าคุณยอมรับการสูญเสียข้อมูลและเวลาหยุดได้แค่ไหน
RTO (Recovery Time Objective เป้าหมายเวลากู้คืน) คือเวลานานที่สุดที่ยอมรับได้นับจากเว็บล่มจนกลับมาให้บริการได้ RPO (Recovery Point Objective เป้าหมายจุดกู้คืน) คือข้อมูลย้อนหลังนานแค่ไหนที่ยอมรับให้หายได้หลังกู้คืน พอตัวเลขสองตัวนี้ชัดเจน ความถี่ในการแบ็กอัปและงบลงทุนสำรองก็จะชัดตามไปด้วย เพราะมันคือการแลกกันระหว่างต้นทุนกับความพร้อมใช้งาน
ข้อสรุปที่ขัดกับสัญชาตญาณ: สำหรับเว็บไซต์ B2B การไล่ตามความพร้อมใช้งาน 99.99% คือการลงทุนเกินจำเป็น เว็บ B2B มีผู้เข้าชมน้อย สอบถามส่วนใหญ่มาจากอีเมลและฟอร์ม การล่ม 4 ชั่วโมงกับการล่ม 1 ชั่วโมงแทบไม่ต่างกันต่อธุรกิจ แต่ต้นทุนสำรองต่างกันมหาศาล ถ้าจะให้ได้ RTO 15 นาที ต้องมีห้องเซิร์ฟเวอร์แบบ dual-active และซิงก์ฐานข้อมูลแบบเรียลไทม์ ต้นทุนต่อเดือนสูงกว่าแบบห้องเดียว 5 ถึง 10 เท่า
| ประเภทเว็บไซต์ | เป้า RTO | เป้า RPO | ความพร้อมใช้งาน | แผนสำรอง |
|---|---|---|---|---|
| เว็บหลักที่รับสอบถาม | ≤1 ชั่วโมง | ≤15 นาที | 99.9% | เครื่องสำรองต่างพื้นที่ + ซิงก์ binlog เรียลไทม์ |
| เว็บ B2B ทั่วไป | ≤4 ชั่วโมง | ≤4 ชั่วโมง | 99.5% | ห้องเดียว + แบ็กอัปทุกวัน + กู้คืนต่างพื้นที่ |
| เว็บบล็อก/คอนเทนต์ | ≤24 ชั่วโมง | ≤24 ชั่วโมง | 99% | แบ็กอัปทุกสัปดาห์ + กู้คืนด้วยมือ |
| เว็บอีคอมเมิร์ซ/ชำระเงิน | ≤15 นาที | ≤1 นาที | 99.99% | หลายศูนย์พร้อมกัน + ซิงก์เรียลไทม์ (ต้นทุนสูงมาก) |
ตัวอย่างสถานการณ์: เว็บขายเครื่องจักรอุตสาหกรรมออกต่างประเทศแห่งหนึ่ง มีสอบถามเดือนละประมาณ 30 ราย มูลค่าต่อออเดอร์ 5 แสนหยวน ถ้าเว็บล่ม 4 ชั่วโมง คิดตามความถี่ของสอบถามก็คงพลาดไป 1 ถึง 2 ราย ความเสียหายจำกัด เว็บแบบนี้ใช้ห้องเดียวบวกแบ็กอัปทุกวัน RTO 4 ชั่วโมง RPO 4 ชั่วโมงก็พอ ต้นทุนสำรองต่อเดือนไม่ถึง 200 หยวน ถ้าฝืนทำ dual-active ก็จ่ายเพิ่มเดือนละ 2,000 หยวนเพื่อซื้อความพร้อมใช้งานที่วัดผลตอบแทนทางธุรกิจไม่ได้
จะรู้ว่าเว็บคุณอยู่ประเภทไหน ดูปริมาณสอบถามต่อเดือนกับมูลค่าต่อออเดอร์ก่อน: ถ้าสอบถามเกิน 100 รายต่อเดือน มูลค่าต่อออเดอร์ต่ำกว่า 1 หมื่น เอนไปทางอีคอมเมิร์ซ ต้องกด RTO ให้เหลือ 1 ชั่วโมง ถ้าสอบถามต่ำกว่า 30 รายต่อเดือน มูลค่าต่อออเดอร์เกิน 1 แสน เอนไปทางโปรเจกต์ RTO 4 ชั่วโมงรับได้สบาย
2. ขั้นตอนการกู้คืน: ทำ 4 ขั้นตอน จดใส่กระดาษไว้ล่วงหน้า
แผนกู้คืนระบบเมื่อเกิดภัยพิบัติเก็บไว้แค่ในหัวไม่ได้ ตอนเกิดเหตุ คนที่ต้องรับมืออาจถูกปลุกกลางดึก กำลังเดินทาง หรือไม่ใช่คนที่คุ้นระบบที่สุด แผนต้องเขียนเป็นเอกสาร ขั้นตอนละเอียดถึงระดับคำสั่ง command line ใครทำอะไรตอนไหน เห็นปุ๊บเข้าใจปั๊บ
ขั้นตอนกู้คืนมาตรฐานมี 4 ขั้น: ขั้นแรกสลับทราฟฟิก สลับ DNS หรือ CDN ไปที่ IP เครื่องสำรอง; ขั้นที่สองกู้คืนข้อมูล ดึง backup ล่าสุดจาก object storage ต่างพื้นที่ กู้คืนไฟล์และฐานข้อมูล; ขั้นที่สามตรวจสอบ ไล่เช็คหน้าแรก หน้ารายการสินค้า การส่งฟอร์มสอบถาม และการรับอีเมล; ขั้นที่สี่แจ้งผู้เกี่ยวข้อง ฝ่ายขาย ฝ่ายบริการลูกค้า และผู้บริหารรับทราบเวลาที่เว็บกลับมาใช้งานได้ สำหรับขั้นตอนกู้คืนกรณีถูกแฮกโดยเฉพาะ ดูที่หลังเว็บไซต์ถูกแฮก。
| ขั้นตอน | การดำเนินการ | ผู้รับผิดชอบ | เวลาที่ใช้โดยประมาณ | เกณฑ์ผ่าน |
|---|---|---|---|---|
| 1 ยืนยันเหตุขัดข้อง | ระบบแจ้งเตือนทำงาน ยืนยันว่าเว็บหลักใช้งานไม่ได้ | วิศวกรประจำเวร | 5 นาที | ตรวจสอบล้มเหลวติดต่อกัน 3 ครั้ง |
| 2 สลับทราฟฟิก | ลด DNS TTL เหลือ 60 วินาที สลับไปที่ IP เครื่องสำรอง | ปฏิบัติการและบำรุงรักษา | 10 นาที | DNS ทั่วโลกมีผล |
| 3 กู้คืนข้อมูล | ดึง backup จาก S3 กู้คืนไฟล์และฐานข้อมูล | ปฏิบัติการและบำรุงรักษา | 1 ถึง 2 ชั่วโมง | เว็บเข้าใช้งานได้ |
| 4 ตรวจสอบฟังก์ชัน | ไล่เช็คหน้าแรก หน้าสินค้า และฟอร์มสอบถามทั้งหมด | วิศวกร + ฝ่ายขาย | 30 นาที | ส่งฟอร์มแล้วได้รับอีเมล |
| 5 แจ้งเตือน | ฝ่ายขายและบริการลูกค้ารู้ว่าเว็บกลับมาแล้ว | หัวหน้าการตลาด | 10 นาที | แจ้งในกลุ่มครบถ้วน |
| 6 ทบทวน | เขียนรายงานเหตุการณ์ภายใน 24 ชั่วโมง | หัวหน้าฝ่ายเทคนิค | 1 วันทำการ | สาเหตุรากและสิ่งที่ต้องปรับปรุง |
ตัวอย่างสถานการณ์: เว็บทำตลาดต่างประเทศแห่งหนึ่งแจ้งเตือนตอนตี 3 เว็บหลักขึ้น 502 วิศวกรประจำเวรทำตามแผน: ขั้นแรกยืนยันว่า MySQL ล่ม รีสตาร์ทแล้วไม่หาย; ขั้นที่สองสลับ DNS ไปที่เครื่องสำรอง ซึ่งตั้ง TTL ไว้ล่วงหน้าแล้วที่ 60 วินาที มีผลทั่วโลกใน 10 นาที; ขั้นที่สามดึง backup จาก S3 ของคืนก่อนหน้ามากู้คืนฐานข้อมูล ใช้เวลา 40 นาที; ขั้นที่สี่ส่งฟอร์มสอบถามทดสอบจากมือถือ ได้รับอีเมลภายใน 30 วินาที; ขั้นที่ห้าแจ้งฝ่ายขายในกลุ่ม พอ 8 โมงเช้าเว็บก็กลับมาปกติแล้ว ทั้งกระบวนการใช้ RTO ประมาณ 1 ชั่วโมง RPO ประมาณ 6 ชั่วโมง ตรงตามเป้าที่วางไว้ในแผน
รายละเอียดการทำงานร่วมกันของ DNS สลับและ CDN ดูที่CDN เร่งความเร็วทั่วโลก ในหัวข้อการสลับโหนดเมื่อเกิดเหตุขัดข้อง แนวคิดการเปลี่ยนโดเมนและการส่งต่อ 301 ก็คล้ายกัน ดูที่การปรับโครงสร้างเว็บและการเปลี่ยนโดเมน。
3. เครื่องสำรองและ cold standby: ไม่จำเป็นต้องทำ active-active ทุกครั้ง
แผนรับมือภัยพิบัติแบ่งเป็น 3 ระดับ: cold standby, warm standby และ active-active cold standby คือมีแค่ไฟล์ backup พอเกิดเหตุก็ตั้งเครื่องชั่วคราวขึ้นมากู้คืน; warm standby คือเครื่องสำรองเปิดทิ้งไว้ตลอด ซิงค์ข้อมูลแบบ asynchronous; active-active คือสองศูนย์ข้อมูลรับทราฟฟิกพร้อมกัน ซิงค์แบบเรียลไทม์ ต้นทุนจากต่ำไปสูง RTO จากยาวไปสั้น
เว็บ B2B แบบยืนเองส่วนใหญ่เลือกผสม cold standby กับ warm standby ก็เพียงพอ: เครื่องสำรองเปิดไว้ตลอดแต่ไม่รับทราฟฟิก ซิงค์ข้อมูลวันละครั้ง พอเกิดเหตุแค่เปลี่ยน DNS สลับไป RTO ก็กดลงมาเหลือ 1 ถึง 2 ชั่วโมงได้ active-active สำหรับคนเดียวหรือทีมเล็กถือว่าลงทุนเกินจำเป็น ความซับซ้อนในการดูแลสูงจนดูแลไม่ไหว
| 方案 | สถานะเครื่องสำรอง | RTO | ต้นทุนเพิ่มต่อเดือน | เหมาะกับสถานการณ์ |
|---|---|---|---|---|
| cold standby | ไม่มีเครื่องสำรอง มีแค่ backup | 4 ถึง 8 ชั่วโมง | 0 หยวน | บล็อก เว็บคอนเทนต์ |
| warm standby | เครื่องสำรองเปิดตลอด ซิงค์ทุกวัน | 1 ถึง 2 ชั่วโมง | ประมาณ 300 ถึง 500 หยวน | เว็บรับสอบถาม B2B ทั่วไป |
| hot standby | เครื่องสำรองเปิดตลอด ซิงค์แบบเรียลไทม์ | 15 ถึง 30 นาที | ประมาณ 1,500-3,000 หยวน | เว็บไซต์ธุรกิจหลัก |
| ทำงานคู่กัน (Active-Active) | ให้บริการจากสองพื้นที่พร้อมกัน | ระดับวินาที | ประมาณ 5,000 หยวนขึ้นไป | อีคอมเมิร์ซ การชำระเงิน |
ข้อเตือนที่สวนทางกับความเชื่อทั่วไป: การสลับ DNS ไม่ได้เกิดขึ้นทันที แม้จะตั้ง TTL ไว้ 60 วินาที กว่า DNS ทั่วโลกจะอัปเดตก็ใช้เวลา 5-15 นาที และแคช DNS ภายในเครื่องของผู้ใช้บางส่วนอาจยึดที่อยู่เดิมไว้หลายชั่วโมง ดังนั้นก่อนสลับทราฟฟิกต้องทำใจไว้ก่อน: หลังสลับแล้วไม่ใช่ทุกคนจะเข้าเครื่องสำรองทันที ต้องมีช่วงเปลี่ยนผ่าน ในแผนต้องเขียนให้ชัดว่า “หลังสลับ DNS ให้รอ 15 นาทีแล้วค่อยตรวจสอบการเข้าถึงจากทั่วโลก”
สี่ ซ้อมแผนประจำปี: ลองรันแผนจริงเพื่อหาปัญหาบนกระดาษ
ความเสี่ยงที่ใหญ่ที่สุดของแผนกู้คืนภัยพิบัติคือ “เขียนไว้แล้วเท่ากับทำแล้ว” ในเอกสารเขียนไว้สวยหรู แต่พอเกิดเหตุจริงกลับพบว่าไม่รู้รหัสผ่านเครื่องสำรอง ดึงไฟล์สำรองไม่ได้ หรือตั้งค่า SMTP ฝังตายไว้บนเซิร์ฟเวอร์เก่า ปัญหาเหล่านี้จะโผล่ก็ต่อเมื่อได้ซ้อมจริงเท่านั้น
จัดซ้อมแผนประจำปีในช่วงเช้ามืดวันอาทิตย์ที่ธุรกิจไม่คึกคัก จับเวลาตลอดกระบวนการ การซ้อมไม่ใช่การสลับเว็บหลักจริง แต่เป็นการเดินตามขั้นตอนกู้คืนครบวงจรในสภาพแวดล้อมทดสอบ ตั้งแต่ดึงไฟล์สำรองไปจนถึงตรวจสอบฟอร์ม บันทึกเวลาที่ใช้จริงในแต่ละขั้น แล้วนำ RTO จริงมาเทียบกับเป้าหมายในแผน ถ้าเกินเป้าหมายก็ยกระดับแผน เมื่อซ้อมเสร็จให้เขียนสรุปบทเรียนและอัปเดตแผน
| รายการซ้อม | สิ่งที่ตรวจสอบ | ปัญหาที่พบบ่อย | แนวทางปรับปรุง |
|---|---|---|---|
| ความพร้อมใช้ของไฟล์สำรอง | ดึงไฟล์สำรองล่าสุดจาก S3 มาแตกไฟล์ได้หรือไม่ | gzip เสียหาย คีย์หมดอายุ | เพิ่มการตรวจสอบความสมบูรณ์ของไฟล์สำรอง |
| การเปิดเครื่องสำรอง | เครื่องสำรองเปิดได้ภายใน 5 นาทีหรือไม่ | เครื่องสำรองไม่ได้เปิดนาน ซอฟต์แวร์หมดอายุ | เปิดเครื่องสำรองเดือนละครั้ง |
| การสลับ DNS | TTL ตั้งไว้ 60 วินาทีจริงหรือไม่ | ลืมลด TTL ล่วงหน้า | ตั้ง TTL ไว้ที่ 60 วินาทีแบบตายตัว |
| การกู้คืนฐานข้อมูล | หลังนำเข้าแล้วภาษาจีนแสดงผลปกติหรือไม่ | charset ผิด เพี้ยนเป็นตัวอักษรขยะ | กำหนด charset ในสคริปต์กู้คืนแบบตายตัว |
| อีเมลฟอร์ม | ส่งแบบฟอร์มทดสอบแล้วได้รับอีเมลหรือไม่ | รหัส SMTP ฝังตายในคอนฟิกเก่า | ใช้ environment variable สำหรับ SMTP |
| ความพร้อมของบุคลากร | ติดต่อคนเข้าเวรได้หรือไม่ | ไม่ได้ส่งมอบงานตอนลาออก | อัปเดตรายชื่อผู้ติดต่อทุกไตรมาส |
ตัวอย่างสถานการณ์: ทีมหนึ่งซ้อมแผนประจำปีครั้งแรก ทำตามแผนดึงไฟล์สำรอง กู้คืนฐานข้อมูล เข้าถึงเว็บไซต์ ผ่านไป 40 นาทีแรกก็ราบรื่นดี พอมาถึงขั้นตรวจสอบฟอร์มสอบถาม ปรากฏว่าส่งไปแล้วครึ่งวันยังไม่ได้รับอีเมล สาเหตุคือรหัส SMTP เขียนไว้ใน wp-config.php และบริการอีเมลของเซิร์ฟเวอร์เก่าก็หยุดไปนานแล้ว ถ้าปัญหานี้เจอตอนเกิดเหตุจริง ก็ต้องเสียเวลาหาอีก 1 ชั่วโมง คุณค่าของการซ้อมคือการเจอปัญหาบนกระดาษแบบนี้ล่วงหน้า
รายละเอียดการตั้งค่านโยบายสำรองข้อมูลดูได้ที่การสำรองและกู้คืนเว็บไซต์ ส่วนเกณฑ์แจ้งเตือนของระบบมอนิเตอร์ดูได้ที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์ และรายการบำรุงรักษาประจำวันดูได้ที่งาน 6 อย่างที่ต้องทำทุกเดือนในช่วงดูแลเว็บไซต์。
FAQ คำถามที่พบบ่อย
RTO กับ RPO คืออะไรกันแน่ กำหนดอย่างไร?
เว็บไซต์แบรนด์ B2B จำเป็นต้องทำ active-active ไหม
แผนกู้คืนภัยพิบัติเขียนอย่างไร ต้องละเอียดแค่ไหน
การซ้อมแผนประจำปีทำอย่างไร ต้องปิดเว็บไหม
สลับ DNS ใช้เวลานานแค่ไหน ทำไมสลับแล้วผู้ใช้ยังเข้าเว็บเก่าอยู่
ขั้นตอนกู้คืนจากการถูกแฮกกับฮาร์ดแวร์เสียเหมือนกันไหม
ทิ้งท้าย
เรื่อง disaster recovery ทัศนคติที่อันตรายที่สุดคือ “เรามี backup ก็พอแล้ว” backup แก้ปัญหาข้อมูลไม่หาย แต่ disaster recovery แก้ปัญหาว่าหลังเกิดเหตุจะกลับมาให้บริการได้เร็วแค่ไหน ใครทำ ทำอย่างไร สองเรื่องนี้ต่างกันทั้งชุดแผนและซ้อม backup ที่ไม่มีแผน พอเกิดเหตุก็ยังวุ่นวายเหมือนเดิม แผนที่ไม่ได้ซ้อม พอใช้จริงก็ยังติดขัดเหมือนเดิม
ลงมือสามขั้น ขั้นแรก กำหนด RTO/RPO ตามจำนวนลีดต่อเดือนและราคาต่อออเดอร์ เว็บ B2B ส่วนใหญ่ 4 ชั่วโมงก็พอ ไม่ต้องไล่ตัวเลขสูงเกินจำเป็น ขั้นที่สอง เขียนแผนกู้คืนระดับคำสั่ง command line เก็บไว้สองที่ใน password manager กับ cloud drive ขั้นที่สาม ซ้อมเต็มรูปแบบใน test environment ปีละครั้ง บันทึก RTO/RPO ที่ได้จริง ถ้าเกินเป้าก็อัปเกรดแผน สามขั้นนี้เสร็จแล้วคุณถึงจะรู้ว่าเว็บตัวเองหลังเกิดเหตุใช้เวลากลับมานานแค่ไหน
ประโยคที่จำง่ายๆ ไว้ RTO ไม่ใช่ยิ่งสูงยิ่งดี ต้นทุน disaster recovery ระหว่าง 4 ชั่วโมงกับ 15 นาทีต่างกัน 10 เท่า คำนวณก่อนว่าเว็บล่ม 4 ชั่วโมงเสียหายจริงเท่าไหร่ แล้วค่อยตัดสินใจว่าจะเตรียม disaster recovery ถึงระดับไหน