sre和ai

AI能力之于SRE来说，我觉得可能在问题在预测和寻找问题根因上是比较有用的。这个在很多公司也都有了很好的实践。

这次主要是看了SREcon2025上有个《Why-Risk-Management-Requires-Taking-Risks-A-Practical-Guide》演讲，了解下英伟达这样公司的sre都是怎么使用ai的。

他们其实是维护了一个游戏平台，https://play.geforcenow.com。

其中有26个SRE分布在北美和印度，150个不同服务和组件。但是分布在35个地区，25K的服务服务器和大概100K多的GPU，其中一些服务是跨云厂商的，个人理解就是一些前台的服务为了快肯定是放不同的云厂商上。

然后说了为什么用ai

上面1-3这个是说当碰到一些站点的特定问题的时候，如何快速弄清楚并决策谁应该被第一个通知，有些人是不希望老被无关自己的通知。同时有些问题是很复杂，并且混合了很多服务的，这个时候就需要靠AI来快速决策了。

同时因为AI可以快速获取console, log, trace 以及各种dashboard的信息，因此它判断起来会比人类快，也更全面。如果人可能需要20,30分钟才能完成。

流式报告这个是之前没有想过的。

AI帮写写日报周报月报，这个要么自己电脑上有个AI agent, 要么你所有的操作都通过AI平台来执行。当然英伟达肯定有这样的工具。这个跟之前网上传一张截图说xxxip访问小红书多久这种的，这种的毕竟限于出口路由器和ssl的限制，它只能对段ip对应什么工具，这个跟周报日报工具差的还非常远呢。当然把打工人从这些日常行政事务中解放出来总是好的。

英伟达也有工具会分析slack上发生的一切，当然前提是他们用slack来管理所有的事件，然后按照格式来创建事后分析。这种就节省了很多时间，让SRE更加集中精力。

非SRE的问题一般是来自公司高层的一些咨询、质疑。 因此，我们目前正在开发一些解决方案，旨在让非 SRE 岗位的同事也能直接进入系统查询各项事务的状态；系统会自动识别他们在公司的角色，并根据他们的具体身份，提供恰当且针对性的回复。

因为是工程师而不是码农。我们真正想做的是构建解决方案去解决问题，而不是整天忙着处理各种突发故障；但在我们目前的实际工作中，处理故障所占用的时间似乎远超我们所期望的限度。因此，我们引入了许多所谓的AI 协作者（copilot）应用，以此来辅助和优化我们的开发流程。值得一提的是，这类工具在弥补团队内部的“技能鸿沟”方面也表现得非常出色。我相信很多人在自己的团队中都遇到过这种情况：某些成员在特定技术领域表现得非常强悍、能力出众。

第二个就是为什么对于SRE来说采用ai解决方案会很难

在SRE领域，许多问题的发生往往都源于变更。 因此，我们天生就具有“风险规避”倾向。我们不愿在既有的工作流程中引入任何新事物，因为担心它们可能会拖慢我们的节奏，甚至引发更多麻烦。 此外，在某些特定场景下，AI 显然还面临着“信任”层面的挑战。你可能会对引入某些 AI 解决方案感到迟疑，因为你担心它给出的答案或提供的数据并非绝对准确。 AI 的“幻觉”确实是客观存在的风险。不过，我们完全可以采取相应的策略，来有效缓解由“幻觉”及其他因素所引发的各类风险。

举例来说，贵公司的安全团队可能会对你实施特定 AI 解决方案的方式提出异议。 通常情况下，他们会格外关注以下几个核心问题：数据究竟存储在何处？谁拥有数据的访问权限？数据是存储在外部云端（Off-premise），还是始终留存在企业内部环境中？

