首页  思维导图  详情



 



如何进行事故复盘

2023-01-29 10:11:29   0  举报





AI智能生成

如何进行事故复盘

事故处理流程

项目管理

软件工程

敏捷开发

复盘

模板推荐

作者其他创作

大纲/内容

故障底层逻辑

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

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

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

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

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

常见的事故问题

故障无法快速定位

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

故障发现不及时

是不是监控覆盖度不够

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

容量故障

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

配置错误

流程经常出错

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

故障复盘的误区

以唯一根因为导向来复盘

案例

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

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

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

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

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

故障和处罚直接挂钩

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

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

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

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

常见的故障复盘步骤

理解故障的技术背景

梳理故障的整体情况

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

梳理故障时间线

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

层层下钻故障根因

分析解决方案

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

总结经验教训

复盘改进跟进闭环

聚焦系统本身及过程

 Collect

Get Started

复盘(回顾，反思，探究，提升）

 Collect

Get Started

复盘+

 Collect

Get Started

事故复盘

 Collect

Get Started

复盘





0 条评论

下一页