雲端監視服務等級目標

本文是雲端監視指南系列文章的一部分。

在下列各節中，您將瞭解服務等級目標的基本原則，以及如何實作和套用它們。

概觀

服務等級目標（SLO）是關鍵以客戶為中心的服務等級指標（SLA）可衡量的目標。 他們會測量客戶的商務或基礎結構工作負載體驗，並判斷企業服務提供者是否符合正式談判服務等級協定（SLA）或各方之間的非正式協定中的承諾。

身為服務代理程式，您仰賴 Microsoft 對 Microsoft 對於 Azure 服務之服務等級協定中所定義之服務可靠性的承諾。 這可讓您專注於服務鏈結中的責任，例如綜合監視、網路連線和安全性與合規性。

詞彙

以下是每個詞彙的定義和簡短描述。 這些定義取自Google的 SRE手冊。

詞彙	描述
服務等級協定 （SLA）	通常是服務提供者與客戶之間的系結承諾。 合約通常包含遺漏 SLO 目標的後果。 服務的特定層面是服務提供者與服務取用者之間同意的品質、可用性和責任。
監視	收集服務與系統的相關量化實時數據的做法。
計量	量值相關的服務行為，並可以匯總為服務等級指標，這些指標會進行處理和匯總，以測量服務的目前作業狀態，並量化其行為。 SLI 是服務目前健康情況的主要和即時指標。
記錄	從程式代碼開始，並報告個別執行程式碼路徑或謹慎事件的相關信息。 使用這項資訊來協助疑難解答並努力找出影響 SLA/SLO 所測量客戶體驗和服務可靠性的根本原因問題。
服務等級目標 （SLO）	服務等級的目標值，如服務等級指標 （SLA） 所測量，可設定服務效能的預期。 SLO 特別追蹤端對端客戶體驗。 若要建立良好的 SLO，您通常會先定義所需的體驗，然後檢測服務程式代碼來測量該體驗（收集相關的 SLA），並設定符合客戶期望的目標。
服務等級指標 （SLI）	計量，可量化服務的品質或可靠性。 至少會評估四個常見的 SLA： 可用性、 延遲、 輸送量和 錯誤率。
可用性	一般而言，是指系統運作和運作的可測量或可觀察時間百分比。 您可以將可用性測量為客戶面向的體驗目標，這受到一或多個可靠性問題的影響（以及與設定變更、套用的更新等相關的其他失敗模式）。
錯誤預算	關於 SLO 剩餘緩衝區的百分比。 錯誤預算是 DevOps 的工具，IT 用來平衡服務可靠性與創新速度。

SLO 的目的

SLO 在雲端工作負載的開發與作業中提供許多基本用途，包括：

• 近乎即時 （NRT）：為客戶所體驗的服務健康情況提供NRT 檢視。
• 減少通知時間（TTN）：將服務問題的自動化通知驅動給客戶，大幅縮短通知的時間（TTN）。
• 主要訊號給客戶：做為部署作業的主要訊號，在發生問題時推動自動回復，從而將較少的客戶暴露在潛在問題。
• 變更驗證：提供變更可達成預期客戶體驗改善的驗證。
• 判斷優先順序：協助小組瞭解建置功能或處理可靠性。
• 服務健康情況 深入解析：啟用目標、以客戶為中心的服務健康情況討論。
• 縮短分析時間：將焦點導向至負責任的服務，以加快客戶問題的風險降低和根本原因分析（RCA）。
• 架構相依性：當服務採用相依性時，做為架構決策的基本輸入。
• 建置信任：提供對健康情況措施的共享瞭解，以在小組之間建立信任。
• 帶來透明度：公開我們用來對客戶執行業務的相同 SLA，讓他們能夠執行其業務。
• 單一玻璃窗格：為服務和其相依性和分解尋址接收器啟用水準單一玻璃窗格。

藉由使用 SLO 來驅動您的工程程式，DevOps 和 IT 可以提早瞭解他們在 Azure 中建置或移轉的應用程式或基礎結構服務健康情況。 然後，這可以用來驅動人類和自動化決策，這些決策需要對這些服務的可靠性進行。 工程實踐中的這項轉換將大幅影響這些服務在短期內的可靠性。

如何定義 SLO？

SLO 的目標是要從客戶的觀點取得清楚的訊號，以準確測量品質。 每個服務小組都會建立一組小型的服務等級目標（SLO），為服務取用者所經歷的最重要可測量計量定義允許的範圍。 SLO 是服務所發出計量的已定義數值目標。 您可以監視與此目標相關聯的計量，以判斷服務是否狀況良好。

例如，以下是內部時間追蹤 Web 應用程式 SLO 的簡化範例 - 過去 5 分鐘內的要求會在第 99 個百分位數的 1000 毫秒內提供。

計量是時間序列數據的匯總，稱為服務等級指標（SIS）。 收集 SLA 的位置很重要。 在上述範例中，如果客戶使用 API 與服務互動，測量系統延遲和處理要求的時間是精確的 SLA。 不過，如果客戶使用入口網站與服務互動，則要求服務的總時間也應該包含網頁的 JavaScript 效能。

