# 50人的Slack事故频道，AI四分钟内破案：Traversal重做SRE排障 > Training Data No. 53 中文精读 - 原标题：From DevOps ‘Heart Attacks’ to AI-Powered Diagnostics With Traversal’s AI Agents - 发布日期：2025-06-24 - 主持：Sonya Huang · Pat Grady · Konstantine Buhler 等 - 网页版：https://trainingdata.qiaomu.ai/ep/053-from-devops-heart-attacks-to-ai-powered-diagnostics-with-tra-7hBG5S.html - 精读字数：约 4892 字（阅读约 11 分钟） > 本文为 trainingdata.qiaomu.ai 基于原始访谈的 AI 改写中文精读，非官方翻译；引用请注明出处并链接网页版。 观测类软件是企业仅次于云支出的第二大技术开销。Datadog、Splunk、Dynatrace、Grafana，一家大企业往往同时供着五六个。 钱花了这么多，事故真发生时，画面是这样的：一个Slack事故频道，30到50个人挤在里面，最后靠一位在公司待了很多年的资深工程师凭直觉破案。没人说得清他是怎么找到答案的，反正找到了。 这是红杉资本播客Training Data在2025年6月一期抛出的场景。嘉宾是Traversal的两位创始人，Anish Agarwal和Raj Agrawal，机器学习博士出身，读博时研究的就是从数据里挖因果关系。产品做了一年多，四位联合创始人没有一个来自观测性行业，红杉是他们的投资方，合伙人Bogomil Balkansky和Sonya Huang亲自主持了这期节目。 他们做的事一句话能说清：让AI agent替人类做根因分析。目前的成绩，只要根因藏在数据里，Traversal能在2到4分钟内找到答案，准确率超过90%。人类工程师的角色，从破案变成了核对答案。 ## 每周心脏病发作两次的工作 Anish喜欢用医疗类比讲DevOps的处境。他把需求分了三层。 第一层是心脏病发作，五分钟内不解决人就没了，对应工程世界里的高严重度事故。第二层是慢性病，比如扭伤的脚踝，天天疼，让人没法规划三个月以后的事，对应的是源源不断的告警流，和每天检查部署安不安全。第三层是养生，优化睡眠和营养，追求长期的生活质量，对应的是规划未来五年的基础设施该长什么样。 他的总结是：**现在DevOps和SRE工程师过的生活，是每周心脏病发作两次，同时每天应付一种消耗性的慢性病。**第三层，基本没时间碰。 > 「如果Traversal把工作做好，高严重度事故和那种被一千个小伤口折磨的日常，应该由AI和AI agent接管。DevOps去做真正有创造性的部分：未来一年、五年的基础设施该长什么样。这会是一份让人满足得多的工作。」 五年后这个岗位还会存在吗？Anish的回答是会，但工作内容会完全不同。 ## 快时尚、支付系统和破案剧 主持人问了个绕不开的问题：Cursor、Windsurf这些自动编程工具火成这样，对系统可靠性意味着什么？ Anish的回答分两个世界。第一个世界是vibe coding，敲几句prompt，一个能玩的原型就立起来了。他把这比作快时尚：试穿，喜欢就穿，不喜欢就扔，换下一件。这个世界里可靠性根本不重要，因为衣服穿一次就丢，没有手艺可言。Bogomil接了一句，一边是路易威登的高级定制，一边是Shein。 第二个世界是关键系统：支付、金融机构、安全、基础设施、流媒体。麻烦在这里。企业都在用AI辅助写代码，代码甚至能通过本地单元测试，一切看起来完美。**但大规模系统的故障，发生在模块以你没想到的方式交互的时候。**代码是AI写的，人没读过，出了问题没有上下文，调试无从下手。 Anish的判断是，除非找到用AI做软件维护的办法，否则整个行业会被卡住。结局要么是停机太多，企业干脆禁掉AI编程工具，要么就是长出一批新工具专门管维护。Traversal押的是后者。 再看事故的一生。Anish说，跨公司看，剧本惊人地一致。客户发现平台不对劲，投诉到客服。客服确认是真实故障，像传话游戏一样逐级上报，穿过企业里五层工程组织，落到DevOps和SRE手里，判断这事够不够格立案。一旦立案，混乱开始：Slack事故频道建起来，30到50个人涌进来，互相隐晦甩锅。然后是那位10倍工程师出场，热修复，回滚，之后再慢慢找长期方案。 荒诞的地方在于，观测性公司已经赚了那么多钱，支出全行业第二，排障这一步还停留在破案剧。 观测性工具做的事，行话叫MELT数据，指标、事件、日志、链路追踪。采集，存储，再盖一层可视化，让人能盯着系统的各个部位。到可视化为止，就是它的天花板，排障这个复杂工作流至今纯手工。工具公司没做错什么，六个月前的技术只允许做到这里。 Agent的定义，Raj给得很干脆：LLM编排工具。在他们的场景里，工具是取日志、取指标、格式化数据、跑异常检测。难点在于把工具定义得足够丰富，让一次根因分析能表达成一串工具调用。数据大到单条trace都塞不进LLM的上下文窗口，只能一步步往里喂，慢慢构建出通向根因的路径。 那为什么没人早点做成？Anish指了指行业的碎片化。大企业同时用Datadog、Splunk、Dynatrace、Elastic、Grafana、ServiceNow，这些公司按存储数据量计费，A公司没有任何动力帮你从B公司的数据里挖洞察，彼此都在往对方地盘渗透，打的是消耗战。SRE排障要同时开五六个工具。**这种历史遗留的碎片化，给了Traversal这种不绑定数据存储层的AI公司一个窗口。** ## 卡死在0%的那一周 Traversal的起步很标准。找小公司，翻客户Slack里最近100次事故，用脑子总结这家公司排障的元工作流，塞进当时流行的ReAct框架。在小客户身上，好用。 然后他们第一次接触大型企业，几千个微服务的那种。把系统跑在历史事故上，准确率0%。 改prompt，不动。改别的，还是不动。顽固地钉在0%。 Anish记得很清楚，那天他和Raj喝了一杯内格罗尼。 酒醒之后做了两个决定。第一，任何特定公司的信息，都不硬编码进prompt。第二，任何人类的工作流，都不硬编码进agent的流程。复杂性总得有个去处，最后他们把它交给了计算：在推理阶段花token，让模型现场多想。后来整个行业都在验证这个判断，推理时计算确实是关键。 架构改对之后，准确率开始飙升。现在的数据是，只要答案在数据里，90%以上的情况能找到，耗时2到4分钟。Slack频道里的人类，时间从破案变成了验证。两个企业最关心的指标都在降：事故解决时长，事故频道的平均人数。 产品内部是两阶段。离线阶段，LLM去遍历客户的代码库和日志，理解语义关联，统计方法从时间序列的自然波动里提取因果痕迹，这是两位创始人读博时的本行，再用self-play优先探索最有希望的路径，最后构建出一张依赖地图。在线阶段，事故一来，agent拿着实时信息和这张地图，决定往哪跳。 早期他们试过模仿人类SRE的排障路径，看一条证据，决定下一条看什么。问题是人类靠系统知识跳步，agent没有这些知识。后来换成系统化搜索，参照Google那本SRE手册里的黄金信号，延迟、错误率，按健康监控的思路在巨大的空间里做顺序搜索。跳步少了，每一步都有据可依。 还有几个工程细节。只读权限，企业不想再多一个生成数据的工具。接入一家客户，5到10小时通读代码库和观测数据，大客户要一天。一次调查要发几千次网络调用。模型用客户已签合同的LLM，自带模型要在企业的安全审查里耗上一年，微调也在客户环境里做，比如客户指向Azure OpenAI实例，每次事故后对比已知根因，让差距一轮轮缩小。 怎么评估？Raj说金标准是真实现场事故。客户事故频率每周两三次，事故结束看postmortem，逐条对照。高频子任务，比如从观测数据里搜特定信息，用来做补充评估。 ## 三个反直觉 第一，Traversal在大企业比在A轮创业公司更能创造价值。一般SaaS的打法是从小客户做起再往上走，他们反着来。原因：大企业观测性成熟，数据都在，但团队碎片化，没有任何一个人握有完整上下文，所以才需要50个人的事故频道。**Agent创造价值的前提是，从触发到根因的推理步骤存在于数据里，只是多到一个人装不下。**数据本身缺失，agent就抓瞎，这时Traversal会反过来建议客户补instrumentation。 用自动驾驶分级打比方：根因在数据里的场景，自评L4。不敢说L5，因为能揪出问题PR、找到冒烟的日志，但最后一公里的修复还差着，尤其需要系统级大改的场景。根因不在数据里的场景，L2，找到关键症状，剩下的跳跃靠人。 第二，博士论文的巧合。Raj读博时跟博德研究所合作，研究CRISPR干预后基因调控网络的因果结构。把节点从基因换成微服务，问题几乎一模一样：一个PR改动如何在系统里层层渗透。纯属运气，钻进问题深处才发现读博攒的东西全用上了。 第三，创新的位置。Anish从学术界出来，本以为最前沿的研究在大学，结果发现最有趣的创新发生在小型研究型创业公司，他管现在叫AI的工业时代。企业的饥渴程度也超出预期，原本一两年才能谈成的单子，几个月就拿下。 > 「你必须不断做这种六个月的押注，判断AI六个月后会在哪里，然后刚好踩上那个浪。能连续押对几个六个月的公司，会赢下这一局。」 他们在去年9月押注推理模型会变强，把架构设计成让推理模型发光，现在兑现了。问他宁愿做AI团队还是观测性团队，他选AI团队，理由是AI团队更擅长做这种押注。 团队现在90%是工程师，有几个机器学习博士，更多是传统软件工程出身、对生成式AI上头的人。Raj说造agent的门槛已经降了，早年调LLM的梯度更新才需要博士。他们专门招基础设施工程师，解决的是怎么让agent干比人多的活。Anish补了一句统一标准：看头衔没用，看的是一个人做事够不够实验性，愿不愿意下小注、快速验证。快速迭代的心态比任何证书都重要。 ## 给AI读的日志，和五年后的银行App 未来的SRE长什么样？Anish给了两条。 一条是技能。AI系统自己也会坏，坏得很有创意，传统的SRE原则加上对AI的熟悉，两头都懂，才是未来吃香的DevOps工程师。 另一条是日志。**日志的读者，正在从人换成AI。**人类不爱在日志里塞长堆栈，因为人读不动，LLM的上下文比人长得多。Raj说要把尽量多的信息埋进message字段，那是AI判断往哪跳的原料。Cursor写日志的格式其实比人类好，人类会打错字，但它还在模仿传统日志的样子。真正的艺术是把日志和业务逻辑连起来，系统「正常」的定义取决于业务。这一步Cursor还做不到，除非它完全理解你的业务。 快问快答环节信息量也不小。未来12个月AI应用的爆发点，Anish押推理模型的应用，诊断类，医疗是典型。欣赏的创始人，Raj选了Demis Hassabis。五分钟读懂AI的文章，Anish推荐Rich Sutton的《The Bitter Lesson》，Sutton凭强化学习拿了2024年的诺贝尔物理学奖。欣赏的agent公司，Perplexity和Glean。个人在用的AI，两位创始人异口同声：只有ChatGPT，Raj说它已经是他最好的朋友。Bogomil说自己的最好的朋友是记笔记应用Granola，Anish表示自己也每天用。 最后一个问题，五年后我们会用vibe coding写银行、支付、医疗系统吗？Anish的回答是，某种程度上会。软件工程的评价标准，会从代码怎么写的，变成功能是否通过测试。通过测试的代码就是好代码，没人在乎里面写了什么。好处是效率，坏处他前面已经讲过：系统故障来自预料之外的交互，第三方服务不守SLA，而你根本不知道那个文件里写了什么。人类现在的优势是系统知识，看到事故能抄近路，因为错误信息是自己写的。AI生成的代码拿走了这个优势。 **所以你需要一个AI排障员。**这就是Traversal存在的理由。 ## 明天就能用的五件事 - 写日志换个思路：把关键上下文塞进message字段，写给未来的AI排障员看。人读不动的长度，恰好是LLM的舒适区。 - 盘一盘团队里AI生成代码的比例，重点查跨服务交互的地方。单元测试全绿不代表系统没病，故障藏在交互里。 - 每次事故复盘多问一句：根因当时在数据里吗？在，说明观测够用，是人的问题；不在，赶紧补instrumentation。 - 记两个基线指标：事故平均解决时长，事故频道平均人数。Traversal的客户盯的就是这两个，AI有没有用，数字说话。 - 花五分钟读一遍《The Bitter Lesson》，然后检查自己的系统里有多少东西是硬编码的，六个月后还成立吗。 观测性支出年年涨，排障还在靠福尔摩斯。这个缺口，AI agent公司打算用推理时计算填上。至于能不能把SRE从每周两次心脏病里捞出来，一年后看那两个指标就知道。