扫码阅读
手机扫码阅读
从研发效能的视角谈“故障复盘”
531 2023-07-15
本文核心观点:
团队的复盘能力有多强,决定了团队的进步空间有多大
复杂系统的高网络密度和强耦合性是造成故障无法完全避免的罪魁祸首
故障是表象,背后技术和管理上的问题才是根因
可以包容失败,但是不允许犯错
不“浪费(忽视)”任何一个失误
不能以唯一根因为导向来复盘
-
避免将故障归因于外部客观原因
在企业业务价值的交付过程中,故障是很难避免的,所以对企业来讲故障复盘是一项关键核心能力,今天我就从研发效能的视角来系统性地聊一聊。
1. 谈故障复盘前,先来看看航空业的安全性
2. 复杂系统故障的特点
3. 故障复盘的概念
4. 故障复盘的价值
5. 故障复盘背后的底层逻辑
5.1 故障是常态,无法完全避免
5.2 故障是表象,背后技术管理上的问题才是根因
故障无法快速定位是不是系统的可观测性设计出了问题 故障发现不及时是不是监控覆盖度不够 容量故障是不是限流、降级、熔断等保障手段缺失 局部小问题的牵一发而动全身是不是故障隔离没有考虑 故障预案在遇到问题时失效,是不是故障预案停留在纸上谈兵,没有实际演练 某些流程经常出错,是不是人工操作步骤太多,或者流程本身需要改善 生产环境的人因故障是不是缺乏对生产环境的敬畏之心 ...
5.3 可以包容失败,但是不允许犯错
5.4 个体的失误反而是一件好事
6. 故障复盘的步骤与最佳实践
理解故障的技术背景 梳理故障的整体情况 识别故障的直接/间接影响 梳理故障时间线 识别和分析故障触发条件和关键环节 层层下钻故障根因 分析解决方案 归纳推演出后续的跟进措施 总结经验教训
6.1 故障根因分析
6.2 改进措施的闭环
6.3 演习的必要性
6.4 复盘过程本身的质量
7. 故障复盘的常见误区与应对策略
7.1 以唯一根因为导向来复盘
VPN连接问题,和运营商网络有关,所以需要给运维人员配备两个以上运营商的上网卡。 值班机制问题,关键运维岗位需要有备份机制,必须确保至少有一人可以快速响应。 MySQL主从切换不生效为什么一直没有发现,原因是缺乏定期的切换演练。 业务没做降级保护,所以要添加鲁棒性设计,并且需要对降级保护进行混沌工程试验。
7.2 将故障和处罚直接挂钩
7.3 将处罚和绩效强绑定
7.4 把故障归因于外部客观原因
7.5 故障缓解措施依赖于管理手段而非技术
原文链接:
https://mp.weixin.qq.com/s?__biz=MzkzNDM1MDU3Mg==&mid=2247483681&idx=1&sn=88073ed710554373be7addb6cad18c9e
茹炳晟聊软件研发的其他文章
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线