故障复盘
2021-09-06 16:53:01 39 举报AI智能生成
原文来自《提升运维稳定性的利器——故障复盘》胡杨 原文link：http://blog.chinaunix.net/uid-7573623-id-2048961.html
作者其他创作
大纲/内容
REVIEW
动作：
完整的记录下故障的发生、发现、原因定位、决策、处理、预案执行、回滚、故障解决等的关键人与关键时间点
时间：
故障发生后的两天
Analyze
目的：
分析rootcause
动作：
1.故障的原因是什么？
2.再往下想一层，这个故障发生是因为其它原因导致的吗？
3.再往下想一层，这是故障发生的根本原因吗？如果不是，请继续往下想一层
4.其次我们还需要分析在处理故障过程中是否有需要优化的点。比如处理时间是否可以缩短？如何缩短？
Summary
目的：故障进行定性、故障定责及总结本次故障带来的经验教训。
故障定责目的：
谁或哪个团队对本次故障负主要责任及次要责任。做到边界清晰、权责对等
故障定性目的：
1.通过故障定性，评估对业务带来的影响、损失及范围
2.通过故障定性，我们可以更加有序、科学的投入不同程度的资源来解决不同级别的问题
3.跳出本次故障本身，更抽象性的看待同级别、不同级别故障的共性或差异，以期更加系统化的解决有普实性的共性问题
其他目的：
由本次故障带来了哪些经验教训。包括得失的体会，以及是否有规律性的东西值得思考
产出：
1.故障定性
2.故障定责
3.故障的故障发生到最终解决的时长
4.监控是否发现
5.是否业务可用性是否受到影响
Action
SMART
1.Specific：即改进项。我们需要改进、优化的单项、指标是什么
2.Measurable：即验收标准。指定改验收标准是什么？
3.Attainable：即改进项是否可以达到。避免出现一些假大空、无法落地的改进
4.Relevant：即要与其他改进具有一定的相关性。即尽可能避免出现孤立的改进
5.Time-bound：即预期解决时间。这个时间建议最长不要超过三个月，避免改进流于形式
5W1H
明确相关改进项的负责人。负责人可以有多个，但主要负责人有且只能有一个。即这个人需要对这个改进项的落地全权负责。当然，这个负责人的指定也需要在权责对等的基础之上
后续改进项的状态如何？是在准备？进行中？还是完成？
关闭改进项
在所有的改进项未关闭前，需要周期性的对后续改进进行跟进、确认。最终改进的结果与验收标准的贴合度，是评价复盘效果最好指标
0 条评论
下一页
