Meta为什么不把故障处理交给AI · 第 185 期

开篇

订阅者朋友，2026年的故障响应工具市场，充斥着这样的句子：“MTTR¹最多缩短70%。”“告警一响，几十秒内就能锁定根本原因。”“相当于雇了一位从不睡觉、永不失去上下文的资深工程师。”

然而，有一家公司已经用5年时间实际验证了这个承诺。那就是Meta。300多个团队在使用它，每天自动运行5万次故障调查。去年12月，它公开了这套系统的论文。

论文报告的平均成效是20%。而更奇怪的是，这套系统的核心并不是AI智能体。

先说结论。瓶颈不在模型。组织的知识还没有变成代码，这才是瓶颈。

🌙 每天运行5万次的剧本，全部由人写成

Meta公开的系统名叫DrP。它做的事情很简单：告警一响，就自动执行事先写好的调查流程，并把结果贴到告警页面上。凌晨3点被叫醒的on-call²工程师，不必再打开五个仪表盘、翻找日志，而是从阅读页面上已经生成好的分析结果开始调查。

Meta把这种“事先写好的调查流程”称为分析器（analyzer）。这正是今天故事的起点。分析器是人用Python或PHP直接写的代码，是一连串条件分支和数据查询组成的，可以说是故障调查的剧本。

来看看规模：分析器超过2,000个，使用团队超过300个，运营时间5年，每天自动分析5万次。换算成30天就是150万次，按秒计算，每1.7秒就有某处的一个剧本在运行。

这些剧本取代了三样东西：没人更新的Wiki文档、散落在各自笔记本电脑里的个人脚本，以及只存在于资深工程师脑海中的隐性知识³。照论文原话来说，他们的做法就是把散布在组织中的手动手册和隐性知识转移成代码。

调查越复杂，效果就越明显。论文以三种场景（简单的服务错误、容器故障、AI模型的特征问题）与手动方式做对比，结果on-call工程师需要走的步骤数减少了4倍到20倍。在最复杂的场景中，工程师需要做的事情被压缩成了唯一一件：在告警页面上读取结果。

⚠️ 论文第9章里埋着的一个小标题

到这里为止，这还是一个熟悉的自动化成功故事。可是翻到论文第9章“经验教训”，会出现这样一个小标题：

“不要过度依赖基于AI的系统进行诊断。”（Do not over-index on AI based systems for diagnosis）

一家运营着地球上数一数二规模AI基础设施的公司，在自己关于故障调查的论文里，把这个写成了教训。

先澄清一下误解：这不是说Meta不用AI。DrP的SDK里，异常检测、时间序列相关性分析、维度分析这类统计与机器学习库全都在里面。还有一个排名模型在运转，它会扫描成千上万个代码和配置变更事件，给出“这个很可能是元凶”的排序。

Meta不交给AI的，是判断的骨架。要按什么顺序看什么东西，在什么条件下走向哪里——这套决策树是人写的。AI只是被用作在其中填补某一格的工具。

理由论文里也写了。纯机器学习系统的局限在于：训练数据的质量、调查当下实际可访问数据的结构，以及每个团队难以自行调整工作流程。因此他们得出的结论是：以社区专业知识为基础的规则型建议，再叠加AI，这样的组合才是出路。

不过更让我在意的是它旁边的另一条教训。标题是“辅助还是完全自动化”。

Meta最初的目标是完全自动化。但方向转变了。理由有三个：第一，系统不断变化，剧本很快就会过时；第二，统计和机器学习会产生误报和漏报；第三，从文化上看，工程师和on-call人员并不总是信任完全自动化的系统。

前两个是技术问题。第三个不是。运转了5年、覆盖300个团队、每天5万次之后，Meta遇到的墙壁不是准确度，而是信任。

论文里的自设调查支持这一点。对于“DrP多久能帮你缩短一次MTTR？”这个问题，回答“总是”的人只有5.9%。回答最多的选项是“偶尔”（47.1%）。论文把这总结为“80%以上的人报告了改善”，这话没错，但回答的重心显然偏向“偶尔”一侧。顺带一提，反推百分比可知受访者规模大约是17人。作为一个供300个团队使用的系统的调查，样本量非常小，这个数字只能作为参考。

📉 20%和80%之间藏着什么

现在该看数字了，但在此之前有件事需要先厘清。

Meta的工程博客是这样写成效的：“MTTR缩短了20%~80%。”读起来像是一个区间，很容易让人以为大概是40%~50%左右，然后就翻过去了。

但论文摘要写的不一样。**平均20%。只有部分团队达到80%以上。**同样的数字，含义却完全不同。

打开论文第7章就能看到原因。

分析器少于5个 → 10%~15%
10个以上 → 50%~80%
全公司平均 → 20%

也就是说，80%不是系统性能，而是投入量的函数。自己团队把多少调查流程转移成了代码，决定了成效的高低。

论文7.2.4节的团队对比表，让这一点更加清晰。

1队：分析器136个，改善率82%
2队：92个，75%
3队：66个，84%
4队：48个，69%
5队：39个，58%
6队：29个，73%
7队：23个，56%
8队：12个，7%

