如何进行事故复盘

事前尽可能控制，但是由于事前无法完全预测和消除，所以系统设计必须考虑“为失效而设计（Design for Failure）”，并在此基础上切实推行有效的复盘机制，才能最终提升复杂系统的鲁棒性

故障是常态，无法完全避免

故障是表象，背后的技术问题和管理问题才是根因

可以包容失败，但不允许犯错

个体的失误反而是一件好事

故障底层逻辑

是不是系统的可观测性设计出了问题

故障无法快速定位

是不是监控覆盖度不够

故障发现不及时

故障预案在遇到问题时失效

是不是限流、降级、熔断等保障手段缺失

容量故障

配置错误

是不是人工操作步骤太多，或者流程本身需要改善

流程经常出错

常见的事故问题

VPN连接问题，和运营商网络有关，所以需要给运维人员配备两个以上运营商的上网

值班机制问题，关键运维岗位需要有备份机制，必须确保至少有一人可以快速响应

MySQL主从切换不生效为什么一直没有发现，原因是缺乏定期的切换演练

业务没做降级保护，所以要添加鲁棒性设计，并且需要对降级保护进行混沌工程试验

由于服务器宕机造成数据库MySQL服务挂了，进而影响上层服务，整个过程花了20分钟才修复，最终被定级成故障。

案例

系统化看待根因

以唯一根因为导向来复盘

故障和处罚直接挂钩

当发生故障时，我们不应该把问题归因于不受我们控制的外部客观原因，而是应该研究我们到底没做什么

把故障的归因于外部客观原因

面对故障我们需要占据主动，面向失败来做设计

技术手段暂时无法满足的，可以靠管理手段来辅助，但是这只能作为辅助手段，一定不能是常态，必须尽快将这些人为动作转化到技术平台中去

故障缓解措施依赖于管理手段儿非技术手段

靠技术和工具来系统性地解决问题。

故障复盘的误区

理解故障的技术背景

梳理故障的整体情况

识别故障的直接/间接影响

梳理故障时间线

识别和分析故障触发条件和关键环节

层层下钻故障根因

分析解决方案

归纳推演出后续的跟进措施

总结经验教训

复盘改进跟进闭环

聚焦系统本身及过程

常见的故障复盘步骤

如何进行事故复盘

聚焦于系统本身及过程