《亞馬遜云科技：2024韌性系統生命周期建設框架白皮書（26頁）.pdf》由會員分享，可在線閱讀，更多相關《亞馬遜云科技：2024韌性系統生命周期建設框架白皮書（26頁）.pdf（26頁珍藏版）》請在三個皮匠報告上搜索。

1、 Amazon Prescriptive Guidance 韌性系統生命周期建設框架 Amazon Prescriptive Guidance：韌性系統生命周期建設框架韌性系統生命周期建設框架 版權所有2023 亞馬遜云科技及/或其附屬公司。保留所有版權。亞馬遜云科技的商標和商業外觀不得用于任何非亞馬遜云科技的商品或服務，也不得以任何可能引起客戶混淆、貶低或詆毀亞馬遜云科技的方式使用。所有非亞馬遜云科技擁有的其它商標均為各自所有者的財產，這些所有者可能附屬于亞馬遜云科技、與亞馬遜云科技有關聯或由亞馬遜云科技贊助，也可能不是如此。Amazon Prescriptive Guidance 韌性系統

2、生命周期建設框架 iii 目錄目錄 引言.1 術語和定義.2 持續韌性.3 第 1 階段：設定目標.4 確定關鍵應用.4 確定用戶故事.4 設定衡量指標.5 創建額外的衡量指標.5 第 2 階段：設計和實施.7 Amazon Well-Architected Framework.7 理解依賴關系.7 災難恢復策略.8 制定持續集成和持續交付（CI/CD）策略.8 開展運行就緒性檢查.9 了解亞馬遜云科技故障隔離邊界.9 選擇響應方式.9 韌性建模.10 故障安全.10 第 3 階段：評估和測試.11 部署前活動.11 環境設計.11 集成測試.11 自動化部署管線.12 負載測試.12 部署后

3、活動.12 開展韌性評估.12 災難恢復測試.13 漂移檢測.13 合成測試.13 混沌工程.13 第 4 階段：運營.15 可觀察性.15 事件管理.15 持續韌性.16 第 5 階段：響應和學習.17 創建事件分析報告.17 實施運營審查.18 審查警報性能.18 警報精確度.18 假陽性.18 假陰性.18 重復的警報.19 實施指標審查.19 提供培訓和賦能.19 創建事件知識庫.19 深入實施韌性.20 結論和資源.21 撰稿人.22 文檔歷史.23 Amazon Prescriptive Guidance 韌性系統生命周期建設框架 1 韌性系統生命周期建設框架韌性系統生命周期建設框

4、架：實現：實現韌性韌性優化的持續方法優化的持續方法 亞馬遜云科技 2023 年 10 月（文檔歷史（23 頁）如今，現代公司面臨著越來越多與韌性相關的挑戰，這在客戶日益期望服務“永遠在線、永遠可用”的背景下尤其如此。公司需要構建遠程團隊和復雜的分布式應用，同時也需滿足客戶對新應用程序不斷增長的需求。因此，公司及其應用均需比以往更具韌性。根據亞馬遜云科技的定義，韌性是指應用程序抵抗中斷（包括與基礎設施、依賴服務、錯誤配置和瞬態網絡問題等相關的中斷）或從中斷中恢復的能力（參見Amazon Well-Architected Framework 可靠性支柱文件中的“韌性和可靠性組件”部分）。然而，為了

5、達到期望的韌性水平，公司通常需要進行權衡，需要對操作復雜性、工程復雜性和成本進行評估和相應調整。在與客戶和內部團隊展開多年合作的基礎上，亞馬遜云科技開發了一個韌性系統生命周期建設框架，其中包括了韌性知識和最佳實踐。該框架概述了下圖所示的五個關鍵階段。在每個階段，您都可以運用相應的策略、服務和機制來優化韌性狀態。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 2 這些階段將在本指南后續章節中予以討論：第 1 階段：設定目標（第 4 頁）第 2 階段：設計和實施（第 7 頁）第 3 階段：評估和測試（第 11 頁）第 4 階段：運行（第 15 頁）第 5 階段：

6、響應和學習（第 17 頁）術語和定義術語和定義 每個階段的韌性概念適用于從單個組件到整個系統的不同層面。概念的實施需要明確定義幾個術語：組件 是執行功能的元素，由軟件和技術資源組成。組件包括代碼配置、網絡等基礎設施，或者甚至服務器、數據存儲和多因素身份驗證（MFA）設備等外部依賴項。應用程序 是交付商業價值的組件集合，比如面向客戶的網絡店鋪或優化機器學習模型的后臺流程。一個應用程序可能由單個亞馬遜云科技帳戶中的組件子集構成，也可能是跨多個亞馬遜云科技帳戶和地區的多組件集合。系統 是管理既定業務功能所需的應用程序、人員和流程的集合。它包括功能運行所需的應用程序；運行流程（比如持續集成和持續交付（

7、CI/CD）、可觀測性、配置管理、事件響應和災難恢復）；以及管理這些任務的操作人員。中斷 是指阻止應用程序正常實現其業務功能的事件。受損 是指如果中斷得不到緩解而將對應用程序產生的影響。如果應用程序遭受一系列中斷，它們可能會因此受損。設定目標 設計和 實施 評估和 測試 響應和 學習 運行 Amazon Prescriptive Guidance 韌性系統生命周期建設框架 3 持續持續韌性韌性 韌性生命周期是一個持續的過程。即便在同一家公司中，應用團隊對每個階段的執行完整程度也有所不同，具體取決于應用程序的要求。不過，每個階段越完整，應用程序的韌性也就越大。您應將韌性生命周期視為公司可運行的標

8、準流程。在對韌性生命周期建模時，亞馬遜云科技有意使其類似于軟件開發生命周期（SDLC），目的是在開發和運行應用程序時，可將規劃、測試和學習融入整個運行流程。與許多敏捷開發流程一樣，韌性生命周期會隨著開發過程的迭代而重復出現。我們建議您在生命周期的各個階段逐步深化實踐。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 4 第第 1 階段階段：設定目標：設定目標 了解需要什么級別的韌性以及如何進行衡量是目標設定階段的基礎。如果你沒有目標或無法對其進行衡量，那么改進將難以實現。并非所有的應用程序都需要相同級別的韌性。在設定目標時，請考慮所需的韌性水平，以便做出正確的

