Traversal AI SRE：破解Claude Hole困局，实现运维自动化根因分析

随着AI编码工具的爆发式增长，软件运维正面临前所未有的新挑战。SemiAnalysis的报告显示，Claude Code每日贡献的代码提交已占据公开GitHub的约4%，其增长曲线呈病毒式上升，从研究预览发布到通用可用版本发布，日提交量实现了42，896倍的惊人增长。然而，AI生成的代码逻辑复杂且往往超出人类直觉理解的范围，这导致了一种被称为 “Claude Hole” 的现象。

这种现象指的是，工程师在使用AI助手（如Claude）排查或开发其不理解的代码时，可能会偏离正确的解决方案轨道，甚至提交完全无关的错误修改。一个来自Reddit的真实案例描述了这种困境：一位工程师在排查一个简单的CNPG模板配置错误（AWS账户号未正确设置）时，最终提交的PR却试图修改整个组织的所有服务账户的OIDC配置，令SRE团队困惑不已。

与此同时，传统可观测性工具的局限性日益凸显。尽管工具如Datadog、Splunk能够展示海量指标和日志——例如在Elasticsearch界面中，单日就能轻松达到千万级别的日志命中量——但它们通常止步于“展示现象”，将根因定位（RCA）这一高度手动且痛苦的工作留给了工程师。

现状是痛苦的：当事故发生时，工程师们陷入“信息海洋”（Sea of info），需要在Sentr y、Splunk、Elastic、Datadog等众多工具的仪表盘中反复切换，进行“数据挖掘”（Dashboard dumpster-diving）。即使找到一个“有希望的线索”（A promising lead??），也需要耗费大量时间“紧盯着代码/变更日志”，最终可能导向一次“PR与变更回滚”。整个过程迭代令人沮丧，且往往需要拉入更多团队协作。

为什么需要AI Native的SRE解决方案？

传统SRE陷入了“工具越多，负担越重”的困境。IDC分析指出，开发者如今仅有约16%的时间用于编写代码，而全球2000强企业每年仍因停机损失约4000亿美元。问题的核心在于，传统工具实现了“数据扩展”，但未能实现“理解能力扩展”。

如果说上一代软件是Copilot思路，主要辅助人类处理数据，那么新一代的Agentic SRE则代表了机器自主推理的思路。这正是人工智能 Agent在运维领域的深度应用。它们的目标是像人类专家一样，自动关联代码、基础设施和遥测数据，生成事故叙事并尝试修复。随着AI Coding的普及，新的运维基础设施玩家必然出现。

Traversal：定位为自主AI SRE Agent

Traversal正是一家致力于解决此问题的初创公司。它将自己定位为一个能够处理高风险事件的AI SRE Agent，其设计初衷是作为一个单一的管理平面，遍历来自不同来源的PB级MELT数据，串联起原本需要跨团队、跨工具反复沟通数小时才能厘清的信息。其目标是端到端变革软件可靠性工程。

核心能力环：

1. 预防措施：以新告警和代码变更的形式部署预防措施。
2. 告警：直接从异常的遥测数据中创建、聚类和升级相关告警。
3. 根因分析：自主调查PB级遥测数据，找到“确凿证据”日志、指标或PR。
4. 修复：通过静态分析代码库和配置文件，建议并部署修复。
5. 事后分析：总结和梳理事件时间线，明确影响和范围。

工作原理：融合因果推理与智能体协作

Traversal认为，要真正实现生产事件样本外的自主排障，必须结合最好的统计工具和语义工具，并由一种新颖的智能体控制流进行协调。其核心技术支柱是：因果机器学习 + 推理模型 + 智能体集群。

1. 离线构建与在线响应
Traversal的工作流分为离线和在线阶段。

• 离线阶段（5-10小时）：系统会浏览客户代码库和现有可观测性系统，构建一个动态、语义丰富的系统依赖图谱。它利用LLM理解非结构化日志的语义关联，应用统计方法识别时间序列中的因果关系，并通过自训练机制优先识别对RCA最有价值的路径。
• 在线阶段：当事件触发时，Traversal的Agent会结合实时数据与关系图进行判断和操作。用户可以通过Slack创建事件频道，Traversal会自动加入并主动发起调查；也可以直接@Traversal提问或提交事件描述。

一个典型的交互示例如下：在Slack频道 #inci-2422 中，用户Olivier Gabison提问：“为什么服务账户用户无法登录？”。几分钟后，Traversal-DEV应用回复：“调查完成，Traversal识别出3个候选问题”，并逐一列出了问题描述、相关日志和告警链接。

2. “有目的的跳跃”式分析
Traversal并非一次性分析所有数据，而是模拟人类排障的思维方式进行“有目的的跳跃”。例如，它可能先检查负载均衡器，如果正常，再深入到应用层或下游服务。各类Agent可以调用现有工具（如查询Prometheus、检索Splunk日志、检查GitHub PR）来收集和验证证据，持续验证或推翻假设。

