K8s AIOps Agent的人类闭环 Remediation 实践

完全自主修复的问题

每个平台团队最终都会问同一个问题：能不能让某个系统自动修复生产环境故障？说有这个冲动是可以理解的——凌晨 3 点的故障代价高昂，而且很多 Kubernetes 故障遵循可识别的模式。但完全自主修复有一个糟糕的失败模式：当 agent 犯错时，它错得很快，而且错得很有规模。

Kubernetes 的 AIOps agent 通过将问题一分为二来解决这个问题：让 agent 负责检测、关联和提案——这些是人类做得慢且不一致的部分——而对于任何有实际后果的操作，由人类作为最终决策者。这就是人机交互（Human-in-the-Loop，HITL）模式，在 Google Cloud 上它能清晰地映射到现有原语：GKE 作为运行时、Cloud Monitoring/Logging 作为信号源、IAM 和 Kubernetes RBAC 作为护栏、Vertex AI 或自托管模型作为推理层。

Agent 实际做什么

抛开术语，Kubernetes 的 AIOps agent 在一个循环中做四件事：

Watch — 消费来自集群及周围 GCP 服务的事件、指标和日志

Correlate — 将症状（例如 5xx 率升高）关联到可能的原因（一次糟糕的发布、节点资源不足、凭证过期）

Propose — 生成一个或多个候选修复方案，每个方案都带有置信度评分和影响范围估计

Act or Ask — 如果操作已被预先批准为低风险则直接执行，否则转交给人类决策

工程工作主要花在第 2 步和第 4 步。第 2 步（关联）要求 agent 在多个往往有噪声的信号源上进行推理，而不是对单个指标进行模式匹配。第 4 步（人工门控）需要一个足够好的评审界面，让疲惫的值班工程师能在几秒内做出正确决策，而不是几分钟。

Approval Gate，具体是怎样的

人机交互门控通常是一个基于聊天的审批流程，因为值班工程师在故障期间已经在 Slack 或 Google Chat 中了。一个典型的提案看起来像这样：

⚠️ Proposed action: Rollback deployment `checkout-service` to revision 47
Confidence: 0.82
Evidence:
  • Error rate: 0.3% → 4.1% (started 6 min after deploy)
  • Matches log signature from incident #INC-1042 (resolved by rollback)
  • Revision 48 changed payment-gateway timeout config
Blast radius: production, checkout traffic (~12k req/min)
Reversible: yes (redeploy revision 48 if needed)

[Approve] [Reject] [Modify] [View full trace]

审批此提案的工程师并非从零开始——他们是在确认或否决一个有充分依据的假设。这与从原始仪表盘诊断故障是根本不同的（也是更快的）认知任务。

审批和拒绝都应该写回系统：审批会强化类似未来事件的置信度模型，拒绝应该捕获原因代码，这样 agent 的模式库会改进而不是重复相同的错误提案。

autonomy line 画在哪里

不是每个操作都值得同样的对待。一个有用的三层划分：

Auto-execute (no approval needed)

Restarting a single crashing pod Clearing a stuck finalizer Scaling a Horizontal Pod Autoscaler within its already-configured bounds

Rolling back a deployment Scaling a node pool beyond a threshold Cordoning or draining nodes Any change touching a Secret, ConfigMap, or IAM binding

Escalate only, no execution capability

Regional failover decisions Anything touching billing-relevant infrastructure Actions the agent has no historical track record for

Auto-execute (no approval needed)

Restarting a single crashing pod Clearing a stuck finalizer Scaling a Horizontal Pod Autoscaler within its already-configured bounds

Rolling back a deployment Scaling a node pool beyond a threshold Cordoning or draining nodes Any change touching a Secret, ConfigMap, or IAM binding

Escalate only, no execution capability

Regional failover decisions Anything touching billing-relevant infrastructure Actions the agent has no historical track record for

这个分层应该是平台团队拥有和审查的配置，而不是 agent 自己决定的东西。agent 的工作是按策略对每个提案进行分类，而不是制定策略。

Kubernetes 原生护栏

因为 agent 运行在集群内，RBAC 做了大部分的执行工作：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: aiops-auto-execute
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
  - apiGroups: ["autoscaling"]
    resources: ["horizontalpodautoscalers"]
    verbs: ["get", "list"]

auto-execute ServiceAccount 正好拥有这些权限，而且仅此而已。需要审批的操作通过另一个具有更广泛权限的 ServiceAccount 运行——agent 只能在从审批系统收到签名审批令牌后才能调用它，而不是持有常设访问权限。这种分离意味着被攻陷或行为异常的 agent 进程无法单方面提升自己的权限。

衡量它是否有效

从第一天就开始追踪这些指标，而不是等到第一次故障之后：

Precision of auto-executed actions — 事故实际上解决了吗，还是只是看起来解决了？

Approval latency — 从提案到人类决策之间需要多长时间， off-hours 时是否飙升？

Rejection reasons — 对拒绝原因进行聚类可以揭示 agent 推理中的系统性差距

Mean time to remediation, before vs. after — 这是管理层真正关心的指标

如果自动执行的精度开始下降，这是一个信号，应该将某类操作拉回到需要审批的层级，而不是调高置信度阈值然后希望它变好。

一个合理的 adoption path：

部署 agent 为只读观察模式两到四周，以针对真实故障建立提案基线，零执行能力。将其提案与 on-call 团队实际所做的进行比较。频繁一致的地方是自动执行的可能候选。首先开启需要审批的层级，因为它本身有人工 backstop。一次一个地将特定的、经过充分验证的操作类型升级为自动执行，每次变更后密切关注精度。

这比从第一天就开启完全自主权要慢，但这是团队信任的 agent 和他们在第一次坏决策后就绕过去的 agent 之间的区别。

Kubernetes 中的 AIOps 最好作为人类判断的放大器，而不是替代品。技术上，在集群内部署、GCP 原生信号源、分层自主权以及快速、证据丰富的审批门控，这些模式构建起来很简单。更困难但更有价值的工作是组织层面的：用数据 deliberatly 决定团队的哪些操作是真正愿意移交的，并建立反馈循环，使这个边界能够随着时间负责任地移动。