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