谈谈“项目复盘会议”怎么组织

复盘目的：通过复盘总结故障发生和处理过程中的经验和教训，找到杜绝类似问题再次发生的方法，并形成落地文档跟进，明确执行人和时间点，执行人需主动同步状态。确保通过改进计划的实施，同类问题不再在公司出现。

• 挖掘故障过程中所有问题。
• 标明后续改进措施及落实时间点。
• 通过改进计划的实施，确保同类问题不再在公司出现。

1、参加review的人员

故障处理完成后要尽快内部复盘，由故障主责方拉相关方一起进行。至少当事人及其领导必须参加，例如开发人员（DEV）、开发领导（DEV leader）、质量保障人员（QA）、质量保障领导（QA leader）等。

2、故障review时间点

• P1/P2 级故障：故障产生后两个工作日内（48 小时）提交故障报告并周知完成。
• P3/P4 级故障：故障产生后三个工作日内（72 小时）提交故障报告并周知完成。

3、故障review前所做准备

• 故障详细处理过程。
• 导致故障的原因。
• 故障影响范围、相关数据。
• 故障的后续改进计划

4、故障详细处理过程要求

• 要描述从故障开始到发现、处理以及处理完成的详细过程，需包含日期、时间、事件、人员。
• 目的是通过详细过程描述找出在发现故障和处理故障过程中暴露出的问题，作为后续改进计划的依据。

5、导致故障的原因

可能导致故障的原因列表

• 变更（程序变更、配置变更、数据变更、集群扩缩容、进程重启、OS相关参数变更、人为误操作、其他）
• 网络故障（网络运营商故障、内网机房间网络）
• IDC基础设施（OS故障、设备硬件故障）
• 基础平台（发布平台、容器平台、其他）
• 性能容量（性能恶化、流量过载、热点问题）
• 代码问题（程序bug、容错能力不足、其他）
• 业务依赖（脏数据、数据延迟、依赖下游服务异常、数据错误、基础服务）（redis、zk、kafka、mysql、hadoop）
• 安全问题（敏感数据泄露、ddos攻击、安全注入攻击、恶意扫描异常请求）
• 第三方厂商故障（CDN厂商故障、云厂商故障、第三方支付故障、第三方登录故障、第三方其它问题）
• 流程规范（流程缺失或不完善、未遵守已有流程）

故障中的问题发掘：问题在3个时间段中查找

项目上线前导致故障未发现的原因

Dev、QA、SRE、DB、DA等角色存在哪些问题，导致故障。

• 为什么上线前DEV自测没有发现？
  1、是没有设计review么？没有code review吗？
  2、是case没有执行么？
• 为什么上线前PM走查未能发现？
  1、是没按照case执行吗？
  2、是case没写么？或者case没有review?
  3、是没有测试环境么？
• 为什么上线前QA没发现？
  1、是流程/规范未执行？
  2、是checklist写的不规范？
  3、是没有进行codediff或对codediff不了解

项目上线后到发现前导致故障发现晚的原因

• 线上操作后没有检查功能、监控、日志的问题吗？
• 监控不完整吗？项目过程中我们没有写业务监控吗？不了解如何加监控吗？
• 报警阈值设置不合理吗？
• 人员未响应报警吗？线上日志大家每天没有人看吗？
• 业务量太小没关注的问题？

故障发现后处理过慢的原因

• 没带电脑回家？在外面吗？
• 没有看监控定位故障时间吗？
• 定位问题过程合理吗？
• 改代码比较耗时间吗？没有测试环境验证吗？

6、故障的后续改进计划

根据review中发现出来的问题，我们需要制定出可实施的改进计划。

目的：同类型的错误我们自己及相关的同时都不应该再犯。

改进计划可以包含但不限于下面几个方面：

• 流程规范、机制完善类
• 人员经验总结类
• 添加监控
• 系统或工具设计改造
• 系统、业务需求改造