北京
昨天又一份災備演練報告歸檔，綠燈，通過。數據在規定恢復窗口內上線，業務可用，團隊簽字，工單關閉。從流程上看，一切完美。可就在測試環境和下一次真實故障之間的某個空白地帶，恢復計劃悄悄和它原本要保護的架構脫了鉤。不是戲劇性崩盤，而是一點一點發生的——可能是一次云遷移、一次身份提供商整合、一套剛上線的SaaS依賴、一次沒寫進操作手冊的網絡改造。
這正是災備計劃失效的隱秘角落：它很少在你演練過的地方翻車，總是倒在那次演練從未觸及的假設上。一次災備演練從限定范圍起步：指定負載、已知起點、提前備好的目標環境。人手充足，權限到位，心無旁騖。爆炸半徑在測試開始前就被控好了。真實的災難性事件一件事都不滿足。
第一條告警傳來，范圍就開始膨脹。身份認證出問題，因為那個不在演練范圍內的IdP此刻根本連不上。網絡異常，因為故障切換路徑依賴的那張路由表三個月前已經更新過。一個計劃里從未留名的供應商不可用，恢復序列卡在某個從未被標注為依賴項的依賴面前。計劃是為測試條件寫的，事故降臨時的條件全是計劃沒料到的。這個裂縫，才是災備計劃失效的真正藏身之處——不在恢復機制本身，而在恢復機制假定自己能連通的一切。
演練驗證了負載。它很少驗證恢復這門活計所依賴的基礎設施本身。想想看，一份典型企業災備計劃默默依賴著什么：身份提供商、備份管理控制臺、云賬號訪問、工單和事件管理系統、第三方服務商、監控與告警設施——這些平時都默認能用，幾乎都不會被納入演練范圍。當真的災難把一個假設可用之物打翻，計劃毫無反應，因為它從來沒想過要為這個準備一條退路。災備計劃一旦依賴一座它從未測試過能否恢復的橋，就不再是恢復計劃，而是一張蓋了章的恢復假設。
紙面上的恢復點目標和恢復時間目標，全都建立在基礎設施按預期運行的默認前提上。線上絕大多數恢復時間目標失敗，并不是備份技術本身出了問題，而是那個時長計算從未包含的某項依賴給出了抗議。災備文檔有出版日期，基礎設施可不會陪它靜止。企業環境里，災備計劃最初是對標某一個架構快照寫的，從那以后，組織一直在變。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
