复盘,即反思。它最先出自围棋术语,指对局完毕后,复演该盘棋的记录,以检查对局中招法的优劣与得失关键。
故障复盘,就是对故障发生及处理过程重新review,进行思考、反思和探究,确定根因,落实改进措施,实现对稳定性和能力的提升。
瑞·达利欧的《原则》这本书写得不错,书中关于人活着的意义写到,人活着就是为了不断进步。那么该怎么进步?我认为可以分为外部因素与内部因素。外因是外部环境的影响,而内因的影响,我认为可以推动自己快速进步的方法就是复盘。
故障复盘则是推动业务系统稳定性、应急响应组织能力提升的高效手段。
围绕复盘目标确定参会人员,包括开发、运维、QA,涉及故障相关团队主要负责人、技术leader等,尽量让各方参与者最高leader级别对别,避免因层级问题影响到复盘效果。
提前与主要参与者沟通好会议时间,确定会议主题。
遵循回顾历程-识别问题-分析原因-制定改进措施的流程:
故障复盘的目的是为了讨论问题,找出改进方案避免再次踩坑。最重要的是要敞开心扉,无所顾虑的暴露问题。会议开始前事先生命复盘讨论的主题、目的。对事不对人,避免形成批评会,如有必要,犯错的那个人不参与会议,或者有他人组织描述处理过程。
对于出现甩锅、批评的现象,会议组织人及时制止。
诚实:基于事实,勇于承认自己的问题;
开放:对事不对人,在尊重他人的前提下,分享自己的观点与看法;
当责:每个团队或个人多从自身找问题,结果导向,主动提出支持与帮助;
目标 | 回顾历程 | 识别问题 | 分析原因 | 改进措施 |
---|---|---|---|---|
如何让修复过程更加高效 | 回顾修复的历程,从发现到解决的全部关键过程 按照故障解决过程的时间顺序回顾,每个团队也可以分享自己事先总结的自己的问题 | 围绕过程,找到问题点: 能不能更快,更及时的发现这个问题? 为什么响应时间过长? 为什么修复时间过长? 有没有自动识别故障、修复故障的工具?为什么信息同步不及时 是否有不符合流程规范的问题? …… | 围绕识别的问题,进行时深度探讨,鼓励相互提问、相互激发,以便找到各个问题的根本原因 | 围绕找到的原因,梳理与总结可以改进的方向,以及制定具体落地的项目计划 |
如何杜绝此类问题再次发生 | 回顾故障是如何出现的,如何从源头一步步地不受控制,发展成后面的问题的 按照职能顺序,产品、设计、开发、运维、测试、QA分享 | 围绕职能的问题:为什么没能阻止这类故障的发生?采用什么手段未来能够阻止此类情况发生? 总结这个故障的本质是什么,这类问题其他相关业务是否可能碰到? | 围绕这个环节的问题,进行深度探讨并达成共识 | 综合制定最优的解决方案 |
还可以从如下这几个问题进行思考
这个阶段只需完整的记录下故障的发生、发现、原因定位、决策、处理、故障解决等的关键人与关键时间点。记录一定要真实、客观、准确,否则将执行影响本次复盘的效果。
聚焦关键问题进行讨论,避免过多的问题讨论影响会议进程。
分析故障的根本原因及故障处理过程中可以优化的点,这个过程需要我们本着抽丝剥茧、根因分析原则来开展。
对前面的分析,总结确定进行后续相关的改进、优化的落地措施。制定的动作及措施符合“SMART”原则:
S:具体的改进项,需要改进和优化点或者指标,避免笼统;
M:可以衡量的验收标准,需要确定验证标准内容;
A:可以实现达成目标,避免出现一些假大空、无法落地的改进措施;
R:尽可能与其他改进措施有一定的相关性,避免出现孤立的改进;
T:有明确的截止期限,预期改进时间不宜过长,避免改进流于形式,一般不超过3个月;
复盘后最关键的是要让改进措施能落地,后期落地难可能碰到如下几类问题:
每个复盘会议结束后,会议的组织者可以整理一个这次复盘的总结文档,传宗归档,供其他团队学习,给组织带来经验的传承,一份好的复盘总结文档要包括如下的内容:
【故障复盘内容】
复盘不局限故障层次,可以是生活或工作很多方面,它就像一面镜子,往往能照出事件真实的样子。”吾日三省吾身”我们很多时候都在忙于往前跑,真的偶尔需要回头看看走过的路,总之需要时不时的认知自己,反省自身,总结规律,提升自我!
[声明:本文大部分内容摘自内部文章,基于作者本身的理解加以补充以及少部分修改。
内部链接 https://km.woa.com/group/29820/articles/show/386477 原文作者:alvinwu(吴新明) ]
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。