从最基本的层面上说，系统韧性指的是系统在逆境中继续执行其任务的程度。虽然对操作连续性至关重要，但系统的服务（能力）只是系统继续执行其任务所必须保护的一些资产。该系统必须检测不利因素，对其作出反应，并从它们对关键资产造成的损害中恢复过来。因此，更深层次的系统韧性是指系统快速有效地保护自身及其连续性相关资产免受不利事件和条件造成的损害的程度。

正如我在本系列的第一篇文章中提到的，系统韧性可以分解为两个子类型：主动韧性和被动韧性。主动系统韧性要求系统检测不利事件和条件，相应地做出反应，以防止或最大限度地减少任何由此产生的中断，并从这种中断中恢复。另一方面，如果系统被过度设计以被动避免中断（例如，通过具有足够的容量，过度负载不会导致性能损失或降级），则可以实现被动系统韧性。如本系列第一篇文章的初始图所示，系统韧性可以是被动的，也可以是主动的，即被动韧性被动地抵御逆境，而主动韧性主动地检测、应对逆境并从逆境中恢复。这种区别可以用于对规定阻力、检测、反应和恢复的韧性要求进行分类。

在本系列的第二篇文章中，我探索了系统韧性如何与其他质量属性密切相关，特别是鲁棒性、安全性、网络安全性、防篡改性、生存性、容量、寿命和互操作性。在第三篇文章中，我将阐述系统韧性需求，这些需求推动选择架构、设计和实现功能（例如，保障、安全控制和韧性相关的模式和习惯用法），以实现所需类型和级别的韧性。

01

系统韧性和次要质量属性要求

系统韧性要求规定了系统通过检测、响应和响应不利事件和条件，在面对不利情况时继续提供系统能力的程度。如下表所示，韧性系统必须克服的逆境类型根据其相关的从属质量属性进行分类。

鉴于系统韧性和上述从属质量属性之间的密切关系，一个自然的问题是，系统韧性要求与其他相关质量属性要求（如鲁棒性、安全性、网络安全和类似要求）有何不同？例如，以下是韧性要求还是鲁棒性（容错）要求：

当子系统Y中发生故障（不良事件）时，系统应继续提供服务X，可能处于降级模式。

以下是系统韧性要求还是安全要求：

汽车应检测到黑冰（即公路冰层，代指危险-不利条件），并通过修改牵引力控制来做出反应，以保持足够的牵引力，防止失去转向控制（服务）和由此产生的交通事故（对关键资产的伤害）。

同理，以下是韧性要求还是网络安全要求：

当威胁参与者在系统外部防火墙之外实现未经授权的访问（不良事件）时，系统应继续提供功能X。

关于与防篡改（例如，试图远程访问关键程序信息）、生存能力（例如，检测敌方雷达或导弹锁定等威胁）、容量（例如，系统接近或超过其最大容量）和寿命（例如，接近或超过设计寿命的系统组件）相关的不利因素，可以指定类似的要求。

02

都有哪些类型的要求？

关于韧性要求与其他质量属性要求的重叠，有三种学派：

方法1：无重叠

下图说明了系统韧性需求的MITRE方法。如果需求规定系统在面临特定逆境时应保持特定能力的特定水平，则该需求是系统韧性需求（由灰色框指示）。这些特定的逆境包括与质量属性相关的逆境：鲁棒性、安全性、网络安全等。系统韧性要求包括防止（也称为避免）逆境、被动抵抗逆境以及主动检测逆境的存在、对检测到的逆境做出反应以及从逆境造成的伤害中恢复的要求。系统韧性需求不包括与在逆境中维护特定能力无关的次要质量属性的需求（即下图的底行）。

方法1-系统韧性和次级需求之间没有重叠

第一种方法基本上表明，一些鲁棒性要求实际上是韧性要求，而不是鲁棒性要求，一些安全要求实际上是依赖性要求，而非安全要求，等等。除了造成混淆外，这种方法还使专业（如可靠性、安全性和安防）工程师更难找到与他们相关的所有需求，这些需求都放在需求规范的相关质量属性特定部分中。它还包括预防（也称为避免），这在逻辑上不属于恢复力的范围。

方法2：双重需求类型

第二种方法是使需求同时既是韧性需求又是从属质量属性需求。下图通过灰色框来说明这一点，灰色框表示韧性和次要质量属性需求。具体来说，由灰色框表示的每个阻力、检测、反应和恢复要求同时是系统韧性要求和从属质量属性（例如鲁棒性、安全性或网络安全）要求。

方法2-同时韧性和次要质量属性要求

这种重叠的方法可能会导致混淆。它还存在冗余规范的问题，这使得确保需求具有唯一的需求ID和将需求跟踪到测试（例如容量、鲁棒性、安全性、安全和互操作性测试）变得更加困难。然而，如果每个需求在需求数据库中仅存储一次，每个需求都用相关的质量属性进行注释，并且专业工程师可以根据其专业知识和职责领域过滤需求，则可以在一定程度上克服此问题。

方法3：衍生需求

下图说明了第三种方法，其中高级系统韧性需求（灰色框）与较低级别、衍生的次要质量属性需求（白色框）分开。这种需求分离将系统韧性需求保持在非常高的抽象级别，以至于它们忽略了质量属性特定的不利因素。例如，以下是这种系统韧性要求的示例：

系统应继续为任务关键能力C提供关键性能参数KPP，概率至少为P，尽管存在所有已识别的潜在不利因素。

一旦需求工程师指定了高级韧性需求，他们就会从这些韧性需求中衍生出多个次要质量属性需求。它们根据与鲁棒性、安全性、网络安全等相关的特定不良事件和条件来规定这些衍生要求。

方法3-衍生次要质量属性需求

