系统韧性研究 | 验证与确认

不良事件和条件可能会中断系统，导致系统无法提供必要的功能和服务。正如我在本系列的前几篇文章中所概述的那样，韧性是大多数系统的一个基本质量属性，因为它们提供了关键的能力和服务，尽管存在不可避免的困难，但这些能力和服务务必继续。

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

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

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

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

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

本文亦即本系列的第六篇文章旨在验证系统的架构、设计或实现是否满足其韧性要求，以及其鲁棒性、被动安全性、主动安全性、防篡改、生存性、容量、寿命和互操作性的次要要求。这八个质量属性涉及不同类型的不利因素，因此它们通常具有特定于属性的验证技术，评估系统的多个韧性技术使其能够：①被动抵抗；②主动检测；③主动响应；④从不利条件和事件以及它们造成的中断中主动恢复的程度。

验证通常以下列四种方式之一执行：

检查涉及对系统、其组件子系统及其工程文件的目视检查。它可能是相对非正式的，仅基于执行检查的利益相关者/专家的经验。它还可能涉及使用各种设备进行测量，以及使用各种技术（例如超声波、X射线和显微镜）来增强肉眼。

分析涉及使用基于数据和其他证据的建模、分析技术和计算，以验证架构（architecture）或设计在实施后是否满足需求。可以手动执行分析，也可以使用分析工具执行分析。分析也可以是动态的或静态的（即无论是否执行模型或模拟）。分析也可以是定性的或定量的。

演示涉及执行已实现的系统，以表明它满足其要求。演示可以是系统或其子系统的原型或各种（可能是部分）版本。

测试涉及使用已知输入并在已知前提条件下执行已实现的系统或其组件子系统，以确定其行为（即输出和后置条件）是否满足其所需/预期行为。演示和测试之间的一个主要区别是，演示试图显示系统正常工作，而测试试图识别系统不正常的情况。

01检查

目视检查包括审核、桌面校验、检查、演练，以及系统及其相关技术文档的正式和非正式技术审查。具体来说，检查专注于韧性技术。执行检查的利益相关者/专家确定系统的韧性技术使其能够克服逆境和其基本能力的任何相关中断的程度。检查与韧性的所有八个次级质量属性相关。可以检查（审计）系统及其架构和设计，以评估所选韧性技术是否已实际纳入系统，是否正确实施，以及在适当情况下是否正确配置。

02分析

分析用于识别潜在的不利因素，并估计系统被动抵抗和主动检测、反应和从不利因素中恢复的能力。可以应用多种分析技术来分析系统的韧性和从属质量属性：

• 韧性。保证（韧性）案例和置信图。包含系统韧性保证案例的论点可以由包含相关八个从属质量属性（即鲁棒性、安全性、安全等）的保证案例的论据组成。
• 鲁棒性。保证（鲁棒性）情况、平均无故障时间（MTBCF）分析/预测和平均修复时间（MTTR）分析/预计。
• 被动安全性。基于系统理论事故模型和过程（STAMP）的保证（安全）案例、危险分析、故障模式、影响和关键性分析（FMECA）、故障树分析（FTA）、危险和可操作性研究（HAZOP）和系统理论过程分析（STPA）。
• 主动安全性。保障（安全）案例、攻击树分析、攻击面分析、滥用案例/误用案例、流量分析、病毒扫描和漏洞/弱点扫描。
• 篡改。保证（篡改）案例。
• 生存能力。保证（生存能力）案例、隐身/可探测性分析和损伤分析。
• 容量。保证（容量）案例、带宽分析和结构分析。
• 长寿。保证（寿命）案例、剩余使用寿命（RUL）评估和预测。
• 互操作性。保证（互操作性）案例和协议分析（即自动动态网络/总线流量分析）。

03演示

演示可以非正式地向利益相关者展示，所实施的系统韧性技术可以正确地工作，以提高系统对特定逆境的韧性，从而使系统在没有不可接受的干扰的情况下继续提供关键功能/服务。演示是一种相对较弱的验证方法，因为它通常用于在有限的、通常是标称的情况下演示正确的功能。在实践中很少使用它来证明在非正常情况下（例如逆境）的正确功能。测试通常是一种更强大的验证技术，因为它专注于对被测系统施加压力，以试图发现可能导致故障的缺陷、弱点和漏洞，比如，由于不利因素而中断关键服务。

