執行失敗模式分析的建議
適用於 Azure Well-Architected 架構可靠性檢查清單建議：
| RE：03 | 使用失敗模式分析 （FMA） 來識別工作負載中的潛在失敗。 識別相依性和失敗點，並針對這些失敗開發風險降低策略。 |
|---|
本指南說明針對工作負載執行失敗模式分析 （FMA） 的最佳做法。 FMA 是識別工作負載內潛在失敗點和相關流程，並據以規劃緩和動作的做法。 在流程的每個步驟中，您會識別多個失敗類型的爆破半徑，以協助您設計新的工作負載或重構現有的工作負載，以將失敗的廣泛影響降到最低。
FMA 的主要原則是，無論應用多少層韌性，都會發生失敗。 更複雜的環境更容易遭遇更多類型的故障。 鑒於此現實，FMA 可讓您設計工作負載，以承受大部分類型的失敗，並在發生失敗時正常復原。
如果您完全略過 FMA 或執行不完整的分析，您的工作負載將面臨未預測的行為和次佳設計所造成的潛在中斷風險。
定義
| 術語 | 定義 |
|---|---|
| 失敗模式 | 一種問題可能會導致一個或多個工作負載元件降級或受到嚴重影響，甚至無法使用。 |
| 緩解 | 您已識別以主動或反應方式解決問題的活動。 |
| 偵測 | 您的基礎設施、資料和應用程式的監控和警示過程及程序。 |
關鍵設計策略
審查並實施有關識別 流程的建議。 假設您已根據關鍵性來識別並設定使用者和系統流程的優先順序。
您收集的數據以及您在工作中建立的成品，會提供整個流程中涉及之數據路徑的具體描述。 若要在 FMA 工作中成功，成品中的精確度和完整性非常重要。
判斷重要流程之後，您可以規劃其必要元件。 接下來，依照每個流程逐步找出相依性，包括第三方服務和潛在失敗點，以及規劃風險降低策略。
分解工作負載
當您從想法移至設計時，必須識別支援工作負載所需的元件類型。 您的工作負載會決定您必須規劃的必要元件。 一般而言，您需要規劃輸入控件、網路、計算、數據、記憶體、支援服務（例如驗證、傳訊和秘密或密鑰管理），以及輸出控制。 在設計工作的這個階段，您可能不知道要部署的特定技術，因此您的設計看起來可能如下列範例所示。
建立初始架構設計之後，您可以重疊流程，以識別這些流程中使用的離散元件，並建立描述流程及其元件的清單或工作流程圖表。 要了解元件的重要性，請利用您指派給流程的關鍵性定義。 請考慮元件故障對流程的影響。
識別相依性
識別您的工作負載相依性，以執行單一失敗點分析。 分解工作負載和重疊流程可讓您深入瞭解工作負載內部和外部的相依性。
內部相依性是工作負載範圍中需要讓工作負載運作的元件。 典型的內部相依性包括 API 或秘密/金鑰管理解決方案，例如 Azure Key Vault。 針對這些相依性，擷取可靠性數據，例如可用性 SLA 和調整限制。 外部相依性是工作負載範圍以外的必要元件，例如另一個應用程式或第三方服務。 典型的外部相依性包括驗證解決方案，例如Microsoft Entra ID，以及雲端連線解決方案，例如 Azure ExpressRoute。
識別並記錄工作負載中的相依性，並將其包含在流程檔成品中。
評估失敗點
在工作負載的重要流程中，請考慮每個元件，並判斷該元件及其相依性可能受到失敗模式的影響。 請記住，當規劃復原力和恢復策略時，需要考慮許多故障模式。 任何一個元件在任何指定時間都會受到多個失敗模式的影響。 這些失敗模式包括：
區域性中斷。 整個 Azure 區域無法使用。
可用性區域中斷。 某個 Azure 可用性區域無法使用。
服務中斷。 無法使用一或多個 Azure 服務。
分散式阻斷服務 （DDoS） 或其他惡意攻擊。
應用程式或元件設定錯誤。
運算子錯誤。
計劃性維護中斷。
元件超載。
分析應該一律在您嘗試分析的流程內容中，因此請務必記錄該流程對使用者和預期結果的影響。 例如，如果您有電子商務應用程式並正在分析客戶流程，特定失敗模式對一或多個元件的影響可能是所有客戶都無法完成結帳。
請考慮每種失敗模式類型的可能性。 有些不太可能，例如多區或多區域中斷，並且除了備援之外，新增緩解計劃不宜浪費資源和時間。
緩解
風險降低策略分為兩大類：建置更多復原能力，並針對效能降低進行設計。
建置更多復原功能包括將備援新增至您的元件，例如基礎結構、數據和網路功能，並確保應用程式設計遵循持久性的最佳做法，例如將整合型應用程式分成隔離的應用程式和微服務。 如需詳細資訊，請參閱備援建議 和 以及自我保留建議 和。
若要設計面對降級效能的狀況，請識別出可能停用一個或多個流程元件但不會完全停用該流程的潛在故障點。 若要維護端對端流程的功能，您可能需要將一或多個步驟重新路由傳送至其他元件，或接受失敗的元件執行函式，讓函式在用戶體驗中不再提供。 若要返回電子商務應用程式範例，微服務之類的失敗元件可能會導致您的建議引擎無法使用，但客戶仍然可以搜尋產品並完成其交易。
您也需要規劃依賴的緩和措施。 強式相依性在應用程式函式和可用性中扮演重要角色。 如果他們缺席或發生故障，可能會有顯著的影響。 缺少弱式相依性只會影響特定功能，而不會影響整體可用性。 這項區別反映了維護服務與其相依性之間高可用性關聯性的成本。 將相依性分類為強式或弱式，以協助您識別哪些元件對應用程式而言很重要。
如果應用程式具有無法運作的強式相依性，則這些相依性的可用性和復原目標應與應用程式本身的目標一致。 將相依性降至最低，以控制應用程式可靠性。 如需詳細資訊，請參閱 將應用程式服務之間的協調最小化，以達到延展性。
如果應用程式生命週期與其相依性的生命週期緊密結合，應用程式的運作靈活性可能會受到限制，特別是針對新版本。
偵測
失敗偵測是確保您在分析中正確識別失敗點並正確規劃風險降低策略的必要條件。 在此內容中偵測表示監視基礎結構、數據和應用程式，以及在發生問題時發出警示。 盡可能自動偵測，並將備援建置到您的作業程式中，以確保一律會攔截警示，並快速回應以符合您的商務需求。 如需詳細資訊，請參閱 監控的建議。
結果
如需分析的結果，請建立一組檔，以有效傳達您的結果、您相對於流程元件和風險降低所做的決策，以及失敗對工作負載的影響。
在您的分析中，根據嚴重性和可能性來設定失敗模式和風險降低策略的優先順序。 使用此優先順序，將您的文件重點放在那些常見且嚴重到值得花費時間、精力和資源來設計緩解策略的失敗模式上。 例如，可能存在一些在出現或偵測上非常罕見的失敗模式。 設計針對這些問題的減緩策略並不值得成本。
請參閱下列 範例數據表 作為文件起點。
在您初始的 FMA 練習中，您產生的文件大多數是理論上的規劃。 FMA 檔應該定期檢閱和更新，以確保它們與您的工作負載保持 up-to日期。 混亂測試和真實世界體驗可協助您隨著時間調整分析。
Azure 支援
使用 Azure 監視器 和 Log Analytics 來偵測工作負載中的問題。 如需基礎結構、應用程式和資料庫相關問題的進一步深入解析，請使用 Application Insights、Container Insights、Network Insights、VM Insights和 SQL Insights等工具。
Azure Chaos Studio 是一種受控服務，使用混亂工程來協助您測量、瞭解及改善雲端應用程式和服務復原能力。
如需將 FMA 原則套用至常見 Azure 服務的相關信息，請參閱 Azure 應用程式的失敗模式分析。
例
下表顯示一個 FMA 範例，適用於裝載於 Azure App Service 實例與 Azure SQL 資料庫且由 Azure Front Door 前端裝載的電子商務網站。
使用者流程：使用者登入、產品搜尋和購物車互動
| 元件 | 風險 | 可能性 | 效果/風險降低/附注 | 中斷 |
|---|---|---|---|---|
| 微软Entra ID | 服務中斷 | 低 | 完整工作負載中斷。 依賴Microsoft進行補救。 | 全滿 |
| Microsoft Entra ID | 設定錯誤 | 中等 | 用戶無法登入。 沒有下游效果。 技術支援中心向身分識別小組回報設定問題。 | 沒有 |
| Azure Front Door（Azure 前端服務） | 服務中斷 | 低 | 外部使用者的完整中斷。 依賴微軟進行補救措施。 | 僅限外部 |
| 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） 會新增進一步的虛擬網路內部保護。 | 低風險，可能部分中斷 |
| 應用服務 | 服務中斷 | 低 | 全部工作負載中斷。 依賴 Microsoft 進行補救。 | 滿 |
| 應用程式服務 | 區域性中斷 | 非常低 | 最小效果。 受影響區域中用戶的延遲。 Azure Front Door 會自動將流量路由傳送至非受影響的區域。 | 沒有 |
| 應用程式服務 | 可用性區域中斷 | 低 | 沒有效果。 應用程式服務已部署為區域備援。 如果沒有區域備援，可能會有影響。 | 沒有 |
| 應用程式服務 | DDoS 攻擊 | 中等 | 最小效果。 進入流量受到 Azure Front Door 和 Azure Web 應用程式防火牆的保護。 | 沒有 |
相關連結
可靠性檢查清單
請參閱一組完整的建議。