9、投資和權衡。在這里，汽車是一個很好的類比：汽車有四個輪胎，但只有一個備用輪胎。這是因為，在單次行駛中出現多個輪胎漏氣的幾率很低，并且配備更多備用輪胎可能會影響汽車的其他功能，比如貨物空間或燃油效率等等。所以，這種配置是合理權衡的結果。目標設定后，您需要在后續階段（第 2 階段：設計和實施（第 7 頁）和第 4 階段：運行（第 15頁）進行觀測和控制，以了解是否達到目標。確定關鍵應用確定關鍵應用 設定韌性目標不應僅限于技術對話。相反，您需要從業務目標入手，去了解應用程序需提供的服務以及受損的后果。然后，再將對業務目標的這種理解擴展到架構、工程和運行等領域。設定的任何韌性目標都可能適用于所有的應用

10、程序，不過衡量目標的方式通常會因應用程序的功能而異。您當前運行的某個應用程序可能對業務至關重要。如果該應用程序受損，貴公司可能會損失大量收入或遭到名譽損害。也有可能的是，您當前運行的某個應用程序可能對業務沒那么重要，因此公司可以容忍一段故障停機時間，同時也不會對業務能力產生負面影響。以一家零售公司的訂單管理應用程序為例。如果該訂單管理應用程序的組件受損并且不能正常運行，那么新的銷售將無法進行。此外，這家零售公司在一處辦公樓內設有員工咖啡廳?？Х葟d提供線上菜單，員工可以通過靜態網頁進行訪問。如果該網頁不可訪問，那么一些員工可能會有怨言，但未必會給公司帶來經濟損失?；谶@個例子，企業可能會選擇為訂

11、單管理應用程序設定更加積極的韌性目標，但不會進行大量投資來確保網頁應用的韌性。衡量應用程序在生產中的韌性十分重要，確定最關鍵的應用程序、需投入非常多精力的領域以及需權衡的事項同樣重要。為了更好地了解應用受損的影響，您可以進行業務影響分析（BIA）。這種分析提供了一種結構化、系統化的方法，可以幫助您確定關鍵業務應用程序及其優先級別、評估潛在風險和影響并識別相互依賴關系。業務影響分析有助于量化貴公司重要應用程序的停機成本，即當特定應用程序受損而無法完成功能時的成本。在前面的例子中，如果訂單管理應用程序受損，那么零售企業可能會損失大量收入。確定確定用戶故事用戶故事 在業務影響分析過程中，您可能會發現

12、某個應用程序可實現多項業務功能，或者某項業務功能需要多個應用程序的支撐。仍以前面的零售公司為例，訂單管理功能可能需要結賬、促銷和定價等多個應用程序共同實現。如果其中的一個應用程序出現故障，那么公司及其用戶都會受到影響。例如，公司可能會無法添加新訂單、提供促銷和折扣或者更新產品價格。訂單管理所需的這些不同功能可能依賴于多個應用程序，還可能依賴多個外部應用程序，這樣，以組件為核心來實現韌性的過程將變得十分復雜。應對這種情境的更好方法是以用戶故事為核心，即概括用戶在與一個Amazon Prescriptive Guidance 韌性系統生命周期建設框架 5 或一組應用程序互動時期望獲得的體驗。關注用

13、戶故事可以幫助您了解哪些客戶體驗尤為重要，這樣，您就可以構建相應的機制來防范特定的威脅。在前面的例子中，用戶故事可以是結賬，它受結賬應用程序所支撐，并且依賴定價應用程序。用戶故事也可以是查看促銷，這涉及到促銷應用程序。在確定了關鍵應用程序及用戶故事之后，您便可以開始設定用來衡量用戶故事韌性的指標。這些指標可以應用于整個故事組合，也可以應用于單個用戶故事。設定設定衡量衡量指標指標 恢復點目標（RPO）、恢復時間目標（RTO）和服務級別目標（SLO）是用來評估既定系統韌性的標準行業指標?；謴忘c指標是指在發生故障時，企業可以容忍的數據丟失量，而恢復時間目標衡量的是應用程序在停機后恢復可用的速度。兩個

14、指標均以時間為單位，包括秒、分鐘和小時。您也可以用它們來衡量應用程序正常工作的時間，這里的正常工作是指應用程序執行設計功能，并且能夠為用戶所訪問。服務級別目標詳述了客戶將獲得的預期服務級別，衡量指標包括在不到一秒的響應時間內獲得無差錯服務的請求的百分比（%）（例如，每月有 99.99%的請求可得到響應）等等?；謴忘c目標和恢復時間目標與均災難恢復策略相關，假設前提是從恢復備份到重定向用戶流量的應用程序運行和恢復過程會出現中斷。服務級別目標通過實施高可用性控制來實現，有助于減少應用程序的停機時間。服務級別目標指標一般用來定義服務級別協議（SLA），后者是指在服務提供商和最終用戶之間簽訂的合同。服務

15、級別協議通常附帶經濟方面的承諾，列出了服務提供商在不遵循協議的情況下將需向用戶支付的罰金。不過，服務級別協議并不是公司韌性的衡量指標，因此增加服務級別協議并不會讓應用程序變得更具韌性?，F在，您可以開始根據服務級別目標、恢復點目標和恢復時間目標來設置您的韌性目標。在設定韌性目標并清楚了解恢復點目標和恢復時間目標之后，您可以利用 Amazon Resilience Hub 對應用程序架構進行評估，以便發現與韌性相關的潛在弱點。Amazon Resilience Hub 將根據 Amazon Well-Architected Framework 最佳實踐來評估應用程序架構，并就需要改進的具體方面給出

16、補救指導，以幫助您實現恢復點目標和恢復時間目標。創建額外創建額外的的衡量指標衡量指標 恢復點目標、恢復時間目標和服務級別目標是衡量韌性的良好指標，不過，您也可以從業務角度考慮總體目標，并圍繞應用程序的功能設定具體目標。例如，您的目標可以是：即便公司前臺和后臺之間的時延增加 40%，每分鐘的成功訂單量也可保持在 98%以上；或者是：即便某個組件丟失，每秒流量也將保持在平均值的標準偏差范圍之內。您也可以創建目標，以縮短各種已知故障類型的平均恢復時間（MTTR）。例如，如果發生某種已知問題，恢復時間將縮短 x%。創建符合業務需求的目標可幫助您預測應用程序可容忍的故障類型，還可以幫助您確定降低應用程序

