定義可靠性目標的建議
適用於此 Azure 架構完善的架構可靠性檢查清單建議：
| RE：04 | 定義元件、流程和整體解決方案的可靠性與復原目標。 將目標可視化，以談判、取得共識、設定期望，以及推動動作以達到理想狀態。 使用定義的目標來建置健康情況模型。 健康情況模型會定義狀況良好、降級和狀況不良狀態的外觀。 |
|---|
本指南說明定義重要工作負載和流程的可用性和復原目標計量的建議。 您應該從與商務項目關係人進行研討會練習中衍生可靠性目標。 然後，藉由監視和測試您的工作負載來精簡這些目標。
請與您的內部項目關係人設定有關工作負載可靠性的實際期望。 然後，他們可以使用合約合約將這些期望傳達給客戶。 現實的期望也有助於項目關係人瞭解和支援您的架構設計決策，並知道您正在設計以達到您同意的目標。
請考慮使用下列計量來量化您的業務需求。
| 詞彙 | 定義 |
|---|---|
| 服務等級目標 （SLO） | 測量工作負載或應用程式的效能和可靠性。 SLO 是針對特定客戶互動所設定的特定可測量目標。 這是您根據客戶預期收到的服務品質，為工作負載或應用程式設定的目標。 |
| 服務等級指標 （SLI） | 服務效能特定層面的量化測量。 您可以使用 SLI 來測量工作負載與 SLO 的合規性。 |
| 服務等級協定 (SLA) | 服務提供者與服務客戶之間的合約合約。 不符合合約可能會對服務提供者造成財務後果。 |
| 平均復原時間 （MTTR） | 偵測到失敗后還原元件所花費的時間。 |
| 平均失敗時間 （MTBF） | 工作負載可以執行預期函式的持續時間，直到失敗為止。 |
| 復原時間目標 (RTO) | 應用程式在事件發生后無法使用的最大可接受時間。 |
| 復原點目標 (RPO) | 事件期間數據遺失的最大可接受持續時間。 |
關鍵設計策略
可靠性目標代表工作負載所需的質量目標， 如其使用者和業務項目關係人所承諾。 該目標包括工作負載的可用性和復原性。 請記住，可靠性目標與效能目標不同，但您應該在可靠性目標中包含效能目標。 請考慮下列可靠性目標：
可用性目標會 定義系統維持可存取和運作的質量標準。 如果不符合這些標準，系統就會被視為不可靠。 使用 SLO 來協助檢查您的系統是否符合這些標準。 商務和技術項目關係人共同作業以設定實際的 SLO，並考慮比較分析、用戶體驗和工作負載配置檔等因素。
正確性目標 可確保工作負載以一致的品質正確執行其功能。 若要測量正確性，請量化工作負載的指標，以便將它們合併成統一的目標分數。
復原目標 會對應至 RTO、RPO、MTTR 和 MTBF 計量，以量化計劃的有效性，並測試商務持續性和災害復原。
為了設定可靠性目標，商務項目關係人會定義廣泛的需求。 然後，技術專家會評估工作負載的目前狀態，並透過監視和警示來達成和維護目標。 雙方必須就現實目標達成一致。
根據使用者和系統流程 對您業務需求的重要性來識別和評分。 使用這些分數來引導工作負載的設計、檢閱、測試和事件管理。 設定這些流程的可靠性目標，並了解無法符合這些目標可能會大幅影響您的業務。
取捨：您的系統技術限制與其業務影響之間可能有差距，例如輸送量與每秒交易。 縮小這一差距可能很艱難。 針對實用且符合成本效益的解決方案，而不是過度工程。
設定可用性目標
工作負載的整體 SLO 反映 整體品質，包括其所有相依性。 SLO 的成熟宣告應該指出該工作負載的整體業務目標，而不只是這些相依性的複合。 例如，如果客戶預期有99.99%的可用性，整體SLO應該針對該目標，即使某個部分只達到99.80%。
項目關係人會評估客戶體驗，並考慮停機時間如何影響營收。 他們會將此損失與設計和操作商務流程的成本進行比較。 然後決策者決定他們是否應該花更多的錢在可靠性上，以避免收入損失並維持其聲譽。
工作負載擁有者 會使用財務目標來判斷目標。 商務需求會對應至可測量的計量。 目標是找出一組影響客戶體驗品質的因素。
工作負載架構設計人員 會根據 SLO 做出許多技術決策。 SLO 可以：
當您考慮其他相依性時，做為架構決策的重要輸入。
提供近乎即時的檢視和對工作負載健康情況的共享瞭解，以啟用客觀的討論。 它們也可協助工作負載小組排定工作優先順序，以改善可靠性和開發新功能。
做為部署作業的主要訊號，這會在發生問題時驅動自動回復，並提供驗證變更可達成對客戶體驗的預期改善。
藉由專注於目標、將問題的自動化通知導向客戶，以及在您的組織中建立小組之間的信任，以加速補救和復原。
重要
您必須知道 SLA 與 SLO 之間的差異。 雖然 SLA 和 SLA 可能會使用或甚至呈現類似的數據，但其意圖不同。 SLA 是組織與其客戶之間的正式合約，如果組織無法履行承諾，則其具有直接的財務和法律影響。 組織會使用 SLO 來評估潛在的停機時間是否在可容忍的限制內。
SLO 和 SLA 會共用業務關係，而且應該獨立控制。 如果 SLA 是商業策略，組織可能會根據企業主的目標，刻意將其設定為高價值。 相反地，SLO 可以更高。 以任務關鍵性工作負載為例。 此工作負載類別無法承受長時間的停機時間，因為影響，包括財務損失，甚至對人類安全的威脅都很重要。 因此，SLO 通常會以 99.999% 的運行時間為目標，通常稱為五個九。 如果 SLO 不符合這些目標，組織必須快速做出反應，以減輕失敗，並防止失敗 SLA 的結果。
本文中的範例會設定高 SLA 以支援商務目標。
雲端平台和技術提供者在其供應專案上發佈 SLA。 您應該將 SLA 視為 SLO 計算的一部分，但若不瞭解 SLA 涵蓋範圍的範圍，就不應該像那樣使用 SLA。 如需詳細資訊，請參閱 評估Microsoft SLA 的影響。
考慮常見的 SLO 和影響因素
每個 SLO 都會以特定品質準則為目標。 請考慮這些常見的 SLO 以取得可靠性。 這份清單並不完整。 根據您的業務需求新增 SLO。
成功率 會測量相對於傳回錯誤或失敗其工作的要求和程式成功。
延遲會測量起始作業要求的時間，以及結果可用或程式完成的時間。
容量 會測量並行使用量，例如節流回應的數目。
可用性 會從客戶的觀點測量運行時間。
輸送量 會測量一定時間內的最小數據傳輸速率。 輸送量會測量為數據速率單位，例如每秒交易數（TPS）或每秒要求數（RPS）。
瞭解 Azure 上工作負載的案例和容錯。 Azure 服務和應用程式元件都會影響工作負載 SLO。 結合下表的回應，以衍生整體 SLO。 使用這些問題作為範例來評估工作負載元件的公用程式。
| 元件特性 | 客戶互動 | 其他因素 |
|---|---|---|
| - 它會公開 要求或回應 API 嗎？ - 是否有 查詢 API？ - 這是 計算 元件嗎？ - 這是 作業處理 元件嗎？ |
- 針對公開的 Azure 服務控制平面和管理平面存取 。 - 數據平面存取，例如建立、讀取、更新和刪除 （CRUD） 作業。 |
- 您的 發行程式 是否涉及停機時間？ - 引進 Bug 的可能性為何？ 如果工作負載與其他系統整合，您可能需要考慮整合 Bug。 - 修補之類的例行作業如何影響可用性目標？ 您是否將合作夥伴相依性納入考慮？ - 您的 人員 是否足以支持持續的緊急和緊急備份隨選輪替？ - 應用程式是否在控制範圍之外有 干擾的 鄰居，這可能會造成中斷？ |
判斷 SLO 範圍
您可以在系統中設定各種層級的 SLO，例如每個應用程式、工作負載或特定流程。 設定層級特定的 SLO，讓您可以根據每個元件的重要性來自定義 SLO。
在軟體即服務 （SaaS） 解決方案中，測量每個客戶的 SLO，以優化每個客戶的體驗。 客戶在其區段中可能有不同的基礎結構資源。 在這種情況下，跨客戶區段匯總所有資源的全系統 SLO 可能沒有意義。 相反地，測量符合每個客戶特定內容的 SLO。 如需詳細資訊，請參閱 多租用戶解決方案的租用模型。
定義複合 SLO 目標
SLO 必須在可觀察性視窗中測量和測量。
SLO 通常是 99.90% 等百分比，但它們也可以是語句。 使用這兩種方法來取得包含所有因素的數值。
SLO 是由可測量的 SLO 所組成，可定義可接受的因素。 SLA 是具有可發出警示之設定閾值的計量。 您可以從平台或應用程式收集它們。 不同的元件會發出相關的 SLA。 當您選擇 SLI 時，請考慮影響 SLO 的因素。
例如，若要計算使用回應和要求 API 之流程的 SLO，請測量伺服器延遲和要求處理時間。 輸送量和錯誤率不適用於虛擬機（VM）、擴展集或 Azure Batch 等連續計算環境。
針對控制平面存取，請考慮 API 回應的錯誤率和延遲，以及資源建立等長時間執行的作業。 數據平面存取取決於所使用的 API，每個 API 都有自己的 SLO 目標。
良好的 SLI 會顯示何時可能會違反 SLO。 它通常以百分位數來測量。 以下是一些常用的百分位數，以及不符合預期可用性的估計時間。
| 目標 | 每周不合規 | 每月不合規 | 每年不合規 |
|---|---|---|---|
| 99% | 1.68 小時 | 7.20 小時 | 3.65 天 |
| 99.90% | 10.10 分鐘 | 43.20 分鐘 | 8.76 小時 |
| 99.95% | 5 分鐘 | 21.60 分鐘 | 4.38 小時 |
| 99.99% | 1.01 分鐘 | 4.32 分鐘 | 52.56 分鐘 |
| 99.999% | 6 秒 | 25.90 秒 | 5.26 分鐘 |
重要
複合 SLO 值是參與因素的產品分佈。
範例複合 SLO 是 99.95% × 99.99999% = ~99.95%。
當您為不同的流程建立複合 SLO 時，請考慮其不同的重要性和相關性。 流程可能有您視為非關鍵且省略計算的元件。 您可以根據其短暫無法使用是否會影響客戶的體驗來證明其遺漏合理性。 在某些情況下，元件可能與您針對 SLO 考慮的使用案例無關。 您也可以從計算中省略這些元件。
相同的原則適用於作業。 某些作業可能會帶來風險或影響 SLO，而其他作業則微不足道。 這一決定應明確，並以共識為基礎。
如需如何定義和測量 SLO 和 SLA 的說明範例，請參閱<範例>一節。
評估Microsoft SLA 的影響
Microsoft SLA 可讓您深入瞭解Microsoft認可區域的可用性。 SLA 不保證整體供應專案。 當您評估 SLA 時，請充分瞭解圍繞已發佈百分位數提供的涵蓋範圍。
請考慮 Web Apps，這是 Azure App 服務 的功能。 此功能會在指定使用案例中傳回 200 OK 狀態時視為可用。 在該特定內容和時間範圍內，它不會涵蓋簡單驗證或位置切換等功能在財務上支持的保證。 您應該考慮在合約中未明確提及的區域，因為平臺盡最大努力提供。
因此，如果您的工作負載依賴部署位置，則無法只從 App Service SLA 衍生 SLO。 身為工作負載小組，您需要對沖並預測運行時間可用性。 不過，這項預測可能不確定，這就是為什麼緊密結合 SLO 與平臺 SLA 可能會有問題。
請考慮另一個範例。 如果 Azure Front Door 具有 99.99% 的可用性，您的設計必須遵循合約中發佈的特定準則。 例如，後端必須包含記憶體，您需要一個作業，可以擷取大小至少 50 KB 的檔案，而且您必須在至少五個 GET 不同地理位置的多個位置部署代理程式。 此 Azure Front Door 的縮小使用案例並不保證快取、路由規則或 Web 應用程式防火牆等功能。 這些層面落在 SLA 的範圍之外。
實作多區域目標
從可靠性的觀點來看，多區域部署是備援原則的實作。 目標是降低區域性中斷或效能降低的風險。 此策略在設計正確時，可以改善 SLO，因為它會新增次要區域來進行故障轉移。
有兩個主要使用案例：
高可用性模式，您可以在其中將負載分散到區域，以取得更多容量。 高可用性不會將工作負載使用者限制為區域，而且整個系統的效能都會對 SLO 造成貢獻。
大量分頁模式，在此模式中，您會將客戶限制為特定區域進行區隔。 在這種情況下，請將多區域部署視為每個區域中的個別部署或 戳記。 使用適合您工作負載的 SLA，分別測量每個戳記的健康情況。 根據每個戳記的健康情況，考慮整體工作負載的 SLO。 如果您可以在戳記之間故障轉移，則您的整體工作負載 SLO 會更高，因為一個戳記中的失敗可透過故障轉移至另一個戳記來復原。
請注意您需要滿足高 SLO 所需的備援程度。 例如，Microsoft保證 Azure Cosmos DB 多區域部署的 SLA 高於單一區域部署的保證。
定義復原計量
實際復原目標的定義，例如 RTO、RPO、MTTR 和 MTBF 計量，會依賴您的失敗模式分析，以及商務持續性和災害復原的計劃與測試。 當您定義這些目標時，請考慮平臺提供的復原保證。 Microsoft只針對某些產品發佈 RTO 和 RPO 保證，例如 Azure SQL 資料庫。
完成這項工作之前，請先與專案關係人討論有抱負的目標，並確定您的架構設計可支持復原目標，以充分利用您的瞭解。 清楚傳達給項目關係人，任何未徹底測試復原計量的流程或整個工作負載都不應該保證 SLA。 確定項目關係人了解復原目標在更新工作負載時可能會隨著時間而變更。 當您新增客戶或採用新技術來改善客戶體驗時，工作負載可能會變得更複雜。 這些變更可能會增加或減少您的復原計量。
注意
MTBF 在定義和保證時可能很困難。 平臺即服務 （PaaS） 或 SaaS 模型可以在沒有雲端提供者的任何通知的情況下失敗和復原，而且程式對您或您的客戶完全透明。 如果您定義此計量的目標，請只涵蓋您控制下的元件。
當您定義復原目標時，請定義起始復原的臨界值。 例如，如果 Web 節點無法使用超過五分鐘，則會自動將新的節點新增至集區。 定義所有元件的臨界值，並考慮特定元件的復原涉及什麼，包括對其他元件和相依性的影響。 您的閾值也應該考慮 暫時性錯誤 ，以確保您不會太快速地啟動復原動作。 記錄並與項目關係人分享復原作業的潛在風險，例如數據遺失或會話中斷。
監視目標並將其可視化
使用您針對可靠性目標收集的數據，針對每個工作負載和相關聯的重要流程建置健康情況模型。 健康情況模型會 定義流程和工作負載的健康情況、 降級和 狀況不良 狀態。 當狀態變更時，模型應該向責任方發出警示。 如需詳細的設計考慮和建議，請參閱 健康情況模型化指引。
若要讓作業小組和工作負載項目關係人知道，請建立視覺效果，以反映工作負載健康情況模型的實時狀態和整體趨勢。 與專案關係人討論視覺效果解決方案，以確保您傳遞其價值且容易取用的資訊。 他們可能也會想要查看每周、每月或每季產生的報告。
Azure 促進
Azure SLA 提供運行時間和連線能力Microsoft承諾。 不同的服務有不同的 SLA，有時服務內的產品有不同的 SLA。 如需詳細資訊，請參閱 線上服務 SLA。
如果工作負載不符合 SLA，Azure SLA 包含取得服務點數的程式，以及每個服務的可用性定義。 SLA 的層面會作為強制執行原則。
探索視覺效果系統的 Azure 監視器 儀錶板 。
範例
Contoso， Ltd. 正在為其活動票證系統設計新的行動體驗。 以下是高階架構。
Grafana 標誌是其各自公司的商標。 使用此標記時不會隱含任何背書。
元件
以下是一些說明 SLO 定義概念的元件。 此架構中有元件未包含在下列清單中。 例如，即使 金鑰保存庫 是重要要求流程的一部分，但不是回應使用案例的一部分。 如果 金鑰保存庫 無法使用，應用程式會使用啟動期間載入的秘密繼續運作。 不過，如果應用程式需要調整，金鑰保存庫 可用性變得很重要，因為需要以秘密載入新的節點。 在此範例中，不會考慮調整作業。 為了簡潔起見，會省略其他元件。
Azure Front Door 是公開客戶用來傳送要求之 API 的單一進入點。
Azure Container Apps 是工作負載小組擁有並用來執行應用程式商業規則的環境。
SQL 受管理執行個體 是由另一個小組所擁有和管理，而且是工作負載的重要相依性。
Azure Private Link 提供 Azure Front Door 與 Container Apps 部署之間的私人連線。 SQL 受管理執行個體 也會透過私人端點向應用程式公開。
在此架構中，API 小組會針對應用程式中的重要流程定義初始 SLO 目標。 他們會採用影響 SLO 的因素中所述的策略。 其目標是定義涵蓋核心功能的目標，而不需要過度強調補充功能。 他們會測量三個重要使用者流程的健康情況，這些流程牽涉到所有核心雲端功能，並跨部署執行程序代碼。 不過，這些流程不會涵蓋所有程式代碼或數據存取。 以下是影響因素。
計算複合 SLO
Azure 可用性 SLO： 適用於 Azure 的財務承諾 SLA 可作為評估平臺可靠性的 Proxy。
Azure 元件 適用的 SLA 涵蓋範圍 SLA 未涵蓋 調整后的 SLO Azure Front Door 成功執行 HTTP GET作業的 99.99%快取、規則引擎 99.98% 容器應用程式 99.95% 以內建輸入可連線的已部署應用程式為基礎 自動調整、令牌存放區功能 99.95% SQL 受控執行個體 99.99% 根據 SQL Server 實例的連線 效能、數據保留 99.80% 私人連結 99.99% 以私人端點網路不接受流量或端點與 Private Link 服務之間流量未流動的整個分鐘數為基礎 持續少於一分鐘的個別失敗 99.99% 這項調整是根據工作負載小組對其目標的承諾而定的幾個因素。 其中一個因素可能是根據先前的經驗，對平臺的功能有信心。 例如，針對 Container Apps 和 Private Link，小組會覺得很自在地採用 SLA 值。
也有細微因素。 例如，小組會將 SQL 受管理執行個體 的 SLO 值降低到 99.80%，以考慮其數據作業的潛在失敗，例如架構變更和進行備份。
小組會藉由計算個別調整的 SLO 值的影響來設定複合 SLO。 此值為99.72%。
還有其他因素。 此架構依賴沒有已發佈 SLA 的 Azure 網路元件，例如虛擬網路和網路安全組 （NSG）。 工作負載小組決定考慮每個元件可用性為 99.99% 的因素。
以預測平臺可用性為基礎的複合 SLO：每月 99.68%。
應用程式程式代碼 SLO： 小組認可其應用程式程式代碼或預存程式中的錯誤可能會影響系統可用性，並配置一小時的每月停機時間來考慮程式代碼相關錯誤。
他們會使用常見的 停機時間百分位數 來估計 SLO 的個別因素，例如程式代碼瑕疵、調整問題和其他程式代碼相關考慮。
以程式代碼和數據可用性為基礎的複合 SLO：每月 99.86%。
資源和應用程式設定 SLO： 小組會辨識雲端資源和應用程式程式代碼必須正確設定。 此目標包括設定自動調整規則、部署 NSG 規則，以及選取正確的 SKU 大小。 為了考慮設定錯誤，他們會預算每月停機 10 分鐘，也就是大約 99.98% 的可用性。
以設定可用性為基礎的複合 SLO：每月 99.95%。
Operations SLO： 工作負載小組會遵循架構完善的營運卓越架構原則，來開發良好的 DevOps 文化。 他們會部署雲端資源、設定和程序代碼每個短期衝刺。
小組會將部署視為風險，因為它們可能會破壞執行中的系統穩定。 TLS 憑證更新、DNS 變更或工具錯誤可能會導致錯誤。 小組也會考慮緊急修正所造成的潛在停機時間。 它們共預算每月停機 20 分鐘，大約為 99.95% 的可用性。
維護期間是系統維護或更新發生的指定時段。 API 通常每天大約四小時未使用。 為了降低無法使用的風險，小組可以在那些較不活躍的時段內排程維護工作。 這種方法會導致較高的 SLO，但小組決定不要將維護期間納入其 SLO 的一部分。
以作業可用性為基礎的複合 SLO：每月 99.95%。
外部相依性 SLO：小組會將 SQL 受管理執行個體 視為主要相依性，其已將 99.80% 的可用性納入整體平臺可用性。 不會考慮其他外部相依性。
以外部相依性為基礎的複合 SLO：不適用。
判斷整體複合 SLO 結果
整體複合 SLO 目標設定為 99.45%，相當於每月大約四小時的停機時間。
為了符合每個月只有四個小時無法使用的 SLO 目標，工作負載小組會建立通話輪替。 客戶支持和綜合交易監視都可以叫用待命網站可靠性工程 （SRE） 支援，以立即啟動復原步驟以解決 SLO 問題。
設定工作負載 SLA
工作負載的 SLA 每月可用性為 99.90%。
工作負載小組的法律和財務部門會每月將工作負載的 SLA 設定為 99.90% 的可用性，超過 SLO 目標 99.45%。 在根據有吸引力的 SLA 分析財務支出與預計的客戶成長，他們會做出此決定。 SLA 涵蓋兩個核心使用者流程，並包含效能考慮，而不只是可用性。 這是商務小組為業務帶來好處所承擔的計算風險，而工程小組知道承諾。
設定正確性 SLO
應用程式的核心使用者流程必須可供使用，甚至具競爭力地回應。 小組會特別為 API 設定回應時間 SLO，但不包括客戶端處理時間和因特網網路周遊。 它們只會在可用性期間評估此 SLO。 他們會選擇第 75 個百分位數作為 SLO 目標和效能測量，以擷取典型的客戶體驗，並排除最差案例。
相關連結
可靠性檢查清單
請參閱一組完整的建議。