上线之后：AI 运维、四大黄金信号与故障处置

第九周关注代码上线之后的事。课上的说法是：写代码大约只占工程时间的三成，更难的七成是让代码在生产环境里稳定运行，那里各种复杂情况、工具孤岛、知识缺口和相互依赖都交织在一起。本周讲生产监控的基本原则、一套故障处置流程，以及 AI 运维（AI SRE）能做什么。周五的嘉宾来自 Resolve：CTO Mayank Agarwal 和技术人员 Milind Ganjoo。

学习目标

• 了解 SRE（站点可靠性工程师）的传统职责和痛点。
• 掌握监控的四大黄金信号：延迟、流量、错误、饱和度。
• 能按课上的流程处置一次数据库相关的线上故障。
• 认识 AI 运维的特点和目前的局限。

核心概念

传统 SRE 的处境。 SRE 的职责包括运维监控、值班、排障、基础设施管理和安全。处理一次故障，往往要从很多数据源和团队那里拼凑信息，还要维护经常过时的应急手册。迁移到容器和 Kubernetes 之后，数据、依赖和系统复杂度都增加了，值班也容易让人疲惫不堪。课上引用的估计是：停机和服务降级每年给全球 2000 强企业造成约 4000 亿美元的损失。

四大黄金信号。

• 延迟：处理一个请求要多久。成功请求和失败请求要分开统计，因为失败请求（比如 HTTP 500）会拉偏平均值；又慢又失败的请求尤其要盯紧。
• 流量：系统承受的负载，通常用每秒请求数衡量，不同系统也可以用会话数、事务数等。
• 错误：失败请求的比例。既包括明确的失败（比如 500），也包括表面成功、内容却是错的情况，还包括违反约定的情况（比如超过了承诺的响应时间）。
• 饱和度：系统有多“满”，也就是 CPU、内存、I/O 这些受限资源用了多少。系统往往在用到 100% 之前就开始变慢，所以要设定安全阈值，并留意延迟上升、存储快满这类前兆。

此外，还要监控生产环境的调用链追踪（trace）。

一套故障处置流程。 课上用了一个场景：凌晨 3 点 12 分，告警系统通知数据库查询的 500 错误突然飙升。处置分八步：

1. 确认并评估：先确认收到告警，再看应用和数据库的监控面板，判断是部分故障还是全面故障。
2. 先查数据库的黄金信号：连接数有没有满、卡住或突然下降？P95 延迟有没有尖峰、有没有慢查询？有没有超时、连接被拒或事务中止？CPU、IOPS、锁、内存和主从复制延迟是否异常？
3. 找最近的变更：最近有没有发版、做数据库迁移、改配置或功能开关、触发自动扩缩容？如果时间对得上，立刻回滚。
4. 缩小影响范围：是所有查询出问题还是个别查询？读还是写？主库还是从库？一个分片还是全部？问题在应用侧（连接池、超时）还是数据库侧（负载、锁）？
5. 快速止血：连接问题就重启应用、降低并发；数据库过载就停掉重型任务、限流、把读请求分到从库；慢查询就关掉相关功能或接口、启用缓存或降级模式；从库延迟就把读请求切回主库、重启从库；节点不健康时只重启从库，主库要上报处理。
6. 稳定并观察：盯着 500 错误率、数据库延迟和流量回到正常，确认没有重试风暴和连锁故障，健康检查也恢复了。
7. 同步进展：按“问题、动作、当前状态”的格式简要通报，处理期间每 10 到 15 分钟更新一次。
8. 收尾：整理时间线，找出根本原因，列出后续改进项，比如修查询、加索引、扩容、调整重试策略、评估容量。

衡量指标包括平均修复时间（MTTR）、被拉进来处理故障的工程师人数，以及对客户承诺的服务等级（SLA）。

AI 运维的特点。 课上提到的产品有 Resolve AI、Datadog 的 Bits AI、Splunk 的可观测性助手。它们的共同点是：动态构建系统的知识图谱；作为智能体跨越整个可观测性工具链和多个云平台工作；实时描述正在发生什么，给出可能的根因和依据，并建议具体的修复步骤；非常重视推理过程的可解释、可审计。它的意义在于把组织和服务层面的知识扩散开来：那些没写进文档的依赖、脆弱的老服务、只在关键故障里才暴露的怪问题，不再只装在少数几个工程师的脑子里。

局限。 能处理的故障复杂度有限；生产环境的技术栈五花八门；根据检测结果直接修复代码的能力还不够，各家目前都从根因分析做起，自动修复是长期目标。好的根因分析离不开平时把监控维护好。另外，AI 运维本身也可能成为新的攻击入口。

实践步骤

这一周没有编程作业，可以按课上的流程自己演练一次：

1. 在一个能跑起来的服务上，为四大黄金信号各配一个监控面板或查询。
2. 写一份针对数据库 500 错误飙升的应急手册，覆盖上面八个步骤，每一步写清要看的面板和要执行的命令。
3. 人为制造一次小故障（比如压低数据库连接池上限），照着手册走一遍，记录每一步用了多长时间。
4. 如果手头有 AI 运维或可观测性助手，让它同时分析这次故障，对比它给出的根因和证据，与你自己的结论差在哪里。

常见误区

• 只看平均延迟。 失败请求会拉偏平均值，要把成功和失败分开统计，并关注 P95 这类分位数。
• 先查原因，再止血。 课上的流程是先找最近的变更并尽快回滚或止血，系统稳定之后再深挖根本原因。
• 以为接上 AI 运维就不用维护监控。 AI 的根因分析好不好，取决于你平时把监控维护得好不好。

动手练习

回想你经历过的一次线上故障，按八个步骤重新写一份复盘：哪一步花的时间最长？如果当时有一个能读全部监控和变更记录的 AI 助手，它最可能在哪一步帮上忙？

要点回顾

写代码只是开始，系统在生产环境里怎么运行同样关键。四大黄金信号和一套固定的处置流程，是人和 AI 运维共同的基础。AI 的价值在于把分散的知识集中起来，加快根因分析；但监控维护和最后的处置决策，目前仍然需要人负责。

参考来源

• CS146S Fall 2025 课程大纲（Week 9）：themodernsoftware.dev/fall2025，核验日期：2026-10-23。
• 讲义幻灯片：AI DevOps / Incident response and DevOps（Google Slides）。
• 课程推荐阅读：Introduction to Site Reliability Engineering（sre.google）。