第三种方法清楚地将韧性需求与其次要质量属性需求区分开来，将韧性需求保持在利益相关者关注的级别，并支持较低级别质量需求的衍生。请注意，与将性能需求分配给多个架构（architecture）组件一样，韧性KPP级别必须分解并分配给相关的派生次要质量属性需求。

03

需求工程（Engineering）过程

我建议使用以下过程（基于上述第三种方法），首先制定高水平的韧性要求，然后推导相应的低水平、特定于逆境的质量属性要求：

1.识别风险资产。在不利条件或事件发生时，哪些关键系统功能（即服务）必须继续提供？如果系统架构已知，则需要哪些关键系统组件（如子系统、硬件和软件）来提供这些功能和服务？类似地，在可用性、机密性和完整性方面必须保护哪些关键系统数据？系统服务是否依赖于任何系统外部资产，系统是否负责这些资产？

2.确定潜在危害。逆境会对这些关键资产造成何种危害，从而导致关键系统功能或服务的损失或降级？

3.确定最大可接受危害。逆境可能对维护关键能力和服务所需的资产造成的最大可接受伤害量是多少？对于功能和服务，请考虑设置以下类型的限制：

对服务/能力相关资产的最大可接受危害：

• 服务/功能降级的最大可接受水平·在逆境期间和恢复之前，服务/能力的最低可接受可用性
• 在逆境中和恢复之前，服务/能力的最低可接受可靠性
• 交付服务/能力所需的对资产的最大可接受损害

服务/能力相关资产的最大可接受损害持续时间（见下图）：

• 可接受的最长不利条件/事件检测时间（检测逆境所需）
• 最大可接受反应开始时间（检测和反应之间的时间，以防止进一步伤害）
• 最大可接受反应持续时间（完成反应以阻止进一步伤害所需的时间）
• 最大可接受恢复持续时间（反应完成到恢复完成之间的时间）
• 服务/能力损失/降级的最大可接受持续时间

能力和服务降级可以根据性能下降来衡量，并可能取决于操作模式（例如操作、培训、演习、维护和更新）。

4.优先考虑资产和危害。在所有可信的情况下，很少有足够的资源来确保足够的复原力。因此，必须根据资产和相关损害的优先顺序来限制分析。

5.制定相关的韧性要求。基于对关键资产的最大可接受危害，开发高级别系统韧性需求。高水平韧性要求的示例模板（括号中包含可选条款）包括：

顶级韧性要求：

• 「当处于模式M」时，系统应在不利条件持续期间，以至少P的概率，继续提供可用性为a的能力C「最大降级为D」。
• 「当处于模式M」时，系统应在不良事件发生后，以至少P的概率继续提供可用性为a的能力C「最大降级为D」。
• 「当处于模式M」时，系统应在不利条件下以至少P的概率继续提供可靠性为R的能力C「最大降级为D」。

检测韧性要求：

• 「当处于模式M」时，系统应在S秒/毫秒内检测到不良事件和条件的P%。
• 「在模式M」下，系统应在S秒/毫秒内检测能力C的丢失/降级。

反应韧性要求：

• 在检测到不利条件「在模式M」时，系统应在S秒/毫秒内限制容量C的进一步损失或降级。

恢复韧性要求：

• 「当处于模式M」时，系统应在检测不良事件和条件的S秒/毫秒内恢复能力C，概率至少为P。

6.确定相关的不利因素。哪些类型的不利条件和事件会导致不可接受的关键服务和能力丢失或显著降级？对于每个次要质量属性，考虑可能损害韧性相关关键资产的不良事件和条件的相关类型。

7.优先考虑可信的逆境。由于在所有可信的情况下，很少有足够的资源来确保足够的韧性，因此，需求分析必须基于造成危害的逆境的优先顺序进行限制。

8.衍生相关的质量属性需求。使用优先化的逆境，从韧性要求中导出特定于逆境的下属质量属性要求，以达到适当的质量属性。

04

衍生需求

顶级系统韧性需求可用于导出组件级和数据级韧性需求，以及导出次要质量属性需求。以下是韧性要求和相关衍生要求的示例：

系统韧性要求：

• 检测要求：系统应在5秒内检测能力C的重大中断（即，超过30%的总损失或退化）。
• 反应要求：在检测到性能C下降超过15%时，系统应采取足够的步骤，确保性能C的下降不超过30%。
• 恢复要求：在检测到能力C的重大中断时，系统应在2分钟内自动恢复全部能力，概率为99.5%。

组件X韧性要求：

• 检测要求：系统应在500毫秒内检测子系统X的故障，该故障需要提供能力Y。
• 反应要求：在检测到子系统X的故障时，该故障会中断性能Y，系统应采取足够的步骤，以确保该故障不会使性能Y降低30%以上。
• 恢复要求：系统应在检测到导致性能Y严重中断的故障后1分钟内自主恢复子系统X。

次要质量要求：

• 反应能力要求：在检测到将事务T的吞吐量降低到每秒20000以下的过度负载时，系统应增加服务器数量，以确保吞吐量不低于每秒18000。

许多不同的可信不良事件和条件可能会破坏相同的关键系统能力。其中一些逆境彼此独立，概率很低，以至于人们可以合理地忽略这些逆境同时发生的可能性。另一方面，其他不利因素可能有共同的原因，或者有足够高的概率必须考虑同时发生。

05

总结与预告

本文阐述了不同类型的系统韧性需求，以及它们如何与派生的次要质量属性需求相关，并提供了一个通用过程，即系统韧性如何与其他密切相关的质量属性相关。下一篇亦即本系列的第四篇文章将介绍支持不良事件和条件的检测、反应和恢复的韧性功能（例如鲁棒性模式、保障和安全控制）。

敬请期待。