17、受損可能性的方法。如果在丟失 5%應用實例的情況下設定繼續運行的目標，您可能會決定對應用進行預擴展或者讓應用具有快速擴展的能力，以支持該事件期間產生的額外流量?；蛘?，您也可能會決定采用第2 階段：設計和實施（第 7 頁）一節中所描述的不同架構模式。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 6 您還應該針對特定業務目標實施可觀測性指標。例如，您可以跟蹤平均訂單率、平均訂單價格、平均訂購數量或其他指標，這些指標可以根據應用程序的行為提供對業務健康狀況的洞察?；趹贸绦虻目捎^測性功能，您可以創建警報，并在這些指標超出您定義的界限時采取措施?？捎^測性在第 4

18、 階段：運行（第 15 頁）一節中有更詳細的介紹。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 7 第第 2 階段階段：設計和實施設計和實施 在前一階段，您設定了韌性目標?，F在，進入設計和實施階段，您將嘗試預測故障模式，并根據您在前一階段設定的目標選擇設計方案。您還需要制定變更管理策略、開發軟件代碼并配置基礎設施。以下章節內容突出了在權衡成本、復雜性和運行費用等因素時應考慮的亞馬遜云科技最佳實踐。Amazon Well-Architected Framework 在根據期望的韌性目標構建應用程序時，您需要評估多項因素，并基于最優架構進行權衡。為了構建高韌性

19、的應用程序，您必須綜合考慮設計、構建、部署、安全和運行等多個方面。Amazon Well-Architected Framework 提供了一整套最佳實踐、設計原則和架構模式，可幫助您在亞馬遜云科技平臺上設計高韌性的應用程序。Amazon Well-Architected Framework 的六大支柱提供了設計和運行安全、高效、經濟、可持續和高韌性系統的最佳實踐。該框架提供了一種方法，可以幫助您參照最佳實踐連貫地衡量應用程序架構，并確定需要改進的地方。以下是 Amazon Well-Architected Framework 如何幫助您設計和實施符合韌性目標的應用程序的示例：可靠性支柱可靠性

20、支柱：可靠性支柱強調了構建即便在故障或中斷期間也能正確、連貫運行的應用程序的重要性。例如，Amazon Well-Architected Framework 建議采用微服務架構，使應用程序變得更小、更簡單，這樣您就可以區分應用程序中不同組件的可用性需求。您還可以找到最佳實踐的詳細描述，通過使用節流、指數回退重試、快速故障（減載）、等冪、恒定工作、斷路器和靜態穩定性來構建應用程序。全面全面檢查檢查：Amazon Well-Architected Framework 鼓勵參照最佳實踐和設計原則對架構進行全面檢查。該框架提供了一種方法，可以幫助您參照最佳實踐連貫地衡量應用程序架構，并確定需要改進的地

21、方。風險管理風險管理：Amazon Well-Architected Framework 可幫助您識別和管理可能影響應用程序可靠性的風險。通過主動解決潛在的故障，您可以降低故障發生的可能性或由此造成的損害。持續改進持續改進：韌性是一個持續的過程，因此 Amazon Well-Architected Framework 強調持續優化。您可以根據 Amazon Well-Architected Framework 的指導定期檢查并改進應用程序架構和流程，這樣就可以確保系統在面對不斷發展的挑戰和需求時始終保持韌性。理解理解依賴依賴關系關系 理解系統的依賴關系是實現韌性的關鍵。依賴關系包括應用程序內部

22、各組件之間的關聯，以及應用程序與外部組件（比如第三方應用程序編程接口和企業自有的共享服務）之間的關聯。理解這些關聯有助于隔離和管理中斷，因為一個組件受損可能會影響其他組件的運行。這些知識可幫助工程師評估損害的影響并相應地制定計劃，從而確保資源得到有效利用。理解依賴關系可以幫助您制定備用策略、協調恢復過程。它還可以幫助您確定可以用軟依賴替換硬依賴的情況，這樣，Amazon Prescriptive Guidance 韌性系統生命周期建設框架 8 當存在依賴損害時，應用程序可以繼續執行其業務功能。依賴性還會影響關于負載平衡和應用程序擴展的決策。在更改應用程序時，理解依賴關系是至關重要的，因為這有助

23、于您確定潛在的風險和影響。這些知識可以幫助您創建穩定、有韌性的應用程序，協助故障管理、影響評估、損害恢復、負載平衡、擴展和變更管理。您可以手動或者使用 Amazon X-Ray 等工具和服務來跟蹤依賴關系，進而理解分布式應用程序的依賴關系。災難恢復策略災難恢復策略 災難恢復（DR）策略在構建和運行韌性應用程序的過程中扮演著關鍵角色，主要的作用是確保業務的連續性。即便在災難性事件中，災難恢復策略也能保證關鍵業務以最小的受損程度持續運行，從而最大限度地減少了停機時間和潛在的收入損失。災難恢復策略對于數據保護至關重要，因為它們常常涉及多地的定期數據備份和數據復制，這有助于保護有價值的業務信息，同時防

24、止災難期間數據的全部丟失。而且，許多行業都受到相關政策的監管，這些政策要求企業制定災難恢復策略來保護敏感數據，并確保服務在災難期間保持可用。通過最大程度地減少服務的受損程度，災難恢復策略還提高了客戶的信任度和滿意度。一項實施良好且屢屢實踐的災難恢復策略可以縮短災難后的恢復時間，并可以幫助應用程序快速地重新上線。此外，災難會帶來巨大的成本，這不僅包括停機造成的收入損失，還包括恢復應用程序和數據的費用。設計良好的災難恢復策略有助于減少這些經濟損失。策略的選擇取決于您對應用程序的特定需求、您設定的恢復時間目標和恢復點目標以及您的預算。Amazon Elastic Disaster Recovery

25、是一種定制化的韌性服務，可用于實施本地和云上應用程序的災難恢復策略。有關更多信息，請參見亞馬遜云科技網站上的 Disaster Recovery of Workloads on Amazon Web Services 和 Amazon Multi-Region Fundamentals。制定制定持續集成和持續交付（持續集成和持續交付（CI/CD）策略策略 導致應用程序受損的一個常見原因是代碼或其他變更改變了應用程序之前的已知工作狀態。如果變更管理不夠細致，那么這種變更可能會導致應用程序頻繁受損。變更頻率越高，產生影響的可能性也就越大。不過，降低變更的頻率會產生更大的變更集合，由于其高度復雜，因

