业务连续性计划
 |
一位维基教科书用户认为此页面应该分成更小的页面，并具有更窄的子主题。 您可以通过将此大页面拆分成更小的页面来帮助我们。请确保遵循 命名策略。将书籍分成更小的部分可以提供更多关注点，并允许每个部分都做好一件事，这有利于所有人。 |
业务连续性计划 (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 手册和恢复基础设施时，测试阶段发现的问题通常必须重新引入分析阶段。