AI 赋能稳定性工程：2026年从谷歌 SRE 看大模型在故障应急、根因分析中的实践

引言

本文从多个行业内的头部公司出发，通过公开的材料支撑，分析这些稳定性工程相对成熟的公司目前结合生成式AI以及机器学习进行运维工作的思路和参考经验，希望对于同样从事运维及稳定性工作的朋友有帮助
谷歌的SRE与运维工作分析

谷歌SRE团队的核心哲学之一是“消除琐事（Eliminate Toil）”，即减少那些缺乏长期价值、高度重复且随着服务规模线性增长的运维工作，这里给出几个谷歌的SRE在做的使用AI工具来解决琐事问题的思路
使用 Gemini Cli 进行故障应急

How Google SREs Use Gemini CLI to Solve Real-World Outages
恢复故障通常分为4个阶段：

• 告警：SRE 收到告警通知。
  
• 缓解：止血以减少客户不良体验时长（Bad Customer Minutes），通常甚至在查明故障原因之前就已开始行动。
  
• 根因分析：待用户恢复满意后，深入调查底层缺陷并彻底修复。
  
• 事后复盘（Postmortem）：记录事件经过，并为工程团队制定详尽的改进项，优先处理以确保同类问题不再发生。
  

Step1: 响应应急，初始分析

首先，谷歌内部拥有完整的故障处理 playbook（如限流、重启、回滚等操作）。在故障发生时，SRE 会打开命令行，执行 fetch_playbook 函数。该函数会分别执行以下动作：

• get_incident_details：获取告警信息。
  
• causal_analysis：找到时间序列和故障处理手册指标中的相关性。
  
• timeseries_correlation：找到最相关的时间节点。
  
• log_analysis：分析相关日志。
  

紧接着，CLI 开始推荐最相关的恢复动作，例如 borg_task_restart playbook，然后执行对应操作。关键点在于，人是参与到整个分析流程中的。
紧接着，cli开始推荐最相关的恢复动作：borg_task_restartplaybook，然后对应的动作就会开始执行；这里的关键点在于人是参与到整个分析流程中的。
Step2: 止血

关键思路：copilot, not an autopilot（副驾驶，而非自动驾驶）
CLI 方法通过实施多层安全策略来进行止血动作：

• 确定性工具：代理不会编写随机的 Bash 脚本，而是通过严格类型化的工具（基于模型上下文协议，如 borg_task_restart）进行选择。
  
• 风险评估：每个工具定义都包含其潜在影响的元数据（如：安全、可逆、破坏性）。系统会自动标记高风险操作以进行更严格的审查。
  
• 策略执行：即使代理尝试执行合法命令，策略层也会检查该命令在当前上下文中是否被允许（例如：“高峰时段禁止全局重启”或“需两人审批”）。
  
• 人在环路（HITL）：最终，命令行工具强制进行确认步骤。代理提出变更操作，但由工程师（如 Ramón）授权执行。这使我们能够以 AI 的速度推进，同时保留人工问责机制。
  
• 审计追踪：由于所有操作均通过 CLI 代理执行，系统会自动记录 AI 提出的具体操作与人工批准的内容，满足合规性要求。
  

注：文中案例的执行动作虽然失败了，但 CLI 识别出该失败不影响整体恢复，因此重启动作最终是有效的。

Step 3：根因定位与问题修复

Gemini 开始拉取相关文件，分析近期代码变更，并与之前提取的生产日志进行交叉比对。在不到两分钟的时间内，它成功锁定了问题根源：一次最近配置推送中的逻辑错误。
Ramón （Google SRE）进一步询问：

“你能为此问题生成一个修复 CL 吗？”
（注：CL 即 Changelist，是 Google 内部对 GitHub Pull Request 的等效概念）

Gemini 随即生成补丁并创建一个 CL，内容包括：

• 回滚有问题的配置；
  
• 添加防护机制，防止同类问题再次发生。
  

操作指引：

• 审查并批准该 CL。
  
• 提交 CL。
  
• 等待自动化发布流程执行。
  

代码修复完成后，发布流程启动，服务恢复正常运行。
Step4: 复盘

火势已扑灭，但工作并未结束。SRE（站点可靠性工程）文化的核心在于 复盘（Postmortem）——一份秉持“无责备”原则的文档，旨在分析问题根源，以便从中学习。
撰写复盘报告往往繁琐耗时。Gemini CLI 通过 自定义命令（Custom Command） 实现了这一流程的自动化。
以 Riccardo（“Ricc”）为例：作为 Google Cloud SRE 团队成员和开发者布道师，他主导开发了一个内置于 ProdAgent 的自定义命令，专门用于辅助创建复盘报告。他运行复盘命令后，工具会：

• 抓取数据：自动收集事件期间的对话历史、监控指标和日志。
  
• 生成时间线：将所有相关事件填充到一个 CSV 格式的时间线表格中。
  
• 撰写报告：基于标准 SRE 复盘模板，生成 Markdown 格式的文档。
  
• 提出建议：自动生成行动项（Action Items, AIs），以防止问题再次发生。
  

最后，Gemini 利用 模型上下文协议（Model Context Protocol, MCP） 与问题追踪系统进行交互：

• 创建缺陷单，将行动项作为真实缺陷录入。
  
• 自动分配负责人。
  
• 将最终复盘报告推送到 Google Docs 存档。
  

总结：