服務擁有者的重點在於判斷下列各項：

• 從客戶的觀點來看，哪些 案例是服務健康情況的重要指標，
• 收集 SLA 的位置 ，使其盡可能接近客戶體驗，以及
• SLO 應該針對這些 SLA 是什麼 ？

SLO 可以透過漸進式方法來定義成就，或直接由企業規定。 您可以使用服務所定義的 SLO，來決定您建置方式的架構決策。 因此，請務必仔細選擇要測量的案例，以及要測量這些案例的時間範圍。 總結來說，SLO 是由下列值所組成：

• SLI。 例如，從負載平衡器測量的足夠快速要求比例小於 400 毫秒。
• 持續時間。 度量的測量時間週期。
• 目標。 例如，您預期在指定期間內符合之要求總數（例如 90%） 的快速要求目標百分比。

SLO 的類型

如果您檢視整個產業，則有兩種類型的 SLO：

• 以服務為中心的 SLO - 這些 SLO 是團隊定義的戰術目標，可隨著時間逐漸改善其服務品質。 它們的設計目的是在工程里程碑中實現務實的目標。 例如，如果服務目前達到99.7%的可用性，小組可以設定目標，在下一季達到99.9%的可用性。

• 以客戶為中心的 SLA - 這些 SLO 會定義理想的未來狀態或目標。 此時，由於您完全符合客戶的期望，因此對質量的進一步投資將被視為不必要的。

例如，如果您的客戶預期您營運的企業或基礎結構服務提供 99.99% 的可用性，且服務目前只達到 99.8% 的可用性，則以客戶為中心的 SLO 仍為 99.99%。

定義適當的 SLO 需要時間。 第一個步驟是與客戶交談，並了解使用者想要從服務衍生少量指標並加以記錄。 瞭解其使用服務的方式案例和容錯，以及您的服務需要傳遞哪些專案，才能順利執行其業務。 這通常是反覆的體驗，其期望範圍從我想要在所有條件下 100% 的可用性，而不會影響我們的收益流，透過管理客戶區隔之間的非常變異的期望。

只查看服務（或服務實例）健康情況的監視方法很容易在頻譜的兩端遺漏客戶體驗問題;服務健康情況不一定會與客戶體驗的品質相互關聯。 這是因為 Azure PaaS 和 SaaS 服務之間有不同的行為特性、這些 Azure 服務的設定、部署其資源的方式和位置，以及新增自定義程式碼/邏輯，這會增加進一步的複雜性。

定義 SLO 時，請務必記住您的雲端提供者是 SLA 的相依性。 針對每個服務所指定的服務等級協議進行帳戶。 針對 Azure，請參閱 在線服務的服務等級協定 （SLA）

如何定義 SLA？

SLI 規格是一份正式聲明，說明您對服務的特定可靠性維度的期望，例如延遲或可用性。

藉由選取正確的計量來測量和收集，並不要透過收集太多不有意義的計量而使它過於複雜，即可開始簡單。 請確定您定義的 SLA 與客戶體驗有直接關係。 這就是為什麼必須瞭解用戶的觀點，才能從少數指標開始。

如果您的服務以某種方式限制資源，例如記憶體或CPU，則其飽和度也可能是絕佳的SLI。 不過，飽和度不應該當做 SLO 使用，因為它不會直接對應到不佳的用戶體驗（服務可以具有高記憶體使用率，但使用者不會受到影響）。

建議您建立最多三個指標。 超過三個指標很少增加顯著價值。 通常，過多的指標數目可能表示您包含主要指標的徵兆。 流量和飽和度應該是這三個主要指標的額外，因為這些指標描述服務負載和支持解譯其他服務指標。

如何實作 SLO？

最重要的 SLI 是最清楚代表您服務的影響，從客戶的觀點來看。 對於許多服務，這包括延遲、輸送量、錯誤率和可用性。 如果您的服務有任何影響客戶體驗的特殊考慮，則也應該測量這些區域的 SLI。 例如，傳訊服務的端對端處理延遲是客戶體驗的直接指標，應該由 SLI 涵蓋。

SLO 範例

人力資源有興趣在企業 IT 的説明下，將其內部時間追蹤 Web 應用程式現代化，並將其裝載在 Azure 雲端中。 他們希望服務能夠繼續觸達組織中的所有使用者，因此他們對下列專案感興趣：

• 使用量報告，以及一段時間后有多少使用者使用服務。
• 定期的健康情況監視，例如可用性、效能、安全性和合規性（服務保固）。
• 成本，例如服務的每月成本。
• 網路安全性，透過遵循 零信任 安全性策略來控制對資源和數據的存取。

如上述範例所示，SLO/SLI 類別和範例必須在服務設計初期定義。 這與您所建置的內部部署服務完全不同。

SLO 資料表/SLI 類別

下列範例絕不是詳盡的清單。 雖然可靠性與可維護性 SLA 是數十年來系統的特徵，但您可以定義 SLA，其中包括網路安全、品質和用戶體驗和成本的量值。