26、此更有可能使應用程序受損。持續集成和持續交付（CI/CD）實踐旨在保持小規模和頻繁的變更（從而提高生產力），同時通過自動化對每項變更進行高級別的檢查。一些基本策略包括：完全自動化完全自動化：持續集成和持續交付的根本目的是盡可能實現應用構建和部署流程的自動化。整個流程包括應用程序的構建、測試、部署甚至監控。自動化管線有助于降低人為錯誤的可能性，確保一致性，并使流程更加可靠和高效。測試驅動開發測試驅動開發（TDD）：）：在編寫應用程序代碼之前編寫測試。這樣可以確保所有的代碼都有相關的測試，因此提高了代碼的可靠性和自動化檢查的質量。這些測試在持續集成管線中運行，以便驗證變更。頻繁提交和集成頻繁提交和

27、集成：鼓勵開發人員頻繁提交代碼并進行集成。小規模且頻繁的更改更容易測試和調試，進而降低了出現重大問題的風險。自動化降低了提交和部署的成本，使得頻繁集成成為可能。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 9 不可變基礎設施不可變基礎設施：將服務器和其他基礎設施組件視為靜態的不可變實體。盡可能替換而不是修改基礎設施；利用經測試的代碼構建新的基礎設施，并通過管線進行部署?；貪L機制回滾機制：如果出現問題，確保能有一個簡單、可靠且經頻繁測試的更改回滾方式。能夠快速返回到先前已知的良好狀態對于部署安全至關重要?；貪L可以由一個簡單的按鈕實現，輕輕一按便可以恢復到以前

28、的狀態，或者也可以完全自動化，警報一響便可啟動。版本控制版本控制：將所有應用程序代碼、配置甚至基礎設施即代碼保存在受版本控制的存儲庫中。這可以幫助您輕松地跟蹤更改，并在需要時恢復更改。金絲雀部署和藍金絲雀部署和藍/綠部署綠部署：首先將應用程序的新版本部署于基礎架構的一個子集，或者維持藍/綠兩種環境，這可以幫助您在生產中驗證更改行為，并在必要時快速回滾。持續集成和持續交付不僅是工具，也構成了一種文化。創造一種重視自動化、測試和從失敗中學習的文化與實施正確的工具和過程同樣重要。如果回滾速度很快且影響極小，那么這種回滾不應被視為是一種失敗的經歷，而是一種學習的體驗。開展開展運營運營就緒就緒審查審查

29、運營就緒性審查（ORR）有助于確定運營和和程序上的差距。在亞馬遜云科技，我們確立了運營就緒審查制度，從數十年大規模服務運營中提取經驗，精選問題，以提供最佳實踐指導。運營就緒性審查總結了以前的經驗教訓，并要求新團隊在應用中考慮了這些經驗教訓。運營就緒性審查可以提供一個故障模式或故障原因的清單，在下面韌性建模一節描述的韌性建?；顒又?，可以輸入這些故障模式或故障原因。有關更多信息，請參見 Amazon Well-Architected Framework 網站上的運行就緒檢查（ORRs）。了解了解亞馬遜云科技亞馬遜云科技故障隔離邊界故障隔離邊界 亞馬遜云科技提供多種故障隔離邊界，以幫助您實現韌性目標

30、。您可以充分利用這些邊界提供的可預測的影響遏制范圍，也應該熟悉如何利用這些邊界來設計亞馬遜云科技服務，這樣就可以有意識地為應用程序選擇依賴項。有關如何在應用程序中利用故障隔離邊界，請參閱亞馬遜云科技網站上的 Amazon Fault Isolation Boundaries。選擇響應選擇響應方式方式 系統可以以多種方式對警報做出響應。某些警報可能需要運營團隊的響應，而某些警報可能會觸發應用程序中的自我修復機制。您可能決定將可以自動化的響應保留為手動操作，以控制自動化的成本或管理工程約束。警報響應類型可被選做響應實施成本、警報預期頻率、警報準確性以及根本不對警報做出響應而造成的潛在商業損失的函數

31、。例如，當服務器進程崩潰時，操作系統可能會重新啟動該進程，或者會有新的服務器代替舊的服務器，或者可能會指示操作員遠程連接并重啟服務器。這些響應結果相同，即都是重啟應用服務器進程，但是實施和維護成本有所不同。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 10 注意注意 您可以選擇多種響應方式，以便構建深入的韌性方法。例如，在前面的場景中，應用團隊可能選擇實施所有三種響應方式，不過在各種響應方式之間有一定的時間延遲。如果服務器進程崩潰指示器在 30 秒后仍然處于報警狀態，那么團隊可以認為操作系統無法重啟應用服務器。因此，他們可能會創建一個自動擴展組，設置一個新

32、的虛擬服務器來恢復應用服務器進程。如果指示器在 300 秒后仍處于報警狀態，則可能會向操作人員發送警報，要求他們連接到原始服務器并嘗試恢復進程。應用程序團隊和企業選擇的響應方式應反映出企業希望通過前期工程時間的投入來抵消運營開支的偏好。您應該仔細考慮每種響應選擇的約束和預期維護成本，進而選擇恰當的響應方式，比如靜態穩定性之類的架構模式、斷路器之類的軟件模式或是操作程序等等。對于應用程序團隊來說，可能存在一些標準的相應方式指導，因此，您可以輸入集中式架構功能管理的數據庫和模式，然后做出相應考慮。韌性韌性建模建模 韌性建模記錄了應用程序響應各種預期中斷的過程。在預測中斷的基礎上，您的團隊可以實現應

33、用的可觀測性、自動化控制和故障恢復，從而減輕或阻止中斷造成的損害。亞馬遜云科技利用韌性分析框架為韌性模型的開發提供指導。該框架可以幫助您預測中斷及其可能對應用程序產生的影響。在預測中斷的基礎上，您可以確定構建可靠、高韌性的應用程序所需的中斷緩解措施。我們建議您采用韌性分析框架，以便在應用程序迭代時更新韌性模型。在每次迭代中使用韌性分析框架也就是在設計階段預測中斷并在生產部署前后測試應用程序有助于減少事故發生；利用韌性分析框架開發韌性模型也有助于實現韌性目標。安全安全的的故障故障 如果你無法避免中斷，那就確保故障是安全的?？紤]利用默認的故障安全操作模式來創建應用程序，這樣就不會導致重大的業務損失

