夜雨聆风凌晨 2 点 17 分，手机又又又开始连续震动。
不是一条告警，是一串。
CPU 高、接口超时、Pod 重启、Redis 连接数上涨、网关 5xx、某个订单接口成功率下降、还有几条看起来不太相关的日志关键字告警。
值班群里已经有人开始问：
“谁在看？”
“是不是刚才发布影响的？”
“业务方说下单慢，有人确认一下吗？”
“先回滚还是先扩容？”
说实话，这种场景很多运维、SRE、平台工程师都不陌生。最难受的不是系统真的挂了，而是你不知道它为什么挂。你手里有监控大屏，有日志平台，有链路追踪，有告警群，有发布记录，有 CMDB，也有一堆脚本。但故障发生时，它们经常像几个互相不说话的人，各讲各的。
指标说 CPU 高，日志说连接超时，链路说某个下游慢，发布平台说十分钟前确实发过版，业务方说用户已经投诉了。领导在群里催进度，研发说“我这边代码没问题”，DBA 说“数据库看起来还行”，网络同学说“没有发现明显丢包”。
最后还是值班同学靠经验，把最近的变更、异常曲线、接口调用链、错误日志一条条拼起来。运气好，半小时定位。运气不好，两个小时过去，大家还在群里贴截图。
这也是我后来慢慢理解 AIOps 的起点。
很多人一听 AIOps，就想到“买个智能告警平台”“接个大模型问日志”“搞个自动根因定位”。但一线做过运维的人都知道，工具当然重要，可工具不是魔法。AIOps 真正要解决的，不是把监控页面换个皮，也不是让 AI 替你背锅，而是让运维从“人肉拼图”变成“体系化判断”。
它不是一个工具采购项目，更像一次运维体系升级。
一、以前我们为什么总是在救火？
传统运维不是没有工具。恰恰相反，很多团队工具很多。
监控有 Prometheus、Zabbix、夜莺、Grafana。 日志有 ELK、Loki、ClickHouse。 链路有 SkyWalking、Jaeger、Pinpoint。 发布有 Jenkins、GitLab CI、Argo CD。 配置有 CMDB、Apollo、Nacos。 通知有邮件、短信、电话、企微、钉钉。
看起来很全。
但真正出故障的时候，问题通常不是“没有数据”，而是“数据太散、太吵、太难判断”。
以前我们经常遇到几个典型问题。
1. 告警很多，但真正有用的不多
一个服务抖动，可能带出几十条告警。
应用实例告警、容器告警、节点告警、接口告警、中间件告警、业务指标告警全都来了。值班的人第一反应不是“我知道问题在哪”，而是“先别炸我手机了”。
更麻烦的是，很多告警只是结果，不是原因。
比如接口超时，可能是自身线程池打满，也可能是下游接口慢，也可能是数据库连接池耗尽，也可能是某个新版本引入了慢 SQL。告警只告诉你“它不正常”，但不会告诉你“为什么不正常”。
所以告警越多，人越麻。
2. 排查依赖个人经验，难复用
有经验的老运维看到一组指标，大概能猜出方向。
比如 CPU 高但 QPS 没涨，要看 GC、死循环、日志刷盘。 接口超时但错误率不高，要看连接池、线程池、下游 RT。 发布后 10 分钟出现错误，要先看灰度批次、配置差异、依赖版本。
这些经验很有价值，但问题是它们大多在人的脑子里。
新人值班时，只能翻文档、问前辈、搜历史群聊。遇到复杂故障，还是要把老同学从床上叫起来。久而久之，团队会形成一种隐性风险：系统稳定性靠几个熟人撑着。
这不是体系，是人肉兜底。
3. 数据之间没有关联
监控、日志、链路、发布、工单、资产信息，单独看都有价值，但很多团队没有把它们串起来。
一个服务报错，你需要自己去查：
这个服务部署在哪些节点？ 最近有没有发布？ 当前版本是什么？ 依赖了哪些下游？ 错误日志从哪个实例开始出现？ 调用链上是哪个环节耗时变长？ 有没有类似历史故障？ 最后一次处理方案是什么？
这些信息不难，但分散。你得在多个系统之间切来切去。
故障排查最耗时间的，往往不是技术判断，而是信息拼接。
4. 巡检和复盘靠人工，质量不稳定
很多团队都有巡检。早上看看大盘，检查集群状态，扫一下错误日志，看看磁盘、水位、慢查询、消息堆积。
但说实话，只要靠人工，就一定会有漏看。
尤其是系统多、服务多、集群多的时候，巡检最后很容易变成“打开页面看一眼，没红就关”。故障复盘也是一样。写得好的复盘，能沉淀经验；写得差的复盘，只剩一句“加强监控，避免再次发生”。
这种复盘没有办法真正反哺系统。
5. 变更和故障之间缺少自动关联
生产故障里，变更永远是高频原因。
代码发布、配置调整、扩缩容、数据库变更、网络策略变更、证书更新、依赖升级，都可能引发问题。
但很多时候，告警平台不知道发布平台发生了什么，发布平台也不知道业务指标正在异常。结果就是故障来了以后，大家在群里问：
“刚才谁动过？”
这句话听着简单，其实暴露了一个很大的问题：变更信息没有进入故障判断链路。
二、AIOps 的常见误区：很多团队一开始就跑偏了
我见过不少团队做 AIOps，最后效果一般。不是因为方向不对，而是切入方式有问题。
误区一：以为买了平台就叫 AIOps
最常见的情况是，团队采购一个平台，接入一堆指标和日志，然后宣布“我们开始建设 AIOps”。
平台上线那天很热闹，演示也挺漂亮： 告警可以聚合，日志可以搜索，异常可以识别，页面还能生成一些分析结论。
但过几个月再看，很多功能没人用。值班还是看原来的 Grafana，排障还是翻日志，故障群里还是截图满天飞。
为什么？
因为只是把工具摆上去了，没有改变运维流程。
AIOps 平台如果没有进入告警处理流程、发布流程、应急流程、复盘流程，它就只是另一个系统。大家故障时不会主动打开它，因为人的习惯是找最熟悉、最能救命的东西。
工具只有嵌进流程，才会变成能力。
误区二：上来就想自动根因定位
很多老板和管理层最爱听“自动根因定位”。
这个词很好听，但一线同学要冷静一点。
根因定位不是看一条日志就能判断，也不是模型随便给一个结论就能信。它依赖几个前提：
指标采集完整； 服务拓扑准确； 调用链覆盖关键路径； 变更记录可靠； 告警规则质量足够； 历史故障有沉淀； 业务指标和技术指标能关联。
这些基础没有做好，所谓根因定位很容易变成“猜因定位”。
模型说可能是数据库慢，但实际上是发布后线程池配置错了。模型说可能是网络抖动，但实际上是某个下游限流。值班同学如果盲信，反而会被带偏。
AIOps 可以辅助判断，但不能一开始就替代判断。
误区三：只关注算法，不关注数据治理
很多团队一聊 AIOps，就开始讨论模型、算法、向量库、大模型、异常检测、时序预测。
这些当然重要。但一线落地时，最先卡住的往往不是算法，而是数据。
服务命名不统一。 标签不规范。 CMDB 不准。 日志字段乱写。 告警等级随便定。 发布记录缺失。 同一个应用在不同平台叫三个名字。
这种情况下，再好的算法也很难做出稳定结果。
我一直觉得，AIOps 的下限由数据质量决定，上限才由算法能力决定。
数据烂，AI 只能更快地输出一堆看似合理的废话。
误区四：忽视人员协同
AIOps 不是运维一个部门就能闭门做成的。
告警规则需要应用负责人参与。 日志规范需要研发配合。 业务指标需要产品或业务团队定义。 变更信息需要发布平台和研发流程打通。 根因验证需要 SRE、研发、DBA、中间件、网络团队一起闭环。
如果组织协同不到位，最后 AIOps 平台会变成运维自己的“大玩具”。数据接不全，知识沉淀没人维护，故障建议没人认可，自动化动作没人敢放权。
所以很多时候，AIOps 不是技术问题，而是工程化和协同问题。
三、AIOps 到底能解决什么？不能解决什么？
先说能解决的。
AIOps 最适合解决那些“重复、海量、关联复杂、需要快速判断”的运维问题。
比如：
告警太多，帮你聚合和降噪； 指标曲线异常，帮你提前发现趋势； 日志太长，帮你摘要和提取关键错误； 调用链太复杂，帮你关联上下游影响； 故障排查步骤重复，帮你生成排障建议； 故障复盘耗时，帮你自动整理时间线； 巡检靠人工，帮你生成日报和风险提示； 历史故障难查，帮你从知识库里找相似案例； 变更影响难判断，帮你把发布和异常关联起来。
这些场景都很实用。
但它不能解决所有问题。
AIOps 不能替代架构治理。一个系统设计本身就脆，AI 不能让它突然高可用。 AIOps 不能替代容量规划。资源长期打满，不扩容、不优化，AI 只能提醒你要爆了。 AIOps 不能替代发布纪律。没有灰度、没有回滚、没有变更审批，AI 也救不了野路子发布。 AIOps 不能替代团队责任。故障复盘没人认领，改进项没人跟踪，再智能的报告也只是文档。
所以我的观点很简单： AIOps 的价值不是让运维“少干活”，而是让运维少干低价值、重复性、纯体力的信息拼接工作，把精力放到稳定性治理上。
四、从监控到智能决策，运维能力是怎么演进的？
很多团队不是突然跳到 AIOps 的。它通常有一个演进过程。
第一阶段：有监控，知道系统挂了
最早我们做监控，目标很朴素：系统挂了要知道。
机器 CPU、内存、磁盘、端口、进程、URL 探活，能报出来就不错。这个阶段解决的是“看不见”的问题。
但它的问题也明显：告警很粗。系统报红以后，还是要靠人查。
第二阶段：有指标，知道哪里不正常
后来监控开始细化到应用层。
QPS、RT、错误率、连接池、线程池、JVM、GC、缓存命中率、消息堆积、数据库慢查询，都能看到。
这个阶段比基础监控强很多。至少你能知道“哪块不正常”。
但指标多了以后，人又遇到新问题：看不过来。尤其是微服务架构下，一个请求经过十几个服务，任何一个指标异常都可能引起连锁反应。
第三阶段：有关联，知道影响链路
再往后，链路追踪和拓扑开始进入生产体系。
一个接口慢，可以看到它调用了哪些服务，在哪个 Span 上耗时最长。一个服务异常，可以看到上游影响哪些入口，下游依赖哪些组件。
这一步很关键。它让排查从“到处猜”变成“沿着链路看”。
但它依然依赖人去分析。链路很长、日志很多、指标很多的时候，人还是会疲惫。
第四阶段：有智能分析，给出候选原因
AIOps 开始介入以后，系统可以做一些自动判断。
比如某个接口 RT 上涨，它可以同时拉取：
同时间窗口的错误日志； 相关服务的发布记录； 上下游调用耗时； 资源水位变化； 数据库慢查询； 缓存命中率； 历史相似故障。
然后给出几个候选方向：
10 分钟前服务 A 发布新版本，异常从该版本实例开始出现； 调用链显示服务 A 到服务 B 的耗时占比提升明显； 服务 A 错误日志中出现大量连接池超时； 历史故障中有相似模式，处理方式是回滚配置并扩大连接池。
注意，是候选方向，不是最终结论。
真正的生产系统里，AIOps 最靠谱的方式不是“一锤定音”，而是把证据整理好，让人更快判断。
第五阶段：辅助决策和半自动处置
再成熟一点的团队，会把一些低风险动作自动化。
比如：
自动拉取故障现场； 自动生成应急群摘要； 自动创建事件单； 自动通知服务 owner； 自动建议回滚或扩容； 自动执行只读诊断脚本； 对明确场景执行半自动修复。
这里一定要强调：生产自动修复要谨慎。
我不建议一开始就全自动执行“重启、扩容、回滚、切流”这类动作。尤其是金融、电商、制造、政企这类系统，自动动作本身也可能制造事故。
比较稳妥的做法是：先自动分析，再人工确认；先只读诊断，再低风险处置；先非核心系统试点，再扩大范围。
下面这张图可以概括这个演进过程：
五、AIOps 不是一个工具，而是工具、流程、数据、人员一起升级
如果只能用一句话解释 AIOps 的落地逻辑，我会说：
工具负责承载能力，数据负责提供证据，流程负责驱动闭环，人员负责判断和改进。
这四个缺一不可。
1. 工具：不是越多越好，而是要能串起来
很多公司已经有一堆工具，不一定非要推倒重来。
AIOps 平台更像一个“运维智能中枢”，把已有系统的数据串起来，而不是替代所有系统。
常见要接的系统包括：
监控系统：指标、告警、阈值、时间序列； 日志系统：错误日志、异常堆栈、关键字段； 链路追踪：调用拓扑、Span 耗时、上下游关系； CMDB：应用、实例、负责人、环境、依赖关系； 发布系统：版本、时间、发布人、发布批次、回滚记录； 工单系统：故障单、变更单、问题单； 知识库：历史故障、SOP、排障手册、复盘报告； 自动化平台：脚本、任务编排、巡检、处置动作。
这些系统不需要都长在一个平台里，但需要通过统一的事件模型和对象模型关联起来。
否则还是信息孤岛。
2. 数据：标签、时间、拓扑，比模型还重要
做 AIOps，数据治理绕不开。
最基础的是统一对象。
同一个服务，在监控里叫 order-service，在日志里叫 order_srv，在发布平台叫 oms-order，在 CMDB 里叫订单服务。你让系统怎么关联？
所以要先统一几个关键维度：
应用名； 服务名； 实例 ID； 环境； 集群； 机房或可用区； 负责人； 版本号； Trace ID； 变更 ID； 告警事件 ID。
这些字段看起来很普通，但它们是关联分析的地基。
再往上，是统一时间。
故障分析非常依赖时间线。告警几点出现，发布几点开始，错误日志几点暴涨，接口 RT 几点抖动，用户投诉几点进来。只要时间不准，后面的判断就会歪。
我遇到过一个很典型的坑：某个日志系统的时间戳用的是容器本地时间，节点时钟漂移了几分钟。结果故障时间线看起来像“先有错误日志，后有发布”，团队差点误判。后来统一了 NTP 和日志采集时间字段，这类问题才减少。
3. 流程：没有闭环，就没有真正的 AIOps
AIOps 不能只停留在“看板展示”。
它要进入日常流程。
告警来了，平台应该自动聚合、定级、分派、关联上下文。 值班处理时，平台应该提供排障路径、相关证据、历史案例。 故障结束后，平台应该生成时间线、影响范围、处理动作、复盘草稿。 复盘完成后，改进项应该进入工单系统跟踪。 改进项完成后，规则、知识库、自动化脚本应该更新。
这才叫闭环。
否则每次故障都是一次性劳动，没有沉淀。
4. 人员：AI 做辅助，人做责任判断
AIOps 再强，也不能取消人的责任。
生产系统里，很多判断不是纯技术问题，还涉及业务优先级、风险控制、影响面评估和组织协同。
比如要不要回滚？ 要不要切流？ 要不要限流？ 要不要降级？ 要不要临时关闭某个功能？
这些不是模型单独能决定的。模型可以告诉你证据和建议，但最终决策应该由值班负责人、服务 owner、业务负责人一起确认。
我比较认可的方式是“人机协同”：
AI 负责发现异常、整理证据、给出建议； 运维负责判断风险、推动处置、沉淀机制； 研发负责确认代码和业务逻辑； 平台负责持续优化数据、规则和自动化能力。
下面这张图可以帮助理解 AIOps 体系中的关系：
六、一个更贴近生产的 AIOps 落地拆解
下面不讲大词，按真实落地方式拆。
假设我们有一个订单系统，经常在大促、发布、数据库抖动时出现接口超时。现在团队想做 AIOps，不是为了演示，而是为了缩短故障发现和定位时间。
第一步：先选一个小场景，不要一口吃成胖子
很多团队一上来就说要做“全域智能运维”。这基本不现实。
正确做法是选一个高频、痛点明显、数据相对完整的场景。
比如：
核心接口超时定位； 发布后异常检测； 告警降噪； 日志错误摘要； 数据库慢查询关联； Kubernetes Pod 异常诊断； 消息队列堆积分析； 每日巡检自动报告。
我建议第一期优先选“发布后异常检测 + 告警聚合 + 排障摘要”。
原因很简单：生产故障里，变更相关问题多；这个场景边界清楚；价值容易衡量；也不需要一开始就全自动修复。
试点目标可以定得很具体：
发布后 30 分钟内，自动观察核心指标； 如果错误率、RT、日志错误量异常，自动标记风险； 自动关联发布批次、实例、版本、负责人； 自动生成排查摘要； 值班人员确认后决定回滚、继续观察或转研发。
不要把目标写成“提升智能化水平”。那种目标没人知道怎么算成功。
第二步：把关键数据接进来
这个场景至少需要几类数据。
第一类是应用指标。
核心包括：
QPS； P95/P99 RT； 错误率； HTTP 5xx； 业务成功率； JVM 内存和 GC； 线程池活跃数； 连接池使用率； Pod 重启次数； CPU 和内存使用率。
第二类是日志。
日志不是全量丢给模型就完事。要先做结构化。
至少要提取：
时间； 应用名； 实例； 环境； Trace ID； 错误级别； 异常类型； 错误码； 关键异常堆栈； 请求路径； 用户或租户维度，注意脱敏。
第三类是链路。
链路要能看到：
入口接口； 上游调用方； 下游依赖； 每个 Span 的耗时； 错误 Span； 慢调用节点； Trace ID 和日志能否打通。
第四类是发布变更。
至少包括：
应用名； 版本号； 发布开始时间； 发布结束时间； 发布批次； 发布人； 变更单； Git commit； 配置变更； 是否灰度； 是否回滚。
第五类是 CMDB。
别小看 CMDB。它决定了系统能不能找到责任人，能不能知道服务依赖关系。
至少要有：
应用负责人； 业务域； 所属团队； 服务等级； 部署集群； 依赖组件； 上下游关系； 值班组。
这些数据不一定一开始都完美，但核心字段必须先统一。
第三步：定义事件模型，不要让告警各说各话
告警系统最常见的问题是事件不标准。
有的告警叫“接口耗时过高”，有的叫“API latency high”，有的叫“P99 超阈值”。内容都差不多，但平台不知道它们是不是同一类。
所以要设计一个统一事件模型。
可以包含：
event_id：事件 ID； event_type：事件类型，比如 latency、error_rate、resource、dependency； severity：严重级别； service：服务名； instance：实例； env：环境； region：区域； metric_name：指标名； current_value：当前值； baseline：基线； start_time：开始时间； related_change：关联变更； related_trace：关联链路； related_logs：关联日志； owner：负责人； status：处理中、已恢复、已关闭。
统一事件模型的价值，是后面可以做聚合、去重、关联和复盘。
否则告警只是告警，无法成为“事件”。
第四步：先做告警聚合和降噪
告警降噪是 AIOps 最容易出价值的场景之一。
比如同一个服务的 20 个 Pod 同时 RT 升高，不应该打 20 通电话。 同一个故障引起上下游多个系统报警，也不应该让每个系统单独拉群。 某个节点挂了，节点上的实例全部告警，应该聚合到节点故障。
聚合逻辑可以从简单规则开始，不一定一开始就上复杂模型。
常见聚合维度：
同服务； 同实例； 同时间窗口； 同拓扑链路； 同发布批次； 同错误码； 同异常类型； 同基础设施节点； 同业务入口。
比如 5 分钟内，order-service 出现接口 RT 上升、错误率上升、日志出现大量 timeout，且都发生在 v2.3.7 版本发布后，就可以聚合为一个“发布后订单服务异常事件”。
降噪不是把告警关掉，而是把噪声变成上下文。
有些团队一做降噪就粗暴屏蔽告警，这很危险。正确方式是保留原始告警，但对值班人员展示聚合后的事件，并提供明细展开。
第五步：做异常检测，不要只靠固定阈值
传统阈值有时候很笨。
比如某个接口白天 QPS 高、晚上 QPS 低。白天 RT 200ms 正常，凌晨 200ms 可能就不正常。某些业务有明显周期性，周一和周末差异很大。
固定阈值容易误报，也容易漏报。
AIOps 可以做基线判断，比如：
同比昨天同时间； 环比前 10 分钟； 同比上周同时间； 根据历史周期生成动态阈值； 对突增、突降、波动、持续偏离做检测。
但这里要注意，异常检测不是越敏感越好。
太敏感会把值班同学折磨疯。太迟钝又失去意义。我的经验是，先按业务等级分层。
核心链路宁可敏感一点。 非核心服务可以宽松一点。 已知发布窗口可以单独设置观察策略。 大促期间要使用单独的基线。
判断标准不要只看单点指标，最好组合判断。
比如“接口异常”可以由三类信号共同触发：
RT 连续 3 个周期高于基线 50%； 错误率超过过去 7 天同时间 P95； 日志中 timeout 或 exception 数量明显增加。
多信号组合，比单一阈值靠谱。
第六步：关联发布和变更
这是我认为最值得优先做的能力。
很多故障都和变更有关。不是说所有故障都是发布导致的，但“先看最近变更”一定是高性价比排查路径。
平台可以在异常发生时自动查：
过去 30 分钟有没有发布； 发布的是哪个应用； 哪些实例已升级； 哪些实例还在旧版本； 异常是否只出现在新版本实例； 异常是否从某个发布批次开始； 配置是否有变化； 依赖版本是否变化。
如果发现异常只集中在新版本实例，候选根因就很明确了。
举个例子。
订单服务灰度发布 v2.3.7，先发 10% 实例。发布 8 分钟后，订单创建接口 P99 从 300ms 涨到 2s，错误率从 0.1% 到 3%。AIOps 平台自动对比发现：
新版本实例错误日志出现大量 ConnectionPoolTimeoutException；旧版本实例没有明显异常； 调用链显示订单服务访问库存服务耗时上涨； 发布记录显示本次变更调整了库存客户端连接池参数； 历史故障中有类似案例，原因是连接池配置过小。
这时候平台不需要“神奇地宣布根因”，它只要把这些证据整理出来，值班同学就能很快判断：优先回滚或修复连接池配置。
这就是实际价值。
第七步：日志摘要要做，但不能迷信大模型
日志是故障排查里最让人又爱又恨的东西。
有时候一眼看到关键异常就能定位。 有时候几千万行日志里全是噪声。 还有时候日志写得很随意，错误堆栈长得像小说。
大模型做日志摘要是有帮助的，特别是在以下场景：
提取高频错误； 合并相似堆栈； 找出首次出现时间； 识别错误码变化； 汇总异常样例； 生成排查说明； 解释陌生异常含义。
但必须加边界。
第一，日志要脱敏。用户信息、手机号、身份证、Token、订单敏感字段不能直接丢进去。
第二，不能把全量日志直接喂给模型。成本高、效果差，还可能超上下文。要先聚类、抽样、过滤。
第三，模型输出要带证据。不能只说“可能是数据库问题”，要说明依据是哪类日志、出现频率、时间窗口、关联服务。
第四，日志质量要治理。应用日志如果没有 Trace ID，没有错误码，没有上下文，再好的摘要也只能总结“发生了很多异常”。
我比较推荐的日志处理流程是：
这套流程比“直接问模型这段日志什么意思”靠谱很多。
第八步：根因定位要做成“证据链”，不是一句结论
我不太喜欢平台直接显示“根因：数据库”。
太粗了，也容易误导。
一个好的候选根因输出，应该像排障证据链：
异常现象：订单创建接口 P99 在 02:17 后持续升高； 影响范围：华东一区 30% 流量受影响； 首次异常实例：order-service-7d9f； 关联变更：02:08 发布 v2.3.7，灰度批次 2； 指标证据：新版本实例线程池活跃数打满； 日志证据：出现大量连接池超时异常； 链路证据：访问 inventory-service 耗时占比从 15% 升至 70%； 历史相似案例：2024-11-08 连接池配置过小导致相同异常； 建议动作：暂停发布，回滚灰度批次，检查连接池参数和下游限流。
这才是对值班同学有用的东西。
AIOps 不一定要百分百给出根因，但要把“排查优先级”排出来。生产里节省 15 分钟，有时候就是少掉一大波投诉。
第九步：自动化处置从只读诊断开始
很多团队一提自动化，就想到自动重启、自动扩容、自动回滚。
我建议先别急。
第一阶段做只读诊断：
自动拉取最近发布； 自动查询服务状态； 自动检查 Pod 重启； 自动查询慢 SQL； 自动查看消息堆积； 自动分析错误日志； 自动生成当前影响范围； 自动整理应急群简报。
这些动作风险低，但能节省大量时间。
第二阶段做半自动处置：
建议扩容，但需要人工确认； 建议回滚，但需要服务 owner 确认； 建议切流，但需要值班负责人确认； 建议清理异常节点，但需要二次确认； 建议执行预案脚本，但要记录审批和执行结果。
第三阶段才考虑全自动处置，而且只适合边界清楚、风险低、验证充分的场景。
比如：
临时实例异常自动摘流； 无状态服务单 Pod 异常自动重建； 磁盘日志分区达到阈值自动清理已归档日志； 已知队列消费者挂掉自动拉起； 只影响测试环境或非核心环境的自动修复。
核心交易链路、数据库写操作、批量删除、全局配置变更这类动作，不要轻易全自动。
自动化的目标不是炫技，是可控。
第十步：复盘沉淀要自动化，不然经验留不住
很多团队故障复盘写得痛苦，是因为故障过程中没有记录。
事后大家靠记忆回填：
几点发现的？ 谁先处理的？ 做了哪些动作？ 哪个动作生效了？ 影响了多少用户？ 根因是什么？ 后续怎么改？
时间一久，很多细节就不准了。
AIOps 可以在故障处理中自动记录时间线：
告警触发时间； 事件创建时间； 值班确认时间； 发布关联时间； 关键日志首次出现时间； 处置动作执行时间； 指标恢复时间； 事件关闭时间。
然后生成复盘草稿。
注意，是草稿。最终复盘还是要人确认。因为复盘不只是记录事实，还要分析机制问题。
比如这次故障是连接池配置错误，那更深层问题可能是：
配置变更没有灰度； 压测没有覆盖高并发； 发布后观察指标不完整； 告警没有区分新旧版本实例； 历史故障没有沉淀成规则。
这些改进项，才是稳定性治理的核心。
“https://edu.51cto.com/surl=48ryOOK，本期分享就到这里啦～如果觉得内容对你有帮助，记得点个「赞」和「推荐」，也欢迎分享给身边的小伙伴！关注「程序员喵手」，持续分享实用工具、优质资源和技术干货，我们下期见！
