云原生服务SLO指标治理与监控体系构建 - 第1节

1.1 什么是 SLO、SLI、SLA

在开始落地 SLO 之前，必须先厘清三个最基础的概念：SLI、SLO 和 SLA。这三者构成了可观测性与服务质量管理的内核，也是整个课程后续所有方法论的基石。

1.1.1 SLI：服务等级指标

SLI（Service Level Indicator） 是对服务某个特定维度的量化测量。它回答的是“服务现在表现如何？”这个事实性问题。

常见的 SLI 类型包括：

• 可用性：请求成功数 / 总请求数（例如：99.9% 的请求返回 HTTP 2xx/3xx）
• 延迟：特定百分位下的响应时间（例如：P99 延迟 < 200ms）
• 吞吐量：单位时间处理的请求数（例如：每秒 10,000 次查询）
• 错误率：错误请求数 / 总请求数（例如：5xx 错误率 < 0.1%）
• 饱和度：资源使用程度（例如：CPU 使用率 < 80%）

1.1.2 SLO：服务等级目标

SLO（Service Level Objective） 是为 SLI 设定的目标阈值。它回答的是“我们希望服务表现成什么样？”这个期望性问题。

SLO 的典型表达方式：

SLI ≤ 目标值 或 SLI ≥ 目标值，在某个时间窗口内

示例：
- 99.9% 的请求在 200ms 内完成（延迟 SLO）
- 99.99% 的请求返回成功（可用性 SLO）
- 过去 30 天内，错误率不超过 0.1%（滚动窗口 SLO）

SLO 是内部承诺，由工程团队自行设定，用于指导日常运维、容量规划和发布决策。

1.1.3 SLA：服务等级协议

SLA（Service Level Agreement） 是服务提供方与客户/用户之间签订的正式合同。它回答的是“如果服务没达标，会有什么后果？”这个契约性问题。

SLA 通常包含：

• 承诺的服务等级（通常比 SLO 宽松）
• 测量方式和报告周期
• 未达标时的惩罚条款（如赔偿、服务抵扣）
• 例外情况和免责条款

1.1.4 三者的区别与联系

下面这张表格清晰展示了 SLI、SLO、SLA 的核心差异：

三者之间的关系可以用一句话概括：SLI 是数据，SLO 是目标，SLA 是契约。SLO 基于 SLI 设定，SLA 又基于 SLO 制定，但 SLA 通常比 SLO 更宽松，留出安全缓冲。

1.2 为什么需要 SLO？

很多团队在没有 SLO 的情况下也运行了多年，那为什么还要引入 SLO？原因可以归结为以下四个核心价值：

1.2.1 从“感觉”到“数据”的转变

没有 SLO 时，服务的健康状态依赖个人经验：“感觉最近系统有点慢”或“好像错误率变高了”。SLO 将这种模糊感知转化为可量化、可对比、可追溯的数字。团队可以明确回答：这个月可用性是否达标？延迟是否在预算内？

1.2.2 为决策提供客观依据

SLO 是技术决策的北极星指标。当需要决定“是否发布新版本”、“是否扩容”、“是否回滚”时，SLO 提供了清晰的判断标准：

• 发布决策：新版本是否导致 SLO 燃烧过快？如果是，则中止发布。
• 容量规划：当前资源能否支撑 SLO？是否需要提前扩容？
• 故障定级：影响 SLO 的故障才是高优先级故障，否则可以排队处理。

1.2.3 对齐业务与技术目标

SLO 是业务语言和技术语言的翻译器。业务方关心“用户体感好不好”，技术方关心“延迟 P99 是多少”。通过 SLO，双方可以共同定义：什么样的技术指标意味着好的用户体验？

1.2.4 控制告警风暴与运维噪音

没有 SLO 的监控系统往往告警泛滥：CPU 超过 80% 告警、内存使用率超过 70% 告警、单次请求超时告警……这些告警中大部分并不影响用户体验。SLO 提供了告警降噪的过滤器：

• 只有威胁 SLO 的事件才需要立即响应
• 不威胁 SLO 的异常可以降级为低优先级工单
• 通过错误预算（Error Budget）机制，量化可容忍的故障时间

1.3 核心概念速查表

为了帮助快速记忆，下面这张速查表总结了 SLI、SLO、SLA 的关键特征：