不良事件和條件可能會中斷系統，導致系統無法提供必要的功能和服務。正如我在本系列的前幾篇文章中所概述的那樣，韌性是大多數系統的一個基本質量屬性，因為它們提供了關鍵的能力和服務，盡管存在著不可避免的困難，但這些能力和服務必須繼續。這些逆境通常是不可避免的，并以多種形式出現。典型的例子包括編碼缺陷（魯棒性）、危害和事故（安全）、漏洞和攻擊（網絡安全和可生存性）、過度負載（容量）、長壽命（壽命）和通信丟失（互操作性）。

在本系列的第一篇文章中，我將系統韌性定義為系統快速有效地保護其關鍵能力免受不利事件和條件危害的程度。

第二篇文章確定了以下八個次要質量屬性，對可能破壞關鍵系統的不利因素進行了分類：魯棒性、安全性（被動）、網絡安全（主動）、防篡改、生存性、容量、壽命和互操作性。

第三篇文章涵蓋了系統韌性需求的工程設計，以及如何使用它們來推導這些次級質量屬性的相關需求。

第四篇文章提出了一個用于分類韌性技術的本體，并澄清了韌性要求和韌性技術之間的關系。

該系列的第五篇文章給出了一個相對全面的韌性技術列表，并用它們執行的韌性功能（即抵抗、檢測、反應和恢復）進行了注釋。

第六篇文章幫助讀者驗證系統的架構、設計或實現是否滿足其韌性要求以及魯棒性、安全性、網絡安全、防篡改、生存性、容量、壽命和互操作性的次要要求。

第七篇文章亦即本系列最后一篇文章，將前面六篇文章中的信息提取為以下16個指導原則，以幫助系統和軟件工程師開發韌性系統。

原則01

專注于關鍵任務能力

系統通常支持許多功能，這些功能因系統的任務和功能而異。一些能力對系統任務的成功至關重要，而另一些能力可能只起到支持作用，或有避免中斷任務的變通辦法。類似地，并不是所有與能力相關的需求都是相等的。一些是任務成功所必需的，而另一些則不是。

系統韌性的目標是確保關鍵任務能力不會因不利條件和事件而中斷。實現這一目標是為什么識別和理解任務關鍵能力是設計韌性系統的起點。

原則02

識別關鍵資產

每個關鍵任務功能都是由相關的關鍵資產實現的，包括系統組件、系統數據和潛在的系統外部數據源/接收器（例如，外部系統和外部數據庫）以及將系統連接到這些數據源/接收器的外部網絡。為了保護關鍵任務能力免受干擾，工程師必須保護相關的關鍵資產，這就是為什么識別關鍵任務能力所依賴的關鍵資產非常重要。

原則03

專注于共同關鍵資產

單個關鍵資產通常支持多個關鍵任務能力。因此，未能保護這些通用關鍵資產可能會導致多個關鍵任務能力的中斷。避免這些中斷是韌性工程應專注于公共關鍵資產（如共享服務/組件、網絡和數據存儲庫）的原因。

原則04

專注于破壞性傷害

不利條件和事件會以多種方式損害關鍵資產。然而，某些條件或事件可能不會中斷任務關鍵能力。因此，韌性工程應專注于破壞任務關鍵能力的危害。

原則05

期待逆境

許多不利因素是不可避免的，特別是在當今動蕩的網絡環境中。因此，韌性工程活動應基于存在不利條件和將發生不利事件的假設。

原則06

考慮所有類型的逆境

這種考慮應包括不利條件和不利事件，以及與所有八個次要質量屬性相關的不利因素：魯棒性、安全性（被動）、網絡安全性（主動）、防篡改性、生存性、容量、壽命和互操作性。通常，系統韌性專注于單個質量屬性（特別是魯棒性、被動安全性或主動安全性），因為系統韌性需求主要由個體可靠性、安全或安全工程師驅動。

原則07

假設多重逆境

逆境并不總是孤立地發生，可能會相互影響。有時，它們同時發生或快速連續發生。不利條件的存在通常會導致相關的不良事件。大多數事故都是由一連串的逆境或逆境網絡造成的。例如，網絡安全攻擊可能會導致導致事故的故障或失效。類似地，事故可能會產生一個漏洞，使網絡安全攻擊能夠成功。

原則08

預計逆境隨時間變化

