執行失敗模式分析的建議

適用於此 Azure 架構完善的架構可靠性檢查清單建議：

本指南說明針對工作負載執行失敗模式分析 （FMA） 的最佳做法。 FMA 是識別工作負載內潛在失敗點和相關流程，並據以規劃緩和動作的做法。 在流程的每個步驟中，您都可以確定多種失敗類型的影響範圍，這有助於您設計新的工作負載或重構現有的工作負載，以將失敗的廣泛影響降到最低。

FMA 的主要原則是，無論套用多少層復原，都會發生失敗。 更複雜的環境會公開給更多類型的失敗。 鑒於此現實，FMA 可讓您設計工作負載，以承受大部分類型的失敗，並在發生失敗時正常復原。

如果您完全略過 FMA 或執行不完整的分析，您的工作負載將面臨未預測的行為和次佳設計所造成的潛在中斷風險。

定義

關鍵設計策略

檢閱並實作 識別流程的建議。 假設您已根據關鍵性來識別並設定使用者和系統流程的優先順序。

您收集的數據以及您在工作中建立的成品，會提供整個流程中涉及之數據路徑的具體描述。 若要在 FMA 工作中成功，成品中的精確度和完整性非常重要。

判斷重要流程之後，您可以規劃其必要元件。 接下來，依照每個流程逐步找出相依性，包括第三方服務和潛在失敗點，以及規劃風險降低策略。

分解工作負載

當您從構思轉向設計時，必須識別支援工作負載所需的元件類型。 您的工作負載會決定您必須規劃的必要元件。 一般而言，您需要規劃輸入控件、網路、計算、數據、記憶體、支援服務（例如驗證、傳訊和秘密或密鑰管理），以及輸出控制。 在設計工作的這個階段，您可能不知道要部署的特定技術，因此您的設計看起來可能如下列範例所示。

建立初始架構設計之後，您可以重疊流程，以識別這些流程中使用的離散元件，並建立描述流程及其元件的清單或工作流程圖表。 若要瞭解元件的關鍵性，請使用您指派給流程的嚴重性定義。 請考慮元件對流程故障的影響。

識別相依性

識別您的工作負載相依性，以執行單一失敗點分析。 分解工作負載和重疊流程可讓您深入瞭解工作負載內部和外部的相依性。

內部相依性是工作負載範圍中需要讓工作負載運作的元件。 典型的內部相依性包括 API 或秘密/金鑰管理解決方案，例如 Azure Key Vault。 針對這些相依性，擷取可靠性數據，例如可用性 SLA 和調整限制。 外部相依性是工作負載範圍以外的必要元件，例如另一個應用程式或第三方服務。 典型的外部相依性包括驗證解決方案，例如Microsoft Entra ID，以及雲端連線解決方案，例如 Azure ExpressRoute。

識別並記錄工作負載中的相依性，並將其包含在流程檔成品中。

評估失敗點

在工作負載的重要流程中，請考慮每個元件，並判斷該元件及其相依性可能受到失敗模式的影響。 請記住，規劃復原和復原時需要考慮許多失敗模式。 任何一個元件在任何指定時間都會受到多個失敗模式的影響。 這些失敗模式包括：

• 區域性中斷。 整個 Azure 區域無法使用。

• 可用性區域中斷。 無法使用 Azure 可用性區域。

• 服務中斷。 無法使用一或多個 Azure 服務。

• 分散式阻斷服務 （DDoS） 或其他惡意攻擊。

• 應用程式或元件設定錯誤。

• 運算子錯誤。

• 計劃性維護中斷。

• 元件多載。

分析應該一律在您嘗試分析的流程內容中，因此請務必記錄該流程對使用者和預期結果的影響。 例如，如果您有電子商務應用程式並正在分析客戶流程，特定失敗模式對一或多個元件的影響可能是所有客戶都無法完成結帳。

請考慮每種失敗模式類型的可能性。 有些不太可能，例如多區域或多區域中斷，而且除了備援之外新增風險降低規劃，也不適合使用資源和時間。

