排障报告结构是什么
面向管理者和面向技术团队的报告要求不同：管理者要的是『影响 + 结论 + 行动』，技术团队要的是『证据链 + 复现路径』。一份合格的排障报告采用结论先行的写法：现象、影响、时间线、根因、处置、证据、改进项依次排列，正文控制在一页内，原始证据放附录或附件。
基本信息
| 结构 | 现象 → 影响 → 时间线 → 根因 → 处置 → 证据 → 改进项 |
|---|---|
| 写法 | 结论先行、证据附录、时间精确到分钟 |
| 长度 | 正文一页内，证据放附件 |
| 关键区分 | 直接原因（技术动作）与根本原因（流程机制）都要写 |
典型使用场景
- 重大故障向上汇报：先给结论与影响，再给过程细节
- 跨团队交接：让接手人不需要反复询问就能重建现场
- 变更后复盘：把变更单编号与配置差异写入证据部分
- 对客户的说明：突出影响时长与已采取的补救措施
- 知识沉淀：报告归档后成为同类故障的处理参考
报告骨架
报告骨架
1. 结论：X 故障由 A 设备 B 配置错误引发，已于 11:20 修复
2. 影响：X 业务不可用 68 分钟，影响用户约 N 千
3. 时间线：10:12 告警 / 10:15 定位 / 11:05 确定方案 / 11:20 恢复
4. 根因：变更单 B123 误删 443 放行规则
5. 处置：回滚变更并执行验证矩阵
6. 证据：pcap、日志、配置 diff（见附件）
7. 改进：变更双人复核；增加端口级拨测常见缺陷对照
| 缺陷 | 后果 | 改法 |
|---|---|---|
| 只写过程不写结论 | 读者要读完全文才知道发生了什么 | 把结论提到第一段 |
| 时间点模糊 | 无法与监控与日志对齐 | 精确到分钟并标注时区 |
| 证据缺失 | 结论无法验证，复盘难以推进 | 附原始输出与文件 |
| 止于人为失误 | 流程缺陷被掩盖，同类故障复发 | 同时给出机制层改进项 |
写根因时要区分直接原因与根本原因：直接原因是『规则被误删』，根本原因是『变更缺乏复核机制』。两者都写，改进项才有着落。
报告里避免使用『可能』『应该是』描述已确认的事实：把已验证的结论与待验证的假设分开写，避免误导后续处置。