网站理念,中文企业网站设计欣赏,互联网创业项目拒绝割韭菜,建筑公司会计做账及报税流程不良事件和条件可能会中断系统#xff0c;导致系统无法提供必要的功能和服务。正如我在本系列的前几篇文章中所概述的那样#xff0c;韧性是大多数系统的一个基本质量属性#xff0c;因为它们提供了关键的能力和服务#xff0c;尽管存在着不可避免的困难#xff0c;但这些… 不良事件和条件可能会中断系统导致系统无法提供必要的功能和服务。正如我在本系列的前几篇文章中所概述的那样韧性是大多数系统的一个基本质量属性因为它们提供了关键的能力和服务尽管存在着不可避免的困难但这些能力和服务必须继续。这些逆境通常是不可避免的并以多种形式出现。典型的例子包括编码缺陷鲁棒性、危害和事故安全、漏洞和攻击网络安全和可生存性、过度负载容量、长寿命寿命和通信丢失互操作性。 在本系列的第一篇文章中我将系统韧性定义为系统快速有效地保护其关键能力免受不利事件和条件危害的程度。 第二篇文章确定了以下八个次要质量属性对可能破坏关键系统的不利因素进行了分类鲁棒性、安全性被动、网络安全主动、防篡改、生存性、容量、寿命和互操作性。 第三篇文章涵盖了系统韧性需求的工程设计以及如何使用它们来推导这些次级质量属性的相关需求。 第四篇文章提出了一个用于分类韧性技术的本体并澄清了韧性要求和韧性技术之间的关系。 该系列的第五篇文章给出了一个相对全面的韧性技术列表并用它们执行的韧性功能即抵抗、检测、反应和恢复进行了注释。 第六篇文章帮助读者验证系统的架构、设计或实现是否满足其韧性要求以及鲁棒性、安全性、网络安全、防篡改、生存性、容量、寿命和互操作性的次要要求。 第七篇文章亦即本系列最后一篇文章将前面六篇文章中的信息提取为以下16个指导原则以帮助系统和软件工程师开发韧性系统。 原则01 专注于关键任务能力 系统通常支持许多功能这些功能因系统的任务和功能而异。一些能力对系统任务的成功至关重要而另一些能力可能只起到支持作用或有避免中断任务的变通办法。类似地并不是所有与能力相关的需求都是相等的。一些是任务成功所必需的而另一些则不是。 系统韧性的目标是确保关键任务能力不会因不利条件和事件而中断。实现这一目标是为什么识别和理解任务关键能力是设计韧性系统的起点。 原则02 识别关键资产 每个关键任务功能都是由相关的关键资产实现的包括系统组件、系统数据和潜在的系统外部数据源/接收器例如外部系统和外部数据库以及将系统连接到这些数据源/接收器的外部网络。为了保护关键任务能力免受干扰工程师必须保护相关的关键资产这就是为什么识别关键任务能力所依赖的关键资产非常重要。 原则03 专注于共同关键资产 单个关键资产通常支持多个关键任务能力。因此未能保护这些通用关键资产可能会导致多个关键任务能力的中断。避免这些中断是韧性工程应专注于公共关键资产如共享服务/组件、网络和数据存储库的原因。 原则04 专注于破坏性伤害 不利条件和事件会以多种方式损害关键资产。然而某些条件或事件可能不会中断任务关键能力。因此韧性工程应专注于破坏任务关键能力的危害。 原则05 期待逆境 许多不利因素是不可避免的特别是在当今动荡的网络环境中。因此韧性工程活动应基于存在不利条件和将发生不利事件的假设。 原则06 考虑所有类型的逆境 这种考虑应包括不利条件和不利事件以及与所有八个次要质量属性相关的不利因素鲁棒性、安全性被动、网络安全性主动、防篡改性、生存性、容量、寿命和互操作性。通常系统韧性专注于单个质量属性特别是鲁棒性、被动安全性或主动安全性因为系统韧性需求主要由个体可靠性、安全或安全工程师驱动。 原则07 假设多重逆境 逆境并不总是孤立地发生可能会相互影响。有时它们同时发生或快速连续发生。不利条件的存在通常会导致相关的不良事件。大多数事故都是由一连串的逆境或逆境网络造成的。例如网络安全攻击可能会导致导致事故的故障或失效。类似地事故可能会产生一个漏洞使网络安全攻击能够成功。 原则08 预计逆境随时间变化 逆境随时间而变化。此外新的不利因素例如新的安全威胁和漏洞经常被发现。维护和更新系统通常会改变逆境的发生概率和负面后果。因此韧性工程从未完成而是一项长期的活动。 原则09 识别并优先处理潜在逆境 为了防止任务关键能力中断必须保护系统免受大量潜在不利条件和事件的影响。必须识别和理解潜在的不利因素。然而潜在不利因素的数量通常很大以至于在实践中只能解决一个子集。风险分析通常用于根据这些不利情况的发生概率和它们可能造成的危害程度来对其进行优先级排序。 原则10 抵御逆境 通常可以对系统进行架构、设计和实现以抵御某些不利因素例如被动地防止这些不利因素干扰任务关键能力。这种被动抵抗有时比主动检测、反应和恢复相同不利因素的韧性技术更有效甚至不需要。另一方面纵深防御可能导致使用被动和主动复原技术来保护关键任务能力免受相同的不利影响。 原则11 检测逆境 要对逆境做出反应并从中恢复首先必须检测到它们。该步骤不仅包括检测不良事件还包括检测不良条件以便相关反应可以防止相关不良事件。 一些朋友可能认为规定反应和回收的要求就足够了检测被理解为必要的即检测要求可能源自反应或回收要求。然而单独调用检测增加了识别适当的检测技术并将其纳入系统的可能性。 原则12 应对逆境 明确“应对逆境”和“从逆境中恢复”之间的区别很重要。在可行的情况下通过阻止逆境损害关键资产来做出反应。该反应可能在完全或部分恢复之前发生。所以一个系统应该包括对逆境做出反应的韧性技术以最大限度地减少它们可能造成的中断的持续时间和范围。 原则13 从逆境中恢复 在系统对逆境做出反应之后——并且没有对关键资产造成进一步的伤害——从中断任务关键能力的伤害中完全或至少部分恢复很重要。然而根据造成的危害和系统的位置例如火星探测车上的车轮电机故障实现这一目标可能不现实甚至也不可能。 原则14 假设组件有故障、失效或受损 如果在系统更新过程中未及时更换或消除所有系统组件最终都会出现故障。正如我在前一篇关于验证和验证的博客文章中所讨论的测试永远不会是穷尽的。因此可以安全地假设软件通常实现系统的大多数功能具有一定程度的潜在缺陷这些缺陷可能会中断系统的功能。组件可靠性的缺乏会影响韧性和可用性。 原则15 比起手动韧性更喜欢自主韧性 重要的是限制任务关键能力的任何中断的持续时间。因此由于与自动韧性技术的响应时间相比人类的反应时间相对较长因此自主韧性通常优于手动韧性。此外由于位置原因例如在卫星和行星探测器和火星“漫游者”并不总是可能包括人类的检测、反应和恢复。 另一方面人类和自动恢复技术通常有不同的最佳点因此在可行的情况下应结合自动恢复技术和人类监督。 原则16 平衡分层防御和复杂性 当避免任务关键能力中断至关重要时通常使用分层深度防御。然而每一种额外的韧性技术都会增加系统复杂性而过多的复杂性反而会降低韧性。因此韧性工程必须平衡韧性技术的数量和类型与它们增加到系统架构、设计和实现中的复杂性。 17总结与展望 系统韧性是大多数系统的基本质量属性特别是那些对被动安全、主动安全以及业务至关重要的系统。我在这一系列文章中的目标是强调系统韧性的重要性并为读者提供该主题的相对完整的概述。 在这一系列的7篇文章中我概述了什么是系统韧性它与其他质量属性的关系以及它对需求、架构和验证特别是测试的影响。从概念模型开始本系列确定了不同类型的韧性相关需求、用于提高韧性的许多架构和设计技术以及用于验证系统充分处理逆境的程度的相关测试技术。 希望所有系统利益相关者能获取有用的信息并为当下以及未来的关键系统开发工作提供实际指导。 截至2020年退休我个人在美国软件工程研究所SEI已经工作了17个年头整个职业生涯更是做了40多年的系统和软件工程师。我以SEI技术说明的形式完成了这七篇系统韧性文章这是该系列的最后一篇文章希望能对诸位有所帮助。 我们江湖再见。