SLA和SLO監視

1）術語和角色

SLA（服務級別協議）是對客戶的外部合同義務（罰款條款，貸款）。
SLO（服務級別目標）是支持SLA執行的目標內部服務級別。
SLI（服務級別指標）是評估SLO/SLA的可測量指標。
錯誤預算是以下時期內「不可用/錯誤」的有效份額：「預算=1 − SLO」。
Scope：通過用戶的眼睛（端到端）進行測量。在微服務中-在組件和端到端路徑級別。

2）SLI選擇： 確切測量什麼

標準是與用戶體驗和業務價值的相關性。

• 可用性：成功查詢的比例。「SLI=成功/全部」。
• 潛伏期：查詢比例比T. 「SLI=P（潛伏期≤ T）」閾值快。
• 質量：正確答復的比例（無5 x/func）。錯誤）。
• 數據相關性：復制延遲/ETL ≤ X分鐘。
• 業務流程績效：成功付款/註冊的比例。

反模式：只將200 ki視為「成功」，而忽略了業務錯誤；在測試網絡而不是用戶網絡中進行測量。

3）公式和觀察窗口

• `Availability = (OK_requests / All_requests) × 100%`.

• 「P95 ≤ T」 →更好地表述為份額：'SLI=T ≤查詢的百分比。
• 示例：「99％的搜索請求在28天內≤ 300毫秒。」
• 滑動窗口：28天或30天（靈敏度和穩定性平衡）。對於事件-添加劑窗口：1小時,6小時,24小時。

4）錯誤預算和更改率控制

計算：以'SLO=99。9%'預算='0。在此期間有1％的錯誤/無法訪問。

• 預算>50%：發布和計劃實驗。
• 預算10-50%：只有低風險發行，加那利群島收緊。
• 預算<10%：發行凍結、根源原因、可靠性提高。
• 與漸進發行版的聯系：金絲雀/feature-flags「吃」預算劑量，降解時自動回滾。

5）警報政治： 從急流到燃燒率

為何不是「daupal SLO-alert子」：為時已晚。需要積極主動。

• 「BR=（觀察到的短窗口錯誤/該窗口的有效錯誤）」。
• 如果「BR> 1」-預算支出比正常水平快。

• 快速警報（噪音敏感，捕捉災難）：窗口5-10分鐘，BR閾值14-20 ×。
• 慢速警報（捕捉爬行降解）：窗口1-6小時，BR閾值2-4 ×。
• 條件組合：快速或緩慢工作-呼叫分頁。
• 級別：用於定制SLO的尋呼機，用於灰色內部降解SLI的滴答聲/通知。

6）可觀察性和真相來源

Logi-原因診斷。
度量是數字SLI（成功/錯誤，潛伏期，分數，計數）。
Traces-直通路徑，將「熱」段本地化。
合成劑是來自外圍的活性樣品（區域-aware）。
實際事件-客戶的RUM/遙測，業務指標（轉換，成功支付）。

要求：發布和事件的行車記錄簿中的單個圖片，「版本/金絲雀/標誌」註釋。

7） SLO設計： 分步模板

1.描述關鍵路徑（例如,「存款卡」）。
2.定義SLI：成功/錯誤、潛伏閾值、完整性。
3.商定SLO： 28天目標+例外（計劃窗口）。
4.與SLA聯系：法律義務≦實際的SLO。
5.指定所有者（服務所有者）、RACI和Alert通道。
6.定義警報策略（雙窗口BR和自動回滾）。
7.實施報告：每周預算審查，事後評論。
8.每季度修訂SLO（負載/體系結構變更）。

8） SLO示例（模板）

• 可用性：'≥ 99。95％'（28 d，不包括宣布的窗口≤ 30分鐘/月）。
• 潛伏期："≥ 99%"答案"≤ 400毫秒。
• 業務運營成功：'≥ 98.5％的成功授權（考慮了fraud過濾器）。

• 潛伏期："≥ 99%"查詢"≤ 300毫秒。
• 緩存相關性：99%的「≤ 5分鐘」積壓。

• 交付：'≥ 99.9%在「≤ 60秒內」（端到端,帶回程）。
• 損失：'≤ 0。01％的消息（啟用了平均電平/重復數據消除）。

9）多區域和多特南特

SLO「按隊列」：國家，支付提供商，VIP部門，設備。
邊緣的本地SLO：來自最接近用戶的點（edge/PoP）的度量。
聚合：通用SLO不應隱藏重要隊列的失敗。
切換提供商：在SLO門級別自動返回路由。

10）Dashbords和報告

發布的行車記錄板：版本，金絲雀（流量百分比），SLI（成功/潛在），BR，標誌註釋。
操作減速板：每天的燃燒預算，頂級事件，MTTR，有問題的隊列。
每周報告：預算余額，BR趨勢，技術債務（瓶頸），改進計劃。

11）過程： 事件，RCA和改進

事件管理：警報→ BR評估→加那利群島/旗幟的規模→回滾/假冒。
RCA（根原因）：事實/時間線/假設/修復/SLI效果檢查。
汲取的經驗教訓：非勤奮的後面面具，強制性的行動項目，包括所有者和時間表。
循環閉合：測試、幻燈片標誌、限制、緩存、撤退、配額的變化。

12）合規與審計

SLO/SLI作為控制工件（策略即代碼，不可更改的邏輯）。
綁定到要求（例如支付交易的可用性）。
證據：警報協議，預算報告，發行日誌/回扣。

13）頻繁的錯誤以及如何避免錯誤

“99.99％或死亡"：無法實現的目標→持續的警報噪音。選擇現實的SLO。
全局平均值掩蓋了局部失誤→引入隊列。
度量標準不是e2e：客戶端實際降解時的高SLO →添加RUM/合成。
Alerta →通過一個閾值切換到雙窗口燃燒率。
與更改無關→版本沒有註釋，沒有自動回滾。

14）實施迷你支票清單

• 描述了關鍵路徑及其SLI/SLO。
• 設置監視和排除窗口。
• 配置了雙窗口BR-Alerta（快速和緩慢）。
• 發行版本和帶有版本/標記註釋的操作的行列。
• 錯誤預算策略會影響發行版。
• 定期預算審查和事後RCA。
• 文件和指標所有者。

15）計算示例（細節）

API可用性SLO： 99。9％在28天內→預算=0。1%.

7天內累積了0。06％的錯誤→花費了每周預算的60％。

在15分鐘的短窗口中觀察到2％的錯誤。此窗口允許： '0。1%的×（15分鐘/40320分鐘）≈ 0。000037%`.

Burn Rate ≫ 1（數十×）→觸發快速尋呼機，金絲雀回滾高達1％，啟用「degrade-payments-UX」字形標誌，RCA觸發。

16）結果

SLA/SLO監控不僅是報告中的數字，而且是管理變更風險和服務質量的機制。正確的SLI、逼真的SLO、錯誤預算管理、雙窗口燃燒率和e2e可觀察性將指標轉化為工作解決方案：更快地釋放價值並保持用戶體驗的可預測性。