1. SLO 基础概念：可靠性工程的基石
在 Kubernetes 及云原生架构中，可靠性不再是“尽力而为”的承诺，而是需要被精确度量、持续追踪并主动运营的工程指标。SLO（Service Level Objective，服务等级目标）正是这一转变的核心工具。要理解 SLO，必须先厘清它与 SLI、SLA 的关系。
1.1 三大概念定义
| 术语 | 全称 | 核心定义 | 典型示例（Kubernetes 场景） |
|---|---|---|---|
| SLI | Service Level Indicator 服务等级指标 |
对服务某个维度的实际度量值，是原始数据。 | 请求延迟 P99 = 120ms；错误率 = 0.05% |
| SLO | Service Level Objective 服务等级目标 |
对 SLI 设定的目标阈值，是内部承诺。 | 99.9% 的请求延迟 ≤ 200ms（月度滚动窗口） |
| SLA | Service Level Agreement 服务等级协议 |
与客户签订的法律/商业契约，含违约后果。 | 月度可用性 ≥ 99.95%，否则赔付 10% 月费 |
记忆口诀：SLI 是“测什么”，SLO 是“目标多少”，SLA 是“做不到赔多少”。
1.2 三者的区别与联系
三者的关系可以用“度量 → 目标 → 承诺”的链条来概括：
- SLI 是 SLO 的基础：没有可靠的 SLI 度量，SLO 就是空中楼阁。在 Kubernetes 中，SLI 通常来自 Prometheus 指标、API Server 审计日志或服务网格遥测数据。
- SLO 是 SLA 的内核：SLA 中承诺的数值必须基于 SLO 来设定。通常 SLA 会比 SLO 更宽松（例如 SLO 99.9%，SLA 99.95%），为内部留出“错误预算”缓冲。
- SLA 驱动商业行为：SLA 的违约赔偿条款反向推动团队必须严格运营 SLO，否则将面临直接经济损失。
关键区别：SLO 是内部工程目标，允许一定比例的失败（错误预算）；SLA 是外部法律承诺，违约必须赔付。SRE 团队主要围绕 SLO 进行日常运营，而非直接围绕 SLA。
1.3 SLO 在可靠性工程中的核心地位
SLO 之所以成为 SRE 和可靠性工程的基石，是因为它提供了以下关键能力：
- 量化可靠性：将模糊的“系统稳定”转化为具体的数字目标（如 99.9%），使团队对可靠性有一致的理解。
- 指导决策优先级：当错误预算充足时，团队可以放心进行功能发布；当错误预算即将耗尽时，必须冻结变更、优先修复稳定性。
- 驱动运维自动化：基于 SLO 的告警（如“错误预算消耗速度过快”）比传统阈值告警更早发现风险，触发自动扩缩容、熔断或回滚。
- 对齐业务与技术：SLO 将用户体验（如页面加载时间）映射为技术指标，让产品、开发和运维团队使用同一套语言沟通。
常见误区：不要试图为所有指标都设定 SLO。SLO 应聚焦于用户可见的关键路径（如 API 网关延迟、数据库查询耗时），而非内部组件细节（如 CPU 使用率）。过多的 SLO 会导致运营成本激增且稀释关注重点。
1.4 典型 SLO 指标维度（Kubernetes 场景）
| 维度 | SLI 示例 | 推荐 SLO 目标 | Kubernetes 数据源 |
|---|---|---|---|
| 可用性 | 请求成功率（非 5xx 占比） | ≥ 99.9% | Ingress Controller 日志、Kiali |
| 延迟 | P99 响应时间 | ≤ 200ms | Prometheus Histogram、Jaeger |
| 吞吐量 | 每秒请求数（RPS） | 满足峰值负载 × 1.5 冗余 | Kubernetes Metrics Server、Custom Metrics |
| 饱和度 | Pod CPU / 内存使用率 | ≤ 80%（预留缓冲） | kube-state-metrics、Node Exporter |
| 错误预算 | 月度累计错误时间 / 总时间 | 剩余 ≥ 20% 时允许发布 | 基于 SLO 计算的自定义指标 |
1.5 本章小结
- SLI 是原始度量，SLO 是目标阈值，SLA 是商业承诺。
- SLO 通过错误预算机制，将可靠性从“被动救火”转变为“主动运营”。
- 在 Kubernetes 场景下，SLO 的 SLI 数据源丰富（Prometheus、Istio、API Server 审计），为精细化运营提供了天然土壤。
- 后续章节将深入讲解如何在 Kubernetes 集群中设计 SLI 采集管道、计算错误预算，并构建基于 SLO 的自动化运营作业模板。