不良事件和條件可能會破壞系統，導致系統無法提供必要的功能和服務。 正如我在本系列的前幾篇文章中概述的那樣，彈性是大多數系統的基本質量屬性，因為它們提供了關鍵功能和服務，儘管不可避免地存在困難，但這些功能和服務必須繼續下去。 這些逆境往往是不可避免的，並且有多種形式。 典型的例子包括編碼缺陷（魯棒性）、危險和事故（安全性）、漏洞和攻擊（網路安全和生存能力）、過載（容量）、長壽命（壽命）和通訊丟失（互操作性）。
在本系列中第 1 部分在本文中，我將系統彈性定義為系統快速有效地保護其關鍵功能免受不良事件和條件影響的程度。
第二部分本文確定了以下八個次要質量屬性，這些屬性對可能危及關鍵系統的不利因素進行了分類：穩健性、安全性（被動）、網路安全（主動）、防篡改、生存能力、容量、壽命和互操作性。
第三部分本文介紹了系統彈性要求的工程設計，以及如何使用它們來推導這些次要質量屬性的相關要求。
第四章本文提出了彈性技術分類的本體論，闡明了彈性需求與彈性技術之間的關係。
該系列的第 5 章本文給出了相對全面的彈性技術列表，並用它們執行的彈性函式（即抵抗、檢測、反應和恢復）對它們進行了注釋。
第六章文章可幫助讀者驗證系統的體系結構、設計或實現是否滿足其復原要求，以及可靠性、安全性、網路安全性、防篡改性、生存能力、容量、壽命和互操作性的次要要求。
第七章本文是該系列的最後一篇文章，將前六篇文章中的資訊提取為以下 16 條指導原則，以幫助系統和軟體工程師開發彈性系統。
原則 01
專注於任務關鍵型功能
系統通常支援許多功能，這些功能因系統的任務和功能而異。 某些功能對於系統任務的成功至關重要，而其他功能可能僅用作支援或具有避免中斷任務的解決方法。 同樣，並非所有與能力相關的需求都是平等的。 有些是任務成功所必需的，而另一些則不是。
系統彈性的目標是確保關鍵任務功能不會因不利條件和事件而中斷。 因此，要實現這一點，識別和理解任務關鍵型功能是設計彈性系統的起點。
原則 02
識別關鍵資產
每個關鍵任務功能都由相關的關鍵資產實現，包括系統元件、系統資料和潛在的系統外部資料來源孤島（例如，外部系統和外部資料庫）以及將系統連線到這些資料來源孤島的外部網路。 為了保護任務關鍵型功能免受干擾，工程師必須保護所涉及的關鍵資產，這就是為什麼確定任務關鍵型功能所依賴的關鍵資產非常重要的原因。
原則 03
聚焦共同關鍵資產
單個關鍵資產通常支援多個任務關鍵型功能。 因此，如果不能保護這些通用關鍵資產，可能會導致多個關鍵任務功能中斷。 為了避免這些中斷，彈性工程應重點關注共享服務元件、網路和資料儲存庫等常見關鍵資產。
原則 04
專注於破壞性傷害
不利的條件和事件會以各種方式損害關鍵資產。 但是，某些條件或事件可能不會中斷任務關鍵型功能。 因此，彈性工程應側重於破壞關鍵任務能力的危害。
原則 05
期待逆境
許多不利因素是不可避免的，尤其是在當今動盪的網路環境中。 因此，彈性工程活動應基於存在不利條件和將發生不利事件的假設。
原則 06
考慮所有型別的逆境
此考慮因素應包括不利條件和不利事件，以及與所有八個次要質量屬性相關的不利因素：魯棒性、安全性（被動）、網路安全（主動）、防篡改、生存能力、容量、壽命和互操作性。 通常，系統彈性側重於單個質量屬性（特別是魯棒性、被動安全或主動安全），因為系統彈性需求主要由個人可靠性、安全性或安全工程師驅動。
原則 07
假設多重逆境
逆境並不總是孤立地發生，並且會相互影響。 有時，它們同時發生或快速連續發生。 不利條件的存在通常會導致相關的不良事件。 大多數事故是由一連串的逆境或逆境網路引起的。 例如，網路安全攻擊可能導致故障或故障，從而導致事故。 同樣，事件可能會造成漏洞，使網路安全攻擊得逞。
原則 08
逆境預計會隨著時間的推移而改變
逆境會隨著時間而變化。 此外，還經常會發現新的不利因素，例如新的安全威脅和漏洞。 維護和更新系統通常會改變逆境的可能性和負面後果。 因此，彈性工程從未完成，而是一項長期活動。
原則 09
識別潛在逆境並確定其優先順序
為了防止關鍵任務功能中斷，必須保護系統免受大量潛在不利條件和事件的影響。 必須識別和理解潛在的缺點。 然而，潛在的缺點數量往往如此之大，以至於在實踐中只能解決一部分問題。 風險分析通常用於根據這些不利情況的發生概率和可能造成的危害程度來確定其優先順序。
原 則 10
抵禦逆境
通常可以對系統進行架構、設計和實施，以防止某些缺點，例如，被動地防止這些缺點干擾關鍵任務功能。 這種被動抵抗有時比主動檢測、反應和恢復相同不利因素的彈性技術更有效（甚至沒有必要）。 另一方面，縱深防禦可以導致使用被動和主動彈性技術來保護任務關鍵型功能免受相同的不利影響。
原則11
檢測逆境
為了對逆境做出反應並從中恢復過來，必須首先發現它們。 此步驟不僅包括檢測不良事件，還包括檢測不良情況，以便相關反應可以預防相關的不良事件。
有些朋友可能認為，規定反應和**的要求就足夠了，而測試被理解為必要（即測試要求可以由反應或**要求推導出來）。 但是，僅呼叫檢測會增加識別適當的檢測技術並將其合併到系統中的可能性。
原則12
應對逆境
重要的是要清楚“應對逆境”和“從逆境中恢復”之間的區別。 在可行的情況下，通過防止逆境損害關鍵資產來做出響應。 反應可能在完全或部分恢復之前發生。 因此，系統應包括應對逆境的彈性技術，以最大限度地減少它們可能造成的中斷的持續時間和範圍。
原則13
從逆境中恢復過來
在系統對逆境做出反應並且沒有對關鍵資產造成進一步傷害之後，必須完全（或至少部分）從中斷關鍵任務功能的損害中恢復過來。 然而，根據造成的危險和系統的位置（例如，火星探測器上的輪式電機故障），實現這一目標可能不現實，甚至不可能。
原則14
假設元件有故障、失效或損壞
如果在系統更新過程中不及時更換或淘汰，所有系統元件最終都會出現故障。 正如我在之前關於驗證和確認的部落格文章中所討論的，測試從來都不是詳盡無遺的。 因此，可以安全地假設通常實現系統大部分功能的軟體存在一定程度的潛在缺陷，這些缺陷可能會中斷系統的功能。 缺乏元件可靠性會影響彈性和可用性。
原 則 15
比起手動韌性，更喜歡自主韌性
限制任務關鍵型功能中斷的持續時間非常重要。 因此，由於與自動韌性技術相比，人類的響應時間相對較長，因此自主韌性通常優於手動韌性。 此外，由於位置原因（例如在衛星、行星探測器和火星“漫遊車”中），並不總是能夠包括人類探測、響應和恢復。
另一方面，人工和自動恢復技術通常具有不同的最佳位置，因此在可行的情況下，應將自動恢復技術和人工監督相結合。
原則16
平衡分層防禦和複雜性
當避免中斷關鍵任務功能至關重要時，通常使用分層縱深防禦。 但是，每增加一項彈性技術都會增加系統複雜性，而過多的複雜性會降低彈性。 因此，彈性工程必須在彈性技術的數量和型別與它們增加的系統架構、設計和實施的複雜性之間取得平衡。
總結與展望
系統彈性是大多數系統的基本質量屬性，尤其是那些對被動安全、主動安全和業務至關重要的系統。 在本系列文章中，我的目標是強調系統彈性的重要性，並為讀者提供該主題的相對完整的概述。
在這個包含 7 篇文章的系列文章中，我概述了什麼是系統彈性，它與其他質量屬性的關係，以及它對需求、架構和驗證（尤其是測試）的影響。 從概念模型開始，該系列確定了不同型別的彈性相關需求、一些提高彈性的架構和設計技術，以及驗證系統充分處理逆境程度的相關測試技術。
希望所有系統利益攸關方都能獲得有用的資訊和實用指導，以開發當今和未來的關鍵系統。
截至 2020 年退休時，我個人在軟體工程學院 （SEI） 工作了 17 年，作為系統和軟體工程師的整個職業生涯已有 40 多年。 我以 SEI 技術筆記的形式完成了這七篇系統彈性文章，這是該系列的最後一篇文章，希望對您有所幫助。
一會見。