Rootly AI实验室负责人谈AI SRE在故障处理中的能与不能

Sylvain Kalache 在 Rootly 负责 AI 实验室，他带 Matty 梳理了 AI SRE 在事故期间能做和不能做的事。他们聊到为什么把每一起小事故都交给机器人处理，会侵蚀响应者在面对大事故时所需的实战能力，以及该衡量哪些指标，才能让值班的人不至于被耗尽。

Sylvain Kalache 在 Rootly 负责 AI 实验室，他首先解释了业界已经约定俗成称之为 AI SRE 的工具背后有两类记忆。长期记忆是一个知识图谱，由你的代码库、过往事故报告、知识库和 Slack 频道构建而成，相当于老手在系统出问题时那种“我大概知道问题在哪”的直觉的机器版本。实时记忆则是刚刚发生的一切：最近的部署、遥测数据、链路追踪。工具基于这两类记忆形成假设并开始排查。Sylvain 的观点是，那个不起眼的部分——收集数据——本身已经是“巨大的时间节省”，因为工具可以同时追查十个假设，并把发现汇总到一个仪表盘上。

Matty 等这个等了很久。多年前他和 Rundeck 创始人 Damon Edwards 聊过，让机器人在响应者还在起床的时候跑同样的初步检查。那从来不需要 AI。AI 增加的是猜测能力：不需要告诉它针对这种特定类型的事故该拉哪些日志。

对于纯体力活级别的事故，Sylvain 说这些工具在 sev 3 和 sev 2 上准确率接近百分之百。再往上就变得“参差不齐”。他最好的例子来自柏林的一场 AI 与可靠性会议，Anthropic 的一位可靠性工程师描述了一次故障：一个携带 22 张图片的请求导致服务崩溃。Claude 没有止步于这个 bug。它注意到同一个请求来自 4,000 个账户，判断这是一次攻击而不只是故障，并建议联系安全团队处理滥用问题。Sylvain 指出，一个只修补 bug 的人很可能根本不会往这个方向看。

同一场演讲里还有相反的情况：模型被一个红鲱鱼带偏，那是一个缓存命中率图表，讲述了一个非常有说服力的故事，结果和问题毫无关系。Matty 指出，人类也经常上这种当，这正是事故指挥官存在的一大原因。

Matty 承认说这话时自己有点发毛，但他还是抛出了这个问题。你对一个 LLM 响应者需要警惕的一切，正是一个优秀的事故指挥官已经在对人类响应者做的事：坐在那里问“这是我们现在恢复服务所需要做的吗？”所以只要配置得当，这个角色的哪一方来做都可能行得通。他觉得危险的是那种说“只要写好 agent 描述，它什么都能干”的人。

他还提到了 PagerDuty 时代这个论点的版本。那时还是机器学习而非 LLM，卖点是拿你所有的事故数据来训练，让它知道该怎么做。他和那里的一位同事不断遇到两个问题。组织没有足够的数据，而且错误答案的代价很重要：一个糟糕的 Netflix 推荐浪费你一集的时间，一个糟糕的餐厅推荐花掉你几百美元，而一个把实际上是 sev 1 的事件判断为可能不是 sev 1 的模型，有同样的问题。Sylvain 同意，并说在 Rootly 使用 AI SRE 的客户中，“人始终参与其中”。他没见过谁放手让它盲跑。

Sylvain 认为，更大的风险在于人身上会发生什么。如果工具接管了所有简单的事故，你就失去了响应者用来练手的小事故——用来理解他们的系统如何运作，用来建立当大事故来临、AI 无法解决时所需的那种直觉。他举了航空业的例子：1990 年代美国航空的飞行员创造了“洋红色之子”这个说法，得名于他们盯着的屏幕上的洋红色线条。自动驾驶往往恰恰在它处理不了的情况被接通，所以行业的解决办法是每年强制进行模拟机训练，演练飞行员可能永远遇不到的紧急情况。

Matty 从他关于“战斗、逃跑或僵住”的演讲中补充道：在平静时刻练习，才能让流程进入肌肉记忆，以备凌晨三点的版本。他引用 Rein Heinrichs 的话：“如果你不擅长处理事故，你有没有试过多来几次？”他还指出，更好的系统和更大的值班轮换意味着你可能几个月都收不到一次呼叫，然后醒来时忘了怎么登录工具。Game day 是显而易见的答案，而显而易见的问题一直在于，总得有人构建并注入一个逼真的故障。LLM 可以完成这部分。Rootly 已经通过 Rootly Academy 更进一步，它与 Uptime Labs 合作打造，由一个人扮演事故指挥官，指挥一组 LLM 角色扮演响应者。

Sylvain 的预测是，行业会把这件事推得太远，吃了亏，然后往回撤。事故的平均时长会变短，但他预计会出现持续数小时甚至数天的更大的重大事故，因为工程师已经和自己的系统脱节了。他花了五年时间经营一所软件工程学校，赌的是人们通过动手而非听讲来学习，那所学校的学员被 Facebook、LinkedIn、Meta、Google 和 Nvidia 录用。应用到事故上：“光看和动手做不是一回事。”他说，这有两个走向。要么模型变得足够好，丢失的知识不再重要，要么就是一次清算。“我对此没有答案。”

Matty 补充了两点。产品负责人是非常优秀的事故指挥官，部分原因是这种经历让他们关心可靠性，而当整个故事变成 Claude 一夜之间修好了它时，这种切身体验就消失了。而且，如果你的编码 agent 拿不到所发生事故的上下文，你就是在跳过你期望人类开发者从事后复盘中获得的同一个反馈回路——而在 LLM 出现之前，事后复盘就已经是只写不读了。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）