ai sre 入门
https://blog.timoq.com/2026/03/30/sre-and-ai/
上文主要是视频的第一段，主要讲的是ai工具对于sre的一些帮助，以及主要是从那个4个层级带来的帮助。 视频的后面一段是将具体如何ai化的，属于how的部分。
由于作者说的并多，所以本文基本上引用了作者说的内容。
在搞这个之前我们需要了解一些基本概念，以及什么时候去使用它们。
- RAG
- Prompt
- Function Call
- Agent
- Fine tunning
我将着手探讨如何在SRE中进一步增强AI能力。大多数工程师在各自的专业领域都非常出色，但在尝试使用新的AI工具时，往往会存在些许惯性阻力。鉴于此，我们应当尝试寻找那些能与现有工作流程无缝衔接的切入点。
这个其实还行，大部分人是怎么简便怎么来，当初大学的是编码还都是vim, emacs, 记事本，editplus这种，后来Java起来就是Eclipse这些IDE了，现在vibe code其实也一样啊。不过我现在还主要都是vim, 主要是这个东西哪里都有。这些外部工具都好说，主要是思想和理念要跟上。现在的瑞士手表也不是100年前的瑞士手表啊。
例如，如果你习惯大量使用终端（Terminal）进行工作，不妨尝试使用支持AI功能的终端，并尝试用自然语言来提问。比如，如果你需要执行某条特定的
git log命令，可以直接用自然语言向AI描述你的需求，大多数情况下它都能准确地为你生成相应的命令。
比如使用Gemini cli这种，大部分情况下免费版的够用了。
另一种方式是，如果你更偏好使用集成开发环境（IDE）进行开发，只需为你的IDE安装一个AI扩展插件，它就能立即为你带来实实在在的价值。你可以针对当前正在处理的代码库提出各种问题——例如：“请告诉我代码中处理‘超时’逻辑的部分位于何处？”—AI工具能够帮你更快地定位代码位置，从而显著提升你理解代码库的效率。
这个国产的很多了，Trae，Qoder这些都可以用。我之前个人一直用trae，这个纯粹是用的早而已，而且现在这些都有Linux版本了，deb和rpm版本的都有，所以对于主流Linux发行版用户都比较友好。之前也写过对应的工具在Linux下的对比。
如果你对数据安全或敏感数据流出内部网络感到担忧，其实针对几乎所有的AI应用场景，目前市面上都有提供自托管（Self-hosted）或开源的解决方案可供选择。
不过，上述这些工具往往侧重于提升个人的工作效率；而在某些情况下，你可能需要为整个团队构建一套共享的AI解决方案。此时，你就需要通过API接口来调用大型语言模型（LLM）的服务了。实现这一目标的方法有很多种：你可以向各大云服务提供商申请企业级的API服务，也可以尝试在内部自行搭建并托管一套模型服务。但总体的原则应当是：尽量选择那些“恰好能解决你的问题”且规模最小的方案。
这个国内其实很便宜的，云厂商的你可以用MiniMax,kimi这些在国内厂商，价格上可比cc这些海外厂家便宜多了，质量是稍微差点，说好听点就是有比较大的成长空间。
举例来说，如果你的团队规模在20、25甚至100人左右，那一套云上提供的API服务就能满足团队的所有需求；只有当成本、延迟、隐私保护等方面的特定限制因素浮现出来时，再考虑转向自托管的解决方案。值得一提的是，如果真的需要自行托管AI模型，其实整个操作流程远比你想象的要简单、直接得多。嗯，大多数现代运行时环境都已经让这一过程变得极其简便。我个人非常熟悉的一个工具是 NVIDIA NIMs；它的操作大致流程是：你只需选择并下载你所需模型的 NIM 镜像，随后运行该容器，通常在不到 5 分钟的时间里，你就能拥有一个正在运行的 LLM（大型语言模型）API 服务。
具体可以参考https://docs.nvidia.com/nim/large-language-models/latest/get-started/index.html
它可以方便的构建生成式 AI 应用，包括 RAG、代理式 AI 等。
默认好像是llama-3.3-70b模型，具体可以直接参考https://build.nvidia.com/models
当然，目前也有其他的开源方案可供选择。你可以从 Hugging Face 或其他任何模型分发平台下载所需的模型，接着利用 VLM 或 SGLAN 等推理引擎来部署服务，这样你同样能搭建起一个可供调用的 LLM API。
不过最近也爆出VLM被人投毒这种事情，所以线上使用还是得小心。不过这种python, nodejs的底层第三方库估计每天都有人盯着呢，防不胜防啊。之前openssh和log4j都爆过类似的外部依赖库被投毒，就是时间成本稍微高一点。
现在我们已经拥有了一个 API。那么，接下来我们该从何处着手，并如何利用它来创造实际价值呢？最简单、直接的切入点莫过于搭建一个 RAG 服务器。RAG 是“检索增强生成”（Retrieval Augmented Generation）的缩写。这项技术在 2024 年可谓风靡一时，备受追捧。 简而言之，RAG 的工作原理是：在模型正式回答用户提问之前，它会先对你所有的文档资料执行一次类似“Ctrl+F”（全局搜索）的操作，从中检索出最相关的文本段落。随后，它会将这些检索到的相关段落与用户的问题一并输入给 LLM。这样一来，语言模型在生成回答时，便能依据其所识别出的具体文本内容进行作答，从而避免了因“幻觉”（Hallucination）效应而凭空捏造、给出不实信息的状况。
搭建 RAG 服务器的起步过程其实相当简单直观。首先，你需要收集齐所有的文档资料，将其拆解为若干个细小的文本片段；接着，将这些片段输入至一个“嵌入模型”（Embedding Model）中进行处理。该嵌入模型会为每个文本片段生成对应的“嵌入向量”（Embeddings），而你需要将这些向量存储在一个“向量数据库”（Vector Database）里。此后，每当用户提出新的问题时，该问题同样会先经过嵌入模型的处理，从而生成一个对应的嵌入向量。利用这一问题向量，你便可以在向量数据库中进行检索，从而精准地找出与该问题内容高度相关的其他文本段落。 本质上讲，整个流程就是：获取所有相关的背景信息，将其喂给 LLM，最终由模型生成相应的回答。整个操作流程不仅简单易行，而且能够迅速显现出其应用价值——这是一项上手门槛极低的技术，你的团队完全可以即刻着手将其投入实际应用。不过，尽管构建一个基础的 RAG 系统看起来相当简单直观，但若要打造出达到“生产级”标准的应用，往往需要考量更多因素——例如，你需要更高的准确性、完善的防护机制（Guardrails），以及扎实的知识基础。
值得一提的是，随着 2024 年 RAG 技术备受瞩目并广受追捧，如今已有海量的相关资源与架构蓝图可供参考。如果你仔细观察这张图片，就会发现它的结构远比上一张复杂得多；因为它不仅引入了“重排序器”（Re-rankers）组件，还具备处理音频、图像及 PDF 文件等多种格式数据的能力。
实际上，这种实现方式在 Nvidia 的 Blueprints（蓝图）中已有提供；它属于机架级 AI 基础设施的标准化设计蓝图，设置起来相当简便。 目前，我们掌握了所有的静态信息，但 SRE通常关注的重点问题往往涉及实时数据。因此，下一步就是将我们的 AI 系统与这些实时数据连接起来。
这正是“工具”（Tools）发挥作用的地方。本质上，工具就是你针对特定功能编写的函数——即你希望大型语言模型（LLM）具备的某种能力。举例来说，如果我有一个名为“获取近期告警”（get recent alerts）的工具，当我将该工具提供给 LLM，且 LLM 决定调用它时，实际发生的情况是：它正在执行该函数对应的具体实现代码，而这段代码实际上是在调用我的监控 API。 大多数 LLM 框架都允许你自定义并提供各类工具；我刚才展示的那个“获取近期告警”工具就是一个典型的例子。当用户提出诸如“显示最近 10 条告警”这样的问题时，如果我也将这个工具提供给 LLM，它就能自主判断何时需要调用该工具去获取响应数据，并基于这些数据生成最终的回复。
此外，这里有一个值得考虑的重要安全模式：你可以先从仅具备只读权限的工具入手。同时，建议将工具返回的原始 JSON 响应数据也一并记录下来（日志化），这样一来，当你收到 LLM 生成的回复时，就可以将其与原始数据进行比对验证，从而逐步建立对整个系统的信任感。
接下来，我将展示一个具体的案例，以此说明这种做法在何种场景下会显得尤为实用。 如图所示，我们面前有一个异常的信号——显然，该信号的状态存在某种故障。然而你不能仅仅将这个原始信号原封不动地直接输入给 LLM，并指望它能自动给出任何有价值的分析结果。例如，在 10 月 6 日这一天，我就观察到该信号出现了某种异常的行为模式。因此我处理这个问题的方法是运行一个简单的预测模型，或者建立一套pipeline，本质上就是通过运行模拟来识别异常情况。对于那些具有明显季节性特征的数据信号，建立预测模型其实非常简单，你只需运行像 Facebook 的 Prophet 这样的工具，就能检测出这些异常点。一旦识别出异常，你就可以将其存储下来；至于具体的存储方式，你可以发挥相当大的创意。你可以记录预期值、实际值，以及实际值相对于预期值的偏差等各类相关信息。
接下来，我会编写一个tool。这正是大型语言模型（LLM）框架中定义工具的标准方式。我创建了一个名为
get_anomalies（获取异常）的函数，并为其编写了详细的描述，说明该工具的功能以及所需的参数。该函数接收的参数包括：服务名称（并列出了允许的服务名称列表）、起始时间、结束时间，以及一些可选参数（例如数据中心字段等）。而该函数背后的具体业务逻辑代码，则由我亲自实现。当我将这个工具暴露出来，使其可供 LLM 调用时，一旦 LLM 接收到用户的提问，它便会自行判断是否需要调用该工具来获取数据，进而生成相应的回答。本质上，tool机制让我们能够以极其简便的方式，实现许多功能强大且复杂的任务。举个相对简单的例子：在发生故障期间，我们可以实时获取故障报告。在故障现场，人们几乎总是会问同一个问题：“现在到底发生了什么？”“目前的最新进展如何？”只要你拥有相应的工具——例如用于获取告警信息、查阅过往故障记录，或是抓取当前故障处理频道中的实时讨论内容的工具——你就能非常轻松地构建一个提示词模板（Prompt Template）。该模板能够自动整合上述各类数据，并迅速生成一份简明扼要的响应报告。 此外，你还可以非常轻松地对这一流程进行扩展，使其能够根据受众的不同（例如高层管理者或一线工程师），生成不同侧重点的报告版本。尽管从表面上看，这似乎只是在获取同一份数据，但最终实际使用的提示词模板却会因提问者的身份不同而有所差异。因此，高管可能会更关注诸如项目影响、持续时长以及相关承诺等方面；而工程师则可能更想了解具体的时间表、目前已执行的命令等细节信息。
这些工作流信息可以自己使用类似 https://www.coze.cn/overview 这样的工具编写看看。 之前在知乎上看过一个课程，就是用扣子来实现的。
因此，只需稍作扩展即添加一条额外的提示词（prompt）你就能生成出独具特色且富有价值的内容。这能极大地节省编写事件报告的时间，至少在起草报告初稿阶段是如此。我们甚至将这一流程在多个 Slack 频道中实现了自动化：一旦有人提出需求，系统便会适时地自动生成报告草稿，并以仅限本人可见的私信形式发送，让你能随时掌握最新动态。
此外，另一项相当受欢迎的应用是编写每周可靠性简报。这项任务的实现过程极其简单直观：你只需建立一种机制，能够查询本周的所有事件工单及重大变更日志；随后，将这些数据套用至预设的模板中，即可自动生成每周一次的可靠性简报。虽然这一过程可能尚未实现完全自动化——也许它只是生成一份初稿，留待你后续进行编辑和发送——但它依然极大地节省了时间并创造了价值，让你无需再耗费精力去处理那种枯燥乏味、从零开始撰写完整报告的繁重任务。
另一项实用功能是“即时绘图”。当然，这项功能也有其局限性，目前仅限于生成某些特定类型且相对简单的图表。假设你拥有两个函数：一个能够以时间序列的形式返回 SLO（服务等级目标）数据，另一个则负责将时间序列数据绘制成图表。这样一来，你只需直接发出指令，请求获取特定服务在特定时间段内的 SLO 数据图表即可。系统将利用大型语言模型（LLM）的能力，首先调用函数去抓取相应的数据，随后调用绘图函数将数据可视化；最终，你将收到一张直观的图表图像，以及一份关于当前状况的简明摘要。
好了，关于工具层面的内容大致就是这些。诚然，各类工具在整合、归纳当前发生的事态方面表现出色；但若要追求更高层次的价值，关键则在于深入探究并理解——究竟是什么原因导致了这些事件的发生。为了实现这一目标，我们不能指望仅仅向大型语言模型（LLM）输入一堆日志和警报，就期待它能自动弄清究竟发生了什么。在我们维护和监控的大多数系统中，往往涉及大量的错综复杂之处；因此，如何为模型提供恰当的上下文信息，正是我们面临的挑战所在。正是在这一点上，我们坚信并且已通过实践成功验证：利用简单的贝叶斯网络能够有效解决问题。通俗地讲，贝叶斯网络本质上就是一张图谱，它以概率的形式描绘了系统中各个组件之间相互依赖的关系。
因此，它使我们能够提出这样的核心问题：鉴于当前观测到的这些故障现象，最可能导致故障的根本原因是什么？这绝非一张简单的、仅具有骨架的依赖关系图。图中的每一条箭头都被赋予了一个特定的概率数值。这张图谱并非通过自动化工具凭空生成的，作为服务的负责人（Service Owner），你需要投入数小时的时间，亲自梳理并绘制出所有的依赖关系；你需要明确哪些状态是可以被观测到的，以及如何判定这些被观测到的状态究竟是正常还是异常。基于这一梳理结果，你将绘制出完整的依赖图谱，并对各种因果关系发生的概率进行预估：即判断哪种情况最有可能发生，以及其发生的频率大致是多少。
这种做法能够带来巨大的价值：
首先，它与SRE的理念高度契合，因为它能够以极其明确的方式将系统组件间的依赖关系显性化。在处理突发故障时，每一位工程师其实都会在脑海中构建一张简易的依赖图谱 – 例如：“这个组件依赖于那个组件”。而贝叶斯网络的作用，恰恰在于将工程师脑海中的这张图谱具象化，使其变得可视化且可供团队成员之间共享。
其次，贝叶斯网络具备处理不确定性的能力。它打破了那种单一警报对应单一故障原因的僵化模式；取而代之的是，它能够综合权衡并整合多条弱警报信息，从而推导出一个比任何单条警报都更具说服力、更确凿的结论。
第三，它能够直接且精准地回答那个在故障排查过程中几乎总是会被反复追问的核心问题：基于当前观测到的这些故障表象，其背后最可能的根本原因究竟是什么？呃，这正是贝叶斯网络的另一项优势所在：当你着手将系统建模为贝叶斯网络时，在这个过程中，你会自然而然地发现自身系统在可观测性方面存在的盲点；而一旦发现了这些盲点，你便可以针对性地增设一些额外的告警机制，从而将整个系统构建成一个更为完善的网络结构。
那么，这一切究竟是如何与大型语言模型（LLM）建立联系的呢？其实很简单，贝叶斯网络的作用在于对系统内部的依赖关系进行映射。当你运行这个网络时，它能够为你提供最可能的故障成因；与此同时，你手中还掌握着所有的系统告警信息和日志数据。这些丰富而详实的上下文信息一旦被输入给大型语言模型，模型便能据此生成出质量更高、更为精准的响应结果。
这里的关键不在于它是否完美，而在于它具有一致性。我们观察到了相同的推理逻辑，而且这种逻辑是可以解释的，因为你可以追溯到究竟是哪些信号推高了相应的概率。当然，我必须加上一个重要的免责声明：这仅仅是一个建议引擎。因此，你的贝叶斯网络（Bayesian network）究竟有多出色，完全取决于你投入了多少时间去构建和优化它的模型。
嗯，言归正传。 接下来，我们想深入探讨AI 辅助故障解决这一环节。毕竟，从一开始，这才是我们所有工作的核心目标。我们希望能直接在生产环境中进行实时变更，但这无疑是一项高风险的操作，试想一下，如果 AI 生成的指令搞错了命名空间（namespace），或者误重启了错误的微服务，那后果将不堪设想。
我们采取的解决方案大致如下：
首先，我们运行贝叶斯网络，以此识别出最有可能发生故障的组件。
接着，我们会找出与该组件相对应的故障处理预案（Playbook）。一旦锁定了预案，我们便利用大型语言模型（LLM）来生成一条候选的修复指令。
随后，这条指令会经过多重过滤标准的严格筛查——例如，我们会设定禁区（Forbidden Zones）或禁用指令清单（如严禁执行任何删除指令），诸如此类。
随后，流程进入人工审批阶段：审批界面会展示那条候选指令，并列出该指令将要作用于的具体资源范围。
此时，便由人工负责对这条特定的指令进行最终核准，一旦获批，该指令便会在指定的资源上正式执行。
整个流程其实相当简洁明了： 贝叶斯网络负责识别潜在的故障点；LLM 负责查找相应的预案并生成修复指令；随后进行二次校验以确保一切正常；最后则是人工审批环节。这绝非那种简单粗暴的做法: 把一堆日志一股脑儿扔给 LLM，指望它能自动创造奇迹。
事实上，我们在幕后投入了大量精力，精心梳理并构建上下文环境，严格把控输入给 LLM 的信息内容。核心理念在于： 尽管当前阶段的大型语言模型（LLM）确实拥有海量的知识，但它们也可能 引发一些具有风险的变更。
因此，我们的思路是利用自身的专业知识， 去构建并管控系统，确保其行为符合我们的预期；具体做法是构建并 提供恰当的上下文信息，以此来辅助 LLM 的运作。这正是我们目前的应用方向。
实际上，我们已经针对这一方案进行了试点运行——例如在服务进行回滚重启（rollout restarts）时应用它。在这一过程中，一旦系统检测到 故障，该方案就能自动介入处理，从而为我们节省了大量 时间。
这种通过贝叶斯网络的方式会更可控一点，确实一股脑都给LLM, 那对应的误差会相当大。 同时第二步的playbook是非常考验文档水平的。所以他们团队那几十个sre确实不算多。
好的。那么，让我来做个简短的总结， 并给出最后的结论。
我想说的是，SRE 日常工作本身就是在管理 不确定性，对吧？这已经是我们工作生活中的常态了。而 AI 只不过是我们要面对的另一种不确定性罢了。因此，这并非什么全新的领域；它仅仅是一套新的工具集，我们需要去适应并掌握它。
此外，成功并非源于回避风险，对吧？ 真正的成功在于利用你手头现有的 工具，系统性地去理解并化解这些风险, 而这恰恰是我们 SRE 团队的核心竞争力所在。
另外，我们经常被问到这样一个重大问题 – 实际上，这也是我们的领导层 非常关注的一个问题,那就是： 自动化技术最终会取代我们吗？我们是不是在亲手构建一套自动化系统， 好让它来取代我们自己的工作岗位？答案是肯定的：是的，我们确实在这么做。我们理应始终致力于通过自动化来让自己失业——但这并非意味着我们要彻底放弃工作， 而更多是指我们要将当前这一版本的工作内容实现自动化，从而腾出精力去迎接 SRE 角色未来更高层次的演进与变革，对吧？
所以，正如我在此处所言，最大的风险并非在于拥抱 AI 技术， 而在于被时代所抛弃。对吧？尤其是当其他人已经学会如何更高效地运用这项技术时，如果你固步自封，就难免会被甩在身后。 好了，我想以上就是我们要分享的全部内容了。