业务连续性管理—第四篇—业务连续性总结和灾难恢复

业务连续性管理—第四篇—业务连续性总结和灾难恢复
⼀、引⾔
在我们⽇常⼯作中常常会将业务连续性管理（BCM）和灾难恢复(DR)两个概念混淆，两者之间有内在联系，但也有所不同。

业务连续性管理更加宽泛，关注企业的战略，以保障业务运营为⽬标，解决全⽣命周期的问题，⽽后者更加注重具体操作，以系统为⽬标，着重解决事中的问题，同步处理事后的问题。

⼀般来讲，可以将灾难恢复做为业务连续性的⼀个部分，但不是全部。

1）按照CISSP中的定义
灾难恢复的⽬标是尽量减少灾难或中断带来的影响。

这意味着要采取必要的步骤以确保资源、⼈员和业务流程能够及时恢复运⾏。

这与连续性规划不同，连续性规划提供给我们处理长期运营中断和灾难的⽅法和程序。

灾难恢复计划的⽬标是在灾难之后，处理灾难及其后果；灾难恢复计划以信息技术为核⼼。

灾难恢复计划是当⼀切事情仍处于紧急模式时实施的计划，其中每个⼈都争相所有关键系统重新联机。

业务连续性规划采取⼀个更⼴泛的解决问题的⽅法。

它可以包括在计划实施中对原有设施进⾏恢复的同时在另⼀个环境中恢复关键系统，使正确的⼈在这段时间内回到正确的位置，在不同的模式下执⾏业务直到常规条件恢复为⽌。

2）按照NIST SP800-34的定义
业务连续性计划（BCP）:业务连续性计划的重点是在中断期间和中断之后维持组织的任务/业务流程。

任务/业务流程的⽰例可以是组织的⼯资单流程或客户服务流程。

业务连续性计划可以针对单个业务单元内的任务/业务流程编写，也可以针对整个组织的流程。

灾难恢复计划（DRP）:DRP适⽤于拒绝长期访问主要设施基础设施的重⼤、通常是物理性服务中断。

DRP是⼀种以信息系统为中⼼的计划，旨在在紧急情况发⽣后恢复备⽤站点上⽬标系统、应⽤程序或计算机设施基础设施的可操作性。

⼀旦备⽤设施建⽴，DRP可由多个信息系统应急计划提供⽀持，以解决受影响的单个系统的恢复问题。

DRP可以通过在备⽤位置恢复任务/业务流程或任务基本功能的⽀持系统来⽀持BCP或COOP计划。

DRP只处理需要重新定位的信息系统中断。

3）按照GB/T 30145-2013/ISO 22301:2012和 GB/T 20988-2007 定义
业务连续性管理（ business continuity management）：识别对组织的潜在威胁以及这些威胁⼀旦发⽣可能对业务运⾏带来的影响的⼀整套管理过程。

该过程为组织建⽴有效应对威胁的⾃我恢复能⼒提供了框架，以保护关键相关⽅的利益、声誉、品牌和创造价值的活动。

业务连续性计划：⽤于指导组织在业务中断时进⾏响应、恢复、重新开始和还原到预先确定的业务运⾏⽔平的形式⽂件的程序。

灾难恢复（disaster recovery）：为了将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运⾏状态、并将其⽀持的业务功能从灾难造成的不正常状态恢复到可接受状态，⽽设计的活动和流程。

总结：
针对三个标准的理解，各个标准关于术语定义描述各有侧重，但笔者更加倾向于NSIT的定义。

笔者认为：业务连续性计划是基于企业战略的、处理长期的、⾯向中断中和后维持业务连续性的规划，核⼼是业务连续；灾难恢复计划是⾯向重⼤的、灾难性的系统故障，在异地恢复业务暂时性正常运转的计划。

灾难恢复解决的临时性的、针对异地恢复的临时性计划。

业务连续性管理从涉及的内容看，包含了灾难恢复计划，还包括⾼可⽤性。

业务连续性更多侧重策划、执⾏和管控，灾难恢复更注重执⾏。

本⽂是笔者近期，短时间内所学的总结，⼀定会有理解不对的地⽅，后期根据知识的更新，会进⾏更新。

总之，业务连续性和灾难恢复，⽆论从安全⾓度，还是企业运营的⾓度是⼗分重要的。

其投资回报是隐性的，但不能因为看不到，摸不着就不投⼊，⼀旦事件发⽣，后悔莫及。

因此规划须是⾃上⽽下的执⾏，⾸先要先从思想的统⼀，需要⾼层的⽀持，作为⼀把⼿⼯程去抓，否则就成了光说不练假把式。

以下内容，主要以IT的视⾓对业务连续和灾难恢复进⾏总结。

