SLI、SLO 与稳定性目标：系统治理为什么要有量化标准

很多团队谈稳定性时，常见表达都是“这个服务还挺稳”“最近好像不太稳定”“用户体验不能太差”。这些说法并不是完全没意义，但它们都太模糊。模糊最大的坏处，就是不同人对“稳”的理解可能完全不同，最终导致治理目标难以统一，排障优先级也难以判断。

SLI、SLO 这类概念真正重要的地方，不在于它们名字听起来专业，而在于它们试图把“稳定性”这种很容易流于感觉判断的事情，转换成一套更清晰、更可沟通、更可追踪的量化标准。

为什么稳定性必须被量化

因为系统治理离不开取舍。

如果没有量化目标，你很难判断某次错误率上升到底算不算严重，也很难判断一个优化值不值得投入资源，更很难在功能开发和稳定性治理之间做长期平衡。所有这些决策，本质上都需要一个相对明确的基准。

所以量化不是为了把问题复杂化，而是为了让“稳不稳”不再只靠感觉争论。

可以把 SLI 理解成“用什么指标来衡量服务质量”。

例如请求成功率、接口延迟、任务完成率、消息消费时延，这些都可能成为不同服务的服务水平指标。关键并不在于名字，而在于：你到底选了哪个指标来代表用户实际感受到的质量。

如果指标选错了，后面再精细的治理也会偏航。

如果说 SLI 是测量对象，那么 SLO 更像是在说“这个指标至少要达到什么水平”。

也就是说，SLO 把“我们希望服务做到什么程度”表达成了更明确的目标。例如成功率要达到多少、延迟在某个阈值内的比例要达到多少。这样一来，团队对稳定性的预期才真正有了共同语言。

因为系统的重要性、使用场景和用户预期本来就不同。

核心交易链路和内部后台工具，不可能使用完全一样的稳定性要求。高实时交互服务和批处理任务，对延迟和成功率的敏感度也完全不同。所以量化标准不是越高越好，而是越匹配真实业务边界越好。

这也说明 SLI 和 SLO 的设计，本质上还是业务理解问题，而不只是技术问题。

一旦你明确了稳定性目标，很多工程动作都会更有方向。

例如哪些告警应该更敏感，哪些发布必须更谨慎，哪些优化值得优先做，哪些功能即使能做也不值得以牺牲稳定性为代价去做。量化目标像一条基准线，让系统治理从“感觉上应该这样”变成“为了守住这个标准必须这样”。

一个常见误区是把目标定得极高，好像目标越严格就代表团队越专业。实际上过高且脱离实际的目标，往往只会让工程压力失真，甚至迫使团队在不必要的地方消耗大量资源。

另一个误区是只盯系统自身指标，而忽略用户真实体验。一个服务内部看起来很健康，不代表用户真的没有感知问题。

想一个你最熟悉的服务，试着回答。

做完这个练习，你会对“稳定性目标”有更具体的感受，而不再只是觉得它是个平台概念。

SLI、SLO 帮助团队把稳定性从模糊感受变成可讨论、可追踪、可取舍的量化目标。前者决定用什么指标来衡量服务质量，后者决定目标要达到什么水平。它们的真正意义，不是让术语更多，而是让系统治理和工程决策有了共同基准。