定義可靠性目標的建議

  • 發行項

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

RE：04 定義元件、流程和整體解決方案的可靠性與復原目標。 將目標可視化，以交涉、取得共識、設定期望，以及推動動作以達到理想狀態。 使用定義的目標來建置健康情況模型。 健全狀況模型會定義狀況良好、降級和狀況不良狀態的外觀。

本指南說明定義重要工作負載和流程的可用性和復原目標計量的建議。 可靠性目標是透過與商務項目關係人進行研討會練習來衍生。 目標會透過監視和測試來精簡。

透過您的內部項目關係人，設定工作負載可靠性的實際期望，讓項目關係人可以透過合約合約與客戶溝通這些期望。 實際的期望也可協助項目關係人瞭解及支援您的架構設計決策，並瞭解您正在設計以最佳方式符合您同意的目標。

請考慮使用下列計量來量化業務需求。

詞彙 定義
服務等級目標 (SLO) 百分比目標，代表元件和可靠性層的健康情況。 層級越高，元件就越可靠。 複合 SLO 代表整個工作負載的匯總目標，以及元件 SLO 的帳戶。
SLI (服務等級指標) 服務發出的計量。 SLI 計量會匯總以量化 SLO 值。
服務等級協定 (SLA) 服務提供者與服務客戶之間的合約合約。 合約會定義 SLO。 不符合合約可能會對服務提供者造成財務後果。
平均復原時間 (MTTR) 偵測到失敗之後還原元件所需的時間。
平均失敗時間 (MTBF) 工作負載可以在不中斷的情況下執行預期函式的持續時間，直到失敗為止。
復原時間目標 (RTO) 應用程式在事件發生之後可能無法使用的最大可接受時間。
復原點目標 (RPO) 事件期間數據遺失的最大可接受持續時間。

在使用者流程和系統流程的內容中，定義這些計量的工作負載目標值。 藉由這些流程對您的需求有多重要，來識別和評分這些流程。 使用這些值來推動工作負載的設計，以架構、檢閱、測試和事件管理作業。 無法符合目標會影響超出容錯等級的業務。

主要設計策略

技術討論不應推動您為重要流程定義可靠性目標的方式。 相反地，商務項目關係人應該專注於客戶，因為它們定義工作負載的需求。 技術專家可協助項目關係人指派與這些需求相互關聯的實際數值。 當他們分享知識時，技術專家允許與實際 SLO 的交涉和相互共識。

請考慮如何將需求對應至可測量數值的範例。 專案關係人估計對於重要的使用者流程而言，在一般上班時間的停機時間會導致每月營收遺失 X 美元。 該金額會與設計可用性 SLO 為 99.95% 而非 99.9% 的流程預估成本進行比較。 決策者必須討論該收益損失的風險是否超過保護所需的額外成本和管理負擔。 當您檢查流程並建置完整的目標清單時，請遵循此模式。

請記住，可靠性目標與效能目標不同。 可靠性目標著重於可用性和復原。 若要設定可靠性目標，請先定義最廣泛的需求，然後定義更特定的計量，以符合高階需求。

最高層級的可靠性與復原需求和相互關聯的計量可能包括，例如，所有區域的應用程式可用性為 99.9%，或美國區域的目標 RTO 為 5 小時。 定義這些類型的目標可協助您識別哪些重要流程涉及這些目標。 然後您可以考慮元件層級目標。

取捨：概念上的差距可能是工作負載元件的技術限制，以及對企業的意義，例如，每秒以 MB 為單位的輸送量與每秒交易數。 在這兩個檢視之間建立模型可能很困難。 不要過度建立解決方案，而是嘗試以經濟但有意義的方式加以解決。

可用性度量

SLA 和 SLA

可用性計量會與您用來定義 SLA 的 SLO 相互關聯。 工作負載 SLO 決定在指定期間內可容忍多少停機時間，例如每月少於 1 小時。 若要確定您可以符合 SLO 目標，請檢閱每個元件的 Microsoft SLA。 請注意符合高 SLA 所需的備援程度。 例如，Microsoft 保證 Azure Cosmos DB 多區域部署的 SLA 高於單一區域部署的保證。

注意