⼆、业务连续性管理
业务连续性管理具体包括：
出现紧急情况时提供及时和适当的应对措施
保护⽣命和确保安全
减少对业务的影响
恢复关键业务功能
在灾难时减少混乱
确保企业的⽣存能⼒
在灾难发⽣后迅速“启动并运⾏”
具体流程和⾥⾯涉及的细节进⾏阐述。

1.BCP的启动阶段⼯作
1）BCP项⽬启动前准备活动
确定BCP需求，可以包括有针对性的风险分析以识别关键系统可能的中断
了解相关法律、法规、⾏业规范以及机构的业务和技术规划的要求，以确保BCP与其⼀致
任命BCP项⽬负责⼈，建⽴BCP团队，包括业务和技术部门的代表
制定项⽬管理计划书，其中应明确项⽬范围、⽬标、⽅法、责任、任务以及进度
召开项⽬启动会，获得管理层⽀持
确定收集数据所需的⾃动化⼯具
设置必要的技能培训和意识提升活动
2）⼯作任务
计划的开发团队与管理层的沟通和联络
有权与计划相关所有⼈进⾏直接接触和沟通
充分了解业务中断对机构业务的影响
熟悉机构的需求和运作，有能⼒平衡机构相关部门的不同需求
与⾼级管理层对话
了解机构业务⽅向和⾼管理层的意图
有能⼒影响⾼级管理层的决策
3）BCP项⽬的关键⾓⾊
恢复团队：灾难后进⾏评估、恢复、复原等相关⼯作的多个团队
业务部门代表：识别机构的关键业务功能，协助恢复策略的选择和制定
IT部门
通信部门
信息安全部门
法律代表
必须建⽴的团队：
损失评估团队：确定灾难原因；确定进⼀步破坏的可能性；标识影响的业务和领域；标识关键资源可⽤程度；标识必要的资源；评估要多久完成。

若评估时间超过原来评估的MTD值，⽴即启动升级BCP。

还原/重建团队（restoration）：让备⽤站点投⼊运营
救援团队（salvage）：把备份站点在转到主站点，让主站点恢复运营。

3）BCP⽬标
确定信息收集技术
选择受访者
识别关键业务功能(critical business functions)及其⽀持资源
确定如果失去这些资源的⽀持这些功能能存活多久
识别弱点和威胁
计算每个业务功能的风险
准备提交BIA报告：存在的问题、应对建议
BCP策略：BCP规划最终应该形成业务连续性策略条款，该条款记录的BCP的⽬标、范围、需求、基本原则和指导⽅针、职责和责任、关键环节的基本要求。

策略条款应得到⾼级管理层的正式批准，并公布成为机构的政策，指导业务连续性的相关⼯作。

2.BIA分析
主要⼯作内容：
确定关键功能
确定关键资源
计算MTD资源
识别威胁
计算风险
确定⽅案
1）BIA过程
2）BIA分析⽅法
定性分析以划分严重程度的⽅式得出灾难或中断事件造成的影响
定量分析以货币的⽅式得出灾难或中断事件造成的影响
BIA的信息分析过程：整理（Organize）归纳（Correlate）分析（Analyses）和确认（Confirm）
BIA分析中断的影响，确定每项业务功能的恢复窗⼝，具体会涉及⼏个值：
⼯作复原时间， Work Recovery Time，WRT：从系统正常运转，恢复业务的时间（数据恢复）
恢复时间⽬标，Recovery Time Object，RTO：在系统的不可⽤性严重影响到机构之前所允许消耗的最长时
恢复点⽬标，Recovery Point Objectives，RPO：数据必须被恢复以便继续进⾏处理的点。

所允许的最⼤数据损失量
RTO+WRT<=MTD
关于MTD与RPO、RTO和WRT的关系如下图：
关于⽹络和资源可⽤性指标
平均修复时间（MTTR）：修复⼀台设备并使其投⼊⽣产状态所需的时间
平均⽆故障时间（MTTF）：计算机系统平均能够正常运⾏多长时间，才发⽣⼀次故障。

系统的可⽤性越⾼，平均⽆故障时间越长。

平均故障时间间隔（MTBF）：期望⼀台设备可靠运⾏估计时间.是衡量⼀个产品（尤其是电器产品）的可靠性指标，单位为“⼩时”。

它反映了产品的时间质量，是体现产品在规定时间内保持功能的⼀种能⼒。

总结：组件越多，整体可靠性越低
3）风险评估
应当识别、评估和记录以下内容：
组织中对时间最敏感的资源和活动的所有脆弱点
组织中最紧迫的资源以及活动的威胁和危害
衡量关键的服务和产品中断的可能性、时间长度以及造成的影响。

