真的万事俱备了吗

刘永刚

在DR/BC(灾难恢复/业务连续性)实践中,企业收集的最重要的定量参数就是恢复时间目标(RTO)和恢复点目标(RPO)。那么,怎样的计划才称得上是优秀的DR/BC计划呢?

BC遭遇多种挑战

业务惟一永恒不变的就是改变。因此,企业BC可能遭遇多种挑战:如果业务中断,该启用哪个计划呢?计划是否拥有足够的灵活性,从而可进行适当的调整呢?能否快速确定中断所产生的影响?能否找出所有在中断后需要调整的地方?……

此外还有协作问题,哪些任务应该优先处理呢?要是计划中部分关键的资源,如某个团队、某个应用程序或某个设备无法及时到位,那又应该怎么办呢?各种可变因素看起来是无穷无尽的。事故管理团队能否得到足够的信息来做出决策?他们在哪里获取信息,又如何获取呢?他们在作出决策之前,和其他执行计划的各个团队是否进行过有效沟通呢?

企业经过不懈努力编写并经过无数次演练得到的计划,是否足以应付公司可能出现的意外呢?如果出现的情况超出了计划范围,业务连续性又该如何保障呢?

只采用场景计划还不够

很多人在制作计划时都采用基于场景的方法。但是我们该知道,出现业务中断会有4个无法预知的条件:不知道会发生什么情况,在什么时候发生,会带来怎样的影响,以及会持续多长时间。场景计划看起来很不错,但是就像战争计划一样,它很可能在遭遇第一个“敌人”之后就开始失效了。

可行的、能够应对各种意外情况的业务连续性管理计划,有赖于有效的方法论、面向目标的分析、组织以及客观条件。

风险分析可以减少、防止或者缓解应对策略所带来的风险。当然,并不是所有威胁都能得到缓解,那些仍然存在的弱点在制定计划时应该特别注意。与其针对不可缓解的风险制定场景计划,不如采取一种更有针对性的策略,利用这些威胁去寻求它们可能带来的具体威胁或者几种相关的威胁。风险分析已经成为准备过程中有用的工具。

大多数的业务影响性分析(BIA)都期望能够确定对业务功能的危险程度。简单地说,BIA能够通过对品牌(或声誉)、客户、需求调整及收益的影响,威胁对企业所有功能造成的危险程度进行排序。

这些分析都只关心某一项功能或者流程出问题时对公司的影响,据此制定的计划必然会忽略大部分功能具有的相互关联性。因此,企业还需要对那些可能影响业务连续性的关键操作进行更加透彻的分析。

不管是为一个设备、一个部门、一个业务流程,还是一个IT系统或应用制定连续性计划,企业都有必要了解其相关的关键资源。这些资源,如设备、技术、供应商、职员及流程,是连续性计划中必不可少的元素。一个良好的BC计划,包含了解决这些关键资源缺失或者不足问题的策略。这样,这个计划就能够应对任何的中断,而不仅仅是一个特定场景或一系列的假设情况。

如果一个公司希望很好地保持连续性,或者从严重的事故中得以恢复,就必须深刻理解业务功能。同样,应该很好地理解服务等级协定,并在计划中得以体现。

制定BC应注意什么

企业是否已经做好了准备应对突发事件,如何管理这些措施,应该如何跟踪事情发展的人物、事件、时间、地点和进展呢?

首先,企业的计划必须与实际运营情况同步。这需要企业及时更新计划,在相关计划中体现业务的变化。值得注意的是,与实际操作同步的计划在遇到中断时会更容易管理。

其次,计划必须是可操作的。计划的每一个重要部分都需要落实到行动或者任务中,并且据此分配资源并指定完成的时间点。切实可行的计划允许恢复团队在每一个预期的里程碑确定进展。每个计划或者计划任务必须包含对必要资源的理解,以便事故管理团队能够为最需要的地方及时调度关键资源。

最后,计划还必须对协作需求有良好理解。团队成员都需要在计划中描述清楚,并界定其职责的范围和限制。执行团队都必须充分认识到每个功能的危险程度和与其他相关功能之间的关系,相关的计划中必须包含有相应的恢复操作。

不管是单独的计划还是总体的事故管理流程,都要列举清楚谁负责什么事情。每一个参与者,哪怕是不进行直接操作的公司高管,都必须了解整体组织结构及相应的职责。

BCM计划的演练也很不容易。要实现计划演练的价值,必须在真实环境中操作。演练的计划不能考虑各种最好的情形。从某种程度上来说,演练就是要让参与者遭遇意外,让他们不舒服。只有在演练中模拟真实环境,才能检验出公司对中断的准备情况,才能看出有哪些工作需要进一步改进。演练应该挑战参与者的应变能力——用他们的知识和经验去探索计划之外的策略和方法。

最后,如果BCM计划是针对公司各种未知情况的,应该反映公司本身的复杂性。准备计划没有捷径可走,它不是仅仅在已知的列表中进行一项项检查,也不是某个业界标准的实现过程。