34、。數據庫故障安全狀態的一個例子是默認為只讀操作，即不允許用戶創建或修改任何數據。針對敏感性數據，您甚至可能希望應用程序默認為關閉狀態，甚至不執行只讀查詢。請考慮應用程序的故障安全狀態應該是什么，并在極端條件下默認使用這種操作模式。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 11 第第 3 階段階段：評估和測試：評估和測試 在應用程序生命周期的評估和測試階段，您已完成應用程序的設計或更改，但尚未發布于生產環境中。在這個階段，您將開展一些活動來測試之前階段的實踐，并對結果進行評估。應用程序可能仍在積極開發中，或者主要開發可能已經完成，應用程序正在接受發布到生

35、產環境之前的測試。在這個階段，您將重點關注開發和運行測試，這些測試將確認應用程序能否達到設定的韌性目標。此外，您還要開發和測試系統的操作程序。您將應用在第 2 階段：設計和實施（第 7 頁）中開發的部署程序，并對結果進行評估。雖然這些測試和評估活動在這一階段開始，不過并非在此結束。在第 4 階段：運行階段（第 15 頁）中，測試和評估將繼續進行。評估和測試階段進一步分為兩個階段，即部署前活動（第 11 頁）和部署后活動（第 12 頁）。部署前活動包括在將應用程序部署于任何環境之前應該完成的各種任務，比如部署軟件的新版本以及在測試環境中的初始部署。部署后活動在將軟件部署于測試或生產環境之后進行。

36、以下章節將對這些階段進行詳細討論。部署部署前前活動活動 環境設計環境設計 測試和評估應用程序的環境會影響測試的徹底程度，也會影響您對測試結果準確反映生產環境的信心。借助 Amazon DynamoDB（參見 DynamoDB 文檔中的本地設置 DynamoDB）之類的服務，您可以在開發人員的機器上本地執行一些集成測試。但是，在某些時候，為了對結果有更強的信心，您需要在模擬生產環境中進行測試。這種環境會產生更高的成本，因此，我們建議您就測試環境采用分階段或管線方法，模擬生產環境將出現在管線的后期階段。集成測試集成測試 集成測試是測試應用程序中定義明確的組件在使用外部依賴項時能否正確執行其功能的過

37、程。這些外部依賴項可以是其他定制開發的組件、應用程序使用的亞馬遜云科技服務、第三方依賴項和本地依賴項。本指南側重于針對應用程序韌性的集成測試，并且假設已經存在證明軟件功能準確性的單元和集成測試。我們建議您針對已實施的韌性模式（比如斷路器模式或減載模式（參見第 2 階段：設計和實現（第 7 頁）設計專門的集成測試。針對韌性的集成測試通常需要向應用程序施加特定的負載，或是利用諸如 Amazon Fault Injection Simulator（Amazon FIS）之類的功能，有意地在測試環境中制造中斷場景。理想狀態是，您需將所有的集成測試作為持續集成/持續交付管線的一部分，并確保每次提交代碼時

38、都運行測試。這可以幫助您快速檢測違背韌性目標的任何代碼或配置變更并做出響應。大規模的分布式應用程序十分復雜，即便是微小的變化也會對應用程序中看似不相關的組件的韌性產生重大影響。盡量在每次提交代碼時都運行測試。亞馬遜云科技提供了一整套出色的工具，可幫助您運行持續集成/持續交付管線和其他 DevOps 工具。有關更多信息，請參見亞馬遜云科技網站上的“亞馬遜云科技平臺上 DevOps 簡介”。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 12 自動化部署管自動化部署管線線 在生產前環境中進行部署和測試是一項反復而復雜的任務，還是能夠自動化完成得好。自動化可以解放

39、人力資源，減少出錯的幾率。實現流程自動化的機制通常被稱為管線。在創建管線時，我們建議您設置一系列逐步接近生產配置的測試環境。您可以利用這一系列環境來反復測試應用程序。與生產環境相比，第一種環境提供的功能比較有限，但成本卻低得多。后續環境應該不斷添加服務并進行擴展，以更好地反映生產環境。首先，在第一個環境中進行測試。如果部署的應用程序通過了第一個測試環境中的所有測試，那么讓它在一定的負載下運行一段時間，看看隨著時間的推移是否會出現任何問題。請確認已經正確地配置了可觀測性（請參閱本指南后面的“報警精度”），這樣您就可以檢測到出現的任何問題。如果應用程序成功地通過了這段觀測期，則可以將其部署到下一個

40、測試環境中，然后重復這個過程，添加環境支持的額外測試或負載。在以這種方式充分測試應用程序之后，您便可以使用之前設置的部署方法將應用程序部署到生產環境中（請參閱本指南前面的“制定持續集成/持續交付策略”）。Amazon Builders Library 中的自動化安全、無需干預的部署一文是很好的資源，描述了亞馬遜云科技如何實現代碼部署的自動化。生產部署之前的環境數量會有所不同，具體取決于應用程序的復雜程度及其依賴項的類型。壓力壓力測試測試 從表面上看，壓力測試類似于集成測試。為了驗證應用程序及其外部依賴項是否按預期運行，您會對其離散性進行測試。不過，測試又超越了集成測試，關注的是應用程序如何在明

41、確的負載下運行。壓力測試需要驗證功能的正確性，因此必須在成功的集成測試之后進行。了解應用程序在預期負載下的響應情況以及在負載超出預期時的行為非常重要。這有助于驗證是否已經實施了必要的機制來確保應用程序在極端負載下的韌性。有關亞馬遜云科技壓力測試的全面指南，請參見 Amazon Solutions Library 中“亞馬遜云科技平臺上的分布式負載測試“。部署后活動部署后活動 韌性是一個持續的過程，因此，部署應用程序之后，必須繼續評估應用程序的韌性。根據部署后活動（比如持續的韌性評估）的結果，您可能需要重新評估并更新在韌性生命周期早期階段執行的一些活動。開展韌性評估開展韌性評估 在將應用程序部署

42、到生產環境中之后，韌性評估并沒有結束。在真實的生產環境中，即便您有定義良好的自動化部署管線，變更也時有發生。此外，可能還存在一些您在部署前韌性驗證中尚未考慮的因素。Amazon Resilience Hub 中有一處核心區域，您可以在此評估已部署的架構能否達成設定的恢復點目標和恢復時間目標。您也可以利用這項服務，根據需求對應用程序的韌性進行自動化評估，甚至將它們集成到持續集成/持續交付工具中，正如亞馬遜云科技博客文章使用 Amazon Resilience Hub 和 Amazon CodePipeline 連續評估應用程序韌性所述。自動化評估是最佳實踐，因為它有助于確保您在生產中持續評估韌性