单点故障的情况
由于关键技能的缺失造成的业务连续风险
由于外包供应商和供应商造成的业务持续性风险
因BCP计划没有涵盖本部门或者BCP计划没有很好地落实⽽造成的业务连续性风险
3.确定预防控制措施
主要的⽬标实施控制，以降低风险
1)数据备份⽅案的选择
数据备份开始位置：归档位。

归档位:操作系统的⽂件系统通过设定归档位来跟踪发⽣变化的⽂件。

完全备份（full backup）：整个数据的备份
增量备份（incremental process）:对最近完全备份和增量备份以后发⽣的所有⽂件进⾏备份;阶段性叠加；占⽤空间少，但恢复慢，恢复时需要把所有增量加上全备份进⾏恢复
差量备份（differential process）：对最近完全备份发⽣改变的部分进⾏备份；与完全备份的差异部分备份；需要空间⼤，恢复快。

恢复时只需要最新⼀次差量和⼀个完备
具体关系图如下:
完全备份是增量备份和差异备份的前提条件，⾸次需要先完成⼀次完全备份后才能开在增量备份、差异备份。

若选择差异备份，当要恢复数据时需要选择⼀次完全备份和以此完全备份为基础的最近⼀次的差异备份，这种⽅式的缺点是备份时间长、占⽤空间⼤，例如开始数据
10G，每天增加1G，那么完全备份的数据是10G，第⼀天的差异备份是1G，第⼆天的是1G+1G，第三天的是1G+1G+1G，这样恢复时，只需要恢复⼀个完全备份，选⼀个需要恢复时间点的差异备份即可；若选择增量备份，但恢复数据时需要选择⼀次完全备份和以此完全备份为基础的所有增量备份，这种⽅式缺点是恢复慢，例如开始书记10G，每天增量1G，那么完全备份的数据是10G，第⼀天是1G，第⼆天是
1G，第三天是1G，这样恢复时，需要先恢复完全备份，然后恢复第⼀天，再恢复第2天，再恢复第3天。

顺序不能乱。

2）⾼可⽤性
应⽤层（负载均衡+⾼可⽤）、数据层（rac）、设施层（HA）
3）电⼦备份解决⽅案
磁盘映像（disk duplexing）（RAID 1）
电⼦传送（electronic vaulting）：在⽂件发⽣改变时进⾏备份，再定期传送到另⼀个地点；不是实时（使⽤备份软件）
电⼦链接：⼀种实时备份到异地设施批量传送⽅法（使⽤备份软件/备份设备）
远程⽇志处理（remote journaling）：离线数据传输⽅法；只将⽇志或事务处理⽇志传送到异地，不传送实际⽂件；类似数据库的归档；通过⽇志可重建丢失的数据，实际为数据被增删改的记录；实时发⽣（归档⽇志）
4）设施选择
完备场所（hot sit）：拥有与主站点的所有软硬件设施，唯⼀缺的是数据。

在⼏个⼩时就能投⼊运营
基本完备场所（warm site）：只配置了主要软硬件
基础场所（cold site）：只提供机房环境
软件备份：代码第三⽅托管
5）其他因素
⽹络和计算机设备冗余
语⾳和数据通信资源冗余
⼈⼒资源
设备和⼈员运送
环境问题
数据和⼈员安全
办公资源
⽂档记录
外包：⼀种风险转移措施
互惠协议（reciprocal agreements）：组织间⽤于分享宕机风险。

在灾难发⽣时，每个组织承诺承担彼此的数据和处理任务。

4.制定恢复策略
业务流程、设施、供应和技术、⽤户和⽤户环境、数据
恢复策略的选择必须符合组织需求
成本效益分析 (CBA)
建⽴策略的初始费⽤
维护恢复策略解决⽅案的持续费⽤
⽅案定期测试的费⽤
通信相关的费⽤
5.制定BCP
⽂档化程序包括：计划程序、恢复程序、恢复解决⽅案、⾓⾊和任务、应急响应
业务连续性计划流程如下：
a)确定业务关键功能
公司的业务计划通常就决定了公司关键的使命和业务功能。

必须为这些功能设定优先级别
b)确定⽀持关键功能的资源和系统
在确定了关键的功能之后，就有必要找出实现这些功能究竟需要那些⽀持。

需要有⼈来对这些资源进⾏分析，这样的分析应该由那些理解资源并知道它们是如何为企业提供功能的⼈来完成。

c)估计潜在的灾难事件
确定所有可能的意外事故和灾难
BIA的结果作为以上的输⼊。

d)选择计划策略
制定有关如何恢复关键资源和评估应急⽅案
6)实施策略
⼀旦决定了策略，就需要将它们归档，这使得我们的努⼒从纯粹的计划阶段进⼊到了实际的实施和⾏动阶段。

6.操作、演练和测试
需要对业务连续性计划做定期测试，因为环境总是在持续变化，每⼀次测试都能够带来⼀些改进。

