定義可靠性目標的建議
適用於此 Azure 架構完善的架構可靠性檢查清單建議：
| RE：04 | 定義元件、流程和整體解決方案的可靠性與復原目標。 將目標可視化，以談判、取得共識、設定期望，以及推動動作以達到理想狀態。 使用定義的目標來建置健康情況模型。 健康情況模型會定義狀況良好、降級和狀況不良狀態的外觀。 |
|---|
本指南說明定義重要工作負載和流程的可用性和復原目標計量的建議。 可靠性目標是透過與商務專案關係人的工作坊練習來衍生。 目標會透過監視和測試來精簡。
配合您的內部專案關係人，設定對工作負載可靠性的實際期望，讓專案關係人可以透過合約協議將向客戶傳達這些期望。 現實的期望也有助於項目關係人瞭解和支援您的架構設計決策，並知道您正在設計以達到您同意的目標。
請考慮使用下列計量來量化商務需求。
| 詞彙 | 定義 |
|---|---|
| 服務等級目標 （SLO） | 測量工作負載或應用程式的效能和可靠性。 SLO 是針對特定客戶互動所設定的特定可測量目標。 這是您根據使用者預期收到的服務品質，針對應用程式設定工作負載的目標。 |
| 服務等級指標 （SLI） | 服務發出的計量。 SLI 計量會匯總以量化 SLO 值。 |
| 服務等級協定 (SLA) | 服務提供者與服務客戶之間的合約合約。 不符合合約可能會對服務提供者造成財務後果。 |
| 平均復原時間 （MTTR） | 偵測到失敗后還原元件所花費的時間。 |
| 平均失敗時間 （MTBF） | 工作負載可以在不中斷的情況下執行預期函式的持續時間，直到失敗為止。 |
| 復原時間目標 (RTO) | 應用程式在事件發生后無法使用的最大可接受時間。 |
| 復原點目標 (RPO) | 事件期間數據遺失的最大可接受持續時間。 |
在使用者流程和系統流程的內容中，定義這些計量的工作負載目標值。 根據這些流程 對您的需求有多重要來識別和評分。 使用值，以架構、檢閱、測試和事件管理作業來驅動工作負載的設計。 不符合目標會影響超出容錯層級的業務。
關鍵設計策略
技術討論不應推動您定義重要流程的可靠性目標的方式。 相反地，業務項目關係人應該專注於客戶，因為他們定義了工作負載的需求。 技術專家可協助項目關係人指派與這些需求相互關聯的實際數值。 當他們分享知識時，技術專家允許就現實SLO進行談判和相互共識。
請考慮如何將需求對應至可測量數值的範例。 專案關係人估計，對於重要的使用者流程，在一般上班時間的停機時間會導致每月營收損失 X 美元。 與設計可用性 SLO 為 99.95% 而非 99.9% 的流程預估成本進行比較。 決策者必須討論該收入損失的風險是否超過保護其所需的額外成本和管理負擔。 當您檢查流程並建置完整的目標清單時，請遵循此模式。
請記住，可靠性目標與效能目標不同。 可靠性目標著重於可用性和復原。 若要設定可靠性目標，請先定義最廣泛的需求，然後定義更具體的計量，以符合高階需求。
最高層級的可靠性與復原需求和相互關聯的計量可能包括，例如，所有區域的應用程式可用性為99.9%，或美洲區域的目標 RTO 為5小時。 定義這些類型的目標可協助您識別哪些重要流程涉及這些目標。 然後，您可以考慮元件層級目標。
取捨：您的工作負載元件技術限制與業務的意義之間可能存在概念上的差距，例如，每秒以 MB 為單位的輸送量與每秒交易數。 在這兩個檢視之間建立模型可能很困難。 與其過度設計解決方案，不如嘗試以經濟但有意義的方式加以處理。
可用性計量
SLO 和 SLA
SLO 是工作負載或應用程式的效能和可靠性的量值。 SLO 是針對特定客戶互動所設定的特定可測量目標。 這是您在使用者預期會收到的服務品質上為工作負載或應用程式設定的目標。
SLO 可以定義各種計量，例如可用性、響應時間、輸送量、成功率等。 例如，Web 服務的 SLO 可能是使用者可在指定月份使用 99.9% 的時間，或它會在 500 毫秒內回應 95% 的要求。
定義應用程式或工作負載的 SLA 之前，請檢閱裝載應用程式或工作負載之基礎服務的Microsoft已發佈 SLA。
注意
Microsoft服務 SLA 不是 平臺 SLA 或 SLO
當您檢閱每個服務的 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 資料庫 的 Azure App 服務 Web 應用程式。 假設這些 SLA 可能是：
- App Service Web 應用程式 = 99.95%
- SQL 資料庫 = 99.99%
此應用程式可預期的最大停機時間為何？ 如果其中一個服務失敗，整個應用程式就會失敗。 每個服務失敗的機率都是獨立的，因此此應用程式的複合 SLA 為 99.95%，× 99.99% = 99.94%。 該值低於個別 SLA。 這個結論並不奇怪，因為依賴多個服務的應用程式具有更多潛在的失敗點。
您可以透過建立獨立的後援路徑來改善複合 SLA。 例如，如果 SQL 資料庫 無法使用，請將交易放入佇列中以供稍後處理：
在此設計中，即使應用程式無法連線到資料庫，仍可供使用。 不過，如果資料庫和佇列同時失敗，就會失敗。 同時失敗的預期時間百分比為 0.0001 × 0.001，因此以下是此合併路徑的複合 SLA：
資料庫或佇列 = 1.0 ≦ （0.0001 × 0.001） = 99.9999%
複合 SLA 總計：
Web 應用程式和 （資料庫或佇列） = 99.95% × 99.9999% = ~99.95%
這種方法會造成取捨：
- 應用程式邏輯更為複雜。
- 您需支付佇列的費用。
- 您必須考慮數據一致性問題。
針對多區域部署，複合 SLA 的計算方式如下：
N 是部署在一個區域中之應用程式的複合 SLA。
R 是部署應用程式所在的區域數目。
應用程式在所有區域中同時失敗的預期機率為 ((1 − N) ^ R)。 例如，如果假設的單一區域 SLA 為 99.95%：
兩個區域的合併 SLA = （1 • （1 • 0.9995） ^ 2） = 99.999975%
四個區域的合併 SLA = （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。 一般而言，內部使用工作負載可能會比客戶面向工作負載限制較少的可用性 SLA。
SLA
將 SLA 視為對 SLO 造成貢獻的元件層級計量。 最重要的 SLI 是從客戶的觀點影響重要流程的 SLI。 對於許多流程，SLA 包括延遲、輸送量、錯誤率和可用性。 良好的 SLI 可協助您識別 SLO 何時有可能遭到入侵。 盡可能將 SLI 與特定客戶相互關聯。
若要避免收集無用計量，請限制每個流程的 SLA 數目。 儘可能針對每個流程的三個 SLA。
復原計量
復原目標對應至 RTO、RPO、MTTR 和 MTBF 計量。 相較於可用性目標，這些度量的復原目標不會嚴重依賴Microsoft SLA。 Microsoft只針對某些產品發佈 RTO 和 RPO 保證，例如 SQL 資料庫。
實際復原目標的定義仰賴您的失敗模式分析，以及商務持續性和災害復原的計劃與測試。 在您完成這項工作之前，請先與專案關係人討論有抱負的目標，並確保您的架構設計能以最佳瞭解來支持復原目標。 清楚傳達給項目關係人，任何未徹底測試復原計量的流程或整個工作負載都不應該保證 SLA。 確定項目關係人了解復原目標在更新工作負載時可能會隨著時間而變更。 隨著客戶加入或採用新技術來改善客戶體驗，工作負載可能會變得更複雜。 這些變更可能會增加或減少您的復原計量。
注意
MTBF 在定義和保證時可能很困難。 平臺即服務 （PaaS） 或軟體即服務 （SaaS） 可以在沒有雲端提供者的任何通知的情況下失敗和復原，而且程式對您或您的客戶完全透明。 如果您定義此計量的目標，請只涵蓋您控制下的元件。
當您定義復原目標時，請定義起始復原的閾值。 例如，如果 Web 節點無法使用超過 5 分鐘，則會自動將新的節點新增至集區。 定義所有元件的臨界值，考慮特定元件的復原涉及什麼，包括對其他元件和相依性的影響。 您的閾值也應該考慮 暫時性錯誤 ，以確保您不會太快速地啟動復原動作。 向專案關係人記錄並分享復原作業的潛在風險，例如客戶的數據遺失或會話中斷。
建置健康情況模型
使用您針對可靠性目標收集的數據，針對每個工作負載和相關聯的重要流程建置健康情況模型。 健康情況模型會 定義流程和工作負載的健康情況、 降級和 狀況不良 狀態。 狀態可確保適當的作業優先順序。 此模型也稱為 交通燈模型。 此模型會針對狀況良好、已降級的黃色指派綠色，並針對狀況不良指派紅色。 健康情況模型可確保您知道流程的狀態何時從狀況良好變更為降級或狀況不良。
您定義狀況良好、降級和狀況不良狀態的方式取決於您的可靠性目標。 以下是您可以定義狀態的一些範例：
綠色或狀況良好的狀態表示密鑰非功能需求和目標已完全滿足，且資源會以最佳方式使用。 例如，95% 的要求會在 =500 毫秒內 <處理，而 Azure Kubernetes Service （AKS） 節點則以 X % 的速度使用。
黃色或降級狀態表示流程的一或多個元件會針對其定義的臨界值發出警示，但流程可運作。 例如，偵測到記憶體節流。
紅色或狀況不良的狀態表示您的可靠性目標所允許的效能降低已持續超過允許的時間，或流程已變成無法使用。
注意
健康情況模型不應該將所有失敗都視為相同。 健康情況模型應該區分 暫時性 和非 轉移 性錯誤。 它應該清楚地區分預期暫時性但可復原的失敗和真正的災害狀態。
此模型的運作方式是使用持續改進原則所開發的監視和警示策略。 隨著工作負載的發展，您的健康情況模型必須隨著它們而演進。
如需分層應用程式健康情況模型的詳細設計考慮和建議，請參閱 任務關鍵性工作負載設計區域中找到的健康情況模型化指引 。 如需監視和警示設定的詳細指引，請參閱 健康情況監視 指南。
視覺效果
若要讓作業小組和工作負載項目關係人知道工作負載健康情況模型的即時狀態和整體趨勢，請考慮在監視解決方案中建立 儀錶板 。 與專案關係人討論視覺效果解決方案，以確保您提供其價值且容易取用的資訊。 他們可能也會想要查看每周、每月或每季產生的報告。
Azure 便利化
Azure SLA 提供運行時間和連線能力Microsoft承諾。 不同的服務有不同的 SLA，有時服務內的 SKU 有不同的 SLA。 如需詳細資訊，請參閱 線上服務的服務等級協定。
Azure SLA 包含不符合 SLA 時取得服務點數的程式，以及每個服務的可用性定義。 SLA 的層面會作為強制執行原則。
相關連結
- 健康情況模型化的架構架構任務關鍵性指引： Azure 上任務關鍵性工作負載的健康情況模型化和可檢視性
可靠性檢查清單
請參閱一組完整的建議。