SLI 和 SLO 是运维日常盯控的数字标尺，将“服务好不好”转化为可采集、告警、复盘的具体指标；SLI 须可观测、可量化、强关联用户体验，如 HTTP 状态码占比、P95 首字节时间，而非 CPU 使用率。
SLI（Service Level Indicator）和 SLO（Service Level Objective）不是抽象概念，而是运维团队每天要盯、要调、要对齐的“数字标尺”。它们把模糊的“服务好不好”变成可采集、可告警、可复盘的具体指标，比如“API 99 分位响应时间 ≤ 200ms”或“月度可用率 ≥ 99.95%”。关键不在定义多漂亮，而在是否真实反映用户感知、是否能驱动改进动作。
SLI：从用户视角定义“什么是正常”
SLI 是衡量服务健康程度的基础观测值，必须满足三个条件：可观测、可量化、与用户体验强相关。不要直接用“CPU 使用率 > 80%”当 SLI——它不等于用户卡顿；而“HTTP 2xx/5xx 请求占比”或“首 字节 返回时间 P95
- 选 SLI 先问：如果这个指标恶化，用户会投诉吗？如果不会，大概率不是好 SLI
- 避免复合指标：如“系统健康分 = 0.3×CPU + 0.4×延迟 + 0.3×错误率”，它掩盖根因，也不可归责
- 同一服务在不同场景下 SLI 可不同：面向内部管理后台的 SLO 可比面向支付接口的更宽松
SLO：设定有共识、可落地的服务目标
SLO 是 SLI 在一段时间内的目标值，本质是团队对外（产品、客户）和对内（开发、运维）达成的“服务承诺”。它不是越严越好，而是权衡可用性、迭代速度与故障成本后的理性选择。例如，99.9% 的月度可用率意味着约 43 分钟不可用时间 / 月，需配套设计降级方案与告警阈值。
- 建议用“错误预算（Error Budget）”机制驱动决策：剩余预算充足时可加速发版；余额不足时自动冻结非紧急变更
- SLO 周期要匹配业务节奏：核心交易链路适合按周滚动计算；配置类服务可用按月评估
- 避免一刀切：前端 页面加载 SLO 和数据库主从同步延迟 SLO 应独立定义、分别监控
落地 SLI/SLO 的四个实操要点
很多团队卡在“知道但做不起来”。真正跑通的关键不在 工具，而在流程嵌入和责任对齐。
- 从一个关键链路起步：比如登录流程，梳理其 SLI（登录成功率、耗时 P95）、SLO（99.95%，P95 ≤ 800ms），跑通采集→告警→复盘闭环
- 用 Prometheus + Grafana 实现基础能力：SLI 做成 Recording Rule 预聚合，SLO 计算用 rate() / increase() 等函数，避免采样失真
- 告警只基于 SLO 违反，而非 SLI 异常：SLI 波动是现象，SLO 违反才代表承诺失效，应触发升级流程
- 每月召开 SLO 回顾会：不讨论“谁背锅”，只分析“错误预算花在哪？是偶发抖动还是架构瓶颈？下一步优化点？”
常见误区与应对
SLI/SLO 容易沦为文档摆设，往往因为脱离实际运行逻辑或缺乏 Owner 意识。
- “SLO 写在 Wiki 里，没人看”→ 把 SLO 卡片嵌入 CI/CD 流水线门禁，发布前自动校验错误预算余量
- “所有服务都套用 99.9%”→ 对非核心服务（如日志查询 API）设为 99%，释放运维精力聚焦关键路径
- “只监控不治理”→ 将 SLO 达成率纳入团队 OKR，与容量规划、压测计划强绑定
SLI 是眼睛，SLO 是方向盘，错误预算是油表。三者合起来，才能让运维从“救火队”转向“服务建筑师”。不复杂，但容易忽略对齐业务目标这一出发点。