此外，另一个常见的问题是缺乏高层管理者的支持。这并非因为高层不认可你们正在做的事情，而是因为他们手头还有其他更紧迫的优先事项需要处理。很多时候，AI 解决方案往往会被搁置在一旁，因为当下有太多“必须立即完成”的任务在等着处理。在许多人眼中，AI 相关的工作似乎总是属于那种 我们迟早是要做的项目。此外，你们可能还会遇到另一种情况：在管理层级中，有些人对 AI 解决方案究竟能为你们正在开发的产品带来多大的实际价值，持怀疑态度。

接下来就是如何去做了。

1. 现在我们其实都明白AI很擅长做一些摘要总结的事情，什么视频会议总结什么的。因此，你可以搭建一个非常简单的应用场景：让 AI 专门负责归纳总结你的各类“行动手册”（RTO手册）、技术文档、设计规范，以及其他任何你需要进行总结处理的内容。这样一来，团队成员就能迅速找到解决问题的方案或疑问的解答。尽管这可能是最容易搭建的 AI 应用场景，但要真正把它做对、做好，却可能是最具挑战性的。这主要是因为你输入（或“喂给”）大型语言模型（LLM）的内容必须是准确无误的。作者从事 SRE工作领域的这 25 年里，似乎从未遇到过一个真正擅长维护文档的团队。通常情况下，很多团队里都堆积着大量陈旧过时的文档，甚至是一堆毫无价值的垃圾信息。由于内容缺乏统一的标准化规范，很难生成高质量、高准确度且值得信赖的摘要。因此在尝试落地基于内容摘要的 AI 解决方案时，这恐怕是你们最需要着力解决、也是最需要下功夫去训练的一项关键能力。
2. 接下来，让我们进入下一个层级的复杂应用场景：信息综合（Information Synthesizing）。这不仅仅是简单地对现有内容进行摘要归纳，而是要主动去抓取并分析全站范围内的实时信息。具体来说，它会同时去查阅你的各项业务指标（Metrics）、服务等级目标（SLOs），以及系统日志，trace信息等所有相关数据。随后，你可以向它提出这样的问题：“嘿，目前保加利亚那边的系统运行状况如何？”随后它会给出响应，并说道：“这就是我所掌握的关于保加利亚当前状况的所有信息，对吧？”接着它会将所有相关细节一一列出。你甚至可以要求它生成图表之类的可视化内容。这样一来，只需输入一段通俗易懂的自然语言查询，你就能在一个统一的界面 上概览所有信息。这有助于在事件处理场景下显著提升效率——你无需再耗费20分钟去费力地汇总数据，该系统能在不到一分钟的时间内自动为你完成数据整合。
3. 在此基础之上，下一个层级 是评估。在这个阶段，AI实际上会为你提供建议，指引你应当采取何种行动，或者指出潜在的问题症结所在。换言之，它正在对当前局势进行某种定性评估。目前，我们正在部署一套基于贝叶斯网络的系统；当系统接收到一系列警报时，该系统能够自动进行分析，从而精准定位最可能出现故障的环节。它能够理解整个网络的拓扑结构及各组件之间的依赖关系，并向你发出建议：“嘿，你系统里最有可能引发故障的组件就是这个。”这能让你迅速缩小排查范围，明确调查与搜索的重点区域。此外，如果你需要启动逐级上报（escalation）流程，该系统也能在一定程度上帮助你避免因误判而导致的无效上报。
4. 最后一点：这或许是最引人入胜、但也最令人感到忐忑的一点，即让AI直接在生产环境中采取实际行动。也就是说，在完成上述评估环节之后，你将赋予AI自主行动的权限。目前，我们也正在研发相关的解决方案，旨在让AI能够主动介入，采取具体的纠正措施，从而自动修复我们系统中的各类故障。显然，大家对于允许 AI去执行诸如“重启服务”之类的操作，多少还是有些顾虑的。这虽然看似非常简单的任务，但你可能会担心 AI 会不小心把一切都彻底搞砸。 不过，其实有一些行之有效的方法，可以用来缓解这种风险。 此外，你也可以在流程中预设一些“检查点”，确保在 AI 真正对线上环境执行任何操作之前，仍需经过人工的审核与确认。