SRE 的“四体问题”：自治运维为什么绕不开上下文

2026-07-06 33 预计阅读时间: 1 分钟
来源: cncf.io AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：9 分钟

一屋子资深 SRE 讨论自治运维时，最容易达成共识的不是“AI 能不能执行命令”，而是“我们凭什么信它现在该执行这个命令”。真正的缺口不在动作本身，而在上下文：服务拓扑、变更历史、告警质量、业务影响、值班规则，这些信息缺一块，自治系统就会从“助手”滑向“高权限猜谜机器”。

自治运维不是自动化脚本的升级版

传统自动化通常处理确定问题：磁盘满了清日志，Pod 卡住了重启，证书快过期了发通知。输入、判断、动作都比较稳定。

自治运维要面对的是另一类问题：同样是 5xx 飙升，可能是刚发布的版本问题，可能是下游支付接口抖动，可能是限流策略生效，也可能是监控标签改坏了。系统如果只看一条告警，就很难做出可信判断。

这也是“信任差距”的核心：SRE 不一定反对机器执行修复动作，但会要求机器解释清楚：

  • 你看到了哪些信号？
  • 你排除了哪些可能？
  • 当前动作的爆炸半径多大？
  • 如果判断错了，如何回滚？
  • 哪些场景必须交给人确认？

没有这些信息，所谓 autonomous operations 只是把 kubectl delete pod 包了一层更漂亮的界面。

“四体问题”：四类上下文互相牵引

可以把自治运维里的上下文拆成四类“引力源”。它们不是线性关系，而是互相影响。

运行时上下文：指标、日志、链路追踪、事件、错误预算、SLO 状态。它回答“系统现在发生了什么”。

变更上下文：最近发布、配置变更、Feature Flag、基础设施调整、依赖版本更新。它回答“刚刚有什么东西动过”。

业务上下文：受影响租户、关键交易路径、收入窗口、地域、客户等级。它回答“这件事重要到什么程度”。

组织上下文：值班表、审批规则、服务 owner、运行手册、事故等级、合规边界。它回答“谁能决定，机器能做到哪一步”。

自治系统真正困难的地方，是把这四类上下文放到同一个判断链里。例如，CPU 高并不总是事故；如果它发生在促销流量高峰、错误率稳定、延迟仍在 SLO 内，自动扩容可能合理。如果它发生在刚发布后、错误率同步上升、只影响新版本 Pod，回滚比扩容更像正确动作。

可以这样实践：把上下文做成可查询的事件包

下面是一个最小化示例：用 Kubernetes 事件、最近发布版本和 Prometheus 指标拼出一个“事故上下文包”。它不会替你自动修复，但能给自治系统或值班工程师提供同一份输入。

运行前需要：

  • 已配置 kubectl 当前集群上下文
  • Prometheus 可通过 PROM_URL 访问
  • Deployment 使用 app 标签
  • 本机安装 jq
#!/usr/bin/env bash
set -euo pipefail

NAMESPACE="${NAMESPACE:-default}"
APP="${APP:-checkout}"
PROM_URL="${PROM_URL:-http://localhost:9090}"
SINCE="${SINCE:-30m}"

echo "== service context =="
kubectl -n "$NAMESPACE" get deploy -l app="$APP" -o json | jq '{
  namespace: .items[0].metadata.namespace,
  deployment: .items[0].metadata.name,
  replicas: .items[0].status.replicas,
  readyReplicas: .items[0].status.readyReplicas,
  image: .items[0].spec.template.spec.containers[0].image,
  revision: .items[0].metadata.annotations["deployment.kubernetes.io/revision"]
}'

echo "== recent kubernetes events =="
kubectl -n "$NAMESPACE" get events \
  --sort-by=.lastTimestamp \
  --field-selector type!=Normal \
  -o json | jq --arg app "$APP" '[.items[] | select(.involvedObject.name | test($app)) | {
    time: .lastTimestamp,
    reason: .reason,
    message: .message,
    object: .involvedObject.name
  }] | .[-10:]'

echo "== prometheus error rate =="
QUERY="sum(rate(http_requests_total{namespace=\"$NAMESPACE\",app=\"$APP\",status=~\"5..\"}[$SINCE]))"
curl -fsG "$PROM_URL/api/v1/query" --data-urlencode "query=$QUERY" | jq '.data.result'

echo "== prometheus p95 latency =="
LATENCY_QUERY="histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{namespace=\"$NAMESPACE\",app=\"$APP\"}[$SINCE])) by (le))"
curl -fsG "$PROM_URL/api/v1/query" --data-urlencode "query=$LATENCY_QUERY" | jq '.data.result'

可以保存为 incident-context.sh 后运行：

chmod +x incident-context.sh
NAMESPACE=payments APP=checkout PROM_URL=http://prometheus.monitoring:9090 ./incident-context.sh

这个脚本的价值不在“聪明”，而在把判断材料固定下来。后续可以把输出交给 LLM、规则引擎或 ChatOps 工作流，但输入必须可追溯、可复查、可复现。

给自治动作加护栏：先限制权限，再谈智能

如果自治系统能直接改生产环境，权限模型要比提示词更重要。一个可落地的做法是把动作分级：观察、建议、低风险执行、高风险执行。

下面是一个 Kubernetes RBAC 示例，只允许某个运维机器人读取常见排障资源，不允许删除 Pod、修改 Deployment 或扩缩容。它适合用于“上下文收集阶段”。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sre-context-reader
  namespace: ops
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sre-context-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "events", "endpoints"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["batch"]
    resources: ["jobs", "cronjobs"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sre-context-reader
subjects:
  - kind: ServiceAccount
    name: sre-context-reader
    namespace: ops
roleRef:
  kind: ClusterRole
  name: sre-context-reader
  apiGroup: rbac.authorization.k8s.io

应用：

kubectl apply -f sre-context-reader.yaml
kubectl auth can-i delete pods --as=system:serviceaccount:ops:sre-context-reader -n payments
kubectl auth can-i list events --as=system:serviceaccount:ops:sre-context-reader -n payments

预期结果是：删除 Pod 返回 no，读取事件返回 yes。这类边界能让团队先放心地引入“读上下文、给建议”的自治能力，再逐步开放更高风险动作。

从建议模式开始，而不是一上来全自动

自治运维的成熟路径更像 SRE 值班训练，而不是一次工具采购。

可以按这个清单推进：

  • 把告警、发布、指标、运行手册、owner 信息统一成可查询上下文。
  • 要求每次建议都输出证据链，而不只是给出结论。
  • 给动作分级：只读、生成建议、需要审批执行、自动执行。
  • 从低风险动作开始，例如收集诊断信息、创建事故频道、关联最近变更。
  • 对每次自治建议做事后评审：判断是否正确、缺了什么上下文、是否误导值班人。
  • 把“不能自动做什么”写清楚，例如数据删除、跨区域流量切换、客户级降级策略。

真正的分水岭不是模型参数，而是上下文工程。SRE 团队愿意信任的自治系统，必须像一个合格值班工程师：知道系统现在怎么了，知道刚刚改了什么，知道业务后果，也知道自己什么时候该停手。

# CNCF # Rust # 云原生

相关推荐