43、狀態。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 13 災難恢復災難恢復測試測試 在第 2 階段：設計和實施（第 7 頁）中，您已制定了災難恢復（DR）策略，并將其作為系統的一部分。在第 4 階段，您需要測試災難恢復程序，以確保團隊為災難事件做好充分準備，同時確保程序按預期工作。您應定期測試所有的災難恢復程序，包括故障轉移和故障恢復，并查看每次測試的結果，以確定是否需要更新以及如何更新系統程序，從而獲得盡可能很好的結果。當啟動災難恢復測試開發時，請提前做好規劃，同時確保整個團隊都知曉預期結果，而且知道如何衡量結果以及應采用何種反饋機制來更新程序。在熟練運

44、行有計劃的災難恢復測試之后，可以考慮運行突擊的災難恢復測試。真正的災難是不會按計劃發生的，所以需要做好隨時演練的準備。不過，突擊不代表沒有計劃。關鍵利益相關方仍需要就災難事件做好規劃，以確保監控到位，并且客戶和關鍵應用程序都不會受到不利影響。偏差偏差檢測檢測 即使自動化和明確定義的程序已經就位，生產應用程序中的配置也可能會發生意外變化。為了檢測應用程序配置的變化，您需確立偏差檢測機制，這里的“偏差”是指與基線配置的偏差。關于如何檢測 Amazon CloudFormation 堆棧中的偏差，請參閱 Amazon CloudFormation 文檔中的“檢測堆棧和資源的非托管配置更改”。關于如何

45、檢測應用程序在亞馬遜云科技環境中的偏差，請參閱 Amazon Control Tower 文檔中的“檢測和解決 Amazon Control Tower 中的偏差”。合成測試合成測試 合成測試是創建可配置軟件的流程，該軟件按計劃在生產中運行，以模擬最終用戶體驗的方式測試應用程序的編程接口。這些測試有時被稱為“金絲雀”，該術語最早是在煤礦開采中使用。當應用程序遭受中斷時，即便損害是局部或間歇性的（灰色故障通常就是這種情況），合成測試也可以提供早期警告?；煦绻こ袒煦绻こ?混沌工程是一個系統化的流程，包括以降低風險的方式故意使應用程序遭受破壞性事件，然后密切監視其響應，并實施必要的改進。其目的是驗證

46、或質疑應用程序應對此類中斷的能力假設?；煦绻こ滩皇侨芜@些事件隨意發展，而是讓工程師能夠在一個受控的環境中安排實驗；實驗通常安排在低流量期間，并且隨時可以獲得有效的工程支持?；煦绻こ痰牡谝徊绞抢斫鈶贸绦虻恼２僮鳁l件，即所謂的穩態。在此基礎上，您需要做出一項假設，詳細描述應用程序在出現中斷時的成功行為。然后，您開始運行實驗，需要故意引入中斷，包括但不限于網絡延遲、服務器故障、硬盤錯誤和外部依賴項受損等等。最后，您將對實驗結果進行分析，并通過學習增強應用程序的韌性?；煦绻こ虒嶒炇且豁楊H有價值的工具，可以幫助您改進應用程序的性能及其他各個方面，并且發現潛在的問題。此外，混沌工程有助于揭示和完善可觀

47、測性和警報工具的缺陷，縮短恢復時間，提高運行技能?；煦绻こ踢€可加速最佳實踐的采用，培養持續改進的心態。最終，它使團隊能夠通過定期的重復實踐來構建和提升運行技能。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 14 亞馬遜云科技建議您在非生產環境中開始混沌工程實驗。您可以利用 Amazon Fault Injection Simulator（Amazon FIS）來運行混沌工程，處理通用故障以及亞馬遜云科技特有的故障。這項完全托管的服務包括停止條件警報和完全許可控制，因此您可以安全、放心、輕松地開展混沌工程實驗。Amazon Prescriptive Guid

48、ance 韌性系統生命周期建設框架 15 第第 4 階段：運營階段：運營 完成第 3 階段：評估和測試（第 11 頁）后，就可以將應用程序部署到生產環境中了。在運營階段，需要將應用程序部署到生產中，并管理客戶體驗。應用程序的設計和實施決定著其自身的許多韌性結果，但這一階段側重于系統用于維護和提高彈性的操作實踐。搭建卓越運營文化有助于為這些實踐制定標準和一致性?？捎^察性可觀察性 監控和警報是了解客戶體驗的首要方式。您需要對應用程序進行檢測，以了解其狀態，而且需要從不同的角度進行檢測，這意味著需要從服務器側和客戶側進行測量-通常使用金雀絲。測量指標應包括應用程序的交互數據及其依賴關系，以及與故障隔

49、離界限相一致的范圍。此外，還應該生成日志，以便提供有關應用程序所執行的每個工作單元的更多詳細信息。您可以考慮使用諸如 Amazon CloudWatch 嵌入式指標格式 之類的解決方案，將指標和日志結合起來。您可能會發現，您總是希望獲得更多的可觀察性，因此請考慮實現預期檢測水平所需要的成本、工作量和復雜性折中。以下鏈接提供了檢測應用程序和創建警報的最佳實踐：監控 Amazon 的生產服務（Amazon Web Services re:Invent 2020 演示）Amazon Builders Library：Amazon 的卓越運營（Amazon Web Services re:Invent

50、 2021 演示）Amazon 的可觀察性最佳實踐（Amazon Web Services re:Invent 2022 演示）對分布式系統進行檢測以實現運營可視性（Amazon Builders Library 文章）構建儀表板以實現運營可視性（Amazon Builders Library 文章）事件管理事件管理 為了在警報（或者更糟糕的是，您的客戶）提示出現問題時處理受損情況，應該制定事件管理流程。該流程應包括聘用值班操作人員、上報相關問題、以及為一致的故障排除方法編寫運行手冊，幫助消除人為錯誤。但是，通常不會孤立發生損壞；單個應用程序可能會影響依賴于其的其他多個應用程序。通過了解受影響

