如何进行事故复盘
2023-01-29 10:11:29 0 举报AI智能生成
如何进行事故复盘
作者其他创作
大纲/内容
故障底层逻辑
故障是常态，无法完全避免
事前尽可能控制，但是由于事前无法完全预测和消除，所以系统设计必须考虑“为失效而设计（Design for Failure）”，并在此基础上切实推行有效的复盘机制，才能最终提升复杂系统的鲁棒性
故障是表象，背后的技术问题和管理问题才是根因
可以包容失败，但不允许犯错
个体的失误反而是一件好事
常见的事故问题
故障无法快速定位
是不是系统的可观测性设计出了问题
故障发现不及时
是不是监控覆盖度不够
故障预案在遇到问题时失效
容量故障
是不是限流、降级、熔断等保障手段缺失
配置错误
流程经常出错
是不是人工操作步骤太多，或者流程本身需要改善
故障复盘的误区
以唯一根因为导向来复盘
案例
由于服务器宕机造成数据库MySQL服务挂了，进而影响上层服务，整个过程花了20分钟才修复，最终被定级成故障。
VPN连接问题，和运营商网络有关，所以需要给运维人员配备两个以上运营商的上网
值班机制问题，关键运维岗位需要有备份机制，必须确保至少有一人可以快速响应
MySQL主从切换不生效为什么一直没有发现，原因是缺乏定期的切换演练
业务没做降级保护，所以要添加鲁棒性设计，并且需要对降级保护进行混沌工程试验
故障和处罚直接挂钩
把故障的归因于外部客观原因
当发生故障时，我们不应该把问题归因于不受我们控制的外部客观原因，而是应该研究我们到底没做什么
故障缓解措施依赖于管理手段儿非技术手段
技术手段暂时无法满足的，可以靠管理手段来辅助，但是这只能作为辅助手段，一定不能是常态，必须尽快将这些人为动作转化到技术平台中去
常见的故障复盘步骤
理解故障的技术背景
梳理故障的整体情况
识别故障的直接/间接影响
梳理故障时间线
识别和分析故障触发条件和关键环节
层层下钻故障根因
分析解决方案
归纳推演出后续的跟进措施
总结经验教训
复盘改进跟进闭环
聚焦系统本身及过程
0 条评论
下一页
