运营韧性 vs 业务连续性 vs 灾难恢复的不同和协同
写在前面 ：随着金融监管机构和政府对关键基础设施的日益关注，运营韧性（Operational Resilience，常简写为OpRes）越来越热，但其内涵与边界在哪儿？在实践中与业务连续性、IT灾难恢复有什么区别？又如何协同？Protech公司的研究和内容负责人Michael Howell带来了两篇文章，分析并介绍了运营韧性、业务连续性和灾难恢复的不同和协同，下面对这两篇文章择要点予以介绍。
运营韧性、业务连续性和灾难恢复（还包括危机沟通、事件管理和应急管理等）并不是“对立”关系，而更多涉及到相互集成、协同以及如何有效利用信息、流程和资源来实现运营成果。但它们毕竟是不一样的东西（否则，没必要造出这些不同的名字），需要搞清楚它们的区别，即它们的分界线在哪儿？在组织中分别由哪些团队负责？以及可能影响其管理成效的关键点是什么？如果搞不清这些问题，在实践中可能会导致： 工作重复，并且不能形成合力； 不同的方法或数据，降低了工作效率； 部门或主题领域专家在权责方面的冲突； 发生扰断时无法有效恢复和保持连续性。
为了说明这三者的关联和区别，Protech公司的研究和内容负责人Michael Howell提出了操作风险（operational risk，也可译为运营风险，我们需要注意到“operational”可译为“操作”或“运营”）概念的“洋葱图”（onion diagram），如下图所示：
图1 操作风险概念的洋葱图
在这个概念图中，首先是操作风险。根据风险的定义，操作风险（operational risk）是不确定性对运营目标（operational objectives）的影响。一般而言，操作风险框架包括： 与相关方就其风险管理流程进行沟通和咨询； 根据组织具体情况，明确组织为实现其目标而愿意承担的风险类型； 识别 可能影响实现既定目标的风险； 分析 已识别的风险，以了解其原因、发生的可能性以及对目标的可能影响； 根据风险偏好 评价 风险或确定是否需要采取行动的标准； 确定风险应对（或处置）框架，包括降低风险发生可能性和/或影响的控制措施； 监控和审查风险管理流程，以提供保证和改进流程 记录和报告，为利益相关方提供信息并支持决策
其次是业务连续性管理，业务连续性管理重点关注那些一旦扰断，将对组织或其相关方造成重大影响的关键业务功能或服务。一般而言，业务连续性管理框架包括： 业务影响分析，以确定扰断对关键功能的影响，并确定支持这些功能所需的资源，如系统、第三方、人员、场所和数据等； 决定已确定的关键功能的最大允许扰断（如超出，组织将遭遇不可接受的影响）； 响应机制和事件升级流程，以便在发生扰断时实现有效沟通和启用业务连续性计划； 制定业务连续性计划，以便在资源扰断时恢复和重续关键功能或运营； 演练和测试业务连续性计划，以评估其有效性、涉及的角色和职责，并培养能力； 在扰断事件期间激活并使用计划 业务连续性管理的重点是准备应对可能威胁到组织生存的“合理事件”（即使它们不大可能发生）。许多业务连续性计划是在关注实体中断的时候制定的。
最后是IT灾难恢复，它是业务连续性管理的子集，侧重于IT资产的恢复和还原，也包括这些系统所依赖的基础设施、系统或数据。一般而言，IT灾难恢复包括： 为单个资产或系统确立恢复时间目标（RTO，即恢复这些资产和系统以支持关键功能的时间）； 确定数据的恢复点目标（RPO，对于给定的系统或资产，我们能接受损失多少数据）； 为单个资产制定灾难恢复程序； 为灾难恢复程序开发持续性的控制和过程，如备份过程或冗余； 演练和测试灾难恢复计划，以评估其有效性、涉及的角色和职责，并培养能力； 在扰断期间与BC团队协作。 备用物理场所的启用也包括在灾难恢复的职责里。重点是恢复IT资产，使企业能够继续运营。
在了解了操作风险管理、业务连续性管理和灾难恢复后，Michael Howell指出，运营韧性是对扰断的全面管理（the complete management of disruption），它具体包括： 首先是预防企业发生扰断； 稳健运营，在扰断发生时将影响降至最低； 尽快从影响中恢复； 适应经营环境的变化； 从扰断中学习，提高应对未来扰断的韧性。
清楚的是，以上每个领域都有助于运营韧性，并且缺少其中任何一个会降低这种韧性。比如，操作风险管理流程有助于识别可能导致扰断的风险和场景。在这三个领域中，操作风险管理侧重于预防（包括完全变更流程或依赖关系以消除风险或其原因，以及实施预防性控制），，而非应对和恢复。关键风险指标（KRI）和早期检测控制还可以提供需应对的风险敞口变化或即将发生的扰断的预警信号，这可以防止扰断或在确定发生时提供时间来吸收一些影响。而业务连续性和灾难恢复则认识到，预防并不总是可行的。一旦发生扰断，它们可以实现有效地恢复，同时将影响降至最低。当然，这涉及到严格地执行管理流程和测试，以确保在发生扰断时有能力做出响应。
Michael Howell所说的“运营韧性是对扰断的全面管理”很有意思，显然，它和业务连续性管理最初由对IT灾难恢复扩展而来一样，我们可以认为运营韧性是对业务连续性管理的扩展；同时，结合“运营韧性是操作风险有效管理的结果”（ BCBS（巴塞尔银行监管委员会）的《运营韧性原则》 ），运营韧性对业务连续性管理扩展后面向的对象是运营及相关的“操作风险”（即运营风险）。从全面风险管理框架来看，运营韧性关联的并非战略风险、财务风险等，与其相并列的仍会有战略韧性、财务韧性。建议结合 公众号文章：《再谈安全、韧性和风险》 阅读。
当然，与业务连续性管理和IT灾难恢复相比较，运营韧性还有一些值得关注的不同：
对内外部相关方影响的关注
业务连续性和灾难恢复主要考虑的是关键功能扰断对组织内部的影响，即使是影响类别涉及客户时，考虑的也是客户的影响在组织中的表现（如流失客户的百分比），而不是对客户的影响；而运营韧性将重点从关键功能扰断对组织内部的影响转移到对外部相关方（如客户或公众）的影响，在一些情景中，组织内部可以接受的东西可能不被这些外部相关方接受。更加关注对外部相关方的影响，也是近年来金融监管机构更加关注和强调运营韧性的原因。
对情景和对资源缺失的关注
业务连续性和灾难恢复计划通常是根据不可用的资源制定。因为，假如根据情景而非不可用的资源编制业务连续性计划（或灾难恢复计划），那就会有几乎无限的情景，或者当情景没有像预想的那样发生时，你可能制定的是不起作用的计划。但运营韧性通常需要考虑重要功能或运营出现严重但合理的情景（特别地，金融监管机构有强制要求）时怎么办？当然，这两种方式并不矛盾，运营韧性基于情景的管理为评估基于资源的连续性和恢复计划提供了一个大环境，比如，在这些情景中，连续性和恢复计划是否有效？情景还有助于评估因果路径和扰断发生的可能性，并有助于组织进行运营变更或实施预防性控制（很明显，单纯的、基于资源的计划因不考虑事件发生的原因而很难进行预防），从而可能减少扰断发生的可能性，或者减小影响。
人员分工的职责的不同考虑
一般而言，人们认为IT灾难恢复是业务连续性管理的子集，而业务连续性管理是操作风险管理的子集，但它们又是相互独立的功能，需要不同的专业技能和知识才能很好地运用。通常在组织中，它们虽然相关，但会由不同的团队来承担责任。比如，灾难恢复很少由技术之外的团队负责。业务连续性管理通常与操作风险（或企业风险）团队紧密关联，可能向这些团队报告或与这些团队一起工作。当然，还有一种可能性是业务连续性管理团队向首席运营官或类似角色报告，毕竟，在发生扰断时，需要继续的是他们负责的运营。
在有些情况下，监管可能决定由谁负最终责任，或者是向谁追责。对于英国的金融部门，运营负责人（chief of operation，根据SMF24）负责运营韧性。对于世界上大多数操作风险、业务连续性或运营韧性受监管的组织，董事会或高管层必须批准相关政策或计划，并确定角色和责任。
考虑到运营韧性、业务连续性和灾难恢复职责的不同，相应团队可以而且应该共同努力，共享方法和数据，协调一致实现运营韧性成果。
相关链接 ： 1.OpRes vs BC vs DR: What’s the difference? https://www.protechtgroup.com/en-au/blog/opres-vs-bc-vs-dr-whats-the-difference 2.OpRes vs BC vs DR: How you can all work together? https://www.protechtgroup.com/en-au/blog/opres-vs-bc-vs-dr-how-you-can-all-work-together
本公众号（ID：bcmplus）专注于业务连续性和运营韧性知识的传播和普及，关注业务连续性、应急和危机管理的朋友可关注本公众号。
由于公众号注册时腾讯已调整政策，未能开通留言功能，希望交流和讨论业务连续性和韧性相关问题，或获取相关资料的朋友，可长按以下二维码加入知识星球留言和讨论（另，公众号每月只能发4次文章，会有一些内容直接在知识星球分享而不在公众号发布）。
原文发表于公众号”业务连续性+” | 原文链接