具体来说，AiOps 的主要功能和应用包括：

• 智能监控和预警：实时监测 IT 系统的各种指标和参数，利用机器学习算法快速准确地识别异常情况，并及时发出预警，帮助运维人员快速响应问题。

• 自动化故障诊断和解决：通过对大量历史故障数据的学习，能够自动诊断故障的原因，并提供相应的解决方案建议，甚至可以自动执行一些修复操作，减少故障解决时间。

• 容量规划和资源优化：预测系统的资源需求，以便合理规划和调整服务器、存储等资源，提高资源利用率，避免资源浪费或不足的情况。

• 日志分析：运用自然语言处理技术分析大量的日志数据，提取有价值的信息，帮助发现潜在问题和规律。

• 智能决策支持：基于数据分析和模型预测，为运维决策提供智能化的建议和参考，协助运维团队做出更科学的决策。

一些知名的科技公司和企业已经在积极探索和应用 AiOps，并取得了显著的成果。然而，AIOps 的实施也面临一些挑战，如数据质量和数据管理、算法的准确性和可靠性、与现有系统的集成等问题，需要企业在实践中不断解决和优化。

今天，我就谈谈 Meta 如何利用人工智能大语言生成模型在自动化故障诊断和解决方面的研究与应用。

Meta公司每天为全球超过一半的互联网人口提供服务，所以 Meta 总是想办法确保尽可能少的发生不良事件，而当它们真的发生时，也会尽可能快地解决它们。因为每秒钟的中断都可能意味着巨大损失。

大量的用户依赖Meta的产品与他们所爱的人联系，此外，Meta 还为数百万企业服务，他们的生活依赖于Meta的系统正常工作。事实上，当 Meta 网站出现问题时，不仅是Meta，甚至警方和政府机构也会被通知。

然而，持续保持网站能够正常运行并不容易。Meta 的基础设施在过去十多年里一直在扩张，随着 Meta 产品和其支持的用户数量的增长，系统之间存在许多依赖关系，系统复杂性很高，而且随时都可能发生大量的变化，因此很容易无意中做出开发者可能不知道的连锁反应。

在深入讨论之前，让我们先退一步，看看如何考虑一个不良事件的生命周期。它从不良事件发生开始，到团队发现，然后找出并尝试弄清楚根本原因是什么，需要解决的实际问题是什么，然后迅速缓解它并恢复服务。在Meta，这个过程原来实际上是手动的，它也非常紧张，坦率地说有点混乱。实际上会有工程师不断参与进来，提供帮助。

Meta 有一群“在线响应工程师（Existing Responders）”，他们通常在得到不良事件通知后就会直接参与进来，他们会尝试跳入问题线索之中，并根据自己的经验，查看最可能发生问题的路径。

同时，还有不断有很多工程师加入进来提供帮助，本文中称TA们为“新响应者”。对新响应者来说，他们需要快速弄清楚已经发生了什么，这样他们才能提供帮助。

因此，从响应工程师的角度来看，实际上更像是这样：首先，他们需要能被引导，去更快速地挖掘所有关于“发生了什么”的历史和聊天记录，以及什么已经被排除在外了；他们还需要撸起袖子，一起帮助确定根本原因。一旦找到了根本原因，可能需要多个人一起工作来实施不良事件缓解措施。这也会在他们之间产生一些有趣的紧张关系。

你会发现对于新加入的响应工程师来说，实际上他们不能马上就行动，他们在提供帮助之前，需要从现有的响应工程师那里获得一些信息。但从现有响应工程师的角度来看，他们很多时候已经在尝试调查一个或多个可能的原因，似乎并没有充分的时间来详细介绍实际现状。所以，如果此时打断他们，实际上是在分散他们的注意力。

那么，怎么办呢？让更多的响应工程师参与不良事件的处理也是至关重要的，需要尽可能多的人帮助解决故障，不可能自己快速做完所有事情。然而，这个新的响应工程师投入抢修的流程并不容易，也并不是一个新的问题。但没有什么是万能的，每件事都有权衡。

