服务器宕机事件故障报告模板，事故复盘

服务器宕机后，一份合格的故障报告要能回答三件事：什么时间发生了什么、根因是什么、以后怎么防止。
本文提供可直接套用的报告模板、复盘步骤和验证方法，适合零基础运维或需要写事故报告的开发人员。

报告动笔前先固定现场数据

故障处理完不等于复盘结束。
写报告前先收集可核验的原始信息，避免事后凭记忆补写。

• 时间线：故障开始、发现、响应、恢复、结束各时间点。
• 监控截图或日志：CPU、内存、磁盘、网络、应用错误日志。
• 变更记录：当天是否有发布、配置修改、扩容、证书更新。
• 影响范围：哪些业务、多少用户、持续时长。

常用命令示例：

# 查看系统最近重启和关机记录
last -x | head -20

# 查看内核日志中的 OOM、硬件错误
dmesg -T | grep -iE "oom|error|fail"

# 查看服务状态与启动时间
systemctl status nginx
uptime

记录时使用服务器实际时区，并注明是 UTC 还是北京时间，避免时间线对不上。

故障报告模板的六个必要字段

一份能用于事故复盘的服务器宕机报告，至少包含以下字段。
可直接复制到文档工具中填写。

# 故障报告：<服务名> 宕机事件

## 1. 事件概要
- 发生时间：YYYY-MM-DD HH:MM
- 恢复时间：YYYY-MM-DD HH:MM
- 持续时长：XX 分钟
- 影响范围：<业务/用户/接口>
- 严重级别：P0/P1/P2

## 2. 时间线
| 时间 | 事件 | 操作人 |
|------|------|--------|
| ... | 监控告警 | 系统 |
| ... | 开始排查 | 张三 |
| ... | 执行恢复 | 张三 |

## 3. 根因分析
- 直接原因：
- 根本原因：
- 为何未提前发现：

## 4. 处理过程
- 执行的命令或操作：
- 结果验证：

## 5. 整改措施
| 措施 | 负责人 | 完成时间 |
|------|--------|----------|
| ... | ... | ... |

## 6. 附录
- 日志片段、监控截图、变更单号

根因分析不能只写“服务器挂了”，要写到具体层级，例如磁盘写满、内存溢出、上游超时、配置错误或硬件故障。

复盘时如何定位真正的根因

定位根因按从外到内的顺序排查，避免一上来就重启。

1. 确认现象：是整机不可达、服务无响应，还是仅部分接口超时。
2. 检查资源：free -h、df -h、top、iostat -x 1。
3. 检查日志：应用日志、/var/log/messages、journalctl -u 服务名 --since "1 hour ago"。
4. 检查变更：对比故障前后的配置文件、发布记录。
5. 复现验证：在测试环境模拟相同条件，确认根因成立。

如果日志被覆盖或轮转，可先查看是否开启持久化日志：

# 确认 journald 是否持久化
ls /var/log/journal

没有持久化日志时，重启后系统日志可能丢失，建议后续开启并限制日志大小。

整改项怎么写才可执行

整改措施要具体到动作、负责人和验证方式，避免“加强监控”这类空话。

• 监控告警：补充磁盘、内存、进程存活、端口探测告警，明确阈值。
• 容量规划：为日志、临时文件设置清理策略，例如 logrotate 或定时任务。
• 变更管控：上线前做配置检查，重要变更保留回滚方案。
• 应急手册：把本次恢复步骤写成操作清单，下次可直接照做。
• 演练验证：在测试环境模拟宕机，验证告警和恢复流程是否有效。

整改项完成后，在报告中标注验证结果和验证时间，形成闭环。

常见疑问

报告需要写多详细？
按影响范围和严重级别决定。P0 事件建议包含完整时间线和日志附录；P2 可简化，但根因和整改项不能省。

故障时间线对不上怎么办？
以监控系统时间为准，并在报告中注明各数据源的时区，不要混用。

没有监控数据怎么写复盘？
先用系统日志和人工记录还原时间线，同时在整改项中补充监控覆盖，避免下次无数据可查。

写服务器宕机事件故障报告的核心不是追责，而是让根因、整改和验证可追溯。
按模板收集现场数据、定位根因、落实整改，事故复盘才能真正降低下次宕机概率。