ข้อความว่า “สำรองสำเร็จ” บอกว่ากระบวนการหนึ่งทำงานจบ แต่ยังไม่ยืนยันว่าข้อมูลครบ เปิดอ่านได้ หรือระบบจะกลับมาทำงานทันเวลาที่ธุรกิจต้องการ วิธีหาคำตอบคือทดลองกู้และตรวจงานที่ใช้ข้อมูลนั้นจริง
เริ่มจากสิ่งที่ธุรกิจต้องกลับมาทำได้ เช่น เปิดคำสั่งซื้อพร้อมเอกสารแนบ หรือให้ทีมเห็นงานค้างและทำต่อ จากนั้นกำหนดว่าต้องมีข้อมูลและส่วนประกอบใดจึงจะถือว่ากู้สำเร็จ
ตกลงก่อนว่าจะคืนอะไร และยอมเสียช่วงข้อมูลได้แค่ไหน
ระบบหนึ่งอาจมีฐานข้อมูล รูป เอกสาร การตั้งค่า และการเชื่อมต่อภายนอกอยู่คนละที่ ถ้าสำรองเฉพาะฐานข้อมูล อาจได้รายการกลับมาแต่เปิดไฟล์ที่เกี่ยวข้องไม่ได้ จัดรายการส่วนประกอบและเจ้าของข้อมูลให้ครบก่อนเลือกวิธีกู้
แยกเป้าหมายสองเรื่องให้ชัด: ต้องกลับมาทำงานภายในเวลาเท่าไร และยอมให้ข้อมูลใหม่หายย้อนหลังได้มากเพียงใด สองเรื่องนี้มักเรียกว่า RTO และ RPO ตามลำดับ ต้องกำหนดจากผลกระทบของงาน ไม่ใช่เลือกตามค่าที่มีในเครื่องมืออย่างเดียว
แนวทางทดสอบการกู้คืนของ AWS แนะนำให้ทดลองคืนข้อมูลและตรวจเทียบกับเป้าหมายเหล่านี้ รวมถึงตรวจว่าข้อมูลไม่เสียและเข้าถึงได้ การมีตารางสำรองอย่างเดียวจึงยังไม่ตอบว่ากู้แล้วใช้งานได้หรือไม่
หากหลายส่วนสำรองคนละเวลา ต้องตรวจว่าข้อมูลสัมพันธ์กัน เช่น รายการที่อ้างถึงไฟล์ต้องมีไฟล์รุ่นที่สอดคล้องกัน ระบุข้อจำกัดที่ยอมรับได้ไว้ก่อน ไม่รอพบหลังเกิดเหตุ
นิยามคำว่าผ่านด้วยงานที่สังเกตได้
เลือกงานตัวแทนที่มีความสำคัญต่อธุรกิจ แล้วเขียนผลที่ต้องเห็น ไม่ใช้แค่เปิดหน้าเข้าสู่ระบบหรือเห็นไฟล์ในโฟลเดอร์เป็นเกณฑ์ทั้งหมด
| สิ่งที่ทดลอง | หลักฐานที่ควรได้ |
|---|---|
| เปิดรายการที่มีอยู่ตอนสำรอง | ข้อมูลสำคัญตรงกับจุดเวลาที่เลือก |
| เปิดไฟล์แนบ | ไฟล์ที่เกี่ยวข้องเปิดได้และไม่สลับรายการ |
| ใช้บัญชีตามบทบาท | เห็นและทำได้ตามขอบเขตที่ตกลง |
| ทำงานต่อหนึ่งรายการ | บันทึกผลและอ่านกลับได้ |
| ตรวจการเชื่อมต่อ | ทราบว่าส่วนใดพร้อมใช้และส่วนใดยังต้องตั้งค่า |
| จับเวลาการกลับมาใช้งาน | รวมการคืนข้อมูลและตรวจความพร้อมตามขอบเขต |
ระบบสำรองบางแบบแยกขั้นคืนข้อมูลออกจากขั้นตรวจผล เช่น เอกสาร Restore testing validation ของ AWS Backup อธิบายการเรียกกระบวนการตรวจหลังงานคืนข้อมูลจบ แนวคิดสำคัญคือผู้ดูแลยังต้องกำหนดว่าผลแบบใดถือว่าใช้ได้สำหรับระบบของตน
อย่าใช้จำนวนรายการตรงกันเป็นหลักฐานเดียว เพราะข้อมูลอาจมีครบจำนวนแต่สัมพันธ์ผิดหรือขาดค่าที่สำคัญ เลือกตรวจทั้งภาพรวมและตัวอย่างที่สะท้อนการทำงานจริง
ทดลองในพื้นที่ที่ไม่รบกวนงานจริง
กำหนดสภาพแวดล้อมทดสอบที่แยกจากระบบจริง พร้อมควบคุมผู้เข้าถึงข้อมูลที่คืนมา โดยเฉพาะเมื่อสำเนามีข้อมูลลูกค้าหรือข้อมูลภายใน การเป็นพื้นที่ทดสอบไม่ได้ทำให้ข้อมูลนั้นกลายเป็นข้อมูลสาธารณะ
ป้องกันไม่ให้ระบบที่กู้มาทดลองส่งอีเมล สร้างคำสั่งซื้อ หรือเรียกบริการจริงโดยไม่ตั้งใจ ให้ผู้ดูแลระบุการเชื่อมต่อที่ต้องแทนด้วยระบบทดสอบก่อนเริ่มใช้
ใช้คู่มือและสิทธิ์ที่คนรับผิดชอบจะใช้จริง จดว่าติดขัดที่การหาไฟล์ การเข้าบัญชี ขั้นตอนคืน หรือการตรวจผล เพื่อแก้ส่วนที่ทำให้เสียเวลา ไม่วัดเฉพาะเวลาที่เครื่องมือคัดลอกข้อมูล
กำหนดวิธีจัดการข้อมูลและทรัพยากรทดสอบหลังจบตามข้อตกลงของทีม พร้อมเก็บหลักฐานที่จำเป็นโดยไม่เก็บสำเนาสำคัญกระจายไว้โดยไม่มีเจ้าของ
เมื่อไม่ผ่าน ให้แก้สาเหตุแล้วทดสอบจุดนั้นใหม่
ถ้ากู้ได้แต่ช้ากว่าเป้าหมาย ให้แยกว่าช้าที่การเข้าถึงบัญชี การคืนข้อมูล หรือการยืนยันผล ถ้าข้อมูลเก่าเกินที่ยอมรับได้ ต้องทบทวนความถี่และวิธีสำรอง ไม่แก้ด้วยการเปลี่ยนคำว่า “ผ่าน” ในรายงาน
บันทึกส่วนที่ยังไม่ครอบคลุม เช่น ยังไม่ได้ตรวจบริการเชื่อมต่อบางตัวหรือไฟล์บางชนิด ผลผ่านเฉพาะขอบเขตหนึ่งไม่ใช่คำรับรองว่าทั้งธุรกิจพร้อมรับเหตุทุกรูปแบบ
มอบหมายงานแก้ไขให้ผู้รับผิดชอบชัดเจนและคงสถานะข้อจำกัดไว้จนทดสอบใหม่ผ่าน รายงานที่บอกว่าพบปัญหาแต่ไม่มีคนรับไปทำต่อยังไม่ช่วยให้การกู้ครั้งถัดไปดีขึ้น
ทำให้การซ้อมครั้งถัดไปทำต่อได้
เก็บวันทดสอบ จุดข้อมูลที่ใช้ รุ่นของระบบ ผู้ทดสอบ ผลที่พบ และงานแก้ไข พร้อมเจ้าของงาน เลือกรอบทบทวนให้เหมาะกับความสำคัญและการเปลี่ยนแปลงของระบบ โดยทดสอบใหม่เมื่อส่วนสำคัญเปลี่ยนจนหลักฐานเดิมไม่ครอบคลุม
อ่านสิ่งที่ต้องส่งมอบเมื่อเปลี่ยนทีมดูแล เพื่อให้คนรับช่วงกู้ข้อมูลต่อได้ และใช้การตรวจข้อมูลก่อนย้ายระบบ เป็นแนวทางเลือกจุดตรวจความครบถ้วนและความสัมพันธ์ของข้อมูล
มีข้อมูลสำรอง แต่ยังไม่เคยลองกู้ให้กลับมาทำงานได้?
Talvyn Labs ช่วยวางขอบเขตและทดลองกู้คืนในพื้นที่ที่เหมาะสม ตรวจข้อมูลและงานสำคัญ พร้อมระบุสิ่งที่ต้องแก้ก่อนเกิดเหตุจริง
ตรวจความพร้อมสำรองและกู้คืน