風險降低

風險降低策略分為兩大類：建置更多復原能力，並針對效能降低進行設計。

建置更多復原功能包括將備援新增至您的元件，例如基礎結構、數據和網路功能，並確保應用程式設計遵循持久性的最佳做法，例如將整合型應用程式分成隔離的應用程式和微服務。 如需詳細資訊，請參閱 備援 建議和 自我保留的建議。

若要針對效能降低而設計，請找出可能停用流程一或多個元件，但未完全停用該流程的潛在失敗點。 若要維護端對端流程的功能，您可能需要將一或多個步驟重新路由傳送至其他元件，或接受失敗的元件執行函式，讓函式在用戶體驗中不再提供。 若要返回電子商務應用程式範例，微服務之類的失敗元件可能會導致您的建議引擎無法使用，但客戶仍然可以搜尋產品並完成其交易。

您也需要規劃相依性的緩和措施。 強式相依性在應用程式函式和可用性中扮演重要角色。 如果他們缺席或發生故障，可能會有顯著的影響。 缺少弱式相依性只會影響特定功能，而不會影響整體可用性。 這項區別反映了維護服務與其相依性之間高可用性關聯性的成本。 將相依性分類為強式或弱式，以協助您識別哪些元件對應用程式而言很重要。

如果應用程式具有無法運作的強式相依性，則這些相依性的可用性和復原目標應與應用程式本身的目標一致。 將相依性降至最低，以控制應用程式可靠性。 如需詳細資訊，請參閱 將應用程式服務之間的協調降至最低，以達到延展性。

如果應用程式生命週期與其相依性的生命週期緊密結合，應用程式的運作靈活性可能會受到限制，特別是針對新版本。

偵測

為了確保您已在分析中正確識別失敗點，並妥善規劃風險降低策略，失敗偵測是不可或缺的。 在此內容中偵測表示監視基礎結構、數據和應用程式，以及在發生問題時發出警示。 盡可能自動偵測，並將備援建置到您的作業程式中，以確保一律會攔截警示，並快速回應以符合您的商務需求。 如需詳細資訊，請參閱 監視的建議。

結果

如需分析的結果，請建立一組檔，以有效傳達您的結果、您相對於流程元件和風險降低所做的決策，以及失敗對工作負載的影響。

在您的分析中，根據嚴重性和可能性來設定失敗模式和風險降低策略的優先順序。 使用此優先順序，將您的檔著重在常見且嚴重到足以保證花費時間、精力和資源來設計周圍風險降低策略的失敗模式。 例如，在發生或偵測時，可能會有一些非常罕見的失敗模式。 針對這些策略設計風險降低策略並不值得成本。

如需檔起點，請參閱下列 範例表格 。

在初始 FMA 練習中，您產生的檔大多是理論上的規劃。 FMA 檔應該定期檢閱和更新，以確保它們能隨時掌握您的工作負載。 混亂測試和真實世界體驗可協助您隨著時間調整分析。

Azure 便利化

使用 Azure 監視器 和 Log Analytics 來偵測工作負載中的問題。 如需基礎結構、應用程式和資料庫相關問題的進一步深入解析，請使用Application Insights、Container Insights、Network Insights、VM Insights 和 SQL Insights 等工具。

Azure Chaos Studio 是一項受管理的服務，使用混沌工程來協助您測量、了解及改善雲端應用程式和服務復原能力。

如需將 FMA 原則套用至常見 Azure 服務的相關信息，請參閱 Azure 應用程式的失敗模式分析。

範例

下表顯示一個 FMA 範例，此網站裝載於具有 Azure SQL 資料庫的 Azure App 服務 實例上，且前面是 Azure Front Door。

使用者流程：使用者登入、產品搜尋和購物車互動

相關連結

• Azure 應用程式的失敗模式分析
• 復原和相依性

可靠性檢查清單

請參閱一組完整的建議。