Meta 实际上尝试了多种方法，比如，要求响应工程师在不良事件期间定期提供更新摘要，这些摘要可以提供给新入者使用，以便更快地就位，而不必查看所有不同的信息来源。然而，在不良事件压力之下，“记得提供更新”可能有点困难。即使你记得有这么个事儿，也可能因为非常紧张，太专注于试图解决不良事件本身，以至于你实际上也不愿意中断下来，编写并分享这些摘要。即便你提供了一些摘要，几分钟后因为做了新的尝试，你学到了新的信息，事情可能就已经改变了。

Meta甚至尝试设定了一个新的角色，例如，一个人将被任命为日志保管者，他／她会帮助新来的响应工程师尽快就绪，同时，保护现有响应工程师免受任何后续问题或联系打断。然而，这种方法无法很好地推广。因为，有的团队可能在不良事件期间人手不足，即使他们不是人手不足，在大型不良事件中，你可能会同时有数十个并行工作流在进行。

那怎么办呢？ Meta 开始使用LLama2 来帮助后来的响应工程师完成不良事件上下文就绪，让他们能以最快的速度进入状态。这种不良事件上下文就绪流程与之前展示的流程有显著变化。

正如你现在看到的，一旦一个响应工程师进入了不良事件处理流程，他们不再需要浏览大量的不同信息来源，而是有一个实时生成的摘要，包含所有相关的信息，从正在进行的讨论到系统当前状态。同时，他们还有一个基于LIama2 的聊天助手，如果他们有任何问题，这个机器人可以回答他们所有的后续问题，从而既保护了现有响应工程师的时间，也加快新响应工程师的就绪进程。正如你所看到的，现有响应工程师和后来的响应工程师之间不必再直接联系。新的响应工程师从LIama2 的聊天助手那里获得即时响应，他们可以快速就绪，并加入到调查和响应炎量。下面，介绍一个Meta 实际上是怎么做的。

一旦一个新响应工程师打开不良事件管理工具，他们就会看到一个实时生成的摘要，它为他们提供了一个快速的概览，以抓住不良事件的主干信息。它包含不同的信息来源，它甚至引用了Meta用来构建摘要的不同信息来源，以便响应工程师实际上可以检查这些信息来源，以验证或甚至获取更多信息。一旦他们有一些需要追问的问题，他们可以利用LLM的助手。

因为这个助手有权访问MATA内的许多不同工件库，它还有权访问不良事件的正在进行的讨论，使其能够回答任何后续问题。这使响应工程师能够立即回答他们所有的问题，并立即帮助进行调查。

当然，帮助后来的响应工程师快速进入就绪状态只是一个环节。下一个问题是，如何迅速找到问题的根本原因并诊断实际问题。

通常不良事件的原因可以分成三类，它们是：

• 变更（配置变更或代码变更），

• 系统负载过高，

• 设备物理故障。

现在，主要讨论一下第一种类型，即：变更。

这在 Meta 真的很难，因为Meta系统的独特架构，Meta有一个叫做单一大仓版本库的东西。这意味着，尽管Meta支持各种不同类型的应用程序和功能，对大多数开发人员来说，他们实际上是在单一大仓中进行变更。这意味着可能有数千个变更同时发生。此外，还有许多依赖项，多个开发人员可能正在更改整个依赖项，因此多个变更同时发生。

对于响应工程师来说，首先很难弄清楚发生了什么。他们必须弄清楚这种特定不良事件的类型和可能的原因，他们必须查看各种数据和日志，然后尝试缩小范围。

如果一旦他们确定了是由代码或配置变更引起的，他们就马上需要尝试将他们看到的数据相关联，以便他们可以进一步缩小这个问题。一旦他们得到有可疑的数百行代码，就必须尝试解释不同的行，试图理解这些变更的影响，这些可能非常耗时和手工。然而，这些工作是必须的，否则，他们不能去缓解问题。

那么Meta如何着手实际确定触发整个不良事件的某次代码变更呢？