Azure SLA 不一定會涵蓋服務的所有層面。 例如，Azure 應用程式閘道 具有可用性 SLA，但 Azure Web 應用程式防火牆 功能不保證會阻止惡意流量通過。 當您開發 SLA 和 SLA 時，請考慮此限制。

收集個別工作負載元件的 SLA 之後，請計算複合 SLA。 複合 SLA 應該符合工作負載的目標 SLO。 根據您的架構設計，計算複合 SLA 牽涉到數個因素。 請思考一下下列範例。

注意

下列範例中的 SLA 值是 假設的 ，僅供 示範之用。 它們 不是用來代表 Microsoft 支援的目前值 。

複合 SLA 牽涉到多個支援應用程式的服務，其可用性層級不同。 例如，請考慮寫入 Azure SQL Database 的 Azure App 服務 Web 應用程式。 假設這些 SLA 可能是：

  • App Service Web 應用程式 = 99.95%
  • SQL Database = 99.99%

此應用程式可以預期的停機時間上限為何？ 如果其中一個服務失敗，整個應用程式就會失敗。 每個服務失敗的機率都是獨立的，因此此應用程式的複合 SLA 為 99.95%，× 99.99% = 99.94%。 該值低於個別 SLA。 這個結論不令人意外，因為依賴多個服務的應用程式會有更多潛在的失敗點。

您可以藉由建立獨立的後援路徑來改善複合 SLA。 例如，如果 SQL Database 無法使用，請將交易放入佇列，以供稍後處理：

顯示後援路徑的圖表。Web 應用程式方塊會顯示分支分支，以 SQL Database 或佇列。

在此設計中，即使無法連線到資料庫，應用程式仍可使用。 不過，如果資料庫和佇列同時失敗，則會失敗。 同時失敗的預期時間百分比為 0.0001 × 0.001，因此以下是此合併路徑的複合 SLA：

資料庫或佇列 = 1.0 — (0.0001 × 0.001) = 99.9999%

複合 SLA 總計：

Web 應用程式和 (資料庫或佇列) = 99.95% × 99.99999% = ~99.95%

這種方法會造成取捨：

  • 應用程式邏輯較為複雜。
  • 您需支付佇列的費用。
  • 您必須考慮數據一致性問題。

針對多區域部署，複合 SLA 的計算方式如下：

  • N 是部署在一個區域中之應用程式的複合 SLA。

  • R 是部署應用程式所在的區域數目。

應用程式在所有區域中同時失敗的預期機率為 ((1 − N) ^ R)。 例如，如果假設的單一區域 SLA 為 99.95%：

  • 兩個區域的合併 SLA = (1 (1 1 - 0.9995) ^ 2) = 99.999975%

  • 四個區域的合併 SLA = (1 (1 1 - 0.9995) ^ 4) = 99.999999%

定義適當的 SLO 需要一些時間和仔細考慮。 商務項目關係人應該了解客戶如何使用應用程式。 他們也應該瞭解可靠性容錯。 此意見反應應通知目標。

SLA 值

下表定義常見的 SLA 值。

SLA 每週停機時間 每月停機時間 每年停機時間
99% 1.68 小時 7.2 小時 3.65 天
99.9% 10.1 分鐘 43.2 分鐘 8.76 小時
99.95% 5 分鐘 21.6 分鐘 4.38 小時
99.99% 1.01 分鐘 4.32 分鐘 52.56 分鐘
99.999% 6 秒 25.9 秒 5.26 分鐘

當您考慮流程內容中的複合 SLA 時，請記住不同的流程有不同的重要性定義。 當您建置複合 SLA 時，請考慮這些差異。 非關鍵流程可能會有您應該從計算中省略的元件，因為它們在短暫無法使用時不會影響客戶體驗。

注意

客戶面向的工作負載和內部使用工作負載有不同的 SLO。 一般而言，內部使用工作負載可能會比客戶面向工作負載限制較少的可用性 SLO。

SLA

請將 SLO 視為構成 SLO 的元件層級計量。 最重要的 SLA 是從客戶的觀點影響重要流程的 SLI。 對於許多流程，SLA 包括延遲、輸送量、錯誤率和可用性。 良好的 SLI 可協助您識別 SLO 何時有遭到入侵的風險。 盡可能將 SLI 與特定客戶相互關聯。

若要避免收集無用計量，請限制每個流程的 SLA 數目。 儘可能針對每個流程的三個SLA為目標。

