集群运维常常面临一个尴尬：监控面板上的曲线很多，告警消息也没少发，可一旦业务方问“这个服务到底能达到几个9”，往往没人能给出确定答案。原因并不复杂——原始监控指标没有被组织成可度量、可承诺、可追责的稳定性体系。SLA（Service Level Agreement，服务等级协议）、SLO（Service Level Objective，服务等级目标）、SLI（Service Level Indicator，服务等级指标）正是解决这个问题的三层框架。它们分别回答对外承诺什么、内部目标定多少、具体测量什么。在集群环境里，这三者不是孤立的概念，而是一条从原始遥测数据到商业承诺的加工链路。理解并落地这条链路，是让集群稳定性从经验判断走向数据驱动的关键一步。

一、先厘清 SLI、SLO、SLA 的边界与依赖

实际运维中很容易把这三个词混用，觉得都是稳定性指标。实际上它们处于不同层级。SLI 是最底层的测量值，直接来自监控系统，例如过去 5 分钟内 API Server 请求成功的比例、某类请求的 P99 延迟、节点处于 Ready 状态的数量占比。SLI 必须可量化、可采集、可聚合，否则后续目标无从谈起。

SLO 是基于 SLI 设定的内部目标，通常包含目标值和时间窗口两个要素。比如一个集群可以规定：30 天内，控制平面读请求的可用性 SLI 必须达到 99.95%。这个 99.95% 就是 SLO。它不直接对外承诺，主要用于指导团队判断当前稳定性是否偏离预期，并决定是否要投入资源修复。SLO 也是错误预算的起点。所谓错误预算，就是 1 减去 SLO 目标值后得到的允许失败空间。99.95% 可用性意味着 30 天内允许约 21.6 分钟不可用。

SLA 则是对外签订的商业协议，通常比 SLO 更保守。例如内部 SLO 是 99.95%，对外 SLA 可能只承诺 99.5%。两者之间的差值就是安全缓冲。SLA 往往带有违约条款，比如月度可用性低于承诺值时需要赔付或减免费用。因此，SLA 不是工程团队单独决定的，需要和业务、法务一起确认。

二、集群场景下怎样选择关键 SLI

集群要比单个服务复杂得多，SLI 的选型不能只看 CPU、内存这些基础资源指标，而要沿着用户请求的路径和运维操作链路来识别。集群的用户可能有两类：一类是运行在上面的业务 Pod，它们关心调度是否及时、网络是否连通、存储是否可挂载；另一类是外部开发者或 CI 系统，它们通过 API Server 执行 kubectl 操作，关心请求的响应速度和成功率。

从控制平面看，API Server 请求延迟和错误率是首要 SLI。可以按 HTTP 方法、资源类型、响应码拆分。比如读请求和写请求要分开统计，因为写请求直接影响集群状态，失败容忍度更低。etcd 作为 API Server 的后端存储，它的提交延迟和 leader 切换频率也必须纳入。调度器的工作队列深度和调度延迟反映集群资源分配的效率，如果队列长期积压，业务 Pod 会一直处于 Pending。

从数据平面看，节点 Ready 状态占比是基础的可用性指标，但它太粗。更细的 SLI 可以包括：Pod 从创建到 Running 的耗时、容器重启率、镜像拉取成功率、存储卷挂载成功率、节点间网络延迟。对于有状态服务，PVC 绑定和挂载的耗时往往是业务故障的高发点。建议每个 SLI 都明确定义口径，例如可用性是指 Pod 处于 Running 且就绪探针通过的比例，而不是只统计节点在线。

下面是一段 PromQL，用来计算 API Server 读请求的 P99 延迟：

# API Server 读请求 P99 延迟，窗口 5 分钟
histogram_quantile(
  0.99,
  sum by (le) (
    rate(
      apiserver_request_duration_seconds_bucket{
        verb="GET",
        scope="resource"
      }[5m]
    )
  )
)

这段查询会输出一个时间序列，代表过去 5 分钟内 GET 资源请求的 99 分位延迟。如果该值持续高于 SLO 阈值，就需要排查 API Server 或 etcd 的瓶颈。

三、从 SLI 到 SLO 的目标设定与错误预算

SLI 选好之后，还不能直接拍一个 99.9% 作为目标。目标定得太松，错误预算形同虚设；定得太紧，团队会陷入告警疲劳。正确的做法是先收集至少 30 天的基线数据，观察 SLI 的典型分布和长尾。比如 API Server 的 P99 延迟平时稳定在 80ms，但每天凌晨备份任务会冲到 500ms。如果 SLO 定为 P99 小于 100ms，就会频繁违约；如果定为 300ms，又掩盖了白天的性能问题。此时可以按时间分窗口设定不同 SLO，或者只统计业务高峰期的数据。