51、的所有應用程序，并經由一次電話會議將多個團隊的操作人員召集起來，可迅速解決問題。不過，根據企業的規模和架構，這一過程可能需要一個集中的運營團隊。除了建立事件管理流程外，您還應通過儀表板定期審查指標。定期審查有助于了解客戶體驗和應用程序性能的長期趨勢。這可幫助您識別問題和瓶頸，以免對生產造成重大影響。以一致、標準化的方式審查指標，可實現顯著效益，但需要自上而下的支持和時間投入。以下鏈接提供了關于建立儀表板和運營指標審核的最佳實踐：構建儀表板以實現運營可視性（Amazon Builders Library 文章）Amazon 成功應對故障的方法（Amazon Web Services re:Inv

52、ent 2019 演示）Amazon Prescriptive Guidance 韌性系統生命周期建設框架 16 持續韌性持續韌性 在第 2 階段：設計和實施（第 7 頁）和第 3 階段：評估和測試（第 11 頁）期間，您在將應用程序部署到生產環境之前啟動了審查和測試活動。在運營階段，您應繼續迭代生產中的這些活動。您應通過 Amazon Well-Architected Framework reviews、Operational Readiness Reviews(ORRs)、以及韌性分析框架，定期審查應用程序的韌性狀態。這有助于確保您的應用程序不偏離既定的基線和標準，并讓您及時了解新的或更新

53、后的指南。這些持續的韌性活動有助于讓您發現以前未曾預料到的中斷，并幫助您找到新的化解措施。在預生產環境中成功運行 game day 和混沌工程實驗后，您可能還會考慮在生產環境中運行這些實驗。game day 用于模擬已知事件，而針對這些事件，您已經建立起加以緩解的韌性機制。例如，game day 可能會模擬亞馬遜云科技區域服務受損并實施多區域故障轉移。雖然實施這些活動可能需要大量努力，但這兩種實踐都有助于讓您相信您的系統能夠承受您所設計的故障模式。在運營應用程序、遭遇運營事件、審查指標和測試應用程序過程中，您將遇到加以應對和學習的多種機會。Amazon Prescriptive Guidanc

54、e 韌性系統生命周期建設框架 17 第第 5 階段：響應和學習階段：響應和學習 應用程序應對破壞性事件的方式會影響到其可靠性。吸取經驗教訓，了解應用程序在過去如何應對破壞性事件，這對提高可靠性也至關重要。響應和學習階段側重于實踐，您可以通過實施這些實踐而更好地響應應用程序中的破壞性事件。其中還包括幫助您從運營團隊和工程師的經驗中提煉出極多知識和教訓的實踐。創建事件分析報告創建事件分析報告 事件發生后，首要任務是盡快防止對客戶和業務造成進一步損害。應用程序恢復后，下一步是了解發生了什么，并確定防止再次發生的措施。這種事后分析通常會編寫成報告，記錄導致應用程序受到破壞的一系列事件，以及中斷對應用程

55、序、客戶和業務造成的影響。此類報告將成為寶貴的學習成果，并應在業務部門間廣泛共享。注注 在進行事件分析時，至關重要的是不要指責任何一方。要假設所有操作人員都根據所掌握的信息優選非常適合的行動方案。請勿在報告中使用操作人員或工程師的姓名。將人為錯誤當作造成損害的原因，可能會導致團隊成員為了自我保護而心懷戒備，從而導致獲取的信息有誤或不完整。出色的事件分析報告-例如 Amazon Correction of Error（COE）程序中記錄的報告-應采用標準化格式，并盡可能詳細地記錄導致應用程序受到破壞的各種狀況。該報告詳述一系列帶有時間戳的事件，并收集定量數據（通常是來自監控儀表板的指標和屏幕截圖

56、），這些數據描述了應用程序隨時間而變化的可測量狀態。該報告應記錄操作人員和工程師采取行動的思維過程，以及導致他們得出結論的信息。該報告還應詳細說明不同指標的性能-例如，發出了哪些警報、這些警報是否準確地反映了應用程序的狀態、事件與由此產生的警報之間的時間間隔、以及解決事件的時間。時間軸還記錄所啟動的運營手冊或自動操作，以及它們說如何幫助應用程序恢復有用狀態的。時間軸上的這些要素有助于您的團隊了解自動化響應和操作人員響應的有效性，包括他們解決問題的速度以及在化解破壞方面的有效程度。這種詳細的歷史事件描述是一種強大的教育工具。團隊應將這些報告存放到中央存儲庫中，供整個企業查閱，以便其他人可以查看相

57、關事件并從中學習。針對生產環境中可能會出現的問題，這可以提高團隊的直覺。詳細事件報告庫還可以成為操作人員的培訓材料來源。團隊可以使用事故報告為桌面或現場 game day 提供靈感，在這種情況下，將為團隊提供報告中按時間軸再現的信息。操作人員可以利用時間軸中的部分信息進行情景排練，并描述他們將會采取的行動。然后，針對應用程序將會如何響應，game day 的主持人可以根據操作人員的行動而提供指導。這可以培養操作人員的故障排除技能，令其更輕松地預測和排解相關問題。負責應用程序可靠性的中央團隊應將這些報告保存在可供整個企業查閱的中心庫中。該團隊還應負責維護報告模板，并培訓團隊如何完成事件分析報告。

58、可靠性團隊應定期審查報告，以便發現整個業務中可通過軟件庫、架構模式或團隊流程變更而加以解決的趨勢。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 18 實施運營審查實施運營審查 如第 4 階段：運營（第 15 頁）所述，運營審查是審查近期功能特性發布、事件和運營指標的機會。另外，還可借運營審查之機，與企業內更廣泛的工程社區分享從功能發布和事件中所獲得的經驗教訓。在運營審查期間，各團隊會審查回滾的功能特性部署、所發生的事件以及處理方式。這為整個企業內的工程師提供了學習他人經驗和提出問題的機會。向公司內的工程社區分享運營審查結果，讓他們更多地了解運行業務的 IT

59、 應用程序以及可能會遇到的問題類型。在他們為業務設計、實施和部署其他應用程序時，將也記得這些知識。審查警報性能審查警報性能 如運營階段所述，警報可能會引發儀表板告警、創建 Ticket、發送電子郵件或呼叫操作人員。一個應用程序會設置許多警報，用以監控其運營的各個方面。隨著時間推移，應該對這些警報的準確性和有效性進行審查，提高警報精確度，降低假陽性并合并重復的警報。警報精確度警報精確度 警報應盡可能明確，以減少解讀或診斷引起警報的具體破壞所需的時間。當因響應應用受損而觸發警報時，接收和響應警報的操作人員必須首先解讀警報所傳遞的信息。這些信息可能是一個與操作步驟（例如恢復程序）相對應的簡單錯誤代碼

