SLO 的价值不在看板上显示一个百分比，而在于帮助团队决定什么时候继续发布，什么时候暂停功能开发处理可靠性债务。
从用户行为选择 SLI
常用 SLI 包括请求成功率、延迟达标率、数据新鲜度和任务按时完成率。指标分母必须代表有效用户请求，健康检查和明显的客户端错误通常需要排除。
可用性 SLI = 成功请求数 / 有效请求总数
延迟 SLI = 在目标时间内完成的请求数 / 有效请求总数设定可承担的目标
99.9% 月度 SLO 约有 43 分钟错误预算。目标越高，架构和运维成本越高。应基于用户容忍度、依赖能力和历史表现，而不是直接选择最多的 9。
用预算驱动动作
预算充足时允许正常迭代；快速消耗时限制高风险发布并启动可靠性改进。规则要提前写进发布策略，避免事故现场临时争论。
常见问题
- 用基础设施 uptime 替代用户可感知指标
- 只看月末结果，无法及时发现快速燃烧
- SLO 高于依赖能提供的能力
- 没有明确预算耗尽后的动作
至少每季度复查一次 SLI 定义，确认它仍然代表真实用户体验。