本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
第二階段：設計及實施
在上一階段，您可以設定彈性目標。現在，在設計和實作階段，您會嘗試預測失敗模式並找出設計選擇，並依照您在前一階段設定的目標指引。您也可以定義變更管理的策略，以及開發軟體程式碼和基礎架構組態。以下幾節重點介紹了在考慮成本，複雜性和營運開銷等權衡時應考慮的 AWS 最佳實踐。
AWS Well-Architected 的框架
當您根據所需的彈性目標架構應用程式時，您需要評估多個因素，並在最佳的架構上進行權衡。若要建置高度彈性的應用程式，您必須考慮設計、建置和部署、安全性和作業等方面。AWS Well-Architected 的架
以下是 AWS Well-Architected 的架構如何協助您設計和實作符合彈性目標的應用程式的範例：
-
可靠性支柱：可靠性支柱強調建置應用程式的重要性，即使在故障或中斷時也能正確且一致地運作。例如， AWS Well-Architected Framework 建議您使用微服務架構，使您的應用程式更小、更簡單，因此您可以區分應用程式中不同元件的可用性需求。您還可以通過使用節流，重試指數退回，快速故障（負載脫落），冪等性，恆定工作，斷路器和靜態穩定性來獲得構建應用程序的最佳實踐的詳細說明。
-
全面審查： AWS Well-Architected 的框架鼓勵針對最佳實踐和設計原則對您的架構進行全面審查。 它提供了一種持續測量架構並識別需要改進的領域的方法。
-
風險管理： AWS Well-Architected 的架構可協助您識別和管理可能影響應用程式可靠性的風險。透過主動解決潛在故障情況，您可以降低其可能性或由此產生的損害。
-
持續改進：復原力是一個持續的過程， AWS Well-Architected 的框架強調持續改進。根據 AWS Well-Architected Framework 的指引，定期檢閱和改良您的架構和程序，您可以確保您的系統在面對不斷變化的挑戰和需求時保持彈性。
瞭解相依性
了解系統的依賴關係是恢復能力的關鍵。相依性包括應用程式內元件之間的連線，以及與應用程式外部元件 (例如協力廠商 API 和企業擁有的共用服務) 的連線。瞭解這些連接可協助您隔離和管理中斷，因為某個元件中的損壞可能會影響其他元件。這些知識可以幫助工程師評估減損的影響並相應地進行規劃，並確保資源得到有效使用。瞭解相依性可協助您建立替代策略並協調復原程序。它也可協助您判斷可以用軟相依性取代硬式相依性的案例，如此一來，您的應用程式可以在發生相依性損害時繼續提供業務功能。相依性也會影響負載平衡和應用程式擴展的決策。當您對應用程式進行變更時，瞭解相依性非常重要，因為它可以協助您判斷潛在的風險和影響。這些知識可協助您建立穩定、彈性的應用程式，協助進行錯誤管理、影響評估、減損復原、負載平衡、擴充和變更管理。您可以手動追蹤相依性，或使用工具和服務，例如瞭AWS X-Ray
災難復原策略
災難復原 (DR) 策略在建置和操作彈性應用程式方面扮演重要角色，主要是確保業務連續性。它保證了即使在災難性事件發生時，重要的業務運營也能以最少的可能損失持續存在，從而最大程度地減少停機時間和潛在的收入損失。災難復原策略對於資料保護至關重要，因為它們通常會整合多個位置的定期資料備份和資料複寫，這有助於保護寶貴的商業資訊，並協助防止災難發生時完全遺失。此外，許多行業都受到政策的監管，這些政策要求企業制定適當的災難恢復策略來保護敏感數據並確保服務在災難期間仍然可用。藉由確保最小的服務損害，DR 策略也增強了客戶的信任和滿意度。實作良好且經常實作的災難復原策略可縮短災難發生後的復原時間，並協助確保應用程式能夠快速恢復上線。此外，災難可能會產生可觀的成本，不僅是因為停機而造成的收入損失，還可能會因為還原應用程式和資料所造成的費用。精心設計的 DR 策略有助於抵禦這些財務損失。
您選擇的策略取決於應用程式的特定需求、RTO 和 RPO，以及您的預算。 AWS Elastic Disaster Recovery
如需詳細資訊，請參閱 AWS 網站上的「工作負載的災難復原」 AWS和「AWS 多區域基礎知識」。
定義CI/CD 策略
造成應用程式損壞的常見原因之一是程式碼或其他變更，會改變應用程式從先前已知的工作狀態。如果您不小心處理變更管理，它可能會導致頻繁的損害。變更的頻率會增加產生影響的機會。但是，較少進行變更的頻率會導致較大的變更集，因為變更集的複雜性較高，因此更有可能導致減值。持續整合和持續交付 (CI/CD) 實務的設計目的是讓變更保持小而頻繁 (從而提高生產力)，同時透過自動化讓每項變更都能達到高水準的檢驗。一些基本策略是：
-
完全自動化：CI/CD 的基本概念是盡可能自動化構建和部署過程。這包括建置、測試、部署，甚至監控。自動化管道有助於減少人為錯誤的可能性，確保一致性，並使流程更加可靠和高效。
-
測試驅動開發（TDD）：在編寫應用程序代碼之前編寫測試。這項做法可確保所有程式碼都有相關的測試，進而改善程式碼的可靠性和自動化檢測的品質。這些測試在 CI 管道中運行以驗證更改。
-
經常提交和集成：鼓勵開發人員經常提交代碼並經常執行集成。較小且頻繁的變更更易於測試和除錯，從而降低發生重大問題的風險。自動化降低了每次提交和部署的成本，從而使頻繁的集成成為可能。
-
不可變基礎結構：處理您的伺服器和其他基礎結構元件，例如靜態、不可變的實體。取代基礎架構，而不是盡可能地修改它，並透過經過測試並透過管道部署的程式碼來建置新的基礎結構。
-
回滾機制：始終有一種簡單，可靠且經常測試的方法來回滾更改，如果出現問題。能夠快速返回先前已知的良好狀態對於部署安全至關重要。這可以是恢復到先前狀態的簡單按鈕，也可以完全自動化並由警報啟動。
-
版本控制：在版本控制的存儲庫中將所有應用程序代碼，配置甚至基礎結構作為代碼維護。此做法有助於確保您可以輕鬆追蹤變更，並在需要時還原變更。
-
Canary 部署和藍/綠部署：首先將新版本的應用程式部署到基礎結構的子集，或維護兩個環境 (藍/綠)，可讓您驗證生產中的變更行為，並在必要時快速復原。
CI/CD 不僅與工具有關，而且與文化有關。創建一種重視自動化，測試和從失敗中學習的文化與實施正確的工具和流程同樣重要。如果在影響最小的情況下迅速完成回溯，則不應將其視為失敗，而是一種學習經驗。
執行 ORR
操作準備程度審查（ORR）有助於識別操作和程序上的差距。在 Amazon，我們建立了 ORR，透過最佳實務指導，將經營大規模服務數十年的經驗提煉成精心策劃的問題。ORR 捕獲先前學到的經驗教訓，並需要新的團隊以確保他們已經在其應用程序中考慮了這些課程。ORR 可以提供故障模式或失敗原因的清單，這些清單可以帶入以下彈性建模一節中描述的彈性建模活動中。如需詳細資訊，請參閱 AWS Well-Architected 的架構網站上的作業準備檢閱 (ORR)。
了解 AWS 故障隔離界限
AWS 提供多重故障隔離界限，協助您達成彈性目標。您可以使用這些界限來利用它們提供的可預測影響限制範圍。您應該熟悉如何使用這些界限來設計 AWS 服務，以便有意針對您為應用程式選取的相依性做出有意的選擇。若要瞭解如何在應用程式中使用邊界，請參閱 AWS 網站上的AWS 錯誤隔離邊界。
選取回應
系統可以通過多種方式對警報進行響應。某些警示可能需要作業團隊的回應，而其他警示可能會在應用程式內觸發自我修復機制。您可能會決定將可自動化的回應保留為手動作業，以控制自動化成本或管理工程限制。警報的回應類型可能會被選為執行回應成本的函數、警報的預期頻率、警報的準確度，以及完全沒有回應警示的潛在業務損失。
例如，當伺服器處理序當機時，作業系統可能會重新啟動該處理程序，或者可能會佈建新伺服器，而舊伺服器則終止，或者可能會指示操作員遠端連線至伺服器並重新啟動伺服器。這些回應的結果相同，即重新啟動應用程式伺服器處理序，但實作和維護成本的層級不同。
注意
您可以選擇多個響應以採取深入的彈性方法。例如，在先前的案例中，應用程式小組可能會選擇實作所有三個回應，每個回應之間的時間延遲。如果失敗的伺服器處理序指示器在 30 秒後仍處於警告狀態，則該群組可以假設作業系統無法重新啟動應用程式伺服器。因此，他們可能會建立 auto Scaling 群組來建立新的虛擬伺服器，並還原應用程式伺服器處理序。如果指示器在 300 秒後仍處於警報狀態，則可能會向操作人員發送警報以連接到原始服務器並嘗試恢復該過程。
應用團隊和業務選擇的回應應該反映企業對工程時間的前期投資來抵消營運開銷的需求。您應該仔細考慮每個響應選項的限制和預期的維護，以選擇響應-例如靜態穩定性，軟件模式（例如斷路器）或操作程序。可能存在一些標準回應來引導應用程式團隊，因此您可以使用集中式架構所管理的程式庫和模式作為此考量的輸入。
韌性建模
彈性模型記錄了應用程式將如何應對不同的預期中斷。 透過預測中斷情況，您的團隊可以實作可觀察性、自動化控制和復原程序，以減輕或預防損害，即使發生中斷。 AWS 通過使用彈性分析框架創建了開發彈性模型的指導。 此架構可協助您預測中斷情況及其對應用程式的影響。 藉由預測中斷，您可以識別建置彈性、可靠應用程式所需的緩和措施。 我們建議您使用彈性分析架構，隨著應用程式生命週期的每次迭代更新您的彈性模型。 在每次反覆運用此架構，藉由預測設計階段中斷，並在生產部署之前和之後測試應用程式，有助於減少事件。 使用此框架開發彈性模型可幫助您確保滿足彈性目標。
安全失敗
如果您無法避免中斷，請安全地失敗。請考慮使用預設的故障安全作業模式來建立應用程式，不會造成重大的業務損失。數據庫的故障安全狀態的一個例子是默認為只讀操作，其中用戶不允許創建或更改任何數據。視資料的敏感度而定，您甚至可能希望應用程式預設為關閉狀態，甚至不執行唯讀查詢。請考慮應用程式的故障安全狀態，並且在極端條件下預設為此操作模式。
