不良事件和条件可能会中断系统，导致系统无法提供必要的功能和服务。正如我在本系列的前几篇文章中所概述的那样，韧性是大多数系统的一个基本质量属性，因为它们提供了关键的能力和服务，尽管存在着不可避免的困难，但这些能力和服务必须继续。这些逆境通常是不可避免的，并以多种形式出现。典型的例子包括编码缺陷（鲁棒性）、危害和事故（安全）、漏洞和攻击（网络安全和可生存性）、过度负载（容量）、长寿命（寿命）和通信丢失（互操作性）。

在本系列的第一篇文章中，我将系统韧性定义为系统快速有效地保护其关键能力免受不利事件和条件危害的程度。

第二篇文章确定了以下八个次要质量属性，对可能破坏关键系统的不利因素进行了分类：鲁棒性、安全性（被动）、网络安全（主动）、防篡改、生存性、容量、寿命和互操作性。

第三篇文章涵盖了系统韧性需求的工程设计，以及如何使用它们来推导这些次级质量属性的相关需求。

第四篇文章提出了一个用于分类韧性技术的本体，并澄清了韧性要求和韧性技术之间的关系。

该系列的第五篇文章给出了一个相对全面的韧性技术列表，并用它们执行的韧性功能（即抵抗、检测、反应和恢复）进行了注释。

第六篇文章帮助读者验证系统的架构、设计或实现是否满足其韧性要求以及鲁棒性、安全性、网络安全、防篡改、生存性、容量、寿命和互操作性的次要要求。

第七篇文章亦即本系列最后一篇文章，将前面六篇文章中的信息提取为以下16个指导原则，以帮助系统和软件工程师开发韧性系统。

原则01

专注于关键任务能力

系统通常支持许多功能，这些功能因系统的任务和功能而异。一些能力对系统任务的成功至关重要，而另一些能力可能只起到支持作用，或有避免中断任务的变通办法。类似地，并不是所有与能力相关的需求都是相等的。一些是任务成功所必需的，而另一些则不是。

系统韧性的目标是确保关键任务能力不会因不利条件和事件而中断。实现这一目标是为什么识别和理解任务关键能力是设计韧性系统的起点。

原则02

识别关键资产

每个关键任务功能都是由相关的关键资产实现的，包括系统组件、系统数据和潜在的系统外部数据源/接收器（例如，外部系统和外部数据库）以及将系统连接到这些数据源/接收器的外部网络。为了保护关键任务能力免受干扰，工程师必须保护相关的关键资产，这就是为什么识别关键任务能力所依赖的关键资产非常重要。

原则03

专注于共同关键资产

单个关键资产通常支持多个关键任务能力。因此，未能保护这些通用关键资产可能会导致多个关键任务能力的中断。避免这些中断是韧性工程应专注于公共关键资产（如共享服务/组件、网络和数据存储库）的原因。

原则04

专注于破坏性伤害

不利条件和事件会以多种方式损害关键资产。然而，某些条件或事件可能不会中断任务关键能力。因此，韧性工程应专注于破坏任务关键能力的危害。

原则05

期待逆境

许多不利因素是不可避免的，特别是在当今动荡的网络环境中。因此，韧性工程活动应基于存在不利条件和将发生不利事件的假设。

原则06

考虑所有类型的逆境

这种考虑应包括不利条件和不利事件，以及与所有八个次要质量属性相关的不利因素：鲁棒性、安全性（被动）、网络安全性（主动）、防篡改性、生存性、容量、寿命和互操作性。通常，系统韧性专注于单个质量属性（特别是鲁棒性、被动安全性或主动安全性），因为系统韧性需求主要由个体可靠性、安全或安全工程师驱动。

原则07

假设多重逆境

逆境并不总是孤立地发生，可能会相互影响。有时，它们同时发生或快速连续发生。不利条件的存在通常会导致相关的不良事件。大多数事故都是由一连串的逆境或逆境网络造成的。例如，网络安全攻击可能会导致导致事故的故障或失效。类似地，事故可能会产生一个漏洞，使网络安全攻击能够成功。

原则08

预计逆境随时间变化

逆境随时间而变化。此外，新的不利因素（例如新的安全威胁和漏洞）经常被发现。维护和更新系统通常会改变逆境的发生概率和负面后果。因此，韧性工程从未完成，而是一项长期的活动。

