SLO / SLA 体系建设从监控到业务保障的跨越专栏监控 可观测性难度专家标签SLOSLASRE可用性错误预算前言监控告警是运维的手段SLO/SLA 才是运维的目标。这篇文章帮你建立从技术指标到业务保障的完整体系。一、概念澄清SLAService Level Agreement对外承诺给用户的服务水平协议违反有赔偿SLOService Level Objective内部设定的服务水平目标是 SLA 的技术支撑SLIService Level Indicator用于衡量 SLO 的具体指标错误预算Error Budget1 - SLO是允许的不可用时间二、SLI 定义可用性 SLI 成功请求数 / 总请求数 # Prometheus 计算可用性 ( sum(rate(http_requests_total{status!~5..}[5m])) / sum(rate(http_requests_total[5m])) ) * 100常见 SLI 类型可用性成功请求比例推荐核心业务使用延迟P99 500ms 的请求比例吞吐量QPS 不低于最低值错误率5xx 错误率低于阈值三、SLO 设定原则SLO 不是越高越好 99.9% 允许 8.76 小时/年 不可用 99.99% 允许 52.6 分钟/年 不可用 99.999% 允许 5.26 分钟/年 不可用 从 99.9% 到 99.99% 的成本差距往往是10倍以上 应当根据业务价值决定 SLO而不是技术可行性四、错误预算管理# 错误预算计算slo99.9# 99.9%period_days30total_minutesperiod_days*24*60error_budget_minutestotal_minutes*(1-slo/100)# 43200 * 0.001 43.2 分钟# 当错误预算消耗超过50%时暂停非必要变更# 当错误预算消耗超过100%时停止所有功能发布专注可靠性五、Grafana SLO 看板# 30天可用性 ( sum(increase(http_requests_total{status!~5..}[30d])) / sum(increase(http_requests_total[30d])) ) * 100 # 剩余错误预算分钟 ( 1 - ( sum(increase(http_requests_total{status~5..}[30d])) / sum(increase(http_requests_total[30d])) ) / (1 - 0.999) ) * 30 * 24 * 60结语SLO体系的价值在于把系统没问题这个感性判断变成错误预算还有X%的精确数字让技术工作有了业务语言。