ออกแบบความพร้อมรับภัย

หัวข้อนี้วัดสองอย่าง หนึ่งคือเราเข้าใจนิยาม RTO กับ RPO แบบไม่สับสนไหม สองคือเรา map ความต้องการธุรกิจไปสู่กลยุทธ์ DR และต้นทุนที่เหมาะได้ไหม คนจำนวนมากสลับ RTO กับ RPO หรือท่องได้แต่ใช้ไม่เป็น DCE ที่เก่งจะอธิบายให้ลูกค้าเข้าใจว่าความพร้อมรับภัยมีราคา แล้วช่วยหาจุดสมดุลระหว่างความเสี่ยงที่ธุรกิจรับได้กับงบที่จ่ายไหว

RTO (Recovery Time Objective): ระยะเวลานานที่สุดที่ระบบยอมหยุดทำงานได้ก่อนต้องกลับมาใช้งาน เป็นเรื่องของ "เวลา" ตอบคำถามว่า "ต้องกู้ระบบกลับมาเร็วแค่ไหน" เช่น RTO หนึ่งชั่วโมงแปลว่าหลังเกิดเหตุต้องทำให้ระบบกลับมาใช้ได้ภายในหนึ่งชั่วโมง

RPO (Recovery Point Objective): ปริมาณข้อมูลมากที่สุดที่ยอมสูญเสียได้ วัดเป็นช่วงเวลา เป็นเรื่องของ "จุดข้อมูล" ตอบคำถามว่า "ยอมเสียข้อมูลย้อนหลังได้กี่นาทีหรือกี่ชั่วโมง" เช่น RPO ห้านาทีแปลว่ายอมเสียข้อมูลที่เกิดในช่วงห้านาทีก่อนเหตุได้ ซึ่งกำหนดว่าต้อง backup หรือ replicate ถี่แค่ไหน

วิธีจำที่ไม่สับสน: RTO เกี่ยวกับ Time ที่ใช้กู้กลับ มองไปข้างหน้าจากจุดเกิดเหตุ; RPO เกี่ยวกับ Point ของข้อมูลล่าสุดที่กู้ได้ มองย้อนหลังจากจุดเกิดเหตุ ลองวาดเส้นเวลา จุดเกิดเหตุอยู่ตรงกลาง RPO คือช่วงย้อนหลังที่ข้อมูลหาย RTO คือช่วงไปข้างหน้าที่ใช้กู้ระบบ

หลักการต้นทุน: ยิ่ง RTO และ RPO ต่ำ (เข้าใกล้ศูนย์) ยิ่งต้องลงทุนสูงขึ้นมาก เพราะต้องมีระบบสำรองที่พร้อมกว่าและ replicate ถี่กว่า การถามลูกค้าว่ารับ RTO/RPO เท่าไหร่ได้คือการถามว่าเขายอมจ่ายเพื่อความพร้อมระดับไหน

สองคำนี้มักถูกพูดปนกันแต่ไม่เหมือนกัน:

• High Availability (HA): ออกแบบให้ระบบไม่ล่มจากความล้มเหลวย่อย ๆ ภายใน region เช่นเครื่องเดียวพัง โดยกระจาย workload ข้ามหลาย zone มี redundancy และ failover อัตโนมัติ เป้าหมายคือ "ไม่ล่มตั้งแต่แรก"
• Disaster Recovery (DR): แผนกู้คืนเมื่อเกิดภัยใหญ่ที่กระทบทั้ง region เช่นภัยธรรมชาติหรือ region ล่ม มักเกี่ยวกับการมีสำเนาข้าม region เป้าหมายคือ "กู้กลับได้เมื่อเกิดเหตุใหญ่"

ระบบที่ดีต้องมีทั้งสอง HA กันเหตุเล็กที่เกิดบ่อย DR กันเหตุใหญ่ที่เกิดนาน ๆ แต่กระทบหนัก

มีสี่รูปแบบหลักไล่จากถูก-ช้า ไปแพง-เร็ว:

Backup and Restore: เก็บ backup ไว้แล้วกู้คืนเมื่อเกิดเหตุ RTO และ RPO สูง (ระดับชั่วโมงถึงวัน) ถูกที่สุดเพราะไม่ต้องรันระบบสำรองตลอด เหมาะ workload ที่ไม่ critical มาก

Pilot Light: เก็บส่วนแกนของระบบไว้ขั้นต่ำ เช่น database ที่ replicate ไว้ ส่วน compute ปลุกขึ้นมาเมื่อเกิดเหตุ RTO/RPO ดีขึ้น ต้นทุนปานกลาง

Warm Standby: มีระบบสำรองรันอยู่บางส่วนตลอดในขนาดเล็ก เมื่อเกิดเหตุก็ scale ขึ้นมารับงานจริงได้เร็ว RTO/RPO ต่ำ ต้นทุนสูงขึ้น