04测试

系统韧性测试不是验证系统在正常情况下是否正常运行。相反，这种类型的测试主要是为了验证系统在面对逆境时是否真正具有韧性。在韧性测试中，测试人员通过引起不利因素来确定系统的反应。

系统韧性测试主要分为三类：

• 基于需求的黑盒测试。当测试人员在系统运行期间造成（或模拟）不利情况时，系统是否继续提供基本服务？请注意，这试图引发外部可见的故障，但不包括发现可能最终（例如，在测试后）导致可见故障的隐藏故障。这些黑盒测试旨在验证系统是否充分抵抗、检测、响应和从从属质量属性特定的不利条件和事件中恢复。
• 基于架构的白盒测试。系统的韧性技术是否正确实施和配置？这些韧性技术是否有效（即它们是否使系统能够继续提供基本能力）？
• 灰盒测试。以下问题通常可以使用黑盒测试、白盒测试或两者的组合（即灰盒测试）来回答。测试用例的选择可以取决于理解韧性技术的实现如何与其他组件以及彼此交互。

主动韧性技术是否检测逆境，做出相应的反应，并使系统能够在事后恢复？请注意，恢复测试是一种特殊形式的韧性测试，用于验证恢复是否成功。

当多种技术必须协同工作以提供韧性时（例如冗余和投票），它们是否正确地协同工作，以提高韧性？

当结合多层韧性技术以实现深度防御时，当初始技术无法实现其预期结果时，后续技术是否接管？

当面临各种类型的逆境时，应对多种逆境有效的韧性技巧是否有效地防止或减轻中断？

以下列表可用于选择用于根据与所考虑的相关类型的不利因素相关联的八个次级质量属性来验证系统韧性的测试类型：

• 鲁棒性。边界值测试、内置测试、Chaos Monkey测试（Chaos Gorilla、Conformity Monkey、Doctor Monkey、Janitor Monkey、Latency Monkey、Security Monkey和10-18 Monkey测试）、破坏性测试、环境测试（包括加速度、声学、 电力、电磁兼容性、跌落、静水压、压力/泄漏、辐射、冲击、温度、拉伸、真空和振动容限测试）、错误播种、故障转移测试、基于故障的测试、故障注入测试、模糊测试、突变测试 、负面测试、性能测试（逆境期间/之后）、开机和关机测试、随机测试（包括Cat on the Keyboard测试、Shoe on the keyboard测试和Stuck Key测试）、恢复测试和冒烟测试。
• 被动安全性。碰撞测试、故障安全测试、基于危险的测试和基于模拟的测试。
• 主动安全性。通信安全（COMSEC）测试、发射安全（EMSEC）试验、故障安全测试、模糊测试和渗透测试。
• 篡改。远程篡改测试（渗透测试的一种特殊类型）。
• 生存能力。实弹射击测试和隐身可探测性测试。
• 容量。负载测试、性能测试（逆境期间/之后）、压力测试和容量测试。
• 长寿。加速寿命试验、高加速寿命试验（HALT）和浸泡试验（又名耐久性和稳定性试验）。
• 互操作性。互操作性测试、（自动）网络协议测试、协议测试和协议一致性测试。

05验证系统韧性的挑战

以下是系统和软件工程师在验证系统韧性时面临的一些关键挑战：

要求。系统韧性处理相对罕见的逆境和中断。因此，应该驱动测试的相关质量属性要求可能被忽略，因此不存在。与系统韧性相关的需求可能分散在多个需求规范和需求规范中的多个部分中，这使得它们很难识别，特别是在具有大量需求的大型复杂项目中。

架构和设计。韧性测试人员需要访问可能分散在文档、图表和模型中的相关架构文档。确定韧性技术的相关文件可能不存在。

所需的专业知识。验证系统韧性需要获得专业（例如，鲁棒性、被动安全性、主动（网络）安全性和生存性）工程专业知识，这可能很难获得。它还需要硬件和软件专业知识，因为：①逆境可能导致硬件和软件故障；②许多韧性技术涉及硬件和软件的组合。

特殊类型的测试。需要但不限于专门形式的测试，如网络攻击的渗透测试、过度负载（容量）的压力测试和过度寿命（寿命）的加速寿命测试。

逆境造成的困难。不利条件和事件通常很难引起或模拟。