错误预算是 SLO 的核心价值。它不是用来追责，而是用来指导发布节奏和风险决策。一个常用的策略是：当错误预算剩余比例高于 80% 时，团队可以正常发布新功能；当剩余比例在 50% 到 80% 之间，需要增加发布审查；当低于 50% 时，冻结非紧急变更，优先做稳定性修复；当错误预算耗尽，则触发内部事故流程，集中复盘原因。

错误预算的计算可以写成 PromQL 表达式。假设某集群的目标是 30 天内 99.9% 可用，那么实际不可用时间与允许不可用时间的比值就是预算消耗比例。在监控系统中，通常用告警规则来跟踪这个比例。下面示例展示如何计算错误预算消耗百分比：

# 错误预算消耗比例，假设 SLO 为 99.9%，统计窗口 30 天
1 - (
  sum(rate(apiserver_request_total{code!~"5.."}[30d]))
  /
  sum(rate(apiserver_request_total[30d]))
)

这段查询会给出过去 30 天的成功请求比例，1 减去该值就是失败比例。如果该比例超过 0.1%，说明已经消耗完 99.9% 可用性的全部错误预算。实际操作中需要排除计划维护窗口和非核心请求，避免误报。

四、SLA 不是简单加个数字：承诺与工程化落地

SLA 与 SLO 最大的区别在于违约后果。工程团队可以承受 SLO 不达标，通过复盘和优化逐步改进；但 SLA 一旦违约，可能涉及商务赔偿和客户信任损失。因此，制定 SLA 时要预留足够的安全边际。通常建议 SLA 目标比 SLO 低一个数量级。比如 SLO 是 99.95%，SLA 可以承诺 99.5%，这样即使出现一次较长时间的控制平面抖动，内部目标已经接近破裂，但对外承诺仍然守得住。

SLA 条款需要明确测量方法、统计周期、排除项和赔偿方式。测量方法应该引用公开可审计的监控数据，而不是靠人工上报；排除项要写清计划维护、用户误操作、第三方网络故障等；赔偿方式可以是服务费减免或延长服务期。在多租户集群中，不同租户的 SLA 可能不同。核心业务租户可以承诺更高的可用性，测试租户则可以放宽。这要求平台层具备按命名空间或按集群拆分 SLI 的能力。

工程化落地上，SLA 不应只存在于合同文本里，还需要自动化输出日报、周报和月度报告。可以用 Grafana 面板展示各租户的 SLI 趋势、SLO 达标情况和错误预算剩余比例。当某个月度 SLA 接近违约时，系统要提前 7 天发出预警，而不是等到最后一天才暴露。这样业务方和平台团队都有缓冲时间协商处理。

五、完整建立流程与工具链支撑

建立集群 SLA、SLO、SLI 指标体系可以按六个步骤推进。第一步识别用户和旅程，明确谁在使用集群、他们最敏感的失败模式是什么。第二步选择关键 SLI，控制平面和数据平面各挑 3 到 5 个，避免一开始铺得太广。第三步统一指标口径和采集方式，确保所有团队对可用性、延迟的定义一致。第四步采集基线并设定 SLO，至少要有一个完整业务周期的数据支撑。第五步配置错误预算告警和发布策略，把 SLO 融入变更流程。第六步定期复盘，SLO 不是一成不变，业务结构和流量模型变化后需要调整。

工具链方面，Prometheus 负责采集和存储 SLI 原始数据，kube-state-metrics 提供资源对象状态，metrics-server 提供 CPU 内存基础指标，Grafana 做可视化和 SLO 面板，Alertmanager 负责告警路由。更高级的做法是引入专门的 SLO 计算服务，例如 Sloth 或 Pyrra，它们可以把 PromQL 查询转换成 SLO 和错误预算指标，并自动生成告警规则。

下面是一个使用 Sloth 风格定义 SLO 的 YAML 片段，展示如何把 SLI 查询和错误预算整合在一起：

version: prometheus/v1
service: cluster-control-plane
slos:
  - name: apiserver-read-availability
    objective: 99.95
    sli:
      events:
        error_query: sum(rate(apiserver_request_total{job="apiserver",code=~"5.."}[5m]))
        total_query: sum(rate(apiserver_request_total{job="apiserver"}[5m]))
    alerting:
      name: ApiserverReadErrorBudgetBurn

这段配置把 SLI 的分子和分母分开定义，由 SLO 计算服务自动生成错误预算消耗率和告警规则。这样团队就不用手工维护复杂的 PromQL，也能避免不同服务之间口径不一致的问题。指标体系建立后，最关键的还是持续运营。没有哪套 SLO 可以一劳永逸，每次事故复盘都应当回头检查 SLI 是否覆盖了真实故障路径，SLO 是否设得合理，SLA 是否仍与业务预期匹配。