人工智能可以遵循您的指示，但仍然无法像您一样调试问题。
译自 Why AI Can't Fix Your Production Issues，作者 Siddarth Jain。
生成式 AI 和大型语言模型 (LLM) 显著提高了各个行业和领域的生产力，从营销到工程。作为一名早期创始人，我个人发现它们在日常工作流程中非常有用，从创建管理文档模板到协助代码语法。
关于 AI 如何取代工程师，已经有了很多讨论，包括一篇关于为什么 AI 无法取代工程团队的StackOverFlow 博客文章。在这篇博客中，我将阐述为什么我认为 AI 虽然是一个很棒的生产力增强工具，但无法为当今的轮班工程师和 SRE 调试生产问题。
LLM 的实际应用：
充当助手 的 AI 工具在整个生命周期中都非常有用。以下是我使用它们的几个例子：
- 代码生成/检测：
LLM 是获取函数或任务的样板代码的好方法。虽然我最终会重写大部分代码，但我确实喜欢不必从头开始，而是从某个点（比如 30%）开始的体验。
- Github CoPilot
- Terraform 生成器 — https://github.com/gofireflyio/aiac 这里有一篇最近的博客 关于用户使用 LLM 进行 Terraform 生成/更新的体验。
- 自然语言到命令
我发现 Warp 的自然语言到命令生成器非常有用，而不是使用 chatGPT 来查找新命令。但对于我第一次做的事情，或者如果我知道一个命令，我非常不愿意使用自然语言模式。它帮助我自然化并加速学习曲线，以学习语法/语言。
我的背景
我对机器学习的经验始于我甚至没有将我的工作称为机器学习的时候。作为一名 2015 年的年轻开发者，我花了一个夏天时间开发一个利用 OpenCV 对数百万份离线文档进行数字化和解析的应用程序。从那时起，我在各种角色中涉足了监督/无监督学习、约束优化问题、预测和 NLP。
在过去的几年里，我一直是 Doctor Droid 的联合创始人，这是一家专注于解决轮班工程师生活中挑战的公司。
工程师对生产事件监控中 AI/ML 的期望：
作为一名创始人，我向其他开发者推销不同的原型，以解决他们在“可观察性”生命周期中遇到的部分问题。在向用户推销时，我经常发现，每当提到以下任何用例时，工程师的兴奋程度都会格外高：
- 在事件发生之前预测/预报事件
- 异常检测，无需配置即可获得警报
- 使用 AI 自动调查事件
自然地，我构建了原型和工具，试图解决其中一个或多个用例。
在我深入探讨原型之前，我想分享一下我对调试的看法。
CAGE 框架用于调试和生产调查
这个框架的灵感来自于我在之前工作中的工程经验以及与 Doctor Droid 开发人员的互动。我意识到，调试通常归结为四件事：
- 上下文：
这指的是关于您的产品做什么、客户如何与之交互、基础设施如何映射到服务、功能等等的部落知识。您的客户投诉可能无法客观地转化为特定的基础设施组件。如果没有能够将问题/用例转化为正确的上下文，即使是团队中现有的开发人员也很难解决生产问题。
- 分析性思维
工程师被期望提出假设，并使用相关性和因果关系来验证/反驳这些假设。关联时间线和异常（通常通过肉眼观察发现）是需要工程师进行部分分析性思维的技能——无论是观察指标并评估它是否是异常，还是观察异常并思考其他可能受到影响的东西（使用他们的部落知识）。
- 目标定义：
工程团队的运营高度依赖于组织的业务承诺和需求。仅仅拥有分析性思维是不够的。去年，我们正在构建一个 分析平台 - 即使在部署时只有四个服务，我们也产生了 2000 多个指标，涵盖了我们的基础设施和应用程序（有关此应用程序的更多信息，请参见下一节）。
如果我们运用分析性思维来评估所有这些指标以进行警报，这对我们团队中的任何人都没有意义。因此，我们定义了 SLO 和按优先级排列的指标细化，以便我们能够优先处理它们。这对于帮助值班工程师了解何时以及需要升级/调查/降级至关重要。
- 熵估计：
生产中的问题通常具有级联的生命周期，包括问题发生前和问题发生后：
- 问题发生前：问题可能是由一个组件行为的一系列“意外”变化引起的（例如， 此 Loom 事件），级联到更多组件。
- 问题发生后：在尝试应用修复/补丁时，轻微的故障或不准确的尝试（ 例如，此 AWS 事件）可能会进一步升级问题。
工程师预计即使在稳定后也要保持完全活跃，以防系统熵可能增加。
以下实验是在 Kenobi 的生产系统上进行的，Kenobi 是 Doctor Droid 在 2023 年构建的实时分析平台。以下是平台的架构：
该平台（以其当前形式）有四个微服务，大约五位开发人员花了六个月的时间才构建出来。该平台每天处理 20-3000 万个事件，这些事件来自不同的来源，并在不到 10 秒的时间内将其提供给 UI 和警报评估进行查询。您可以在此处阅读有关该平台的更多信息。
定义此实验的目标：
- 输入：系统中触发了警报
- 输出：值班工程师用来调查/修复问题的调查运行手册
- 该工具解决的问题：缺乏运行手册/指南，导致调查延迟。
解决方案：
原型的工作原理如下：它从 Slack 接收每个警报的 webhook。然后，原型分析警报的上下文，并尝试通过利用用户可用的上下文信息来推荐最相关的步骤。
以下是用于“上下文”的数据源：
- 团队的内部值班 SOP（视情况而定）
- 添加了特定平台中可用于调试的指标和数据源的上下文。
关于如何在微服务应用程序中调试问题的思维模型
结果：
表面上看，实验的输出质量看起来不错。但是，一旦您在生产环境中对其进行测试，或者将其提供给试图进行调查的人，值班工程师最终会遇到以下问题：
- 通用建议：- “检查 CloudWatch 上相关基础设施的指标”是一个通用的建议，除非开发人员确切地知道哪些组件最相关，否则它可能意味着许多指标。
- 错误的建议：- 在其中一个步骤中，建议检查 ELK/Kibana 中的日志，但 Kibana 不在团队的堆栈中。
- 置信度低的补救措施：- 补救措施通常需要相关数据的支持，而当前的方法无法做到这一点。鉴于建议的通用检查数量，在广泛的指标上运行异常检测的 ML 模型也不切实际。
虽然这些建议感觉是一个令人兴奋的开始，但我们意识到，值班工程师通常更喜欢以下方法来缩短调试问题的时间：
- 按照文档/运行手册中的步骤“逐字逐句”进行
- 将其提升给可能与该问题密切相关的工程师/团队
有了这个经验教训，我们决定将重点从智能转移到为自动化提供框架。
目标：
- 输入：用户配置其可观察性工具及其调查运行手册
- 输出：当收到警报时，剧本将自动触发，然后团队将收到分析结果，作为对原始来源（Pagerduty/Slack/Teams 等）中警报的丰富。
- 该工具解决的问题：值班工程师需要手动调试问题，这通常会导致升级到其他工程师。
结果：
这个 框架 提高了参与用户的开发效率，最高可达 70%。除了数据之外，我们还有一些额外的学习：
- 对确定性结果的偏好： 鉴于在值班时提出的问题至关重要，并且存在升级或业务损失的风险，工程师更喜欢确定性结果而不是概率性结果。
- 对手动配置的抵触： 鉴于该框架依赖于用户的调试步骤/过程，一些团队在手动配置运行手册方面存在挑战，因为他们担心这很耗时，并且重复出现的问题通常是自动化的。
- 仅在某些情况下适用： 探索性问题需要用户超越框架。
实验 2 中的人工智能使用：
(a) 从文档生成剧本：我们编写了一个小型代理，它读取现有文档并将其映射到集成工具。该工具的目标是减少配置剧本的工作量。
此输出类似于之前提到的关于 Terraform Generator 的博客——它仍然不是自动模式，需要用户审查和迭代。
(b) 从数据生成摘要
此摘要器帮助用户首先阅读最相关的要点，而不是手动浏览所有数据。
如您所见，这些是辅助实现，高度依赖于中心框架。
AI/ML 在可观察性领域带来了很多机会，但 它们将针对特定/狭窄的上下文设计。“生产调试”的范围很广，但以下列举了三个范围更窄的示例，这些示例是 AI/ML 今天正在使用的：
- 调查的摘要和分类：
- 创建一个 AI 层，分析自动化框架提取的数据并将摘要发送回工程师，可以减少他们调查问题的时间。
- 多家企业已在内部实施了此功能。微软有一篇关于此的 论文，讨论了他们的产品 RCACoPilot（虽然名称是 CoPilot，但该工具在调试/调查方法上非常确定性，并且仅依赖于 LLM 进行摘要和事件分类）。
（收集阶段的“处理程序”是针对每个警报/事件的用户编写的运行手册。）
- 部署监控和自动回滚：
- 在预测与异常检测的实现中，一种常见的用例是在部署语境中，因为它们通常是问题的来源且是众所周知
- 这种方式已被多家企业采用；以下是两个公开已知的企业：Slack 和 Microsoft。
- 警报分组和降噪：
- 将上下文缩小到仅警报有助于在平台内实现智能。以下是一些 AIOps 平台（今天）可以在用户警报数据之上提供的智能见解：
- 根据标签、时间和历史记录对警报进行分组和关联。
- 分析警报频率以了解它是否是一个嘈杂的警报。
经过所有这些实验和原型设计，我得出两个主要结论：
- 即使是微不足道的采用也需要比定制配置系统的现状少得多的噪音。
- 从第一个结论继续，开箱即用地达到这些低噪声阈值并不常见。优化它们通常需要为每个团队/用例进行大量定制工作。
因此，您会看到许多工具和平台在其可观察性堆栈中利用 AI/ML，但它可能会局限于特定范围，在这些范围内协助工程师，而不是成为“工程师的全面替代”。