業務連續性計劃
 |
一位華夏公益教科書使用者認為此頁面應該分成更小的頁面，並具有更窄的子主題。 您可以透過將此大頁面拆分成更小的頁面來幫助我們。請確保遵循 命名策略。將書籍分成更小的部分可以提供更多關注點，並允許每個部分都做好一件事，這有利於所有人。 |
業務連續性計劃 (BCP) 方法用於制定計劃，使組織能夠在正常運營遭受某種中斷的情況下繼續運營。該方法需要能夠擴充套件以適應任何規模和複雜程度的組織。儘管該方法起源於受監管行業，但任何型別的組織都可以建立 BCP 手冊，並且可以說每個組織都應該有一個 BCP 手冊，以確保組織的長期生存。災難生存統計資料表明，企業在 BCP 準備方面投入的時間和資源不足。火災會永久關閉 44% 的受影響企業。在 1993 年世貿中心爆炸事件中，受影響的 350 家企業中有 150 家未能從事件中倖存下來。相反，在 911 襲擊事件中受影響的企業，其 BCP 手冊已得到很好的開發和測試，在幾天內就恢復了運營。
小型組織的 BCP 手冊可能只是一本印刷手冊，安全地存放在主要工作地點之外，其中包含危機管理人員、一般員工、客戶和供應商的姓名、地址和電話號碼，以及非現場資料備份儲存介質的位置、保險合同副本和其他對組織生存至關重要的材料。最複雜的是，BCP 手冊可能概述了輔助工作地點、技術要求和準備情況、監管報告要求、工作恢復措施、重建實體記錄的方法、建立新供應鏈的方法或建立新生產中心的方法。企業應確保其 BCP 手冊在危機期間切合實際且易於使用。因此，BCP 與危機管理和災難恢復計劃並行，是組織整體 風險管理 的一部分。
BCP 手冊的開發分為五個主要階段：分析、解決方案設計、實施、測試和組織接受以及維護。
BCP 手冊開發中的分析階段包括影響分析、威脅分析和影響場景，以及由此產生的 BCP 計劃需求文件。
影響分析將組織的關鍵職能與非關鍵職能區分開來。如果組織受損對利益相關者的影響被認為是不可接受的，則某個職能可能被認為是關鍵的。建立和維護適當的業務或技術恢復解決方案的成本可能會改變對中斷可接受性的看法。如果法律規定，某個職能也可能被認為是關鍵的。接下來，影響分析將為每個關鍵職能生成恢復要求。恢復要求包括以下資訊
- 災難發生後必須恢復關鍵職能的時間範圍
- 關鍵職能恢復的業務需求，以及/或者
- 關鍵職能恢復的技術需求
定義恢復需求後，建議記錄潛在威脅，詳細說明特定災難的獨特恢復步驟。一些常見的威脅包括以下內容
以上示例中的所有威脅都具有共同的影響 - 組織基礎設施可能受損 - 除了疾病。疾病的影響最初純粹是人類的，可以透過技術和商業解決方案來緩解。在 2002-2003 年非典爆發期間，一些組織將員工分組為獨立的團隊，並在主要工作地點和輔助工作地點之間輪換團隊，輪換頻率等於疾病的潛伏期。
這些組織還禁止團隊成員在工作時間和非工作時間進行面對面的接觸。透過這種分割，組織提高了對政府下令隔離措施的抵禦能力，如果一個團隊中的一人感染了疾病或暴露於疾病中，他們會更容易應對。
洪水造成的損害也具有獨特的特徵。如果辦公室環境被非鹽水和無汙染的水淹沒（例如，發生管道爆裂事件），裝置可以徹底乾燥，並且可能仍然可以使用。
定義潛在威脅後，建議記錄構成業務恢復計劃基礎的影響場景。通常，最好為影響範圍最廣的災難或干擾制定計劃，而不是為規模較小的問題制定計劃，因為幾乎所有規模較小的問題都是大型災難的一部分。一個典型的影響場景，如“建築物損失”，很可能涵蓋所有關鍵業務職能，以及任何潛在威脅的最壞可能結果。如果組織擁有不止一座建築物，業務連續性計劃也可能記錄其他影響場景。還可以記錄其他更具體的影響場景 - 例如，一個建築物中特定樓層暫時或永久損失的場景。
完成分析階段後，需要記錄業務和技術計劃要求，以便開始實施階段。對於以辦公室為基礎的，資訊科技密集型的企業，計劃需求可能涵蓋以下要素，這些要素可以被歸類為 ICE（緊急情況下）資料
- 在輔助地點，在主要業務地點之外需要的工作臺數量和型別，無論是專用工作臺還是共享工作臺
- 參與恢復工作的人員，以及他們的聯絡方式和技術資訊
- 輔助地點工作臺需要的關鍵業務職能所需的應用程式和應用程式資料
- 手動應急解決方案
- 應用程式允許的最大停機時間
- 外設需求，如電腦印表機、影印機、傳真機、計算器、紙張、筆等。
其他業務環境，例如生產、分銷、倉儲等，需要涵蓋這些要素，但可能在破壞性事件後需要管理其他問題。
解決方案設計階段的目標是確定最具成本效益的災難恢復解決方案，該方案滿足影響分析階段的兩個主要要求。對於 IT 應用程式，這通常表示為
- 最低應用程式和應用程式資料需求
- 最小應用程式和應用程式資料必須可用的時間範圍
災難恢復計劃可能也需要在 IT 應用程式領域之外，例如儲存硬複製格式的資訊，或恢復過程工廠中的嵌入式技術。此 BCP 階段與災難恢復規劃方法重疊。解決方案階段確定
- 危機管理指揮結構
- 輔助工作場所的位置（如有必要）
- 主要和輔助工作場所之間的電信架構
- 主要和輔助工作場所之間的資料複製方法
- 輔助工作場所所需的應用程式和軟體，以及
- 輔助工作場所的物理資料要求型別。
實施階段，簡單來說，就是執行解決方案設計階段確定的設計元素。工作包測試可能在解決方案實施期間進行，但是，工作包測試不代替組織測試。
測試的目的是使組織接受業務連續性解決方案滿足組織的恢復要求。由於恢復要求不足或不準確、解決方案設計缺陷或解決方案實施錯誤，計劃可能無法達到預期效果。測試可能包括
- 危機指揮團隊呼叫測試
- 從主要工作場所到輔助工作場所的技術切換測試
- 從輔助工作場所到主要工作場所的技術切換測試
- 應用程式測試
- 業務流程測試
至少，測試通常按半年或一年進行。在初始測試階段發現的問題可能被彙總到維護階段，並在下一個測試周期中重新測試。
BCP 手冊的維護分為三個定期活動。第一個活動是確認手冊中的資訊。第二個活動是測試和驗證為恢復操作建立的技術解決方案。第三個活動是測試和驗證已記錄的組織恢復程式。半年或一年的維護週期是典型的。
所有組織都會隨著時間的推移而發生變化，因此 BCP 手冊必須發生變化才能保持與組織的相關性。一旦驗證了資料準確性，通常會進行呼叫樹測試以評估通知計劃的效率以及聯絡資料準確性。手冊中應識別和更新的一些更改型別包括
- 人員變動
- 人員角色
- 重要客戶及其聯絡方式的變更
- 重要供應商/供貨商及其聯絡方式的變更
- 部門變動，例如新部門、關閉部門或發生根本性變化的部門。
作為持續維護的一部分，必須檢查任何專門的技術部署的功能。一些檢查包括
- 計算機病毒定義分發
- 應用程式安全和服務補丁分發
- 硬體執行能力檢查
- 應用程式執行能力檢查
- 資料驗證
隨著工作流程的不斷變化，以前記錄的組織恢復程式可能不再適用。一些檢查包括
- 所有關鍵功能的工作流程是否都已記錄？
- 執行關鍵功能所使用的系統是否已更改？
- 記錄的工作清單對員工是否有意義且準確？
- 記錄的工作流程恢復任務和支援的災難恢復基礎設施是否允許員工在預定的恢復時間目標內恢復？
正如本文所含圖表所示，測試和維護階段與影響階段之間存在直接關係。從頭開始建立 BCP 手冊和恢復基礎設施時，測試階段發現的問題通常必須重新引入分析階段。