服务器运维事后分析怎么做

服务器运维的事后分析（Post-Incident Analysis / Postmortem）核心目标不是“追责”，而是还原事实、定位根因、沉淀经验、防止再犯。下面给你一套可落地的方法论和模板。

一、什么时候需要做事后分析

• 线上故障（服务不可用、数据异常、性能严重下降）
• 误操作（误删数据、错配线上）
• 安全事件（被入侵、泄露）
• 重大变更失败（发布、扩缩容、迁移）

建议：P1/P2 级事件必做，小问题可简版复盘

二、事后分析标准流程（6步）

1. 快速记录（事件结束后 24h 内）

先记“发生了什么”，不要急着下结论：

• 时间线（UTC+时区）
• 影响范围（用户、业务、地域）
• 严重程度

2. 还原时间线（Timeline）

精确到分钟：

10:02 告警：CPU 100%
10:05 值班介入
10:20 定位为慢SQL
10:35 杀掉异常连接恢复
10:50 业务正常

工具：监控（Prometheus/Zabbix）、日志（ELK）、工单系统

3. 根因分析（RCA）

常用方法：

• 5 Whys：连续问“为什么”
• 鱼骨图：人 / 机 / 法 / 环 / 测
• 故障树（FTA）

示例：

为什么宕机？→ 连接数打满
为什么打满？→ 慢查询
为什么慢？→ 缺索引
为什么缺？→ 上线未走SQL评审

4. 影响评估

• 故障时长（MTTR）
• 损失（订单、请求失败率）
• SLA 是否违约

5. 改进项（Action Items）

必须：

• 明确负责人
• 明确截止时间
• 可验证 示例：
• DBA 每周 SQL 审计（负责人：X，3/1 前）
• 增加连接数监控告警（负责人：Y，2/25 前）

6. 知识沉淀

• 写入 Wiki / 知识库
• 纳入故障演练
• 更新 runbook

三、事后分析报告模板（可直接用）

# 故障复盘报告

## 1. 基本信息
- 事件名称：
- 等级：P1/P2/P3
- 时间：
- 负责人：

## 2. 事件概述
（一句话说明）

## 3. 时间线
| 时间 | 动作 | 人员 |
|----|----|----|

## 4. 根因分析
- 直接原因：
- 深层原因：

## 5. 影响范围
- 用户数：
- 损失：

## 6. 改进计划
| 项目 | 负责人 | 时间 |
|----|----|----|

## 7. 经验总结

四、常见坑（避坑指南）

• ❌ 写成“某人犯了错”
• ❌ 只有现象没有根因
• ❌ 改进项无负责人
• ✅ 关注系统缺陷而非个人

五、进阶做法

• 混沌工程验证改进是否有效
• 建立“无责复盘”文化
• 用 MTTR / 故障率做趋势管理

如果你愿意，可以给我一个真实故障场景，我帮你写一份完整的事后分析报告样例。