執行失敗模式分析的建議

適用於此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：03	使用失敗模式分析 (FMA) 來識別並排定解決方案元件中潛在失敗的優先順序。 執行 FMA 以協助您評估每個失敗模式的風險和效果。 判斷工作負載如何回應和復原。

本指南說明針對工作負載執行失敗模式分析 (FMA) 的最佳作法。 FMA 是識別工作負載內的潛在失敗點，以及據以規劃風險降低動作的作法。 在流程的每個步驟中，您會識別多個失敗類型的快射半徑，協助您設計新的工作負載或重構現有的工作負載，以將失敗的廣泛影響降到最低。

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

如果您完全略過 FMA 或執行不完整的分析，您的工作負載可能會發生未預測的行為，以及次佳設計所造成的潛在中斷。

定義

詞彙	定義
失敗模式	一種問題，可能會導致一或多個工作負載元件降級或嚴重影響到無法使用的點。
風險降低	您已識別出以主動或被動方式解決問題的活動。
偵測	您的基礎結構、數據和應用程式監視和警示程式和程式。

主要設計策略

必要條件

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

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

FMA 方法

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

分解工作負載

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

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

識別相依性

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

內部相依性是工作負載範圍中需要讓工作負載運作的元件。 典型的內部相依性包括 API 或秘密/金鑰管理解決方案，例如 Azure 金鑰保存庫。 針對這些相依性，擷取可靠性數據，例如可用性 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 前端。

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

元件	風險	可能性	效果/風險降低/注意	Outage
Microsoft Entra 識別碼	服務中斷	低	完整工作負載中斷。 相依於 Microsoft 進行補救。	完整
Microsoft Entra 識別碼	設定錯誤	中	用戶無法登入。 沒有下游效果。 技術支援中心會向身分識別小組報告設定問題。	無
Azure Front Door	服務中斷	低	外部使用者的完整中斷。 相依於 Microsoft 進行補救。	僅外部
Azure Front Door	區域中斷	非常低	最小效果。 Azure Front Door 是全域服務，因此全域流量路由會透過非作用的 Azure 區域引導流量。	無
Azure Front Door	設定錯誤	中	部署期間應該攔截錯誤設定。 如果在設定更新期間發生這些變更，系統管理員必須回復變更。 組態更新會導致短暫的外部中斷。	僅外部
Azure Front Door	DDoS 攻擊	中	可能會中斷。 Microsoft 管理 DDoS (L3 和 L4) 保護和 Azure Web 應用程式防火牆 封鎖大部分的威脅。 L7 攻擊的潛在影響風險。	部分中斷的可能性
Azure SQL	服務中斷	低	完整工作負載中斷。 相依於 Microsoft 進行補救。	完整
Azure SQL	區域中斷	非常低	自動故障轉移群組故障轉移至次要區域。 故障轉移期間的潛在中斷。 復原時間目標 (RTO) 和恢復點目標， (RPO) 在可靠性測試期間決定。	可能已滿
Azure SQL	可用性區域中斷	低	沒有影響	無
Azure SQL	惡意攻擊 (插入)	中	風險降到最低。 所有 Azure SQL 實例都是透過私人端點和網路安全組系結的虛擬網路， (NSG) 新增進一步的虛擬網路內部保護。	潛在低風險
App Service	服務中斷	低	完整工作負載中斷。 相依於 Microsoft 進行補救。	完整
App Service	區域中斷	非常低	最小效果。 受影響區域中用戶的延遲。 Azure Front Door 會自動將流量路由傳送至非受影響的區域。	無
App Service	可用性區域中斷	低	沒有影響。 應用程式服務已部署為區域備援。 如果沒有區域備援，可能會有作用。	無
App Service	DDoS 攻擊	中	最小效果。 輸入流量受到 Azure Front Door 和 Azure Web 應用程式防火牆 的保護。	無

相關連結

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

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單