復原計量

復原目標會對應至 RTO、RPO、MTTR 和 MTBF 計量。 相較於可用性目標，這些度量的復原目標不會高度依賴 Microsoft SLA。 Microsoft 只會針對某些產品發佈 RTO 和 RPO 保證，例如 SQL Database。

實際復原目標的定義取決於您 的失敗模式分析和 計劃，以及商務持續性和 災害復原的測試。 完成這項工作之前，請與專案關係人討論期望目標，並確定您的架構設計支持復原目標，以獲得最佳瞭解。 清楚傳達給項目關係人，任何未徹底測試復原計量的流程或整個工作負載都不應該保證 SLA。 請確定項目關係人了解復原目標會在工作負載更新時隨著時間變更。 當新增客戶或採用新技術來改善客戶體驗時，工作負載可能會變得更複雜。 這些變更可能會增加或減少您的復原計量。

注意

MTBF 在定義和保證時可能會是一項挑戰。 平臺即服務 (PaaS) 或軟體即服務 (SaaS) 可能會失敗並復原，而不需要雲端提供者的任何通知，而且程式對您或您的客戶完全透明。 如果您定義此計量的目標，請只涵蓋您控制件下的元件。

當您定義復原目標時，請定義起始復原的臨界值。 例如，如果 Web 節點超過 5 分鐘無法使用，則會自動將新的節點新增至集區。 定義所有元件的臨界值，考慮特定元件的復原牽涉到哪些專案，包括對其他元件和相依性的影響。 您的閾值也應該考慮 暫時性錯誤 ，以確保您不會太快速地啟動復原動作。 記錄並與項目關係人分享復原作業的潛在風險，例如客戶的數據遺失或會話中斷。

建置健康情況模型

使用您針對可靠性目標收集的數據，針對每個工作負載和相關聯的重要流程建置健康情況模型。 健康情況模型會定義流程和工作負載 的健康情況、 降級和 狀況不良 狀態。 狀態可確保適當的作業優先順序。 此模型也稱為 交通燈模型。 此模型會為狀況良好、已降級為黃色指派綠色，並針對狀況不良指派紅色。 健康情況模型可確保流程的狀態何時從狀況良好變更為降級或狀況不良。

定義狀況良好、降級和狀況不良狀態的方式取決於您的可靠性目標。 以下是您可以定義狀態的一些範例：

  • 綠色或狀況良好的狀態表示關鍵非功能需求和目標已完全滿足，且資源會以最佳方式使用。 例如，95% 的要求會在 =500 毫秒內<處理，Azure Kubernetes Service (AKS) 節點在 X% 使用。

  • 黃色或降級狀態表示流程的一或多個元件會根據其定義的臨界值發出警示，但流程可運作。 例如，偵測到記憶體節流。

  • 紅色或狀況不良的狀態表示您的可靠性目標所允許的效能降低已持續超過允許的時間，或流程變得無法使用。

注意

健康情況模型不應將所有失敗視為相同。 健康情況模型應該區分 暫時性 和非 傳輸 性錯誤。 其應該清楚區分預期暫時性但可復原的失敗，以及真正的災難狀態。

此模型的運作方式是使用持續改善原則所開發的監視和警示策略。 隨著工作負載演進，您的健康情況模型必須隨著這些模型演進。

如需分層應用程式健康情況模型的詳細設計考慮和建議，請參閱在任務關鍵性工作負載設計區域中找到 的健康情況模型指引 。 如需有關監視和警示設定的詳細指引，請參閱 健康情況監視 指南。

視覺效果

若要讓您的作業小組和工作負載項目關係人知道工作負載健康情況模型的即時狀態和整體趨勢，請考慮在監視解決方案中建立 儀錶板 。 與專案關係人討論視覺效果解決方案，以確保您傳遞其價值和容易取用的資訊。 他們也可能想要查看每周、每月或每季產生的報告。

Azure 指導

Azure SLA 可為運行時間和連線能力提供 Microsoft 承諾。 不同的服務有不同的 SLA，有時服務內的 SKU 有不同的 SLA。 如需詳細資訊，請參閱 線上服務的服務等級協定。

如果不符合 SLA，則 Azure SLA 包含取得服務點數的程式，以及每個服務的可用性定義。 SLA 的層面會作為強制執行原則。

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單