⼀般会形成以下计划：
测试计划
改进计划
培训计划
1）具体测试类型包括：
清单/检查表测试（checkling test）：计划副本发涉及的部门让他们审核，避免出现不切实际或遗漏的措施。

各部分分头审核提意见
组织演练测试/结构化排练测试（structured walk-through test）：各部门⼈员聚在⼀起审核计划。

聚集在⼀起审核提意见
模拟测试（simulation test）：所有相关⼈聚集在⼀起，根据某个场景展开练习如何执⾏灾难恢复计划。

测试每个⼈的反应。

确保没有遗漏步骤。

测试过程只包含哪些实际灾难中可能存在的情况。

测试⼀直持续到搬到了异地设施处并真正配置了替换设备为⽌。

所有⼈聚集⼀起测试，选定场景，知道设备搬到异地备份结束。

并⾏测试（parallel test）：系统搬到备⽤⼚所运⾏，然后与原⼚所对⽐。

只系统搬到异地，本地还运⾏，对⽐分析
全中端测试（full-interrupution test）：完全模拟真实场景，原站点关闭，备⽤站点启⽤。

本地全停⽤，异地启⽤，管理层批准，先要完成并⾏测试。

2）测试策略包含测试⽬标和范围
测试BCP/DRP 每年⾄少测试⼀次：当重⼤变更发⽣时需要进⾏测试
测试⽬标刚开始可以简单逐渐增加复杂度、参与级别、职能以及物理位置
测试不要危及正常业务运⾏
测试展⽰在模拟危机下各种管理和响应能⼒，逐渐增加更多的资源和参与者
揭⽰不恰当之处以便修正测试程序
考虑偏离测试脚本插⼊意外事件，⽐如关键个⼈或服务的损失
包括⾜量所有类型交易确保恢复设施适当的能⼒和功能
测试策略包含测试计划：基于预定的测试范围和⽬标
包含测试计划评审程序
包含各种测试场景和⽅法的开发
测试计划：主测试计划应包括所有的测试⽬标
测试⽬标和⽅法的具体描述
所有测试参加者包括⽀持⼈员的⾓⾊
测试参与者的委派
测试决策制定者和后续计划
测试位置
测试升级条件和测试联系信息
7.维护BCP
整合到变更控制流程中，主要包括：
分配责任
更新计划
更新后发布
8.应急事件处理流程
再造阶段（reconstittution phase）：当公司开始搬回原来的场所或搬进⼀个新设施时。

三、灾难恢复计划
灾难恢复：指⾃然或⼈为灾害后，重新启⽤信息系统的数据、硬件及软件设备，恢复正常商业运作的过程。

灾难恢复⽬标：降低灾难或业务中断的影响；采取必要的步骤保证资源、⼈员和业务流程尽快恢复运作。

往往更加关注IT层⾯。

预防性措施与恢复战略的区别
预防性是不仅降低公司经历灾难的可能性，同时减轻破坏程度，对灾难本⾝进⾏缓解
恢复战略是灾难发⽣后⽤于保护公司的⽅法，利⽤提供备⽤场所，对灾难本⾝没有啥改变
业务流程恢复：是⼀组相互关联的步骤，它通过特定的决策活动完成具体的任务
DR包括反应、⼈员、沟通、评估、恢复和培训
灾难恢复计划执⾏⼤体上可以以下⼏步组成：
响应阶段：开始判断灾难的原因，先分析才能对症下药。

沟通阶段：针对事件情况进⾏沟通评估
评估阶段：确定需要⽴即替换的资源、判断关键系统上线的时间，为下⼀步⼯作作准备，并确定是否启动BCP计划。

恢复阶段：宣告灾难，开始灾难恢复。

四、其他相关计划
业务连续性计划：着重于恢复必须重建的业务流程⽽⾮IT组件
操作连续性计划：在灾难发⽣后建⽴⾼级管理层和总部，说明⾓⾊、权威，继任的先后顺序
IT应急计划：⽤于⽹络、系统和主要应⽤程序恢复的过程计划
紧急通信计划：包括内部和外部沟通结构和⾓⾊
⽹络事故响应计划：主要关注恶意软件、⼊侵攻击和其他安全问题
灾难恢复计划：重点说明在发⽣灾难后恢复各种IT机制
场所应急计划：⼈员安全和撤离程序。

特别声明：
1.以上所有描述内容部分参考链接/⽂献未逐⼀列出，若有侵权，请及时告知，有则改之⽆则加勉。

2.以上仅是学习过程的总结，相信有很多理解偏差的地⽅，特别希望指出，给予帮助，更新知识体系，共同进步。

3.以上内容⼤部分是采⽤百度翻译，结合⾃⼰的理解，所有有些理解偏差的，请批评指正！
参考⽂件：
业务连续性系列
<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">。