这是一个完整的线上事件处理流程——从凌晨 3 点的混乱告警，到最终定稿的复盘报告——整个过程完全在终端中驱动完成。
通过使用 Gemini CLI，Google 将 Gemini 的推理能力与真实的运维数据连接了起来。不仅仅是向一个聊天机器人寻求建议；而是利用一个智能体（Agent）来执行工具、分析实时日志、生成代码补丁，并将其部署到生产环境。正是这种直接的集成，Google 能够显著缩短平均修复时间（MTTM），并将“糟糕的客户体验时长”（Bad Customer Minutes）降至最低。
对于国内的SRE 工作而言，完全可以使用类似的思路来创造自己的故障排查及问题定位 agent
与 dataops 相关的故障应急

2 AM Alerts Just Got Easier: Using Gemini CLI as a Unified Orchestrator for DataOps
这篇文章与上面的文章类似，不同的是这篇文章中提到的Google Cli 会主动分析现场日志，并且文章提到了一个最关键的三层架构：
“确定性三明治架构”（Deterministic Sandwich architecture）

它回答了生产环境使用 LLM 的核心问题：LLM 行为不可预测，如何确保安全？
该架构分为三层：

• 大脑（Brain，以 Gemini 为例）：概率性，负责判断“该做什么”。
  
• 双手（Hands，即 MCP 工具）：严格确定性，是预先编写、经过单元测试的脚本。
  
• 安全策略层（Safety Policy Layer）：基于规则的检查层，用于验证 AI 意图是否符合硬性规则（如“禁止删除生产数据集”），确保 AI 只能在人类设定的安全边界内操作。
  

如何处理高风险变更？

在生产环境中，自动批准所有 AI 操作是灾难的根源。必须建立 “人在回路”（HITL） 机制：

• 交互式审批（Interactive Approval）：默认以交互模式运行。执行类似 gcloud dataproc jobs submit 的命令前，CLI 会展示完整命令，由人做最终决策。
  
• 计划审查（Plan Review）：在数据湖等场景中，Gemini 可能建议“增加 Dataproc 节点内存并重启任务”，但执行前需人工输入 Approve 或 Y。
  
• “Dry Run”习惯：可要求 Gemini 在执行前始终显示等效的 gcloud 命令或 SQL 预览，以确认操作内容。
  
• 审计日志（Audit Logs）：CLI 使用你的凭据（ADC）操作，所有行为均被记录在 GCP Cloud Audit Logs 中，确保 AI 驱动的修复或变更可追溯、可问责。
  

谷歌是否是运维和研发分离的？

维度传统运维 (SysAdmin)谷歌 SRE 模式软件研发 (SWE)核心目标维持运行，降低变更风险通过工程手段提高可靠性，优化效率交付业务功能，提升用户体验技术手段手动配置、脚本、工单系统软件自动化、基础设施即代码 (IaC)业务逻辑开发、架构设计对待风险的态度规避风险，减少变更拥抱风险，通过 错误预算 管理风险追求速度，对稳定性关注度相对较低团队构成系统管理员、网络工程师软件工程师 + 系统知识工程师软件工程师、产品经理核心指标平均修复时间 (MTTR)、可用性SLO、错误预算、消灭琐事 (Toil)发布频率、功能交付周期SRE 是否完全托管生产环境？

谷歌的实践显示了一种 “条件式托管” 逻辑：

• 并非所有服务都由 SRE 托管。
  
• 即便是托管服务，SRE 也不承担所有“背锅”和“打杂”责任。
  

SRE 团队被视为 稀缺且昂贵 的资源。研发团队必须通过 生产环境就绪评估（Production Readiness Review, PRR） 来证明其服务的价值和稳定性，才能获得 SRE 的“托管服务”。
PRR 模型的详细材料
在谷歌很多核心服务中，研发团队同样需要参与 24/7 值班轮转。当故障涉及复杂业务逻辑时，SRE 作为一线响应者在无法解决时会立即升级给 SWE 值班工程师。这种模型确保了 SRE 不会成为与业务脱节的“孤岛”，也保证了研发团队能时刻感受生产环境的压力。
关于 Toil

工作类别具体内容谷歌对 SRE 的要求运维琐事 (Toil)手动重启、处理重复告警、ACL 更新、磁盘清理必须控制在 50% 以下，否则视为团队失败工程项目开发自动部署系统、构建自愈框架、优化性能监控必须占据 50% 以上，是 SRE 职业发展的核心Toil 的理解
字节跳动的SRE工作分析

M3-Agent 核心论文
通过模块化的架构设计和动态的任务分配机制，实测的数据运维效率提升了40%，跨领域的复杂故障定位准确率达到了92%，较传统监控工具高出40个百分点；
指标维度传统 AIOps (2020-2023)M3-Agent-Control (2025)增幅/改善故障排查平均耗时 (MTTR)45 分钟18 分钟缩短 60%故障定位准确率~52%92%提升 40%资源利用率优化区间60% - 70%80% - 85%显著提升上下文理解长度< 32K Token512K Token16 倍提升协同模式预设脚本流动态智能体协作范式跨越在公开的材料当中，对于字节的SRE和LLM实践确实不多，不过从这里我们可以看到类似的agent架构，通过多层的架构设计，实现人工运维动作的效率提高。
附录

谷歌SRE播客
谷歌的容量预测
google sre book 精华文档

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！