请看最后一行。8队做了12个分析器，超过了论文自己设定的“10个以上”标准，但改善率只有7%。论文的主张，在论文自己的表格里被反证了。真正的悬崖，就藏在12个和23个之间的某处。

这里我自己算了一笔账。把2,000个分析器分给300个团队，平均每队6~7个。而论文自己说，少于5个的团队改善率是10%~15%。这意味着什么？**在Meta内部，处于中位数的团队，仍处在低收益区间。**全公司平均止步于20%的原因，就在这里。

时间成本也不容小觑。论文指出，简单的分析器一天就能做出来，但要把一个团队的调查工作流完整地承载进去，需要几个月。这不是买工具所需的时间，而是转移知识所需的时间。

最后再说说MTTR的绝对值。1队从771小时降到了139小时，也就是从32天变成了5.8天。这不是服务停机的时间，而是从检测到解决、并经过事后复盘的整个周期。如果觉得“MTTR缩短20%”看起来不算多，那就要连同基线到底有多大一起看。

补充一点，这张表里7队那一行，如果按前后数值重新计算得出的是36%，但论文里写的是56.1%。其余七行都精确到小数点都对得上，因此这一处很可能是笔误。不过这也说明了一个道理：在原样照搬别人的表格之前，值得先按一下计算器。

🔁 那么，为什么现在要谈“AI原生”

Meta博客的最后一段是这样收尾的：未来将把DrP进化为AI原生平台。

这不是很奇怪吗？前一句还写着“不要过度依赖AI”，紧接着下一段就说要走向AI原生。

这不是矛盾，而是顺序。

让我们重新看一遍Meta过去5年实际做的事。散落在Wiki文档、个人脚本和资深工程师记忆中的调查知识，被这样改造了：

变成有类型定义的代码（调查流程明确表达为分支和条件）
变成结构化的输出（结果以机器可读的格式呈现）
变成留有执行记录的数据（保留过去30天的调查输入输出）

尤其是第三点是决定性的。每次修改分析器时，Meta都会用过去的调查记录重新跑一遍进行验证，建立了一套回测⁴体系。它最初的目的是抓bug。但结果是，故障调查过程本身变成了带有标准答案的数据集。

在这里我想把问题反过来问：AI智能体要调查故障，需要什么？

第一，手。需要能访问数据的工具。第二，流程。需要一张关于看什么、按什么顺序看的地图。第三，标准答案。需要一份关于过去哪些判断是正确的记录。DrP用5年时间做出来的，正是这三样东西。

论文里还有一条教训，标题是“数据就是一切”。观测数据的质量，以及服务依赖关系、数据血缘这类结构化元数据——没有这些，相关性分析本身就无法进行。再好的模型，也没有可以附着的地方。

于是，今天题目的答案就变成了这样：Meta不是因为不信任AI才不把工作交给它，**而是顺序还没到。**如今它判断顺序已经到了。

要让AI替人工作，那件工作首先得变成代码。无论模型变得多好，只要组织的知识还留在Wiki文档和某个人的记忆里，AI就没有地方可以附着。

🇰🇷 那我们又处在什么位置

在今年6月24日于首尔举行的一场会议上，三星电子MX事业部云计算团队公开了自己的路线图。这是一个负责三星支付、Bixby、Galaxy Store等50多项面向客户服务稳定性的中央SRE⁵组织。

他们提出的成熟度阶段分为四个：事后应对、自动应对、预测运营、自主运营。他们自我诊断的当前位置是第一阶段。自主运营的目标时间点是2028年。国内顶级SRE组织的自我评估尚且如此，其他组织所处的位置也就可以想见了。

值得注意的是Yu Hyeon-seong（音译）组长在发言结尾说的一句话：即便自动化范围扩大，最终的责任和判断仍属于人。这与Meta论文中“辅助还是完全自动化”得出的结论完全一致。

在同一场活动上，KT Palantir事业本部长Byeon U-cheol（音译）说得更直接。他指出，由于经营层的急躁，根本问题没有被触碰，AI就先被叠加上去了，因此没有出成效。他指出的解决办法，是把数据整理成AI可以读取的结构。这与Meta论文中“数据就是一切”是同一句话。

国内也确实有正在运转的案例。Yanolja在今年4月公开，6个团队共14人用6周时间做出了6个运营智能体。其中的故障响应智能体，把从故障发生到事后报告所需的2周时间缩短到了24小时。不过拆解结构会发现，这里的智能体同样是建立在检索公司内部知识库和文档这一基础之上运作的。顺序是一样的。

Oswarld视角

我重新数了一遍论文第9章的六条教训。其中关于模型性能的，**一行都没有。**全都是关于采用的。

让社区自己去做。到用户所在的地方去。植入他们已经在用的工作流程里。特别是这句话让我印象深刻：对大多数软件工程师来说，开发分析器并不是本职工作。所以Meta把SDK打磨到一天就能做出一个，并让结果可以直接在代码编辑器里看到。

