【51CTO.com原創稿件】常言道：流水不腐、戶樞不蠹。您企業的災難恢復計劃是否 N 久沒被更新了？我們來看看一位 90 后是如何對 DRP 進行整改的案例。

[[216314]]

話說我們公司應急響應中心新來了一位小嵇同學。作為典型的90后，他受過良好教育、個性張揚、特立獨行。

那天，他對我們說：他覺得咱們現在的 DRP（災難恢復計劃）就像他過去彈鋼琴一樣，存在著如下三大問題：

我們當初聽過了后，也沒在意。可沒想到幾日后，他在某次 IT 管理層會議上，一邊問著：“驚喜不驚喜？意外不意外？”，一邊向我們展示了他改進后的 DRP。

大家雖然不喜歡這種粗暴的“手撕”方式，但耐著性子認真閱讀之后，也不得不承認他的更改的確解鎖了一些新技能，并填補了一些老坑點。

總的來說，這份新的 DRP 基本上“沒毛病”。下面就讓我們來具體看看他在原來的基礎上做了哪些改進。

事前篇

清晰定義“災難”

“傻傻”分不清楚，但是你要分清楚

原來的 DRP 上手就談如何應對災難，可是公司上上下下在多數情況下，經常會混淆問題（Problem）、緊急情況（Emergency）與災難（Disaster）之間的細微差別，并造成了一旦出事就“匆忙上陣”，出現人浮于事的狀況。

因此，他開宗明義地做了如下定義：

• 問題：是指單個或少量的計劃外的業務和/或服務中斷或質量水平驟降，造成損失較輕，直接責任部門容易迅速實施補救。

不涉及到 DRP 和 DR 相關團隊，一般小于 24 小時。

• 緊急情況：是指多個不可預見性的業務和/或服務中斷情況的組合，造成了一定的損失或破壞，多個部門需要盡快解決。

DR 相關團隊需時刻根據實際情況觸發 DRP，一般大于 24 小時但小于 48 小時。

• 災難：是指成規模的對資產和/或服務造成了損害、損失或破壞的重大事件。需要公司管理層的參與。

DR 相關團隊立即啟用 DRP 并分步驟實施 DR，一般大于 48 小時。

厘清上述關系，可見對于掌握 DRP 的觸發條件是至關重要的，而后續的恢復活動才能夠有的放矢地進行開展。

BIA + RA

“預則立，不預則廢” 

業務系統在日常運營過程中，可能發生的各種災難，對我們來說就是“天災人禍”類的重大事件。

過去的 DRP 對于當前的生產系統來說不但已經陳舊，而且有著較大的出入。

因此要想達到有條不紊的恢復效果，就需要通過 BIA（業務影響分析）和 RA（風險分析）來識別出那些與本公司日常運營密切相關的職能模塊和關鍵應用。

小嵇通過參考各種 SLA（服務水平協議）、事故記錄、以及內/外審報告，對各類主/次要系統定義了 MTD（最大允許中斷時間），區分了輕重緩急，并排定了恢復的先后次序。

在 BIA 中，他依次以“業務職能”和“關鍵應用”兩大部分為出發點，分別根據關鍵（1-4 小時）、緊急（24 小時）、重要（72 小時）、一般（7 天）、非必要（30 天）五種 MTD，擬出了 2×5 =10 張表格。

下面就是兩類表頭的示例，大家可以批判地審視一下：

上述的 BIA 主要從“知己”的角度出發，為了實現“百戰不殆”的小目標，它還努力定義了“知彼”，即 RA。

下面就是他依次引入的三個維度的參考指標：

• 內/外部威脅源或威脅代理：自然層面上的各種災害；技術層面的，如軟/硬件損壞所造成的大量數據丟失和分布式拒絕服務攻擊等。

支撐系統方面的，如供電、空調和接入網絡等；以及人為方面，如故意使用惡意軟件進行破壞和操作疏忽與失誤等。

• 風險可能性：基于過往事件/事故的記錄、放置和使用區域特征、相關合規要求、自身魯棒性，得出高中低的性質。
• 影響范圍：整個組織/所有外部客戶、多個站點/多個系統與服務、或是單個站點/單個系統。

最后將這些都對應到各個業務模塊上形成風險分析的矩陣。由此可見，他通過對現有系統的全方位、立體“掃描”和剖析，掃清了識別層面上的“死角”，為必要時的全面復盤做好了基礎性的準備工作。

團隊與責任

拒絕懵逼、也拒絕“布朗運動”

舊的 DRP 僅簡單定義了一個應急響應小組來全面履行災難恢復，可是有過實戰經驗的小伙伴一定知道，這種“低配”是完全不夠的。

在此，小嵇同學細化并深耕了 DR 團隊，并為他們“賦能”。下面讓我們來看看這些“破壁”的人們需要哪些必備的技能，才能幫助我們把災難懟回去：

恢復管理團隊：

• 設置緊急熱線電話、保持“呼叫樹（Call Tree）”的準確性。
• 審查通知模板、災難評估報告、測試結果。
• 確保相關人員的技能和意識培訓、以及演練的落實。
• 定期審閱 DRP 并落實更新。
• 批準和控制恢復全程的成本。
• 檢查確認系統的恢復。

