在 Kubernetes 上运行生产服务时，团队经常陷入一个矛盾：业务要求快速迭代，而稳定性团队希望严格控制变更。错误预算正是为解决这个矛盾而生的量化指标。它把服务的可靠性目标转化为一定时间内允许的失败额度，只要预算没有耗尽，团队就可以按照正常节奏发布；一旦预算被击穿，就需要暂停高风险操作，集中精力恢复稳定性。这种机制比单纯依靠人工审批或发布窗口更加客观，也更容易自动化。
错误预算的底层逻辑与 SLO 设定
错误预算的计算公式非常直接：错误预算 = 1 - SLO。例如某个服务承诺月度可用性为 99.9%，那么允许的不可用时间为 43.2 分钟；如果 SLO 提升到 99.99%，错误预算则缩减到 4.32 分钟。这里的可用性通常不是简单的进程存活，而是从用户视角定义的成功请求比例或延迟达标比例。在 Kubernetes 环境中，一个 Pod 处于 Running 状态并不代表服务健康，因为应用内部可能返回 500，或者数据库连接池耗尽导致部分请求超时。因此计算错误预算前，必须先确定合适的 SLI。
SLI 的选择直接影响错误预算的准确度。对于大多数微服务，请求成功率是首选指标，计算公式为：成功请求数除以总请求数。对于延迟敏感的服务，还需要加入延迟 SLO，例如 95% 的请求必须在 300 毫秒内完成。Kubernetes 本身提供了容器级别的 CPU、内存指标，但这些指标不能直接等同于用户体验。推荐从 Ingress 网关、服务网格或应用埋点中采集请求维度指标。以 Prometheus 为例，计算 5 分钟窗口内的错误率可以使用如下 PromQL：
sum(rate(http_requests_total{job="myapp",status=~"5[0-9][0-9]"}[5m]))
/
sum(rate(http_requests_total{job="myapp"}[5m]))
这条查询会返回一个 0 到 1 之间的值，代表 5 分钟内 5xx 错误占所有请求的比例。需要注意的是，如果使用正则匹配状态码，5[0-9][0-9] 会覆盖 500 到 599 的区间，但不会包含 4xx，因为 4xx 通常属于客户端错误，是否计入错误预算需要产品团队明确。有些团队会把特定 4xx 也算作失败，例如 429 限流错误，这会影响预算消耗速度。
在 Kubernetes 多副本场景下，滚动更新会短暂出现新旧版本共存的情况。如果新版本存在兼容性问题，错误率可能在更新过程中上升，此时错误预算会快速消耗。因此 SLO 的统计窗口建议采用月度或双周维度，而不是小时维度，否则单次发布导致的短暂波动就会耗尽全部预算，使机制失去意义。设定 SLO 时还要考虑维护窗口、云服务商基础设施故障等不可控因素，避免目标定得过高造成误报。
Kubernetes 中采集 SLI 与监控设计
要让错误预算真正落地，必须有稳定可靠的 SLI 采集管道。Kubernetes 生态中最常见的方案是 Prometheus 配合 ServiceMonitor 或 PodMonitor 自动发现指标端点。应用需要在 /metrics 端点暴露请求计数和延迟直方图，ServiceMonitor 通过标签选择器关联到对应的 Service，然后 Prometheus 定期抓取指标。下面是一个典型的 ServiceMonitor 配置：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: myapp-servicemonitor
namespace: production
spec:
selector:
matchLabels:
app: myapp
endpoints:
- port: metrics
interval: 30s
path: /metrics
这个配置会让 Prometheus 每 30 秒从带有 app=myapp 标签的 Service 后端 Pod 抓取指标。如果服务运行在 Istio 服务网格中，还可以利用 Envoy 自动暴露的指标计算请求成功率，而不需要修改应用代码。但无论采用哪种方式，都要保证指标中携带足够多的标签，例如服务名、版本号、HTTP 状态码，以便后续细分错误预算。
除了白盒监控，黑盒监控也是错误预算的重要补充。白盒监控依赖于应用主动暴露指标，如果应用完全崩溃，Prometheus 可能无法获取数据，从而出现监控盲区。黑盒监控通过从集群外部发送 HTTP 请求来验证服务可用性，blackbox-exporter 是常用工具。例如可以配置一个探测任务，每 10 秒访问健康检查接口，当探测失败率达到一定阈值时，直接计入错误预算。在 Kubernetes 中，blackbox-exporter 可以以 Deployment 方式部署，并通过 Prometheus 的静态配置或额外抓取配置关联。
还有一个容易忽视的问题是时延数据的采集。请求成功率只能反映“是否成功”，不能反映“是否足够快”。如果用户等待时间超过 1 秒，即使请求最终返回 200，用户体验也已经受损。因此延迟类 SLI 需要借助 Prometheus 的 Histogram 类型指标，并在 PromQL 中使用 histogram_quantile 函数计算分位数。错误预算如果只基于错误率，会漏掉大量的性能退化问题。
基于错误预算的发布策略与自动化
错误预算最大的价值不在于事后统计，而在于事前控制。当剩余预算充足时，可以自动允许团队进行更快速的发布，例如使用金丝雀发布或蓝绿发布；当预算低于阈值时，自动暂停 CD 流水线，强制团队处理稳定性问题。在 Kubernetes 生态中，Argo Rollouts 和 Flux 都支持渐进式发布策略，可以与 Prometheus 指标结合做自动回滚。例如 Argo Rollouts 可以在分析阶段查询错误率，如果超过阈值则自动回退到旧版本。
更灵活的做法是在 CI/CD 流水线中直接查询 Prometheus API 获取当前错误预算消耗情况，然后根据结果决定是否继续部署。以下脚本片段演示了如何计算最近 1 小时的错误率，并与 SLO 允许的错误率做比较：
#!/bin/bash
SLO=99.9
ALLOWED_ERROR_RATE=$(echo "scale=6; (100 - $SLO) / 100" | bc)
CURRENT_ERROR_RATE=$(curl -sG 'http://prometheus:9090/api/v1/query' \
--data-urlencode 'query=sum(rate(http_requests_total{status=~"5[0-9][0-9]"}[1h])) / sum(rate(http_requests_total[1h]))' \
| jq -r '.data.result[0].value[1]')
if (( $(echo "$CURRENT_ERROR_RATE > $ALLOWED_ERROR_RATE" | bc -l) )); then
echo "错误预算已耗尽，禁止发布"
exit 1
else
echo "错误预算充足，允许发布"
exit 0
fi
这段脚本使用 bc 做浮点数比较，避免了 shell 原生整数比较的局限。实际生产环境中，建议把这类检查放在发布流水线的 approval 阶段之前，避免人工审批滞后。还可以将查询结果发送到 Grafana 看板，让开发团队直观看到剩余预算。
策略引擎也可以实现更细粒度的控制。例如使用 Open Policy Agent 作为 Kubernetes Admission Controller，在创建 Deployment 资源时检查标签中声明的错误预算状态。如果预算耗尽，则拒绝带有高风险标记的变更请求。这种方式不需要修改 CI/CD 脚本，所有通过 kubectl 或 GitOps 提交的变更都会被统一拦截。但要注意，策略引擎无法感知应用层错误率，因此仍需要与监控系统联动。
常见误区与预算恢复策略
错误预算管理中最常见的误区是把预算当作必须完全避免消耗的指标。实际上，错误预算的唯一用途就是被消耗，它代表团队可以承受的失败范围。如果团队把错误预算视为不可触碰的红线，那么任何变更都会被过度限制，最终导致功能交付变慢。正确的做法是：预算消耗到一定程度时触发告警和评审，而不是等到完全耗尽才行动。例如可以设置黄色阈值 50% 和红色阈值 100%，分别对应不同级别的响应。
另一个误区是只关注聚合平均值。Kubernetes 集群中可能存在流量不均的情况，某个副本持续返回错误，但平均错误率仍然很低。此时需要结合分位值和按 Pod 维度拆分的指标，定位具体的故障副本。比如使用 kubectl top pod 查看资源使用，再结合 Prometheus 按 pod 标签查询错误率，往往能发现单个副本的异常。错误预算的恢复也不能只靠回滚，还需要深入分析根因，例如是否是配置变更、镜像版本、节点调度或网络策略导致。
预算恢复策略包括：回滚到上一个稳定版本、扩容以缓解资源争用、重启异常副本、调整限流阈值、修复数据库慢查询等。在 Kubernetes 中，回滚 Deployment 可以使用 kubectl rollout undo deployment/myapp，但回滚只能恢复代码版本，如果错误由外部依赖或容量引起，回滚无效。因此错误预算耗尽后，应该暂停所有非紧急变更，集中精力恢复预算，而不是匆忙发布新的修复版本，因为新版本本身也会消耗预算。可以借助混沌工程在预发布环境提前消耗预算，验证监控告警和自动回滚的有效性。
总之，Kubernetes 错误预算管理不是单点工具，而是 SLI 定义、监控采集、发布控制和团队文化的组合。只有把预算量化并接入自动化流程，才能在快速迭代与高可用之间找到可持续的平衡点。
