故障复盘(胡杨)
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 条评论
下一页