[{"data":1,"prerenderedAt":482},["ShallowReactive",2],{"article-\u002Farticles\u002Fsre-slo-sli-sla-error-budget":3},{"id":4,"title":5,"body":6,"date":469,"description":115,"excerpt":470,"extension":471,"meta":472,"navigation":473,"path":474,"seo":475,"stem":476,"tags":477,"__hash__":481},"articles\u002Farticles\u002Fsre-slo-sli-sla-error-budget.md","SRE 的 SLI、SLO、SLA 與錯誤預算：先分清楚「量什麼」「承諾什麼」「賠什麼」",{"type":7,"value":8,"toc":458},"minimark",[9,14,18,51,54,57,61,75,106,116,119,123,126,132,135,179,182,200,207,213,217,226,229,235,238,292,296,299,305,308,312,315,321,330,333,351,354,358,361,433,449,452,455],[10,11,13],"h2",{"id":12},"三個縮寫三個不同層次的問題","三個縮寫，三個不同層次的問題",[15,16,17],"p",{},"SRE（Site Reliability Engineering）用 SLI、SLO、SLA 三個概念，把「服務可靠嗎」這個模糊的問題拆成三個可以分別回答的層次：",[19,20,21,33,42],"ul",{},[22,23,24,28,29,32],"li",{},[25,26,27],"strong",{},"SLI（Service Level Indicator，服務水準指標）","：",[25,30,31],{},"量測什麼","——用什麼具體、可觀測的數字代表服務品質",[22,34,35,28,38,41],{},[25,36,37],{},"SLO（Service Level Objective，服務水準目標）",[25,39,40],{},"內部目標訂多少","——這個指標要維持在什麼範圍，才算「服務健康」",[22,43,44,28,47,50],{},[25,45,46],{},"SLA（Service Level Agreement，服務水準協議）",[25,48,49],{},"對外承諾、沒達成要賠什麼","——寫進合約、對客戶的正式承諾，通常附帶罰則或補償",[15,52,53],{},"三者是包含關係：先有 SLI 這個量尺，才能訂 SLO 這個內部目標，SLA 則通常是 SLO 裡再留一點緩衝、正式對外公布的版本。",[15,55,56],{},"混用最常見的錯誤，是把內部拿來自我要求的 SLO 直接當 SLA 公佈出去——SLO 是團隊用來提早自我警惕的門檻，SLA 是對外的底線，兩者刻意留有落差才有意義。",[10,58,60],{"id":59},"用一個案例貫穿全文電商訂單系統的-orderservice","用一個案例貫穿全文：電商訂單系統的 OrderService",[15,62,63,64,69,70,74],{},"為了不讓 SLI、SLO、SLA 停留在抽象定義，這篇文章統一用同一個場景舉例：",[65,66,68],"a",{"href":67},"\u002Fportfolio\u002Fecommerce-microservices-observability","電商微服務可觀測性專案"," 裡的 ",[71,72,73],"code",{},"OrderService","。",[15,76,77,78,80,81,84,85,88,89,80,91,94,95,97,98,101,102,105],{},"使用者呼叫「建立訂單」API 後，",[71,79,73],{}," 發布 ",[71,82,83],{},"OrderCreatedEvent","，交給 ",[71,86,87],{},"PaymentService"," 請款；付款完成後 ",[71,90,87],{},[71,92,93],{},"PaymentCompletedEvent","，",[71,96,73],{}," 收到後確認付款（",[71,99,100],{},"OrderPaid","），再觸發 ",[71,103,104],{},"ShippingService"," 出貨。整個流程畫成圖大致是這樣：",[107,108,113],"pre",{"className":109,"code":111,"language":112},[110],"language-text","使用者\n  │\n  │ 建立訂單\n  ▼                    ← SLI 量測點：建立訂單成功且夠快的比例\nOrderService\n  │\n  │ 發布 OrderCreatedEvent\n  ▼\nPaymentService\n  │\n  │ 向金流請款\n  ▼                    ← 錯誤預算消耗點：Consumer Lag 過高，訂單卡在這步\nPaymentCompletedEvent\n  │\n  ▼\nOrderService（確認付款 OrderPaid）\n  │\n  ▼\nShippingService（觸發出貨）\n","text",[71,114,111],{"__ignoreMap":115},"",[15,117,118],{},"下面每一節都會回到這個場景，示範 SLI 怎麼選、SLO 怎麼訂、SLA 怎麼跟 SLO 拉開差距，以及錯誤預算怎麼算、怎麼用；最後一節再把這幾步收斂成一張總表。",[10,120,122],{"id":121},"sli先選對量什麼量測才有意義","SLI：先選對「量什麼」，量測才有意義",[15,124,125],{},"SLI 是一個比率，通常長這樣：",[107,127,130],{"className":128,"code":129,"language":112},[110],"SLI = 好的事件數 \u002F 總事件數\n",[71,131,129],{"__ignoreMap":115},[15,133,134],{},"常見的 SLI 選擇，取決於服務的本質：",[136,137,138,151],"table",{},[139,140,141],"thead",{},[142,143,144,148],"tr",{},[145,146,147],"th",{},"服務類型",[145,149,150],{},"常見 SLI",[152,153,154,163,171],"tbody",{},[142,155,156,160],{},[157,158,159],"td",{},"請求／回應型 API",[157,161,162],{},"可用性（成功回應的比例）、延遲（在 X 毫秒內回應的比例）",[142,164,165,168],{},[157,166,167],{},"資料處理／批次系統",[157,169,170],{},"新鮮度（資料多久前更新）、正確性（處理結果無誤的比例）",[142,172,173,176],{},[157,174,175],{},"儲存系統",[157,177,178],{},"耐久性（資料不遺失的比例）、可用性",[15,180,181],{},"選 SLI 最容易犯的錯，是選了系統內部方便量測、但不代表使用者真實體驗的指標。例如只看伺服器的 CPU、記憶體使用率——這些是資源指標（Resource Metric），可以拿來做容量規劃，但不能直接代表使用者感受到的服務品質。",[15,183,184,185,192,193,195,196,199],{},"SLI 應該盡量貼近使用者視角、用業務語言描述，而不是直接拿 API 路徑、HTTP 狀態碼這種技術術語當指標名稱——",[25,186,187,188,191],{},"使用者在意的是「建立訂單這件事有沒有順利完成」，不是「",[71,189,190],{},"\u002Forders"," 端點回不回 5xx」","。拿 ",[71,194,73],{}," 舉例，比較貼近使用者體驗的 SLI 會是：",[25,197,198],{},"過去一段時間內，「建立訂單」成功且在 300 毫秒內完成的比例","，而不是「伺服器 CPU 有沒有超過 80%」這種內部資源指標。",[15,201,202,203,206],{},"底層量測時當然還是要落到具體的 API 與狀態碼，但那是",[25,204,205],{},"實作細節","，不是對外溝通這個 SLI 時該用的語言：",[107,208,211],{"className":209,"code":210,"language":112},[110],"# 業務指標：建立訂單成功且在 300ms 內完成的比例\nsum(rate(http_requests_total{service=\"OrderService\", route=\"\u002Forders\", status!~\"5..\", le=\"300ms\"}[28d]))\n\u002F\nsum(rate(http_requests_total{service=\"OrderService\", route=\"\u002Forders\"}[28d]))\n",[71,212,210],{"__ignoreMap":115},[10,214,216],{"id":215},"slo內部目標用來在還沒出事的時候就先警覺","SLO：內部目標，用來在「還沒出事」的時候就先警覺",[15,218,219,220,222,223,74],{},"SLO 是針對 SLI 訂出的目標範圍，通常寫成「在 N 天的滾動視窗內，SLI 要維持在 X% 以上」。針對前面的 ",[71,221,73],{}," 建立訂單 API，一個合理的內部 SLO 可能是：",[25,224,225],{},"過去 30 天，可用性 ≥ 99.9%",[15,227,228],{},"SLO 不是訂得越高越好。100% 的可靠性幾乎不可能達成，而且追求它的邊際成本極高——從 99.9% 提升到 99.99%，代表允許的故障時間從一年 8.76 小時降到 52.6 分鐘，這通常需要多活架構、更複雜的容錯機制，成本可能是等比級數上升，但使用者實際感受到的差異可能很小。",[15,230,231,232,234],{},"訂 SLO 時該問的問題是：使用者真的會在意這個差異嗎？多花的成本，值得換來這個差異嗎？對 ",[71,233,73],{}," 來說，建立訂單偶爾多等幾百毫秒，使用者多半無感；但如果整條「建立訂單 → 確認付款 → 觸發出貨」的事件鏈卡住超過幾分鐘，使用者就會直接看到訂單狀態卡住不動，這種等級的落差，才是決定 SLO 該訂多嚴格的依據。",[15,236,237],{},"常見的可用性 SLO 與對應的容忍停機時間（一年）：",[136,239,240,250],{},[139,241,242],{},[142,243,244,247],{},[145,245,246],{},"SLO",[145,248,249],{},"一年可容忍的停機時間",[152,251,252,260,268,276,284],{},[142,253,254,257],{},[157,255,256],{},"99%",[157,258,259],{},"約 3.65 天",[142,261,262,265],{},[157,263,264],{},"99.9%",[157,266,267],{},"約 8.76 小時",[142,269,270,273],{},[157,271,272],{},"99.95%",[157,274,275],{},"約 4.38 小時",[142,277,278,281],{},[157,279,280],{},"99.99%",[157,282,283],{},"約 52.6 分鐘",[142,285,286,289],{},[157,287,288],{},"99.999%",[157,290,291],{},"約 5.26 分鐘",[10,293,295],{"id":294},"sla對外承諾通常比-slo-更寬鬆","SLA：對外承諾，通常比 SLO 更寬鬆",[15,297,298],{},"SLA 是寫進合約、對客戶的正式承諾，沒達成通常伴隨罰則（例如：退費、抵用額度）。因為違反 SLA 有實際代價，SLA 的門檻通常會設得比內部 SLO 更寬鬆。",[15,300,301,302,304],{},"如果 ",[71,303,73],{}," 未來要包裝成對外銷售的電商 SaaS，內部 SLO 可以訂 99.95%，但寫進客戶合約的 SLA 通常會退一步只承諾 99.9%——中間留的差距，就是給團隊在真正踩到「要賠錢」的紅線之前，有機會先自己發現、先自己修正的緩衝空間。",[15,306,307],{},"如果把 SLO 直接當 SLA 公佈，等於把「自我警惕的門檻」和「賠錢的底線」訂成同一條線，團隊會失去這段緩衝，每次 SLO 稍微沒達標就等於要面對合約糾紛，這通常會逼團隊在訂 SLO 時反而不敢訂高，長期反而傷害真正的可靠性文化。",[10,309,311],{"id":310},"錯誤預算把可靠性換算成一個可以花的額度","錯誤預算：把「可靠性」換算成一個可以花的額度",[15,313,314],{},"錯誤預算（Error Budget）是 SRE 最核心的工具，公式很直接：",[107,316,319],{"className":317,"code":318,"language":112},[110],"錯誤預算 = 1 - SLO\n",[71,320,318],{"__ignoreMap":115},[15,322,301,323,325,326,329],{},[71,324,73],{}," 建立訂單 API 的 SLO 是 99.9%，錯誤預算就是 0.1%——代表在 30 天的視窗週期內，允許不可用（或不符合 SLI 定義的「好」）的時間大約是 ",[25,327,328],{},"43.2 分鐘","，這是團隊在這個週期內可以「花」的額度。",[15,331,332],{},"錯誤預算真正厲害的地方，是它把「可靠性」跟「開發速度」放進同一個可以量化的天平上，變成團隊自己可以決定怎麼分配的資源，而不是模糊的「盡量別出事」：",[19,334,335,341],{},[22,336,337,340],{},[25,338,339],{},"預算還沒花完","：代表系統目前比承諾的更可靠，團隊可以承擔更高風險——加快發版節奏、上更多實驗性功能、做更積極的架構重構",[22,342,343,346,347,350],{},[25,344,345],{},"預算已經花完（或快花完）","：代表可靠性已經逼近甚至跌破承諾的底線，這時候應該",[25,348,349],{},"凍結非必要的變更","，把資源轉去修復可靠性問題（減少故障、改善監控、補測試），直到預算恢復到安全水位",[15,352,353],{},"這個機制解決了 SRE 團隊與產品／開發團隊之間最常見的拉鋸：開發團隊想衝功能上線速度，SRE 想要穩定，雙方常常各說各話。錯誤預算把這個拉鋸變成一條雙方都同意、有數字依據的規則——預算沒花完就能衝，花完了就該停下來修穩定性，不需要每次都吵一輪「這樣改風險大不大」。",[10,355,357],{"id":356},"三者放在一起的實務流程走一遍-orderservice-的完整情境","三者放在一起的實務流程：走一遍 OrderService 的完整情境",[15,359,360],{},"把前面幾節串起來，套進「建立訂單」這件事，四個概念實際會填成這樣的具體範例：",[136,362,363,376],{},[139,364,365],{},[142,366,367,370,373],{},[145,368,369],{},"概念",[145,371,372],{},"決定什麼",[145,374,375],{},"「建立訂單」的範例",[152,377,378,391,403,420],{},[142,379,380,385,388],{},[157,381,382],{},[25,383,384],{},"SLI",[157,386,387],{},"量什麼",[157,389,390],{},"建立訂單成功且在 300ms 內完成的比例",[142,392,393,397,400],{},[157,394,395],{},[25,396,246],{},[157,398,399],{},"內部目標訂多嚴格",[157,401,402],{},"過去 30 天，建立訂單成功的比例 ≥ 99.9%",[142,404,405,410,413],{},[157,406,407],{},[25,408,409],{},"Error Budget",[157,411,412],{},"這個週期可以花多少不可用時間",[157,414,415,416,419],{},"30 天內，建立訂單最多可以累計 43.2 分鐘不可用（",[71,417,418],{},"1 - 99.9%"," 換算）",[142,421,422,427,430],{},[157,423,424],{},[25,425,426],{},"SLA",[157,428,429],{},"對外承諾、賠什麼",[157,431,432],{},"對客戶承諾建立訂單成功率 ≥ 99.5%，達不到就退費或補償",[15,434,435,438,439,441,442,445,446,448],{},[25,436,437],{},"實際決策範例","：某天 ",[71,440,87],{}," 因為 Kafka Consumer Lag 飆高，大量訂單卡在「已建立、但付款一直沒被確認」，事後盤點這次事件吃掉了 30 分鐘的錯誤預算，只剩 13.2 分鐘餘裕。團隊據此決定這個月",[25,443,444],{},"暫停","訂閱制、優惠券等新功能開發，優先修 ",[71,447,87],{}," 的消費延遲、補上 Consumer Lag 告警，等下個 30 天視窗重新開始、預算恢復安全水位，才恢復原本的功能開發步調。",[15,450,451],{},"這張表就是 SLI、SLO、SLA、錯誤預算實際搭配運作的樣子：SLI 決定量什麼，SLO 決定內部多嚴格，SLA 決定對外承諾多少，錯誤預算則把前三者換算成一個具體數字，讓「現在該衝新功能還是該停下來修穩定性」變成有數字依據的決策，而不是靠感覺吵架。",[10,453,454],{"id":454},"一句話總結",[15,456,457],{},"SLI 決定量什麼，SLO 決定內部目標訂多嚴格，SLA 決定對外承諾與賠什麼；錯誤預算則是把「可靠性」換算成一個團隊可以自己決定怎麼花的額度——預算還在，就有本錢衝新功能；預算花完，就該停下來把穩定性補回來。",{"title":115,"searchDepth":459,"depth":459,"links":460},2,[461,462,463,464,465,466,467,468],{"id":12,"depth":459,"text":13},{"id":59,"depth":459,"text":60},{"id":121,"depth":459,"text":122},{"id":215,"depth":459,"text":216},{"id":294,"depth":459,"text":295},{"id":310,"depth":459,"text":311},{"id":356,"depth":459,"text":357},{"id":454,"depth":459,"text":454},"2026-09-20",null,"md",{},true,"\u002Farticles\u002Fsre-slo-sli-sla-error-budget",{"title":5,"description":115},"articles\u002Fsre-slo-sli-sla-error-budget",[478,246,384,426,479,480],"SRE","錯誤預算","可靠性","lqwaaMIs2KkvlJVPpDiWDS6HlFHFdbAdfvCtkF9tfyY",1792959150190]