运维事故怎么定位根因

运维事故根因定位（RCA，Root Cause Analysis）是一项系统性工程，核心目标是不止于“重启恢复”，而要找“为什么发生”。下面按“流程 + 方法 + 工具 + 常见坑”给你一套可落地的思路。

一、事故定位总体流程（标准动作）

1. 先止血，再查因

• 优先恢复业务（回滚、扩容、切流、限流）
• 保留现场：别急着重启（日志、连接、进程、内存、磁盘别清）

2. 明确事故边界

回答四个问题：

• 什么时候开始？（时间点）
• 影响什么？（服务 / 用户 / 地域）
• 变更是什么？（发布 / 配置 / 网络 / 依赖）
• 是否自愈或人为恢复？

3. 时间线重建（非常关键）

按时间排序：

变更 → 指标异常 → 告警 → 用户反馈 → 处理动作

4. 假设驱动验证

• 列出可能原因（变更 / 容量 / 依赖 / 外部）
• 逐一验证，不靠猜

二、常用根因分析方法

1. 5 Whys（最实用）

例：

• 为什么宕机？→ 线程池满
• 为什么满？→ 下游超时
• 为什么超时？→ 数据库慢
• 为什么慢？→ 新索引未生效
• 为什么没生效？→ 发布脚本漏执行

✅ 适合：人为 / 流程类事故

2. 故障树分析（FTA）

• 顶层：服务不可用
• 分支：网络 / 应用 / 存储 / 依赖
• 逐层拆解到原子事件

✅ 适合：复杂分布式系统

3. 变更回溯法（运维最常用）

90% 的事故和“最近变更”有关

检查：

• 代码发布
• 配置变更
• 基础设施（扩容 / 缩容）
• 中间件升级
• 外部依赖变更

4. 依赖链路分析法

• 从用户入口反向追
• 用 trace / 调用链定位“慢在哪一层”

三、不同层面的定位重点

应用层

• 错误日志（ERROR / Exception）
• Thread Dump
• GC 日志
• 慢接口 / 慢 SQL

系统层

• CPU / 内存 / IO / 句柄
• dmesg / syslog
• OOM / 磁盘满

网络层

• 丢包 / 延迟 / DNS
• 防火墙 / 策略变更

中间件

• MQ 积压
• Redis 击穿 / 雪崩
• 数据库连接池

四、工具辅助（别靠肉眼）

• 监控：Prometheus / Grafana
• 日志：ELK / Loki
• 链路：SkyWalking / Jaeger
• 变更：CMDB / 发布平台
• 演练：混沌工程

五、常见误判（避坑）

❌ 只看表象（CPU 高 = 代码烂）
❌ 只怪下游（不查自己超时配置）
❌ 忽略“隐形变更”（脚本 / 定时任务）
❌ 事故报告写成“已恢复”

六、事故复盘输出（建议模板）

1. 事故概述
2. 时间线
3. 直接影响
4. 根因结论
5. 改进项（短期 + 长期）
6. 责任与流程问题

如果你愿意，可以发一个具体事故场景（如：接口 502、数据库雪崩、K8s Pod 频繁重启），我可以直接帮你做根因推演。