60、，也可能包括應用程序日志中的多行內容，您必須查看日志才能了解警報觸發原因。當您的團隊學會更有效地運行應用程序時，他們應該改進這些警報，使其盡可能清晰且簡潔。您不可能預料到應用程序可能出現的所有受損情況，因此總會出現一些需要操作人員分析和診斷的一般警報。為了縮短響應時間和平均修復時間（MTTR），您的團隊應努力減少一般警報的數量。理想情況下，警報與自動或人工響應之間應該是一一對應的關系。假陽性假陽性 隨著時間的推移，操作人員可能會忽略那些無需采取任何行動、但會以電子郵件、呼叫或 Ticket 形式發出告警的警報。定期或在事件分析的過程中審查警報，識別那些經常遭到忽略或無需操作人員采取任何措施的警

61、報（假陽性）。為了向操作人員發出可執行的警報，您應努力刪除警報或改進警報。假陰性假陰性 在事件發生期間，如果某個事件以意想不到的方式影響到了應用程序，則設置為在事件發生時發出告警的警報可能會失效。在事件分析的過程中，您應該審查本應發出但實際上并未發出的警報。您應努力改進這些警報，以便其更好地反映事件可能引發的狀況?；蛘?，您可能需要創建更多警報，用于映射由不同的征兆引發的相同受損情況。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 19 重復的警報重復的警報 損害應用程序的破壞可能會引發多種征兆，并可能導致多個警報。應定期或在事件分析的過程中，查看所發出的警報

62、和告警。如果操作人員收到重復警報，則應創建警報集合，將其合并為單個警報消息。實施指標審查實施指標審查 您的團隊應收集有關應用程序的運行指標，例如每月按嚴重程度分類的事件數量、探測事件所需要的時間、確定原因所需要的時間、補救時間以及創建的 Ticket、發送的警報和發出的呼叫數量。至少每月審查一次這些指標，借以了解操作人員的負擔，他們處理的信噪比（例如，信息性警報與可執行警報），以及對于其控制下的應用程序，團隊是否正在提高操作能力。通過這種審查，了解運營團隊可量度方面的趨勢。針對如何改進這些指標，征求團隊的意見。提供培訓和賦能提供培訓和賦能 引發事件或意外行為的應用程序及其環境難以詳細描述。此外

63、，對應用程序的韌性進行建模以預測此類情況并不總是簡單明了。您的企業應投資于培訓和賦能材料，以便運營團隊和開發人員參與到韌性建模、事件分析、game day 和混沌工程實驗等活動之中。這將提高團隊所編制報告以及他們所獲取知識的準確性。同時，團隊的能力也能得到提升，從而在無需依賴經驗豐富的工程師小組（工程師須通過定期審查而分享見解）的情況下預測故障。創建事件知識庫創建事件知識庫 事件報告是事件分析的標準輸出結果。即使應用程序并未受損，您也應該使用相同或類似的報告，記錄所檢測到的應用程序異常行為情況。使用相同的標準化報告結構，記錄混沌工程實驗和 game day 結果。該報告代表著導致事件或其他意外

64、行為的應用程序及其環境的快照。您應該將這些標準化報告存放在中心庫中，供企業內的所有工程師查閱。這樣，運營團隊和開發人員可以搜索該知識庫，了解過去哪些情況曾導致應用程序受損，哪類狀況可能會導致破壞，以及哪些情況可以防止應用程序受損。該知識庫將成為提高運營團隊和開發人員技能的加速器，使他們能夠共享知識和經驗。此外，您還可以將這些報告用作培訓材料以及game day 或混沌工程實驗的場景，借以提高運營團隊排解故障的直覺和能力。注注 標準化的報告格式還能給予讀者一種熟悉感，有助于他們更快速地找到所需要的信息。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 20 深入

65、實施韌性深入實施韌性 如前所述，先進的企業會對警報實施多種響應。單一一種響應無法保證有效，因此，通過逐級響應，應用程序可以更從容地應對故障。我們建議您為每個指標至少實施兩種響應，確保單一響應不會成為可能導致災難恢復場景的單點故障。這些響應層應按順序創建，這樣只有在前一種響應無效時才會執行后一種響應。不應對單個警報運行多個逐級響應。相反，應使用警報指示響應是否未取得成功，如果沒有成功，則啟動下一級響應。Amazon Prescriptive Guidance 韌性系統生命周期建設框架 21 結論和資源結論和資源 通過在5個階段實施最佳實踐，本指南展示了一個有助于您不斷提高應用程序韌性的生命周期：

66、設定目標、設計和實施、評估和測試、運營以及響應和學習。關于本指南中所述服務和概念的更多信息，請參見以下資源。亞馬遜云科技服務：Amazon Backup Amazon Elastic Disaster Recovery Amazon Fault Injection Simulator(Amazon FIS)Amazon Resilience Hub Amazon Route 53 Application Recovery Controller Amazon X-Ray 博文和文章：可用性及其他：了解并提高基于亞馬遜云科技的分布式系統韌性 亞馬遜云科技故障隔離界限 亞馬遜云科技多區域基礎 云端混

67、沌工程 利用 Amazon Resilience Hub 和 Amazon CodePipeline 持續評估應用程序韌性 將內部應用程序災難恢復至亞馬遜云科技 可靠性支柱 Amazon Well-Architected Framework 韌性分析框架 Amazon Prescriptive Guidance 韌性系統生命周期建設框架 22 撰稿人撰稿人 本指南的撰稿人包括：Bruno Emer，亞馬遜云科技首席解決方案架構師 Clark Richey，亞馬遜云科技首席解決方案架構師 Elaine Harvey，亞馬遜云科技可靠性服務總經理 Jason Barto，亞馬遜云科技首席解決方案架構師 John Formento，亞馬遜云科技首席解決方案架構師 Lisi Lewis，亞馬遜云科技高級產品營銷經理 Michael Haken，亞馬遜云科技首席解決方案架構師 Neeraj Kumar，亞馬遜云科技首席解決方案架構師 Wangechi Doble，亞馬遜云科技首席解決方案架構師 Amazon Prescriptive Guidance 韌性系統生命周期建設框架 23 文檔歷史文檔歷史 下表描述了本指南的重要變更。如果您想要接收關于未來更新的通知，請訂閱 RSS 源。變更 說明 日期 首次發布(第 23 頁)2023 年 10 月 6 日