RPO อธิบายช่วงเวลาข้อมูลสูญหายที่คุณยอมรับได้ ส่วน RTO อธิบายระยะเวลาหยุดชะงักที่คุณตั้งเป้าให้อยู่ภายใน กำหนดทั้งสองสำหรับฟังก์ชันทางธุรกิจที่มีประโยชน์ แล้วพิสูจน์ลำดับการกู้คืนในการฝึกซ้อม ตารางการสำรองข้อมูลหรือข้อกำหนดเซิร์ฟเวอร์เพียงอย่างเดียวไม่ได้กำหนดวัตถุประสงค์ใด ๆ
เริ่มต้นด้วยบริการที่ผู้คนใช้งานได้
วัตถุประสงค์การกู้คืนจะมีประโยชน์เมื่ออธิบายฟังก์ชันทางธุรกิจแทนที่จะเป็นเครื่องเดียว เซิร์ฟเวอร์อาจบูตได้ขณะที่ลูกค้ายังลงชื่อเข้าใช้ ดึงไฟล์ หรือทำคำขอให้เสร็จสมบูรณ์ไม่ได้ เขียนเงื่อนไขสิ้นสุดด้วยภาษาธรรมดา: ผู้ใช้ที่ได้รับอนุญาตสามารถเข้าถึงแอปพลิเคชันและข้อมูลที่จำเป็นมีความสอดคล้องกัน สิ่งนี้ทำให้เป้าหมายทดสอบได้โดยบุคคลนอกทีมโครงสร้างพื้นฐาน
ถามเจ้าของแอปพลิเคชันว่าการหยุดชะงักจะขัดขวางอะไรและข้อมูลที่สูญหายจะมีต้นทุนเท่าใด งานเผยแพร่รายสัปดาห์และแอปพลิเคชันประมวลผลธุรกรรมอาจมีคำตอบต่างกัน ถือว่าวัตถุประสงค์ที่ได้เป็นเป้าหมายการวางแผน ไม่ใช่คำสัญญาที่ประดิษฐ์จากแค็ตตาล็อกฮาร์ดแวร์ บันทึกว่าใครอนุมัติและแผนครอบคลุมสถานการณ์ความล้มเหลวใด
แยกนาฬิกาสองเรือนออกจากกัน
RPO เกี่ยวข้องกับว่าข้อมูลที่กู้คืนได้ย้อนหลังไปได้ไกลเพียงใดเมื่อเทียบกับการหยุดชะงัก ส่วน RTO เกี่ยวข้องกับฟังก์ชันอาจไม่พร้อมใช้งานนานเท่าใด การสำรองข้อมูลล่าสุดสามารถปรับปรุงช่วงเวลาข้อมูลสูญหายได้ ขณะที่การกู้คืนที่ช้ายังคงพลาดเป้าหมายเวลากู้คืน ในทางกลับกัน การรีบูตที่เร็วสามารถคืนการเข้าถึงแอปพลิเคชันที่ข้อมูลใหม่ที่สุดไม่ได้รอดชีวิตได้
ระบุจุดอ้างอิง ตัดสินใจว่าเวลาของเหตุการณ์เริ่มเมื่อใด อะไรนับเป็นการดำเนินงานที่กู้คืนแล้ว และจุดข้อมูลที่ใช้งานได้จะถูกระบุอย่างไร แยกเป้าหมายออกจากผลลัพธ์ที่วัดได้: วัตถุประสงค์คือสิ่งที่คุณมุ่งหวัง การฝึกซ้อมแสดงว่ากระบวนการปัจจุบันทำได้อะไร ทบทวนทั้งสองเมื่อแอปพลิเคชันหรือชุดข้อมูลเปลี่ยนแปลง
จัดงบประมาณให้ทุกขั้นตอนของการกู้คืน
งบประมาณ RTO ที่ปฏิบัติได้จริงรวมถึงการตรวจจับ การประเมิน การอนุญาต การเข้าถึงสภาพแวดล้อมการกู้คืน การกู้คืน การตรวจสอบแอปพลิเคชัน และการเปิดใช้งานใหม่ เวลาคัดลอกไฟล์เป็นเพียงองค์ประกอบเดียว หากผู้ถือคีย์การกู้คืนไม่พร้อมใช้งาน การสำรองข้อมูลที่เร็วตามทฤษฎีก็ยังใช้งานไม่ได้ จัดทำรายการการพึ่งพาและตรวจสอบว่าทีมกู้คืนสามารถเข้าถึงได้ระหว่างความล้มเหลวที่พิจารณา
กำหนดเวลาเบื้องต้นให้แต่ละขั้นตอน แล้วแทนที่การประมาณการด้วยการสังเกต ในงบประมาณสองชั่วโมงเชิงตัวอย่างนี้ การกู้คืนได้รับการจัดสรรเวลามากที่สุด แต่การตรวจสอบยังมีเวลาที่ป้องกันไว้ ตัวเลขเหล่านี้อธิบายตัวอย่างการวางแผน ไม่ใช่การให้บริการของ SwissOctet หากยอดรวมไม่มีส่วนเผื่อ การออกแบบต้องปรับปรุงก่อนที่วัตถุประสงค์จะน่าเชื่อถือ
| ขั้นตอนการกู้คืน | เวลาจัดสรรเชิงตัวอย่าง | หลักฐานที่ต้องเก็บรวบรวม |
|---|---|---|
| ตรวจจับและประเมิน | 15 นาที | การมาถึงของการแจ้งเตือนและการตัดสินใจเหตุการณ์ |
| เตรียมสภาพแวดล้อมการกู้คืน | 20 นาที | การเข้าถึงและการกำหนดค่าพร้อมใช้งาน |
| กู้คืนข้อมูลและบริการ | 50 นาที | การกู้คืนเสร็จสมบูรณ์พร้อมข้อมูลที่สอดคล้องกัน |
| ตรวจสอบและเปิดใช้งานใหม่ | 25 นาที | เส้นทางของผู้ใช้สำเร็จ |
| ส่วนเผื่อสำหรับเหตุฉุกเฉิน | 10 นาที | งานที่ไม่คาดคิดถูกบันทึกไว้ |
ตรวจสอบช่วงเวลาข้อมูลสูญหายจริง
งานที่ตั้งเวลาไว้ทุกชั่วโมงไม่ได้ให้ RPO หนึ่งชั่วโมงโดยอัตโนมัติ งานที่ล้มเหลว การอัปโหลดที่ล่าช้า หรือสำเนาที่ใช้งานไม่ได้สามารถทำให้จุดกู้คืนล่าสุดเก่ากว่ามาก สังเกตการเสร็จสมบูรณ์ที่สำเร็จและสถานะที่กู้คืนได้จริง สำหรับแอปพลิเคชันที่มีที่เก็บข้อมูลหลายแห่ง ยืนยันว่าจุดกู้คืนเข้ากันได้แทนที่จะอ่านแต่ละเวลาประทับแยกกัน
เลือกเหตุการณ์อ้างอิงระหว่างการฝึกซ้อม เช่น บันทึกทดสอบที่ได้รับอนุญาตซึ่งสร้างขึ้น ณ เวลาที่ทราบ หลังการกู้คืน ระบุบันทึกที่ถูกต้องใหม่ที่สุดและวัดช่องว่าง ใช้ข้อมูลทดสอบที่ไม่เป็นอันตราย สิ่งนี้ให้ผลลัพธ์ที่ปฏิบัติได้จริงและเปิดเผยสมมติฐานที่แดชบอร์ดซึ่งแสดงเฉพาะความสำเร็จของงานอาจซ่อนไว้
เลือกกลยุทธ์ภายในงบประมาณ
การสำรองและกู้คืน สภาพแวดล้อมสแตนด์บายที่เตรียมไว้ และการออกแบบแอปพลิเคชันแบบจำลอง แลกต้นทุนและความซับซ้อนกับความเร็วในการกู้คืน การจำลองสามารถลดความล่าช้าบางอย่างได้ แต่อาจจำลองการลบโดยอุบัติเหตุหรือข้อผิดพลาดของแอปพลิเคชันด้วย สแตนด์บายที่เบี่ยงเบนจากการกำหนดค่าที่ใช้งานสร้างความเสี่ยงของตัวเอง เลือกกลยุทธ์ตามสถานการณ์ความล้มเหลวและวัตถุประสงค์ที่คุณจัดทำเอกสารไว้
พิจารณาบริการขนาดเล็กที่มีเป้าหมายสี่ชั่วโมงและชุดข้อมูลขนาดใหญ่ที่การกู้คืนเพียงอย่างเดียวใช้เวลาหกชั่วโมงในการฝึกซ้อม การซื้อพอร์ตเครือข่ายที่เร็วกว่าเป็นเพียงสมมติฐาน: การอ่านที่เก็บข้อมูล การรับการเขียน และการกู้คืนแอปพลิเคชันอาจเป็นปัจจัยหลัก ปรับปรุงขั้นตอนจำกัดที่วัดได้ ลดชุดการกู้คืน หรือเปลี่ยนกลยุทธ์ แล้วฝึกซ้อมอีกครั้ง
ฝึกซ้อมโดยไม่เป็นอันตรายต่อระบบโปรดักชัน
ใช้สภาพแวดล้อมการกู้คืนที่แยกออกและช่วงเวลาการฝึกซ้อมที่กำหนดไว้ ตรวจสอบว่างานที่กู้คืนไม่สามารถส่งการแจ้งเตือนจริง รับชำระเงินสาธารณะ หรือเขียนลงในการเชื่อมต่อโปรดักชันได้ ทดสอบการเข้าถึง ความสมบูรณ์ของข้อมูล และเส้นทางผู้ใช้ที่เป็นตัวแทนก่อนถือว่าการฝึกซ้อมเสร็จสมบูรณ์ รวมบุคคลที่ไม่ได้เขียนขั้นตอนเดิมเพื่อเปิดเผยคำแนะนำที่ขาดหาย
เก็บบันทึกไทม์ไลน์ของการฝึกซ้อม จุดกู้คืนที่ทำได้ และการหยุดชะงักทุกครั้งที่เกิดจากข้อมูลที่ไม่พร้อมใช้งาน รายงานที่มีประโยชน์ระบุผลลัพธ์ที่วัดได้ ช่องว่างถึงวัตถุประสงค์ และการดำเนินการแก้ไขที่เฉพาะเจาะจง ทำซ้ำหลังการเปลี่ยนแปลงที่มีนัยสำคัญและในช่วงเวลาที่เหมาะสมกับความสำคัญของโครงการ
ทำให้แผนใช้งานได้ระหว่างเกิดความล้มเหลว
เก็บขั้นตอนการกู้คืนไว้ที่ทีมสามารถเข้าถึงได้โดยไม่ต้องพึ่งพาแอปพลิเคชันที่ล้มเหลวเพียงอย่างเดียว เก็บข้อมูลรับรองและคีย์เข้ารหัสในตำแหน่งที่ได้รับการป้องกันพร้อมกระบวนการเข้าถึงที่ทดสอบแล้ว อัปเดตรายชื่อติดต่อ ขนาดชุดข้อมูล และการพึ่งพาเมื่อโครงการพัฒนา แผนที่ล้าสมัยสามารถกินส่วนเผื่อเวลาก่อนการกู้คืนจะเริ่มต้นด้วยซ้ำ
เมื่อเปรียบเทียบการกำหนดค่า SwissOctet แยกสถาปัตยกรรมการกู้คืนของคุณออกจากตัวเลือกการสำรองข้อมูลเสริมของแค็ตตาล็อก ยืนยันว่าตัวเลือกหนึ่งครอบคลุมอะไร ข้อมูลการกู้คืนถูกเก็บที่ใด และใครทำการกู้คืน แค็ตตาล็อกไม่ได้กำหนด RPO หรือ RTO ของแอปพลิเคชัน กระบวนการที่คุณวัดได้และข้อกำหนดบริการจริงเป็นพื้นฐานสำหรับการตัดสินใจนั้น
รายการตรวจสอบปฏิบัติของคุณ
- กำหนดฟังก์ชันทางธุรกิจที่กู้คืนแล้ว
- อนุมัติเป้าหมาย RPO และ RTO แยกจากกัน
- จัดงบประมาณการตรวจจับ การเข้าถึง การกู้คืน และการตรวจสอบ
- วัดจุดข้อมูลที่ใช้งานได้ล่าสุด
- ฝึกซ้อมในสภาพแวดล้อมที่แยกออก
- บันทึกช่องว่างและทำซ้ำหลังการเปลี่ยนแปลงที่เกี่ยวข้อง
รายละเอียดที่สำคัญ
RTO เหมือนกับ uptime หรือไม่?+
ไม่ RTO เป็นเป้าหมายการกู้คืนสำหรับสถานการณ์การหยุดชะงัก uptime วัดความพร้อมใช้งานในช่วงเวลาหนึ่ง อย่างหนึ่งไม่ได้กำหนดอีกอย่างหนึ่ง
การสำรองข้อมูลรายชั่วโมงรับประกัน RPO หนึ่งชั่วโมงหรือไม่?+
ไม่ ตรวจสอบสำเนาที่เสร็จสมบูรณ์และใช้งานได้ และข้อกำหนดความสอดคล้องของแอปพลิเคชัน งานที่ล้มเหลวและการถ่ายโอนที่ล่าช้าสามารถขยายช่องว่างข้อมูลที่กู้คืนได้
ทุกโครงการต้องใช้เซิร์ฟเวอร์สแตนด์บายหรือไม่?+
เลือกกลยุทธ์ตามวัตถุประสงค์การกู้คืนของโครงการและกระบวนการกู้คืนที่วัดได้ สแตนด์บายเพิ่มต้นทุนและความซับซ้อนในการดำเนินงานและไม่จำเป็นโดยอัตโนมัติ
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- NIST SP 800-34 Rev. 1: คู่มือการวางแผนเหตุฉุกเฉิน nvlpubs.nist.gov
- AWS Well-Architected: กำหนดวัตถุประสงค์การกู้คืน docs.aws.amazon.com
- Microsoft Learn: ความต่อเนื่องทางธุรกิจ ความพร้อมใช้งานสูง และการกู้คืนจากภัยพิบัติ learn.microsoft.com
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก