AIOps工业化应用助Meta42%概率几分钟定位故障根因

引言

在企业数字化转型持续加速的浪潮下，IT系统的复杂度与规模不断攀升。传统运维模式面临巨大压力，如何提升效率、降低成本并保障系统稳定，已成为每个技术团队必须破解的核心课题。在此背景下，AIOps（智能运维）应运而生，并迅速成为行业焦点。

近年来，深度学习、自然语言处理等技术的突破，进一步加速了AIOps的实际落地。它不再局限于处理海量数据，而是开始具备更强大的智能决策支持能力。具体而言，AIOps的核心能力体现在以下几个方面：

• 智能监控与预警：实时追踪系统各项指标，利用机器学习模型快速识别异常并及时发出告警，帮助运维人员第一时间掌握问题动态。
• 自动化故障诊断与修复：通过对历史故障数据的深度学习，自动诊断故障原因，提供解决方案建议，甚至直接执行修复操作，大幅缩短故障解决时间。
• 容量规划与资源优化：预测未来资源需求，指导服务器、存储等资源的合理调配，避免资源浪费或不足，实现成本最优。
• 日志分析：运用自然语言处理技术，从海量日志中提取有价值信息，帮助发现潜在问题与运行规律。
• 智能决策支持：基于数据分析与模型预测，为运维决策提供科学依据和可操作的参考建议。

众多知名科技公司已在AIOps领域取得显著成果。当然，实施过程并非一帆风顺。数据质量、算法可靠性、与现有系统的集成等问题，仍是企业在实践中需要持续攻克的难点。

那么，在自动化故障诊断与解决这一关键环节，Meta具体是如何做的？下面我们重点来看。

Meta 在网站稳定性上的巨大挑战

每天，全球超过一半的互联网人口都在使用Meta旗下的产品。这听起来令人震撼，但同时也意味着，任何一次短暂的中断都可能带来巨大损失。确保系统尽可能少出问题，并在出现问题时以最快速度解决，是Meta技术团队的核心目标。

大量用户依赖Meta产品与亲友联系，更有数百万企业的生存直接依赖于Meta系统的稳定运行。事实上，一旦Meta网站发生大规模故障，不仅用户会炸锅，有时连警方和政府机构都会被惊动。

然而，要保持这一切稳定运行绝非易事。Meta的基础设施在过去十多年里持续扩张，系统之间存在着复杂的依赖关系。加上产品与用户量的快速增长，系统复杂性呈指数级上升。任何一次看似微小的变更，都可能引发开发者未曾预料到的连锁反应。

处理不良事件的工作流程

在深入讨论技术方案之前，先来梳理一下一个不良事件的生命周期：从事件发生，到团队发现，再到定位根本原因，最后快速缓解并恢复服务。在Meta，这个过程最初完全是手动的，而且相当紧张和混乱。可以说，每当出问题时，会有大量工程师涌入，试图帮忙。

Meta有一群“在线响应工程师”，他们通常是事件发生后第一批介入的人。这些人凭借经验，会迅速跳入问题线索，尝试找出最可能的故障路径。与此同时，还会有大量“新响应者”陆续加入。对于新加入的人来说，他们首先需要快速搞清楚“到底发生了什么”，然后才能提供有效帮助。

这里就出现了一个典型的冲突：新响应者需要从现有响应工程师那里获取信息，但后者正忙于排查问题，根本没有时间详细解释现状。如果此时频繁打断他们，实际上是在分散注意力，拖慢整个排查进度。

那么，该怎么办？让更多人参与进来是必要的，因为不可能一个人把所有事情都干完。但如何让新加入者快速“就绪”，同时又不干扰现有响应工程师？这本身就是一个棘手的问题。Meta尝试过不少方法，比如要求响应工程师定期提供更新摘要，但这些在高压状态下很难坚持。即便提供了，几分钟后情况可能又变了。

他们还尝试设立“日志保管者”角色，专门负责帮助新来者跟上进度，同时保护现有响应工程师免受打扰。但这种方法无法大规模推广——有些团队在事件期间本身就人手不足，而在大型事件中，可能会有数十个并行工作流同时进行。

用 AI 辅助事件上下文就绪过程

最终，Meta决定使用Llama 2来帮助新响应工程师完成“不良事件上下文就绪”。这让整个流程发生了显著变化。

现在，当新响应工程师进入事件处理流程后，他们不再需要逐一浏览海量的不同信息来源，而是直接面对一个实时生成的摘要，其中包含了所有相关信息——从当前的讨论到系统状态。此外，还有一个基于Llama 2的聊天助手。如果新响应工程师有任何疑问，可以直接问这个机器人，从而既保护了现有响应工程师的时间，也加速了新人的就绪过程。