原则09

识别并优先处理潜在逆境

为了防止任务关键能力中断，必须保护系统免受大量潜在不利条件和事件的影响。必须识别和理解潜在的不利因素。然而，潜在不利因素的数量通常很大，以至于在实践中只能解决一个子集。风险分析通常用于根据这些不利情况的发生概率和它们可能造成的危害程度来对其进行优先级排序。

原则10

抵御逆境

通常可以对系统进行架构、设计和实现，以抵御某些不利因素，例如，被动地防止这些不利因素干扰任务关键能力。这种被动抵抗有时比主动检测、反应和恢复相同不利因素的韧性技术更有效（甚至不需要）。另一方面，纵深防御可能导致使用被动和主动复原技术来保护关键任务能力免受相同的不利影响。

原则11

检测逆境

要对逆境做出反应并从中恢复，首先必须检测到它们。该步骤不仅包括检测不良事件，还包括检测不良条件，以便相关反应可以防止相关不良事件。

一些朋友可能认为，规定反应和回收的要求就足够了，检测被理解为必要的（即检测要求可能源自反应或回收要求）。然而，单独调用检测增加了识别适当的检测技术并将其纳入系统的可能性。

原则12

应对逆境

明确“应对逆境”和“从逆境中恢复”之间的区别很重要。在可行的情况下，通过阻止逆境损害关键资产来做出反应。该反应可能在完全或部分恢复之前发生。所以，一个系统应该包括对逆境做出反应的韧性技术，以最大限度地减少它们可能造成的中断的持续时间和范围。

原则13

从逆境中恢复

在系统对逆境做出反应之后——并且没有对关键资产造成进一步的伤害——从中断任务关键能力的伤害中完全（或至少部分）恢复很重要。然而，根据造成的危害和系统的位置（例如火星探测车上的车轮电机故障），实现这一目标可能不现实，甚至也不可能。

原则14

假设组件有故障、失效或受损

如果在系统更新过程中未及时更换或消除，所有系统组件最终都会出现故障。正如我在前一篇关于验证和验证的博客文章中所讨论的，测试永远不会是穷尽的。因此，可以安全地假设软件（通常实现系统的大多数功能）具有一定程度的潜在缺陷，这些缺陷可能会中断系统的功能。组件可靠性的缺乏会影响韧性和可用性。

原则15

比起手动韧性更喜欢自主韧性

重要的是限制任务关键能力的任何中断的持续时间。因此，由于与自动韧性技术的响应时间相比，人类的反应时间相对较长，因此自主韧性通常优于手动韧性。此外，由于位置原因（例如在卫星和行星探测器和火星“漫游者”），并不总是可能包括人类的检测、反应和恢复。

另一方面，人类和自动恢复技术通常有不同的最佳点，因此，在可行的情况下，应结合自动恢复技术和人类监督。

原则16

平衡分层防御和复杂性

当避免任务关键能力中断至关重要时，通常使用分层深度防御。然而，每一种额外的韧性技术都会增加系统复杂性，而过多的复杂性反而会降低韧性。因此，韧性工程必须平衡韧性技术的数量和类型与它们增加到系统架构、设计和实现中的复杂性。

17总结与展望

系统韧性是大多数系统的基本质量属性，特别是那些对被动安全、主动安全以及业务至关重要的系统。我在这一系列文章中的目标是强调系统韧性的重要性，并为读者提供该主题的相对完整的概述。

在这一系列的7篇文章中，我概述了什么是系统韧性，它与其他质量属性的关系，以及它对需求、架构和验证（特别是测试）的影响。从概念模型开始，本系列确定了不同类型的韧性相关需求、用于提高韧性的许多架构和设计技术，以及用于验证系统充分处理逆境的程度的相关测试技术。

希望所有系统利益相关者能获取有用的信息，并为当下以及未来的关键系统开发工作提供实际指导。

截至2020年退休，我个人在美国软件工程研究所（SEI）已经工作了17个年头，整个职业生涯更是做了40多年的系统和软件工程师。我以SEI技术说明的形式完成了这七篇系统韧性文章，这是该系列的最后一篇文章，希望能对诸位有所帮助。

我们江湖再见。