在做了20多年GTM战略的过程中，我反复看到一个模式：组织在评估一款新工具时，抛出的第一个问题总是“它有多准确”。但真正决定采用率的，几乎总是“它有多麻烦”。**如果为了用一款准确率95%的工具，还得多开三个窗口，那这款工具就不会被使用。如果准确率只有70%，但结果就显示在已经打开的那个屏幕上，那它就会被使用。**Meta把结果推送进告警页面，这不是技术选择，而是GTM选择。

所以我认为，现在很多组织把问题问错了方向。不该问“该引入哪种AI智能体”，而应该先问：**我们团队每次重复的判断流程中，有多少个已经变成了代码？**如果这个数字接近于零，无论买来什么模型，都没有地方可以附着。

结语

Meta用5年时间、每天运行5万次的故障调查系统，其核心不是AI智能体，而是2,000个由人手写的剧本。**决定成效的也不是模型，而是写了多少个剧本。**Meta如今能够谈论“AI原生”，也正是因为它用5年时间把隐性知识转化成了机器可读的形式。

如果想再深入了解，只需翻开论文第9章“Lessons Learned”。短短三页，浓缩了5年的试错。

请回想一下订阅者朋友团队里，每次都按同样顺序重复的一项判断流程。如果它还只存在于Wiki或某个人的脑海里，为什么它至今没有变成代码？是因为没有时间，还是因为每个人的流程都不一样？欢迎在评论区分享你遇到的最大障碍，我会把它纳入下一期的素材。

💬 欢迎在评论区分享你对上述问题的经验。我会在下一期加以反映。 📨 如果身边有正在为运营自动化或AI引入而烦恼的同事，请把这篇文章转发给他们。

我每周二、四、日交替阅读科技、经济与人文，并写下在它们交汇处发现的东西。也有像今天这样，把一篇论文钻研到底的日子。

参考资料与延伸阅读

核心来源

Shubham Somani 等14人，“DrP: Meta’s Efficient Investigations Platform at Scale”，arXiv:2512.04250 [cs.SE]，2025年12月。：第7.2节（MTTR评估）和第9节（经验教训）是本文的核心依据。如果时间不够，只读第9节的三页也足够了。
Meta Engineering，“DrP: Meta’s Root Cause Analysis Platform at Scale”，2025年12月19日。：这是论文的官方摘要版，不过把MTTR压缩表述为“20%~80%”，与原文的语气有出入。如果要引用数字，建议参考论文原文。

背景知识

Rootly，“What Is an AI SRE Agent? How AI Is Changing Incident Response in 2026”，2026年4月。：可以看到本文开篇里提到的那些市场承诺，是以怎样的语气在售卖的。这是厂商资料，需要有所保留地看待，不过它把自主性分为四个阶段的框架，值得与三星的四阶段成熟度模型放在一起对照。
Google，“Being On-Call”，Site Reliability Engineering。：关于on-call这一制度为何产生、又为何消耗人的原始文献。Meta的论文也在脚注中引用了这份文档。
ZDNet Korea，“读不懂数据的AI毫无用处，KT与三星的解法是什么”，2026年6月24日。：三星电子SRE组织的四阶段路线图，以及KT对数据结构的诊断，都在同一篇文章里呈现。是把握国内坐标最有用的一篇。
Edaily，“三星，用AI解决云故障，2028年目标自主运营”，2026年6月。：三星电子发布的具体数值目标（恢复时间缩短90%，10分钟内检测率99%等）整理得更详细。
AWS技术博客，“Yanolja利用Strands SDK与Bedrock AgentCore构建AIOps Agent的案例”，2026年4月。：可以按6周冲刺的单位，细看国内实际运转的运营智能体的结构。

📝 术语说明

作者安光涉是世宗大学经营学教授，也是 OBF（Oswarld Boutique Consulting Firm）首席顾问。他在大学教授经营数据管理、商业分析等统计与数据分析课程，同时在产业现场负责 GTM 与人工智能战略咨询，设计技术与商业的连接方式。他曾发表关于 AI 对话系统记忆架构（HEMA）的学术论文，并运营每日策展全球 AI 论文的 Daily Arxiv 项目。他毕业于高丽大学技术经营专业研究生院与 KMBA，著有《把思考交出去的人：Homo Brainless》。

注释

MTTR（Mean Time To Resolution）：从发现故障到解决故障所经过的平均时间。Meta的论文只针对经过事后复盘的事件进行计算，因此需要把它理解为不是服务停机的时间，而是包含原因排查和处置在内的整个周期。 ↩
On-call：为了在故障发生时立即响应而设立的轮值制度。凌晨3点告警响起时必须起床的那个人，就是当天的on-call。 ↩
隐性知识（Tribal Knowledge）：没有留存在文档中、而是在组织内通过人传递的知识。比如“那台服务器出这种问题时要先看那里”这类内容。 ↩
回测（Backtesting）：把过去的数据重新跑一遍，验证修改后的代码是否得出与以前相同结果的方法。Meta保留了最近30天的调查记录，每次修改分析器时都会自动运行一次。 ↩
SRE（Site Reliability Engineering）：以软件工程方式管理服务稳定性的职务和组织。2003年始于Google，on-call和故障响应是其核心工作之一。 ↩