具体来说，当新响应工程师打开事件管理工具时，首先会看到一个实时摘要，快速提供事件的“主干信息”。摘要会引用不同的信息来源，并标明出处，方便工程师验证或深入了解。一旦需要追问，他们可以直接和LLM助手对话。这个助手有权访问Meta内部的多个工件库，以及事件的实时讨论内容，能够回答任何后续问题，让新响应工程师能立刻上手参与调查。

当然，帮助新工程师快速就绪只是第一步。接下来更关键的问题是：如何迅速找到问题的根本原因？

AI 辅助的根因筛查与分析

通常，不良事件的原因可以归为三类：变更（配置或代码变更）、系统负载过高、以及设备物理故障。这里重点讨论“变更”这一类——这也是Meta面临的最大挑战之一。

Meta有一个独特的“单一大仓版本库”架构。这意味着，尽管旗下有各种不同的应用和功能，但大多数开发人员都在同一个大仓里进行变更。结果就是，可能同时发生数千次变更，而且这些变更之间还存在复杂的依赖关系。

对于响应工程师来说，第一步就是弄清楚发生了什么。他们需要分析事件类型和可能的原因，查看大量数据和日志，然后不断缩小范围。一旦确定是由代码或配置变更引起的，他们就需要将数据关联起来，进一步定位。即便找到了可疑的数百行代码，还得逐行解释变更的影响——这些工作极其耗时，但又必须完成。

那么，Meta是如何在成百上千次变更中，找出真正触发整个不良事件的那一次呢？

幸运的是，Meta有一个非常扎实的历史事件数据模型。工程师们积累了大量的数据，并从中提炼出趋势和模式，建立起变更与故障之间的相关性。有些规则很简单（比如受影响系统的所有者与变更文件的所有者是同一组人），有些则复杂得多。例如，通过分析一个在线服务依赖哪些文件——这本质上是一种运行时依赖图——就能将搜索空间从数万次变更锐减到几百次，实现了约100倍的压缩，且准确性没有明显下降。

但这还不够。在事件处理过程中，让工程师逐个浏览几百次变更仍然不现实。那么，如何进一步缩减呢？

研究发现，这些变更通常都与受影响的系统有关，或者更新了某些依赖项。关键是需要一种方法来推理：这次变更在多大可能性上改变了系统行为，并导致了当前的事件。Meta使用了一个70亿参数的Llama 2微调版本，它在内部数据和业务上下文上进行了专门训练，也针对“识别根本原因”这个用例做了优化。模型会接收所有相关的事件信息，以及从先前过滤步骤中得到的变更列表，然后输出最可能相关的五个左右变更。

不过，Llama 2的内容窗口有限，不可能一次性处理所有变更。于是Meta结合了“选举法排序选择”的方法：将变更分成多个组，每组20个左右。对每个组，模型会评估并选出最可能的五个变更。然后再将多个组的结果合并，重复这一过程，直到最终剩下一个包含大约五个或更少变更的候选列表。这些就是GenAI推荐给响应工程师去重点检查的变更。

AI 辅助的效果如何？

投入实际使用后，效果相当可观。在帮助新响应工程师快速就绪方面，用户对实时摘要和问答助手的反馈非常积极，认为能帮助他们极快地了解发生了什么。几乎有一半的事件处理都已经依赖这一功能，有效性高达86%。

在根本原因分析方面，数据更加亮眼：当不良事件被发现后的几分钟内，有42%的机会找到潜在的根本原因。这意味着，开发人员再也不用花费数小时去挖掘各种数据和代码，而是直接拿到初步方向，可以大大减轻压力、提升效率。

使用 Gen AI 的三原则

当然，任何新技术都有其局限性，GenAI也不例外——它有时会产生“幻觉”。如果在事件处理中提供了错误信息，那将是灾难性的：它可能会引导工程师把宝贵的时间花在错误的方向上。

因此，Meta确立了使用GenAI的三个核心原则：

• 第一，必须透明。AI必须清晰说明自己的信息来源和局限性，以赢得用户的信任。用户需要知道模型到底是从哪里获取信息的。
• 第二，必须易于理解。用户需要能跟随AI的逻辑和步骤。AI不能只给一个“答案”，而是要提供多种可能的选项和建议，让用户能自行判断和尝试。
• 第三，必须可执行。AI的建议要具备可操作性，能够直接指导下一步行动。即便无法直接定位，也要提供有价值的关键知识帮助工程师缩小范围。

AI有潜力真正改变Meta处理不良事件的方式——从事件发生到完全缓解，整个周期有望从小时级缩短到分钟级。而Meta还在持续探索，如何利用这些信息去主动预防未来可能发生的不良事件。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：AIOps工业化应用助Meta42%概率几分钟定位故障根因要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题