Hot Standby หรือ Multi-site Active-Active: ระบบสำรองรันเต็มขนาดพร้อมรับงานทันที หรือทั้งสองฝั่งรับงานพร้อมกัน RTO/RPO เข้าใกล้ศูนย์ แพงที่สุดเพราะต้องจ่ายโครงสร้างซ้ำเกือบเต็ม เหมาะระบบที่หยุดไม่ได้เลย เช่นการเงินหลัก

การเลือกกลยุทธ์คือการแปลตัวเลข RTO/RPO ของลูกค้าเป็นรูปแบบที่เหมาะ แล้วชั่งกับงบ

แนวทางและ service ที่เกี่ยวข้อง:

• กระจายข้าม zone และ region: zone หลายตัวใน region เดียวให้ HA, การมีสำเนาข้าม region ให้ DR
• Database replication: เช่น Cloud SQL มี cross-region replica และ automated backup, Spanner มี multi-region configuration ที่ให้ทั้ง availability และความถูกต้องระดับ global
• Cloud Storage หลาย location: เลือก regional, dual-region หรือ multi-region ตามความต้องการความทนทานและ availability
• Backup and DR Service: บริการสำรองและกู้คืนแบบจัดการให้
• Snapshot ของ Persistent Disk และ automated backup ตามตาราง
• Load balancing และ traffic management สำหรับสลับไปใช้ระบบสำรองเมื่อเกิดเหตุ
• Infrastructure as code: ทำให้สร้างระบบขึ้นใหม่ในอีก region ได้เร็วและซ้ำได้
• การทดสอบ DR: แผน DR ที่ไม่เคยทดสอบคือแผนที่เชื่อไม่ได้ ควรพูดถึงการซ้อม failover เป็นระยะ

ถาม: "RTO กับ RPO ต่างกันอย่างไร" ตอบ: RTO คือเวลาที่ยอมให้ระบบล่มก่อนกู้กลับ, RPO คือข้อมูลย้อนหลังที่ยอมเสียได้ ใช้เส้นเวลาอธิบายและยกตัวอย่างตัวเลข

ถาม: "ลูกค้าต้องการ RTO หนึ่งชั่วโมง RPO ห้านาที จะออกแบบอย่างไร" ตอบ: RPO ห้านาทีต้อง replicate หรือ backup ถี่ระดับนาที เช่น cross-region replica ของ database; RTO หนึ่งชั่วโมงเลือกได้ราว warm standby ที่ scale ขึ้นได้เร็ว พร้อม automated failover และทดสอบเป็นระยะ

ถาม: "HA กับ DR ต่างกันอย่างไร" ตอบ: HA กันเหตุย่อยภายใน region ด้วย multi-zone, DR กันเหตุใหญ่ระดับ region ด้วยสำเนาข้าม region

ถาม: "ลูกค้าอยากได้ RTO/RPO เป็นศูนย์แต่งบจำกัด จะคุยอย่างไร" ตอบ: อธิบายว่าใกล้ศูนย์ยิ่งแพงแบบทวีคูณ ชวนจัดลำดับว่าระบบไหน critical จริงค่อยลงทุนสูง ส่วนระบบรองใช้กลยุทธ์ที่ถูกลง เป็นการ map ความเสี่ยงกับงบ

ถาม: "ทำไมต้องทดสอบ DR" ตอบ: เพราะแผนที่ไม่เคยซ้อมมักใช้ไม่ได้จริงตอนเกิดเหตุ การซ้อม failover ทำให้มั่นใจว่าตัวเลข RTO/RPO เป็นจริง

สลับนิยาม RTO กับ RPO; ท่องนิยามได้แต่ map เป็นกลยุทธ์ไม่เป็น; เสนอ active-active กับทุกระบบโดยไม่ดูงบและความ critical; สับสน HA กับ DR; ลืมว่าการเลือกกลยุทธ์คือการแลกต้นทุนกับความเสี่ยง; ไม่พูดถึงการทดสอบ DR; ไม่ถามตัวเลข RTO/RPO ก่อนออกแบบ

RTO คือเวลาที่ยอมให้ล่มก่อนกู้กลับ RPO คือข้อมูลย้อนหลังที่ยอมเสียได้ ยิ่งต่ำยิ่งแพง HA กันเหตุเล็กภายใน region ส่วน DR กันเหตุใหญ่ข้าม region กลยุทธ์ DR ไล่จาก backup-restore, pilot light, warm standby ถึง hot standby/active-active ตามต้นทุนและความเร็ว บน GCP ใช้ multi-zone, multi-region, database replication, automated backup และ IaC พร้อมทดสอบ failover เป็นระยะ หัวใจคือ map ตัวเลข RTO/RPO ของลูกค้าเป็นกลยุทธ์ที่สมดุลระหว่างความเสี่ยงกับงบ