ระบบไหนต้องกลับมาก่อน: วาด Recovery Dependency Map ให้กู้คืนได้จริง
เมื่อหลายระบบล่มพร้อมกัน แอปที่สำคัญที่สุดอาจยังเปิดไม่ได้เพราะต้องรอ identity, DNS, กุญแจ หรือผู้ให้บริการภายนอก ชวนวาดแผนที่การพึ่งพาเพื่อเลือกจุดเริ่มกู้คืนที่ใช้ได้จริง
ถ้าระบบสั่งซื้อหยุดทำงานพร้อมกับระบบอื่น สิ่งที่คนในทีมอยากเห็นกลับมาก่อนก็คงเป็นหน้ารับคำสั่งซื้อ ผมเองก็จะเริ่มจากคำถามนั้นครับ แต่ก่อนกด restore แอป ผมอยากรู้ว่าเครื่องที่เปิดกลับขึ้นมาจะติดต่ออะไรเพื่อให้คนล็อกอิน รับออเดอร์ และส่งงานต่อได้
นี่คือเหตุผลที่ควรมี Recovery Dependency Map หรือแผนที่ว่าแต่ละบริการต้องพึ่งอะไรในการกลับมาทำงาน มันช่วยเปลี่ยนคำว่า “กู้ระบบสั่งซื้อก่อน” ให้เป็นลำดับงานที่ทำได้จริง ถ้า identity สำหรับเข้าระบบยังล่ม DNS ยังชี้ผิด หรือกุญแจถอดรหัส backup หยิบไม่ได้ การเอาตัวแอปกลับมาก่อนอาจทำให้ได้เพียงหน้าจอที่เปิด แต่ยังขายของไม่ได้
สำหรับทีมเล็ก ผมจะไม่เริ่มจากการวาดทุก server ในบริษัทให้ครบในวันเดียว เลือกงานที่หยุดแล้วกระทบลูกค้าชัด ๆ สักงาน เช่นรับคำสั่งซื้อ แล้วไล่ย้อนจากผลลัพธ์ที่ต้องการ: ลูกค้าสั่งได้ ทีมงานเห็นรายการ และส่งรายการไปขั้นตอนถัดไปได้หรือไม่ แผนที่นี้ควรช่วยตัดสินว่าอะไรต้องคืนก่อน อะไรรอได้ และจะรู้ได้อย่างไรว่ากลับมาแล้วจริง
แอปเปิดได้ แต่คนยังทำงานไม่ได้
ลองใช้ระบบสั่งซื้อเป็นตัวตั้ง อาจมีหน้าร้านบนเว็บ ฐานข้อมูล และพื้นที่เก็บไฟล์ที่อยู่ในแผน backup แล้ว แต่คนดูแลจะกู้มันได้อย่างไรถ้าบัญชี admin ต้องยืนยันตัวตนผ่านผู้ให้บริการ identity ที่เข้าไม่ได้? ถ้า backup ถูกเข้ารหัส กุญแจอยู่ที่ไหน และคนที่ได้รับอนุญาตให้ใช้กุญแจติดต่อได้หรือเปล่า? คำถามเหล่านี้เกิดก่อนขั้นตอน restore ตัวแอปเสียอีก
จากนั้นค่อยดูเส้นทางที่ผู้ใช้ต้องผ่าน DNS แปลงชื่อเว็บให้ไปถึงปลายทางที่ถูกต้อง ส่วนระบบยืนยันตัวตนทำให้คนเข้าบัญชีได้ บางระบบยังต้องต่อ payment gateway หรือบริการส่งข้อความภายนอกด้วย แต่ไม่ต้องถือว่าทุกอย่างเป็นเงื่อนไขสำหรับ “เปิดรับออเดอร์” เสมอไป หากจ่ายเงินไม่ได้แต่ยังรับรายการไว้รอดำเนินการได้ ธุรกิจอาจเลือกกลับมาให้บริการแบบจำกัดชั่วคราว การตัดสินนี้ควรมาจากเจ้าของงานและเงื่อนไขลูกค้า ไม่ใช่ให้ทีม IT เดาเองตอนระบบล่ม
ผมชอบแยกบนกระดาษสองอย่าง: เส้นที่ ต้องมีจึงเริ่มบริการได้ กับเส้นที่ ขาดแล้วบริการยังทำงานแบบจำกัดได้ ไม่ต้องใช้เครื่องมือวาดแผนภาพราคาแพง ลูกศรบนกระดาษหรือ whiteboard ก็เริ่มได้ เพียงแต่ควรเขียนความหมายของลูกศรให้ตรงกัน เช่น “ระบบสั่งซื้อใช้ identity นี้เพื่อให้พนักงานล็อกอิน” ไม่ใช่ลากเส้นเพราะทั้งสองระบบอยู่ใน rack เดียวกัน
ใครถือกุญแจ และจะโทรหาใคร
แผนที่ทางเทคนิคจะช่วยได้น้อยถ้าไม่รู้ว่าคนไหนลงมือได้จริง สำหรับเส้นสำคัญ ผมจะจดผู้รับผิดชอบหลัก คนสำรอง และช่องทางติดต่อที่ไม่พึ่งระบบซึ่งกำลังกู้ เช่นถ้าอีเมลบริษัทล่ม เบอร์ติดต่อ vendor และวิธีประสานกันภายในไม่ควรอยู่เฉพาะใน inbox นั้น
กุญแจและบัญชีฉุกเฉินเป็นจุดที่อยากดูเป็นพิเศษ ทีมอาจเก็บ backup ครบ แต่ข้อมูลสำหรับปลดล็อก backup อยู่ใน password manager ที่ต้องใช้ SSO ผ่าน identity ตัวเดิม ถ้า identity ล่มพร้อมกัน แผน restore จะวนกลับมาหาตัวเอง เรื่องนี้ไม่จำเป็นต้องแก้ด้วยการแจก password ให้ทุกคนเก็บสำเนาเอง ควรมีวิธีเข้าถึงที่แยกจากระบบหลัก ควบคุมผู้ใช้ และลองเปิดใช้ตามขั้นตอนที่ตกลงกันไว้ อ่านเรื่องการพึ่งพาบัญชีและ recovery code เพิ่มได้ใน Account Recovery Plan
ผู้ให้บริการภายนอกก็เป็นส่วนหนึ่งของแผนที่ ไม่ว่าจะเป็น cloud, DNS, payment หรือระบบส่งข้อความ จดว่าทีมควบคุมขั้นตอนไหนเองได้ ขั้นตอนไหนต้องเปิด ticket และระหว่างรอมีวิธีทำงานชั่วคราวหรือไม่ ผมไม่ชอบแผนที่เขียนเพียงว่า “ติดต่อ vendor” โดยไม่มีชื่อผู้รับผิดชอบ ช่องทาง และสิ่งที่ต้องแจ้งให้เขาตรวจ เพราะพอถึงเวลาจริงประโยคนั้นยังเริ่มงานไม่ได้
ลำดับกู้คืนไม่ได้เท่ากับลำดับความสำคัญของธุรกิจ
ระบบสั่งซื้ออาจสำคัญที่สุดต่อรายได้ แต่ลำดับลงมืออาจเริ่มจากเครือข่าย การเข้าถึง backup, identity หรือ DNS ก่อน เพื่อให้ระบบสั่งซื้อใช้งานได้ ลำดับแบบนี้ไม่ใช่การลดความสำคัญของลูกค้า มันคือการเอาสิ่งที่แอปต้องพึ่งกลับมาให้พอ แล้วจึงคืนบริการที่ลูกค้ารออยู่
ตรงนี้ต้องคุยเรื่องเวลาที่ยอมให้หยุดได้ด้วย ถ้างานขายหน้าร้านมีทางรับรายการด้วยมือชั่วคราว แต่การส่งข้อมูลคลังสินค้ารอไม่ได้ ลำดับอาจเปลี่ยนไปตามผลกระทบจริง NIST SP 800-34 แนะนำให้ใช้การวิเคราะห์ผลกระทบต่อธุรกิจเพื่อกำหนดความสำคัญ และจัดกิจกรรมกู้คืนเป็นลำดับตามการพึ่งพาของส่วนประกอบ ผมมองว่านี่เป็นเหตุผลให้เจ้าของงานมานั่งโต๊ะเดียวกับคนกู้ระบบตั้งแต่ก่อนเกิดเหตุ ไม่ใช่ให้เอกสาร IT เป็นคนตัดสินแทน
ถ้าแผนที่เริ่มมีเส้นวน เช่นการเข้า backup ต้องใช้ identity แต่การกู้ identity ต้องอ่านข้อมูลจาก backup จุดนั้นควรหยุดคุยทันทีว่าอะไรคือทางเข้าอิสระที่ทดสอบได้ หรือจะใช้วิธีชั่วคราวที่ปลอดภัยอย่างไร ถ้ายังตอบไม่ได้ อย่าเพิ่งเขียนลำดับว่า “กู้ identity ก่อน” แล้วคิดว่าเรื่องจบ เส้นวนบนกระดาษมีประโยชน์ตรงที่มันทำให้เห็นปัญหาตั้งแต่ยังไม่ต้องใช้แผนจริง
จุดจบของการกู้ ไม่ใช่ไฟเขียวบนหน้าเครื่อง
หลังคืนบริการพื้นฐานและตัวแอปแล้ว ผมจะลองงานที่คนใช้จริงแบบไม่กระทบลูกค้า: ล็อกอินด้วยบัญชีที่เหมาะสม สร้างรายการทดสอบ ดูว่ารายการไปถึงทีมงาน และตรวจว่าการเชื่อมต่อภายนอกที่จำเป็นตอบกลับตามที่คาด ถ้าทำได้เพียงเปิดหน้าเว็บ แต่สร้างออเดอร์ไม่ได้ ก็ยังบอกว่า “ระบบกลับมาแล้ว” ไม่เต็มปาก
การซ้อมครั้งเล็ก ๆ มักเผยสิ่งที่แผนที่ลืม เช่นกุญแจที่คนรับผิดชอบเปิดไม่ได้ เบอร์ vendor ที่เปลี่ยนไป หรือชื่อ DNS ที่ใช้ได้เฉพาะในสำนักงาน ประเด็นนี้ต่อจาก Backup Restore Drill ซึ่งชวนลองกู้ข้อมูลจริง ไม่ใช่ดูเพียงสถานะ backup สีเขียว เมื่อซ้อมจบ ผมจะปรับแผนที่ตามสิ่งที่พบ แล้วเก็บสำเนาไว้ในที่ที่ทีมเข้าถึงได้แม้ระบบหลักล่ม
ถ้าจะเริ่มทำวันนี้ เลือกบริการที่ลูกค้าหรือทีมต้องใช้หนึ่งรายการ แล้วถามย้อนจนถึงคน บัญชี กุญแจ DNS และผู้ให้บริการที่ทำให้มันกลับมาได้ แผนที่แผ่นแรกอาจยังไม่สวย แต่ถ้ามันบอกได้ว่าควรหยิบอะไรก่อนและใครเป็นคนหยิบ ก็มีค่ากว่ารายชื่อระบบยาว ๆ ที่ทุกคนต้องมาเดาลำดับในวันที่เกิดเหตุครับ