損失評估團隊：

• 評估災難影響程度、量化損失以獲賠償。
• 起草并提交損失報告。

設施資源團隊：

• 編錄并更新生產環境中的軟/硬件列表和備件庫存情況。
• 保證能在必要時獲取外部服務與支援。
• 維護離站資源和備用站點，提供各類相關的參考文檔和操作手冊。
• 必要時安排離站資源向受損主站的調配，以及人員轉往備用站點的各種后勤。

技術恢復團隊：

• 向評估團隊提供必要的技術和數據信息。
• 提出過渡性的臨時運營方案。
• 按照既定的順序執行具體災難恢復的各項技術操作。
• 防止次生災難的發生。
• 災難期間，對備用站點提供各項技術支持。
• 事后總結，提出加固方案，并更新 DRP。

公關法務團隊：

• 在各個階段，保持與各個方面的溝通，并使用既定的模板進行相關發布。
• 給予法律、合規方面的指導。
• 如有必要，則實施電子或物理取證。

由上可見，在“大難臨頭”之時，如果沒有明確規定好計劃中相對應的團隊角色和其負有的職責的話，別說什么組隊打“怪”了，只要出現一位“豬一樣的隊友”，大家就真的只能去“領盒飯”了。

事中篇

設定應對流程

“審判日”的絕地反擊 

曾經的 DRP 在這個環節寫得“頭重腳輕”，開始響應階段細致入微，甚至有些吹毛求疵，而實際操作中并無過多的時間去層層報告和批示。

另外，在原 DRP 中，其恢復過程過于“速度與激情”化，導致業務回歸上線后就草草收場，缺乏必要的確認與總結，而小嵇改版后的 DRP 則能明顯體現“步步為營”的流程感。

讓我們一起往下看：

• 事故出現，初步檢測與識別，并定性災難。
• 通知管理層，吹響 DR 團隊的“集結號”。
• DR 團隊迅速拍馬趕到，各司其職，展開深入調查與取證。
• 損失評估，分析災難源、填寫如下災難評估模板。（注意：評估報告需在災難發生的 4 小時之內完成并提交。）

• 對內/對外宣告災難。注意對內可以使用不同顏色的通知模板，以便受眾一目了然。對外提供可能問及的技術細節解答和支持。
• 在受災處，根據主次關系和既定順序，先抑制再恢復，逐步實施各種基礎設施、通信線路、硬件、軟件的安裝和配置、以及數據的恢復。

在 DR 的各項活動中，除了要注意各個 RTO 與“里程碑”外，也要注意填寫并提交如下的日志檢查表。

• 實時評估并驗證恢復的有效性。如有必要，迅速修改恢復流程與方法，避免滋生次生破壞。
• 各個受影響的部門對災難的恢復結果予以確認，并對內/外宣布完成。
• 總結評審執行效果，分析與原計劃的偏離，并提出改進措施。

事后篇

更新與測試

自建生態，形成閉環

我們或許都有這樣的共識：IT 服務和系統是隨著企業的業務動態生長，并不斷迭代的，可見舊版本的 DRP 之所以能被小嵇“吊打”和“按到地上摩擦”，就是因為它針對的是彼時多年前的系統狀態。

因此，為了防止老化和淘汰，小嵇版本的 DRP 特地在最后部分增加了按需更新和例行測試。

具體來說，他羅列到的更新觸發條件包括如下因素的增加、變更與淘汰：

• 服務器/用戶端硬件設備與模塊
• 網絡設備、連接與架構環境
• 機房、數據中心與外部鏈路
• 關鍵軟件程序、應用平臺和服務系統
• 辦公自動化（OA）與協同（Collaboration）相關軟/硬件產品
• 關鍵配置與數據格式
• 服務策略（SLA）與員工規則

為了避免出現“扎心了，老鐵，這方案沒法實施”的情況發生，小嵇也定義了相應的例行維護與測試頻率：

俗話說：貓有九條命，但是我們的業務服務系統可沒有那么多的命哦。

因此，唯有保持 DRP 可操作性和可實現性，才能讓這個所謂的剛性需求不斷地“滿血復活”。

小結

前些時“第一批 90 后已經…”的各種段子刷爆了微信朋友圈。

但是不可否認的是 90 后一代正在成為企業內的中堅技術力量，并正在逐步向管理崗位邁進。

雖然我們公司里的 90 后在技術水平上經常被黑，但是講真：這次以小嵇為代表的 90 后對于 DRP 的大刀闊斧式的改進，讓我們這些自稱佛系，卻時常油膩的 70 后老年人不得不刮目相看了。

[[216317]]

作者：陳峻

陳峻（Julian Chen） ，有著十多年的 IT 項目、企業運維和風險管控的從業經驗，日常工作深入系統安全各個環節。作為 CISSP 證書持有者，他在各專業雜志上發表了《IT運維的“六脈神劍”》、《律師事務所IT服務管理》 和《股票交易網絡系統中的安全設計》等論文。他還持續分享并更新《廉環話》系列博文和各種外文技術翻譯，曾被(ISC)2 評為第九屆亞太區信息安全領袖成就表彰計劃的“信息安全踐行者”和 Future-S 中國 IT 治理和管理的 2015 年度踐行人物。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】