重视不够。测试的自然趋势是专注于验证标称操作，几乎没有时间测试相对罕见的不利条件和事件。

逆境发生时机。中断可能在不同的时间产生：当不利条件开始时，在不利条件期间，以及当不利条件导致不利事件时。对于硬实时系统，测试人员必须意识到时间问题（如行动计划），并确定逆境发生的时间是否对韧性产生负面影响。

操作系统。可能无法在实际操作系统上进行测试，因为韧性测试试图导致基本能力的中断，这可能会导致重大或灾难性的负面结果。在具有大量备用容量的云环境中进行韧性测试在韧性非常有限的嵌入式系统中可能完全不切实际。

多对多映射。不同类型的不同逆境（即不同的次要质量属性）可以导致相同类型的中断，而单一类型的逆境可以导致多种类型的中断。

层叠的逆境和破坏。逆境可以导致多个故障和失效的级联网络，因此这种级联可以涉及多个从属质量属性。例如，网络攻击（主动安全性）可能导致导致事故（被动安全性）的危险，这可能导致故障和失效（鲁棒性）。为了确定中断的真实范围，测试人员需要允许故障和失败发生，而不是在出现问题的第一个迹象时停止测试。

被动安全性。由于危险和事故相关的危险，安全测试通常不涉及实际系统的硬件。相反，通常模拟硬件和外部环境。这些模拟的行为以及实际硬件和环境中的任何偏差都可能导致测试产生假阳性和假阴性结果。

韧性验证可识别问题，这些问题在修复后会增加系统对试图中断关键功能的逆境的韧性。

通过系统韧性验证发现的缺陷和弱点，特别是通过测试发现的缺陷，提高了整个组织对专注于韧性的需求的认识。

生产系统的韧性测试确保没有人变得自满。这反过来又鼓励通过需求和架构（韧性技术）将韧性构建到系统中。

在验证过程中，潜在中断的日期和时间是预先确定的，以便可以进行适当的准备，并且人员准备在问题发生时立即介入并解决问题，从而将任何由此产生的中断的影响降至最低。

由于逆境很可能是罕见的事件，因此处理它们的软件的质量可能低于在标称条件下提供基本功能的软件。因此，它可能隐藏比平均水平更多的缺陷。韧性测试专注于需求、架构、设计和实现缺陷倾向于聚集的地方。

所有开发/测试团队都应该使用相同的工具来注入不利因素和监视/记录服务中断。

对于24x7系统，验证检测、反应和恢复是否自动。

重点监控可能导致中断的任何灾难之前、期间和之后的系统数据。

在可行的情况下，对生产系统执行系统韧性测试，因为它将迫使开发人员在需求、架构、设计、实现和测试期间注意韧性。

绘制不利条件和事件期间的响应时间。

06系统韧性验证的好处

韧性验证可识别问题，这些问题在修复后会增加系统对试图中断关键功能的逆境的韧性。

通过系统韧性验证发现的缺陷和弱点，特别是通过测试发现的缺陷，提高了整个组织对专注于韧性的需求的认识。

生产系统的韧性测试确保没有人变得自满。这反过来又鼓励通过需求和架构（韧性技术）将韧性构建到系统中。

在验证过程中，潜在中断的日期和时间是预先确定的，以便可以进行适当的准备，并且人员准备在问题发生时立即介入并解决问题，从而将任何由此产生的中断的影响降至最低。

由于逆境很可能是罕见的事件，因此处理它们的软件的质量可能低于在标称条件下提供基本功能的软件。因此，它可能隐藏比平均水平更多的缺陷。韧性测试专注于需求、架构、设计和实现缺陷倾向于聚集的地方。

07改进系统韧性验证的建议

所有开发/测试团队都应该使用相同的工具来注入不利因素和监视/记录服务中断。

对于24x7系统，验证检测、反应和恢复是否自动。

重点监控可能导致中断的任何灾难之前、期间和之后的系统数据。

在可行的情况下，对生产系统执行系统韧性测试，因为它将迫使开发人员在需求、架构、设计、实现和测试期间关注到韧性。

绘制不利条件和事件期间的响应时间。

08总结与预告

这篇文章提供了各种技术来验证系统充分处理逆境的程度，从而抵抗、检测、响应和从其关键能力的中断中恢复。

本系列的第七篇也是最后一篇文章将以工程韧性系统的15条指导原则的形式总结本系列的关键要点。

敬请期待。