系统韧性技术是任何提高系统韧性的架构、设计或实现技术。这些技术(例如缓解措施,如冗余、保障措施和网络安全对策)或被动地抵御逆境或主动检测逆境,并对其做出反应,亦或者从它们造成的伤害中恢复过来。系统韧性技术是系统实现其韧性需求的手段。韧性技术也可以被视为架构、设计或实现模式或习惯用法。本文首先澄清韧性要求和韧性技术之间的关系。由于系统、软件和专业工程师有许多可以用于提高系统韧性的技术,因此本文还提出了一个用于对这些韧性技术进行分类的本体。
01
系统韧性-简要回顾
正如我在本系列的前3篇文章中所概述的——系统韧性很重要,因为没有人想要一个无法克服“不可避免的逆境”的脆弱系统。如果不利事件或条件导致系统无法正常运行,则可能会对有价值的资产造成各种形式的损害。
在本系列关于系统韧性的第一篇文章中,我通过提供以下更详细和微妙的定义来解决这些问题:系统的韧性达到了它快速有效地保护其关键能力免受不利事件和条件造成的伤害的程度。
第二篇文章确定了八个次要质量属性,对可能破坏关键系统的不利因素(即不利条件和事件)进行了分类。
第三篇文章介绍了系统韧性需求的工程,以及如何使用它们来推导下级质量属性的相关需求。
本文,亦即本系列的第四篇文章将要做的是,提供一种对系统韧性技术进行分类的方法,并展示它们与系统韧性需求的关系。
02
系统韧性技术
单个韧性技术通常可以保护任务关键能力免受多种类型的多重不利因素的影响。每个关键能力通常会被多种类型的大量逆境破坏。通常,在有限的项目资源(如人员配置、时间表和预算)内,会有更多的不利因素无法适当解决。因此,首先强调必须保护其免受破坏性损害的关键能力。然后,可以使用风险管理来识别、优先化和分析足够多的最重要的不利因素,以充分保护任务关键能力。
如下图所示,韧性要求并不直接推动韧性技术的选择。相反,这种选择是由衍生的韧性相关鲁棒性、被动安全性、主动安全性、防篡改、生存性、容量、寿命和互操作性需求中捕获的特定不利因素驱动的。下图显示了关键功能、实现它们的关键资产以及可能对它们造成的破坏性伤害如何推动韧性需求的工程。特定的不利因素用于导出下级韧性相关质量属性的需求(即鲁棒性、被动安全性、主动安全性、防篡改、生存性、容量、寿命和互操作性需求)。然后,架构师和专业工程师选择适当的韧性技术来直接实现这些特定于逆境的衍生需求,从而间接实现韧性需求。
除了韧性及其从属质量属性外,许多韧性技术还增加了多个质量属性。例如,冗余还可以提高可用性和可靠性,而模块化也可以提高可维护性。
韧性技术是抽象的,必须在系统中实现,以实现其预期效果。然而,如果技术选择不当或实现不当,结果可能与预期不同,甚至可能降低系统的韧性。因此,韧性技术并不总是“最佳实践”,因此添加更多的技术并不一定更好。需要大量的专业知识、分析和测试,以确保所实施的选定技术实现系统的韧性要求,而不会导致系统无法满足其他质量属性要求。
下图显示了对韧性技术进行分类的三种不同方法。从左到右,它们是:
- 自治程度(紫色部分)。与手动韧性技术不同,自动韧性技术在无需人工干预的情况下自动执行。混合韧性技术部分自主,部分手动。
- 执行韧性功能(黄色部分)。抵抗力技术被动地抵抗逆境。检测韧性技术主动检测逆境,而反应韧性技术主动对检测到的逆境做出反应,恢复韧性技术主动修复逆境造成的伤害。许多技术结合了这类技术中的两种或更多种。
- 构成(蓝色部分)。子系统韧性技术由专用子系统(如火灾探测和灭火系统)实现。它们可以用硬件(如硬件联锁和冗余传感器)或软件(如各种投票方案)来实现。同理,数据韧性技术主要在数据中实现(如校验和),尽管它们通常需要软件来操作数据。
下图显示了如何将韧性技术映射到韧性需求,但又与韧性需求有所不同,韧性需求应该是内聚的,并且只指定单个独立于实现的需求,单个韧性技术通常执行多个功能。例如,火灾探测和灭火系统(FDSS)既可以检测不利因素(烟雾的存在),又可以通过抑制相关火灾来做出反应,以最大限度地减少额外的危害。
03
总结与预告
显而易见的是,有很多可以用于实现系统韧性需求的技术。这些技术可以以多种方式进行分类,其中最重要的两种是按韧性功能和实施方式分类。这种丰富的技术和类型的技术为系统架构师和专业工程师提供了很大的灵活性,以确保足够的韧性,特别是在使用多层“深度防御”方法时。另一方面,整合韧性技术增加了系统复杂性,因此,矛盾的是,会降低系统的韧性。选择正确的数量、类型和韧性技巧的平衡绝非易事。
在下一篇文章亦即本系列的第五篇文章中,我将探讨一个相对全面的韧性技术列表,并给出一个表单,根据它们执行的韧性功能和组成来对其进行组织。
敬请期待。