幸运的是，在 Meta 有一个非常坚实的实例数据模型，响应工程师一直在很好地收集跨历史不良事件的数据。能够分析历史不良事件，并已经演变成一套规则的趋势和模式，建立变更和给定故障之间的相关性。其中一些是非常简单的人类学划分，即：对于给定的受影响的系统，是同一组所有者实际上拥有正在变更的文件。而有些则更要复杂一些。

例如某一个在线服务，它受到此不良事件的影响，它依赖于哪些文件？此时，它基本上是一种运行时依赖图。通过这些手段，就能够显著减少搜索空间。范围从数万次变更可以减少到几百次的量级。这是一个100倍的减少，但在准确性方面没有显著变化。

现在还需要再现实一点，在不良事件期间，让响应工程师要浏览数百次变更是不可行的。那怎么办呢？

最后发现，这些变更有一个共同点是，大多数实际上与与此不良事件相关的系统或受到不良事件影响的系统有关，又或者可能更新了系统或更改了其中一些依赖项，但它们都以某种方式相关联。所以需要的是一种方法来推理，这个变更在哪种可能性上，如何改变系统的行为，并导致给定的不良事件。Meta 使用一个7亿参数的Llama 2，这是Lama 2的一个微调版本，它在内部数据和内部业务上下文上进行了微调。这个模型也针对识别不良事件根本原因的用例进行了微调。Meta将为这个模型提供所有相关的不良事件内容，以及从先前的STP中找到的变更，模型会提供最相关的五个左右的变更，这些变更可能是根本原因或触发此不良事件的原因。

LLama2 有一个有限的内容窗口，当一些变更可能非常大并且有几百次变更的话，如何处理呢？这就是Meta结合了选举法排序选择，即：将这些变理分成多个组，每组的大小为20。有些组可能少于20个变更，对于每个给定的页面，再将其传递给模型，连同不良事件的信息，问模型这组中最有可能的五个变更是什么。这最终给出了一组通常大约五个或更少的变更。现在已经从每个组中消除了 15个变更。然后，将每四组合并，回到20个为一组的大小。通过不断重复这个周期，直到最终得到最后的一个组，其中的变更可能只有5个。当然，最终的结果可能少于五个变更，这是 GenAI 给响应工程师的变更，以检查可能包括根本原因。

那么，投入使用后，效果如何呢？在帮助后来的响应工程师就绪方面，用户（也就是响应工程师）对实时摘要以及回答问题的反应非常积极，认为可以帮助他们快速弄清楚发生了什么。

几乎有一半的实例已经依赖于此，有效性达到了 86%。

在根本原因分析方面，当不良事件被发现后的几分钟内，有42%的机会找到潜在的根本原因。

这意味着，作为开发人员，不必花费数小时试图弄清楚挖掘各种数据代码等，你实际上已经有了这些信息，可以帮助你并减轻压力。

当然，在使用这种新技术时，AI 往往会有点幻觉。如果在不良事件期间，提供错误信息可能是灾难性的，这意味着 GenAI 正在占用人们宝贵的时间去寻找错误的原因，以至于他们实际上没有看他们真正需要做的事情。

因此，使用 GenAI 有三个原则。

第一,GenAI必须非常透明，以赢得用户的信任。必须非常清楚AI的限制，并帮助人们理解它从哪里获取信息。

第二，GenAI需要非常容易被理解，用户需要的是逻辑性。也就是让用户能够跟随AI的逻辑，以及它采取的步骤，以便让用户能够理解要注意什么，同时，避免提供单一建议，这样用户也可以自行决定尝试自己的方法。

第三，GenAI需要确保建议有可执行性，要提高 GenAI 的能力，如果无法达成可执行性，也要带来有效的关键知识。

AI有潜力真正改变 Meta的不良事件处理方式，它可以在不良事件处理的所有阶段提供帮助，从发生一直到被缓解。可以将整个周期从小时级缩短到分钟级。Meta 仍在探索用这些信息来主动预防未来不良事件发生的可能性。