值班中最令人头疼、最机械的部分就是根因分析的第一小时。事实证明，这就是今天一支 AI 代理团队可以承担的工作。于是我们构建了一个，将其指向一个 Kubernetes 集群，看着它自己争论。
简要概述
- 几乎每起事故的第一小时都是苦差事：找出服务，检查最近的部署，阅读日志，形成假设，猜测自己的信心程度。这种流程每次都一样，通常发生在凌晨 2 点，通常还有重要的人在清醒。
- 我们构建了一个系统，警报会触发一组只读的 AI 代理，它们像 SRE 那样进行调查。随后，一个怀疑代理（其人格就是怀疑他人）会尝试推翻结论。信任来自于一致认同，而不是被宣布。
- 对于高置信度的代码缺陷，它会打开一个真实可合并的拉取请求，包含修复，并将整个故事发送到 Teams。只读、短暂、仅供参考，因此仍需人工合并。
- 这不是把聊天机器人简单地挂在运维手册上。它正是人们开始称之为 AI SRE 的东西，也是企业 AI 实际发展方向的预览。这些代理处理枯燥且昂贵的第一小时，让人类能够从有趣的部分开始。
没有人会放在幻灯片上的软件中最昂贵的一小时
某东西出故障。仪表盘变红。有人的晚上结束了。
而第一小时总是相同的流程：哪个服务，什么发生了变化，日志说什么，这是全新的问题，还是我们曾誓言修复的周二的旧问题。是回滚还是前进修复。
这一切都不聪明。这是一个疲惫的人在压力下反复执行的清单——同样的清单，同样的顺序，在每起事故中永远重复。而能够执行它的机器却闲置在那里，就像一个昂贵的纸体重量，附带月度订阅费。
那第一小时不是创造性工作，而是在压力下完成的机械工作。这是对‘把这交给计算机’这一说法的最佳描述。
RCA 是代理驱动的，而非聊天机器人驱动的
这就是大多数‘AI for ops’演示失败的地方。他们构建了一个聊天机器人。你问它哪里出错了。它会给你写出一个华丽且结构良好的段落。
它也经常自信满满、雄辩地编造整件事，因为它根本没有真正查看任何东西。
根因分析不是一个问题，而是一次调查。收集证据，关联部署，形成假设，自我质疑，得出结论。于是我们没有写一个巨大的提示然后祈祷。我们组建了一个团队。如果你想用行业正在统一的术语，那就是 AI SRE。它并不像人类 SRE 那样样样都做，而是大家最怕的那部分——第一小时。
四位专家各自使用只读工具独立调查。一个查看代码，一个查看最近的发布，一个查看基础设施，一个查看指标。综合者将它们汇总并裁决分歧。还有持怀疑态度的人，只得到结论，并被告知基本上，“去推翻它们。”
置信度并不是模型无论正确还是幻觉，都以同样愉快的能量说出“95% 确定”。置信度是赢得的。取决于有多少独立专家得出了相同的原因，以及持怀疑态度的人是否未能击破它。
我们实际上构建了什么
警报触发。调度器为每个事件启动一个临时的 Kubernetes Job，承载团队。它以只读方式进行调查，发布带有置信度评分的裁决，如果存在真正的代码修复，则打开拉取请求。
整个控制平面之所以微小且乏味，是刻意如此。没有框架，没有向量数据库，也没有我们太尴尬而不敢展示的十二服务图。调查者只能读取，物理上无法触碰任何东西。整个系统中唯一能写入的是修复代理，而它最坏也只能提出一个等待人类批准的更改。
观察它如何崩溃，以及它如何运作
我们在一个服务中植入了潜在的 bug 并将其打开。错误率上升，警报触发。
调度器启动一个代理 Job。这一步奇怪地令人满意。你会看到调查者出现，执行任务，然后消失，就像一个承包商在工作完成后真的离开。
几分钟后，出现了裁决。不是日志堆砌，而是诊断、置信度仪表和确切的修复方案。
代理人意见分歧的部分，以及这正是重点所在
这就是在那个短暂的 Job 中发生的事情。
在我们的这次事件中，团队出现了分歧。两个代理认为问题出在代码上，另外两个代理认为是配置更改导致的。没有人会就任何事情达成一致，事件就这样闲置着，好像一整天都没人管。而作为一个事件，它确实如此。
代码: 发现了确切的缺陷，一个在缺失记录时会崩溃的无保护查找。很有把握。
发布: 最近的一次发布翻转了一个设置。这就是点燃火焰的变更。
基础设施: Pod 完全健康。没有崩溃，没有重启，也没有内存压力。这不是我们的问题。
指标: 大约三分之一的请求失败，快速且具确定性，不是慢速超时。
怀疑者: 试图反驳这一点。未能成功。昨天相同的配置运行得非常健康。已得到确认。
单一模型会挑选一方，全力以赴地说出来，尽管语法无懈可击，但仍有四十%的时间是错误的。在这里，分歧就是信号。双方都是正确的。确实存在代码缺陷，而配置更改是触发它的原因。怀疑者无法推翻这一点，两位专家达成一致，因此裁决返回了高置信度。这是通过努力获得的，而不仅仅是感觉。
“直接修复”，这个让它真正有用的决定
机器从技术上讲是正确的。触发因素是一次配置更改。这是最令人恼火的那种“对”。
但事实上，就在眼前有一个真实且可修复的 bug。于是我们做出了决定。只要存在具体的修复方案，就提出它，不管我们给事故贴什么标签。诊断和修复是两个不同的问题，而我们一直让其中一方否决另一方。
于是它这么做了。它想出了最小的安全改动，写了说明，并提交了一个 pull request 供人工审查。这是一个真正的 PR，能够合并。我刷新了两次页面，以确保它不会被撤回。
不光鲜的细节，它们区分了演示和产品
我们栽了两次跟头。每次都像踩到耙子一样，给我们上了一课。
它不断刷屏频道。第一个版本带有观点并且会分享它们，每隔几分钟一次，持续不断地出现在频道里。罪魁祸首很隐蔽：一个不断喷出错误的服务实际上拥有一个完全健康的 pod，没有任何东西崩溃，它带着微笑返回失败，指标绿色，点赞。于是我们的“一切正常”信号不断触发，导致一切被重置，整个流水线不断循环执行。修复办法是只有在警报真正消除时才将事件视为已解决，而不是当 pod 看起来乐观时。一起事件，一条通知。
然后它把完整的故事、根本原因、推荐的修复方案和所提出的更改，整合到一张干净的卡片中，以便人们能在合适的场所进行讨论。
为什么这种形状适用于企业
像这样的 AI SRE 之所以不仅仅是个花哨的把戏，归根结底在于几个枯燥却承载重要作用的属性。
成本随事件数量而变化，而非服务数量。该 Job 仅在调查期间存在，调查结束后即消失。一万个健康的服务对您来说成本为零。
它默认是只读的。调查者无法更改任何内容。它唯一会产出的东西是一个人需要审批的建议。
而且它可以移植。用您云上已经运行的任何监控替换本地监控，大脑保持不变。触发器和证据会变化，但团队不变。
接下来是什么
有一个问题确实令人谦卑地困难。这是否与上次相同的事件，还是一个恰好看起来完全一样的全新问题？目前我们根据症状进行匹配，而两个完全不同的错误可能会触发完全相同的警报。
要确认这确实是同一个问题，需要诊断原因的指纹，而这只有在你进行调查后才会存在。因此，下一个版本是记忆。过去事件的记录，使得重复发生时能直接跳到‘见过这个，这就是有效的做法，欢迎使用’。之后，将一个原因与众多警报关联起来，并形成一个学习循环：被接受的修复会提升信心，被拒绝的修复会降低信心。
值班有趣的部分从来不是第一小时
它是之后的一切。判断。权衡。在 CEO 看着仪表盘时，‘我们是回滚还是前进修复’的问题。
所以把艰苦的工作交给机器。证据收集、部署关联、以及一个你可以真正信任的置信度的假设初稿。把判断留给自己。那一直都是好的部分。
如果你今晚在值班，这里是我的问题。当寻呼机尖叫时，你实际上希望代理递交给你什么？是证据、假设，还是待审查的修复？请在评论中告诉我。特别是如果答案是‘另一份工作’。
