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

[[216314]]

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

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

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

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

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

事前篇

清晰定義“災難”

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

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

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

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

不涉及到 DRP 和 DR 相關(guān)團隊，一般小于 24 小時。

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

DR 相關(guān)團隊需時刻根據(jù)實際情況觸發(fā) DRP，一般大于 24 小時但小于 48 小時。

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

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

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

BIA + RA

“預則立，不預則廢” 

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

過去的 DRP 對于當前的生產(chǎn)系統(tǒng)來說不但已經(jīng)陳舊，而且有著較大的出入。

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

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

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

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

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

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

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

支撐系統(tǒng)方面的，如供電、空調(diào)和接入網(wǎng)絡(luò)等；以及人為方面，如故意使用惡意軟件進行破壞和操作疏忽與失誤等。

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

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

團隊與責任

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

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

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

恢復管理團隊：

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

損失評估團隊：

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

設(shè)施資源團隊：

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

技術(shù)恢復團隊：

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

公關(guān)法務團隊：

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

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

事中篇

設(shè)定應對流程

“審判日”的絕地反擊 

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

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

讓我們一起往下看：

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

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

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

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

事后篇

更新與測試

自建生態(tài)，形成閉環(huán)

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

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

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

• 服務器/用戶端硬件設(shè)備與模塊
• 網(wǎng)絡(luò)設(shè)備、連接與架構(gòu)環(huán)境
• 機房、數(shù)據(jù)中心與外部鏈路
• 關(guān)鍵軟件程序、應用平臺和服務系統(tǒng)
• 辦公自動化（OA）與協(xié)同（Collaboration）相關(guān)軟/硬件產(chǎn)品
• 關(guān)鍵配置與數(shù)據(jù)格式
• 服務策略（SLA）與員工規(guī)則

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

俗話說：貓有九條命，但是我們的業(yè)務服務系統(tǒng)可沒有那么多的命哦。

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

小結(jié)

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

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

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

[[216317]]

作者：陳峻

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

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】