服務

服務或系統的一般高階量值通常會在服務合約中編纂。 大部分的新式合約會測量可用性作為主要 SLO，並根據關鍵工作負載專案或生產單位使用簡單的停機時間量值，例如驗證令牌、信箱或記憶體帳戶。

類別	描述	範例
可用性	簡單停機時間或維護或操作可用性之間的平均時間 （MTBM/（MTBM+MDT））	每月99.99%
Capacity	確保適當的、最大或最佳商務和服務效能、輸送量、記憶體、人員、頻寬、需求、資源和服務功能。 包含作為觸發程式的人力和時間限制。	% 使用率（CPU、記憶體、記憶體、延遲、輸送量、調整）
安全性	可能會或造成企業、資產和數據損害的作用中威脅和弱點（內部和外部）。	偵測HAFNIUM威脅
法規遵循	更新、服務層級、強化合規性、所需的設定漂移	所有資產的99.5%服務更新
連續性	從大型災害和外部事件中生存和復原的能力。	時間（重組）
Quality of Service (QoS)	一段時間后用戶實際體驗的特性。	Teams 通話品質 - 收到封包遺失 < 2%

可靠性

傳統 SLO 的可靠性表示一段時間後，系統、服務、資源或元件失敗和故障轉移的可靠性、持久性和品質程度，並套用管理工作來解決失敗（例如在更多備援中建置或新增內容傳遞網路），以增加作業時間或可用性。 這也可能表示用來測量 SLO 之數據的精確度、精確度、完整性和可信度。 這可能表示 系統在指定條件下執行其預期函式的傳統機率 ，例如溫度壓力。 復原功能也包含內建的設計因素或功能，可提供調整、冷卻、負載平衡、復原、無法預測的需求、嚴重壓力下的效能降低，以及大型災害中持續性的設計（通常是個別的 SLO）。

類別	描述	範例
失敗率	總作業時數的失敗數目	973 小時內 5 個失敗，我們的 .00514
平均失敗時間 （MTBF）	MTBF 是失敗率的反函數	194.6 小時

可維護性

結合支援 SLO 以進行 IT 服務管理程式，例如事件和問題管理，以及可靠性 SLA，以便達成可用性測量。

類別	描述	範例
服務事件效能	依類別或產品或優先順序。	事件生命週期每個階段的時間和成本量值。
安全性事件效能	依類別或產品或優先順序。	事件生命週期每個階段的時間和成本量值。
元件平均修復時間 （MTTR）	從事件偵測到還原或補救。
平均維護時間（MTBM）	所有維護動作的平均或平均時間，包括正常生產工作發生的預防性動作。	請參閱維護延遲時間
維護延遲時間 （MDT）	從偵測到復原的總時間，包括物流和系統管理延遲。	更換硬體的時間，以包含訂購、出貨和安裝。

客戶體驗

類別	描述	範例
輸送量	一段時間后，放在系統上的工作負載或生產力負載的數量、速率或速度。	每單位時間的交易。
錯誤率	以百分比表示的總錯誤數目。	% 安全性事件
延遲	從輸入到輸出、透過進程移動工作，或從應用程式到使用者的時間或延遲量值。	平均秒數。

其他

類別	描述	範例
成本	依服務、元件或時間測量支出、帳單和發票。	資本支出或營運費用
涵蓋範圍	管理下的元件、系統和服務的百分比（合規性）	法規遵循
摘要可靠性	活動訊號、連接器、變更等失敗。	追蹤任務關鍵性公司數據的變更。
生產力	有效率地完成工作	勞動，時間由員工，分析師生產力。

考量

• 確定存取權。 請確定組織中的經理和其他角色可以存取 Azure 監視器中可用的視覺效果，或從其他 Azure 服務，特別是 Azure SaaS 和 PaaS 取得的視覺效果，以避免複製視覺效果。

• 確保監視涵蓋範圍或 資產可見性總計。 請確定代理程式、發出的記錄、數據表和查詢，找出所有需要管理及保護的資產，並識別涵蓋範圍中的「盲點」或缺口，以確保 SLO 的真實性。

• 在正確的取用者面前取得正確的數據。 請確定 SLO 和 SLA 的取用者可以使用從數據取得的資訊來解譯基礎數據，以建置信任和引導決策。

• 做出合理的承諾。 當將 SLO 設定為 目標 時，特別是當成本管理很重要時，請確定實際系統效能不會過度執行或傳遞不足，或調整目標來管理客戶的期望。

• 考慮未預期的外部事件。 開發持續性計劃和風險評估，以考慮未受您控制的事件，例如天氣、停電或災害。

• 帳戶變更。 請確定 SLO 會考慮服務變更，或變更技術可靠性、輸送量、品質和可維護性，例如減少支持人員。

• 提供一組平衡的 SLO。 請確定提供服務或系統平衡或 360 度 觀點的 SLO 範圍，並專注於可靠性。

下一步

收集正確的數據