首页  思维导图  详情



 



故障复盘

2021-09-06 16:53:01   40  举报





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

明确相关改进项的负责人。负责人可以有多个，但主要负责人有且只能有一个。即这个人需要对这个改进项的落地全权负责。当然，这个负责人的指定也需要在权责对等的基础之上

后续改进项的状态如何？是在准备？进行中？还是完成？

关闭改进项

在所有的改进项未关闭前，需要周期性的对后续改进进行跟进、确认。最终改进的结果与验收标准的贴合度，是评价复盘效果最好指标

 Collect

Get Started

计划&复盘模板知识库

 Collect

Get Started

项目复盘

 Collect

Get Started

《复盘+》读书笔记

 Collect

Get Started

工作复盘





0 条评论

下一页