逆境隨時間而變化。此外，新的不利因素（例如新的安全威脅和漏洞）經常被發現。維護和更新系統通常會改變逆境的發生概率和負面后果。因此，韌性工程從未完成，而是一項長期的活動。

原則09

識別并優先處理潛在逆境

為了防止任務關鍵能力中斷，必須保護系統免受大量潛在不利條件和事件的影響。必須識別和理解潛在的不利因素。然而，潛在不利因素的數量通常很大，以至于在實踐中只能解決一個子集。風險分析通常用于根據這些不利情況的發生概率和它們可能造成的危害程度來對其進行優先級排序。

原則10

抵御逆境

通常可以對系統進行架構、設計和實現，以抵御某些不利因素，例如，被動地防止這些不利因素干擾任務關鍵能力。這種被動抵抗有時比主動檢測、反應和恢復相同不利因素的韌性技術更有效（甚至不需要）。另一方面，縱深防御可能導致使用被動和主動復原技術來保護關鍵任務能力免受相同的不利影響。

原則11

檢測逆境

要對逆境做出反應并從中恢復，首先必須檢測到它們。該步驟不僅包括檢測不良事件，還包括檢測不良條件，以便相關反應可以防止相關不良事件。

一些朋友可能認為，規定反應和回收的要求就足夠了，檢測被理解為必要的（即檢測要求可能源自反應或回收要求）。然而，單獨調用檢測增加了識別適當的檢測技術并將其納入系統的可能性。

原則12

應對逆境

明確“應對逆境”和“從逆境中恢復”之間的區別很重要。在可行的情況下，通過阻止逆境損害關鍵資產來做出反應。該反應可能在完全或部分恢復之前發生。所以，一個系統應該包括對逆境做出反應的韌性技術，以最大限度地減少它們可能造成的中斷的持續時間和范圍。

原則13

從逆境中恢復

在系統對逆境做出反應之后——并且沒有對關鍵資產造成進一步的傷害——從中斷任務關鍵能力的傷害中完全（或至少部分）恢復很重要。然而，根據造成的危害和系統的位置（例如火星探測車上的車輪電機故障），實現這一目標可能不現實，甚至也不可能。

原則14

假設組件有故障、失效或受損

如果在系統更新過程中未及時更換或消除，所有系統組件最終都會出現故障。正如我在前一篇關于驗證和驗證的博客文章中所討論的，測試永遠不會是窮盡的。因此，可以安全地假設軟件（通常實現系統的大多數功能）具有一定程度的潛在缺陷，這些缺陷可能會中斷系統的功能。組件可靠性的缺乏會影響韌性和可用性。

原則15

比起手動韌性更喜歡自主韌性

重要的是限制任務關鍵能力的任何中斷的持續時間。因此，由于與自動韌性技術的響應時間相比，人類的反應時間相對較長，因此自主韌性通常優于手動韌性。此外，由于位置原因（例如在衛星和行星探測器和火星“漫游者”），并不總是可能包括人類的檢測、反應和恢復。

另一方面，人類和自動恢復技術通常有不同的最佳點，因此，在可行的情況下，應結合自動恢復技術和人類監督。

原則16

平衡分層防御和復雜性

當避免任務關鍵能力中斷至關重要時，通常使用分層深度防御。然而，每一種額外的韌性技術都會增加系統復雜性，而過多的復雜性反而會降低韌性。因此，韌性工程必須平衡韌性技術的數量和類型與它們增加到系統架構、設計和實現中的復雜性。

17總結與展望

系統韌性是大多數系統的基本質量屬性，特別是那些對被動安全、主動安全以及業務至關重要的系統。我在這一系列文章中的目標是強調系統韌性的重要性，并為讀者提供該主題的相對完整的概述。

在這一系列的7篇文章中，我概述了什么是系統韌性，它與其他質量屬性的關系，以及它對需求、架構和驗證（特別是測試）的影響。從概念模型開始，本系列確定了不同類型的韌性相關需求、用于提高韌性的許多架構和設計技術，以及用于驗證系統充分處理逆境的程度的相關測試技術。

希望所有系統利益相關者能獲取有用的信息，并為當下以及未來的關鍵系統開發工作提供實際指導。

截至2020年退休，我個人在美國軟件工程研究所（SEI）已經工作了17個年頭，整個職業生涯更是做了40多年的系統和軟件工程師。我以SEI技術說明的形式完成了這七篇系統韌性文章，這是該系列的最后一篇文章，希望能對諸位有所幫助。

我們江湖再見。