复盘，源自围棋中的一个术语，指棋手下完一盘棋后，要在棋盘上重新摆一遍，看看哪里下得好，哪里下得不好。下得好的要继承，下得不好的，要在重新摆的过程中探究怎么样落子才更好。
线上问题复盘，通过还原问题现场，问题发生时间线，分析设计、开发、测试、上线、运维等各个环节的问题、充分暴露风险，找到问题发生根本原因，通过行之有效的改进措施，避免同类问题的再次发生。
复盘的目的：
-
避免同样的(类似的)错误不再发生
-
为经验的传承和能力的提升提供依据
-
把失败转化为财富，把成功转化为能力
什么时候复盘？
-
通常为线上故障发生后3天内（视问题严重程度&影响范围，可在3-7天内完成，趁热打铁考虑，通常建议一周内完成）
哪些角色需要参加？
-
PM、RD、QA、项目经理（须参加）
-
对应模块接口人（可能为PM/RD/QA，建议参加）
-
PM leader、RD leader、QA leader（视问题严重程度&影响范围，可选参加）
-
专项负责人（可选参加）
如何准备复盘？
-
复盘发起人需要完成：
-
项目背景梳理、触发场景是什么、影响范围和持续时间、问题排查时间点整理（做了什么，谁做的）、问题根本原因是什么（需形成复盘文档）
-
各角色、干系人拉到群里约时间地点，并至少提前1天把复盘文档发到群里供参与人查阅（复盘会上明确需要某个参与人发言的，可做专门提醒）
复盘过程怎么做
问题回溯
原因分析
-
设计&实现
-
线下测试
-
线上部署
-
问题发现
-
线上止损
改进计划
|
|
不容易实施
|
容易实施
|
|
收益大
|
专项改进 — 中长期目标
|
快速处理 — 短期目标
|
|
收益小
|
可不处理 - 浪费时间
|
可稍后处理 — 短期目标
|
落地跟进
-
跟进机制
-
短期事务：实时通报(钉钉、邮件)
-
长期事务：专项周报等
-
负责人&时间
-
效果追踪
-
技术改进：设置里程碑，review事项达成
-
流程改进：形成规范，实际run起来
