生成式人工智能在获取、存储和共享确定事件严重程度、根本原因分析和事后总结所需的背景信息方面表现出色。
翻译自 Interrogate Your Software with AI — The Future for SREs 。
图片来自 Shutterstock 的 Smile Studio AP
站点可靠性工程(SRE)是大多数企业的基石。没有站点可靠性工程师(SRE),应用程序和基础架构管理问题将无法得到解决,客户将遭受糟糕的用户体验,业务将因此而损失资金。事实上,缺乏强大的 SRE 团队和收入损失之间存在着简单的因果关系,但事情就在这里变得复杂起来。
SRE 的工作可能既繁琐又复杂,可能需要数小时的调查才能发现问题的根源。而且,所有这些努力通常都可能只是为了发现问题以前就已经发生过,但修复措施记录不完整且沟通不畅。所以本应只需要很少时间的事情,最终却花费了数小时,让 SRE 感到恼火,并在此过程中为组织损失了资金。
更糟糕的是,当问题本身并不是整体问题的关键时。经常出现一系列警报被标记为潜在与关键应用程序故障有关。如果没有正确的经验或文档,SRE 可能会感到迷失,不知道应该首先解决哪个问题。缺乏背景信息可能会非常糟糕,以至于有时候看似存在的问题实际上只是配置更改,使用的机器移动或简单的更新。
当主观因素介入时,问题会变得更加严重。例如,什么样的图表被认为是糟糕的?许多人根据自己的经验进行推断,基本上是凭直觉工作。事情似乎有些不对劲,所以他们请 SRE 出马。但是直觉只会浪费 SRE 的时间;虽然事情似乎有些不对劲,但可能是我上面提到的任何非问题中的任何一个。此外,不同的工程师可能会对实际问题进行不同的排名。缺乏共识意味着浪费了时间和资源。
手动数据分析耗时且可能导致对关键模式的疏忽。通过基于 AI 的事件分析,我们能够迅速处理数据并识别可能被忽视的相关性。这使我们能够采取积极措施,利用历史数据预测潜在事件,摆脱了被动维护的局限性。
此外,基于 AI 的分析在帮助 SRE 确定事件严重程度方面可以起到至关重要的作用。通过为事件严重程度分类定义标准,并依赖于 AI 的洞察力,我们可以做出更明智的决策,高效地优先考虑响应工作。SRE 的重要组成部分之一是资源分配,AI 生成的统计数据可以为资源的影响和需求提供清晰的图像,使我们能够根据严重程度和复杂性来扩展响应。
最后,我们不能忘记事件报告、文档和运维手册。我们都知道它们有多糟糕。根据谁对事件进行了分类,所报告和记录的内容可以从简单的段落到数页的深入研究和分析不等。即使它们很好,它们也可能会丢失,在某个地方存储在驱动器上,永远不会再次看到。
特别是生成式 AI 可以系统地做到这一点 —— 获取、存储和分享正确的根本原因分析和事后总结所需的背景信息。猜测将成为过去,速度和信任可以在这些工作流程中得到培养。
有一点可以肯定,SRE 团队在组织中的关键性将在未来继续存在。它们的重要性不会改变,但是它们的工作方式会改变。随着时间的推移,我们可以预期SRE不仅将调查,还将验证 AI 工具在后台执行的工作。
即使在猖獗的自动化中,仍然需要人类的参与。这将需要学会如何有效地使用智能生成式 AI 助手的提示,以及帮助其他团队和整个组织进行解释。
在日常工作中,SRE 可以预期能够通过类似 PromptOps 的生成式 AI 聊天工具直接审问他们的系统并获得答案。这还将使他们能够从优化到确保应用程序可靠功能的新流程和功能等更高级的工作中获得解放,这些工作以前他们可能无法完成。
我最喜欢的部分之一:他们不再需要充当业务关注的同事的翻译者。当然,他们需要能够提取正确的信息,但是如果您需要一份在业务背景下解释问题的报告,就让类似 PromptOps 的工具生成它,只需关注验证即可。