3. 深度技术整合：因果ML与数字孪生
与依赖统计相关性的传统工具不同，Traversal构建了基于因果图的底层架构。它通过与Kubernetes、Terraform等云基础设施深度集成，实时绘制服务间依赖图，从而通过逻辑链精准追踪故障传播路径。

其团队背景（MIT、Berkeley教授）为因果机器学习提供了坚实支撑，利用了如“合成控制”和“潜变量模型”等算法。一篇相关的经济学论文《A Causal Inference Framework for Data Rich Environments》探讨了在拥有大量单元和测量的“数据丰富”环境中进行反事实估计的模型，这与运维排障的场景高度契合。

此外，Traversal引入了数字孪生技术，构建与生产环境同步的虚拟副本。这使得系统能在采取实际行动前，进行“主动试错”式的多路径仿真模拟。例如，面对数据库性能问题，它会并行模拟“增加只读副本”、“优化查询语句”、“调整连接池”等多种方案，并使用强化学习模型对结果评分，只有最优解才会被考虑应用于生产。对于高风险操作，Traversal会采用影子测试或金丝雀发布等安全机制。

商业落地与客户验证

Traversal采用混合式、以结果为核心的定价模式，在覆盖系统规模成本的基础上，根据实际创造的运维价值（如自动修复的事故数、避免的停机时间）收费。这区别于传统工具按数据量计费的模式。

其实践效果已在复杂环境中得到验证。系统设计可处理极端数据规模，例如：

• 某公共保险公司：2万亿条日志，1万亿条追踪，7万次变更。
• 某公共金融公司：1万亿条日志，1000亿条指标，2000万次事件。
• 某公共票务公司：100亿条追踪，1000万条指标，600万次事件。

它能在5分钟内从事件触发定位到根因，并兼容Datadog、Dynatrace、OpenSearch、Grafana、Splunk、ServiceNow、GitHub、Amazon CloudWatch等主流工具。

来自头部客户的反馈数据证实了其价值：

客户	关键维度	详细指标与反馈
PepsiCo	MTTR	降低90%，从3.75小时缩短至10-15分钟
	准确率	在仅接入4-5个应用下，根因分析成功率达65%-70%；人工验证准确率70%-80%
Wayfair	事故减少	部署后，重大可扩展性相关停机事故减少两位数百分比
	NPS评分	专家给出8-9分（满分10分）
Zscaler	效率提升	事件解决效率提升30%-40%
	生产力	SRE团队整体生产力提升70%-75%
Shell	AI能力评分	有专家给出9.95/10的极高评价

在合同规模上，Traversal已获得可观的年度合同价值，例如PepsiCo的试点合同超过$100万，未来潜力可达$200-$300万+；Shell高管认为若全球部署，3-5年内规模可达$500-$700万。

部署进度：

• 全面生产：DigitalOcean（MTTR缩短38%，事故覆盖率82%）、Wayfair（成功预测Redis过载）。
• 战略试点：Zscaler、Adobe。
• 客户流失案例：Nike因Traversal无法满足其气隙环境要求及对内部文档的访问限制，转而选择了Resolve。这凸显了深度集成带来的合规与隐私挑战，是此类工具扩张时需面对的主要阻力。

团队与竞争格局

Traversal的创始团队由MIT、伯克利的教授及来自Citadel Securities、WorldQuant的量化交易员组成。这种独特的背景使他们没有陷入传统的日志分析路径，而是从第一性原理出发，将运维/DevOps/SRE的核心重新定义为“理解根因并指导行动”，而非仅仅是“观测”。

在市场竞争中，Traversal面临多方挑战：

1. 传统可观测性巨头：如Datadog Bits AI，优势在于原生数据集成和较低成本，但受限于其平台边界，难以进行跨异构数据源的深度关联和复杂事故的根因分析。
2. AI SRE专业工具：
   • Resolve：最直接竞争对手。Traversal在自动化修复和深度分析上占优，但Resolve在混合架构和合规性上更适应大型企业。
   • Flip：在自然语言交互和Copilot体验上更强，但技术壁垒较浅，向上做深度分析难度大。
   • Deductive：常作为PagerDuty插件，在日志异常检测上专业，但平台完整性和因果性分析不及Traversal。

总结

Traversal代表了一种新的范式：即通过人工智能 Agent集群，结合因果推理与仿真模拟，将SRE从被动响应、手工排障的繁重劳动中解放出来，转向主动预测和自动化修复。尽管面临技术验证、巨头竞争和数据合规的挑战，但其在复杂环境中验证的有效性和清晰的商业价值，使其成为AI时代重构软件可靠性工程的重要候选者。随着AI生成代码占比的持续攀升，对于能够理解并维护这些代码的“AI医生”的需求将变得愈发迫切。

参考资料

[1] 当人读不懂 AI 代码，Traversal 如何做企业运维的 AI 医生？, 微信公众号：mp.weixin.qq.com/s/1pDTZWgRBYfXfXTDeXv1lA

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。