为什么要进行故障复盘  

稳定性是运维工作的基石。故障，也就是稳定性问题是悬在各位运维从业者头上的一把达摩利斯克之剑。稳定性一旦出现问题，运维的其它工作基本也就算前功尽弃了。那么如何提升稳定性是所有运维从业者都绕不开的话题。

那么出现了稳定性问题怎么办？，没关系，请老中医坐诊，药到病除。「望闻问切」后，开出了一味药方，药方很简单，但是一剂猛药，按时按量服用，但可药到病除。药方上书只有两字：「复盘」。这剂药该怎么用呢？先别急，做为一个坐台多年 的老中医，先从为什么开这剂方子说起。

什么是故障复盘  

先来介绍一下这个方子，即什么是复盘？

复盘源于围棋术语。复盘也称「复局」，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法。

回到「故障复盘」本身也是一致，就是对故障发生及处理过程重新「过」一遍。对这个过程的进行和思考进行回顾，反思和探究，实现稳定性及能力的提升。

怎么进行故障复盘  

为什么开出的是「复盘」这剂方子？大致来讲，这剂方子可以有以下疗效：

·                     避免出现同样或同类的故障。让出现过的故障处于「可控」又或「收敛」的状态；

·                     从出现的故障中可以提炼、固化一些流程，提升效率的同时，同样或同类也可以避免出现同样的故障；

·                     从「蒙着打」变成「瞄着打」，让我们所有的动作更有目的性，清楚自己的目的是什么。

·                     看清故障背后的问题，找出故障背后真正的原因。

·                     发现解决问题的新思路或者新方法；

·                     更加客观的认清业务当前稳定性的现状，以便寻求最佳的解决办法。

「复盘」这剂药要该怎么服用呢？这剂药服用方法很简单，药品的使用说明上都有写，其实也就四个字母：RASA。

我们再翻看药盒的背面，上面写着有这剂药的禁忌：

·                     该药品需要在病状发作时2日内复用，如不及服用，可出现药力减弱甚至出现负作用；

·                     该药品处方药。不可单独1人服用。需要在专业医生的指导下使用；

·                     请严格按照「RASA法」吞服。如使用此药品单个疗程不见效果，请在专业医生指导下反复使用；

那么什么是「RASA」呢？简单点说服用「复盘」这剂药的整个过程。即Review(回顾),Analyze（分析），Summary(总结)，Action(行动)    。来来来，我们来逐一来讲解一下这四步要该怎么走。

    Step 1:Review

即回顾故障发生的整个过程。这一步是最简单，但同时也是最重要的。这一步只需要完整的记录下故障的发生、发现、原因定位、决策、处理、预案执行、回滚、故障解决等的关键人与关键时间点。这一点记录一定要尽可能的准确，这一步会直接关系到本次复盘的效果。为了保证信息尽可能的客观、准确，所以需要按照这剂药的禁忌上所写：

·                     故障发生并解决后尽快着手开始复盘，以避免因时间较长出现的偏差。按老军医的建议，最好是在故障出现后两日内完成；

·                     同样为了避免出现信息偏差，建议参与故障处理的相关人员、角色共同参与复盘；

    Step 2:Analyze

即分析故障的根本原因及故障处理过程中可以优化点。这一步需要本着抽丝剥茧、根因分析（RootCause）原则来进行开展。这个过程大概可以分成－    故障的原因是什么？

－    再往下想一层，这个故障发生是因为其它原因导致的吗？

－    再往下想一层，这是故障发生的根本原因吗？如果不是，请继续往下想一层

－    其次我们还需要分析在处理故障过程中是否有需要优化的点。比如处理时间是否可以缩短？如何缩短？

    Step 3:Summary

即总结本次故障及处理故障的过程。简单点说就是，故障进行定性、故障定责及总结本次故障带来的经验教训。

·                     为什么要对故障进行定性？简单点说有以下几个方面：

A.    通过故障定性，评估对业务带来的影响、损失及范围；

B.    通过故障定性，我们可以更加有序、科学的投入不同程度的资源来解决不同级别的问题；

C.    跳出本次故障本身，更抽象性的看待同级别、不同级别故障的共性或差异，以期更加系统化的解决有普实性的共性问题；

·                     故障定责这个就比较清晰了。即谁或哪个团队对本次故障负主要责任及次要责任。做到边界清晰、权责对等；

·                     由本次故障带来了哪些经验教训。包括得失的体会，以及是否有规律性的东西值得思考。

·                     除了上述之外，在总结这一步，还需要完善以下信息：

A.    故障的故障发生到最终解决的时长；

B.    监控是否发现？

C.    是否业务可用性是否受到影响

    Step 4:Action

即对上面的分析、总结确定进行后续相关的改进、优化的落地措施。所以制定的动作及措施都需要符合SMART原则，即：

·                     Specific：即改进项。我们需要改进、优化的单项、指标是什么？

·                     Measurable：即验收标准。指定改验收标准是什么？

·                     Attainable：即改进项是否可以达到。避免出现一些假大空、无法落地的改进；

·                     Relevant：即要与其他改进具有一定的相关性。即尽可能避免出现孤立的改进；

·                     Time-bound：即预期解决时间。这个时间建议最长不要超过三个月，避免改进流于形式；

除了SMART之外，还需要用5W1H原则进行补充：

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

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

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

实战  

某业务在业务高峰期出现异常，导致业务关键指标下跌超过30%。从表面上来看是业务在高峰期触发了程序的BUG导致，修正掉这个BUG即可解决问题。

但我们通过复盘发现了该业务基础技术结构耦合过重导致业务自愈能力弱、部分应急响应机制流程缺失、多个业务关键节点存在单点或弱备份等多种较为严重的问题。

后续我们通过多次针对此故障的复盘，并持续更有针对性的进行改进。使得同类型故障从原来的发生到恢复需要15~30分钟提升到目前的1~3分钟内由程序自愈解决。

总结  

我们通过使用故障复盘这把利器，更加系统化的解决业务问题的同时，也提升了整个团队的战争力。当然，故障复盘这剂药虽说是剂猛药，但还是需要坚持服用才能看到明显效果的。

（胡杨原创）

为什么要进行故障复盘  

稳定性是运维工作的基石。故障，也就是稳定性问题是悬在各位运维从业者头上的一把达摩利斯克之剑。稳定性一旦出现问题，运维的其它工作基本也就算前功尽弃了。那么如何提升稳定性是所有运维从业者都绕不开的话题。

那么出现了稳定性问题怎么办？，没关系，请老中医坐诊，药到病除。「望闻问切」后，开出了一味药方，药方很简单，但是一剂猛药，按时按量服用，但可药到病除。药方上书只有两字：「复盘」。这剂药该怎么用呢？先别急，做为一个坐台多年 的老中医，先从为什么开这剂方子说起。

什么是故障复盘  

先来介绍一下这个方子，即什么是复盘？

复盘源于围棋术语。复盘也称「复局」，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法。

回到「故障复盘」本身也是一致，就是对故障发生及处理过程重新「过」一遍。对这个过程的进行和思考进行回顾，反思和探究，实现稳定性及能力的提升。

怎么进行故障复盘  

为什么开出的是「复盘」这剂方子？大致来讲，这剂方子可以有以下疗效：

·                     避免出现同样或同类的故障。让出现过的故障处于「可控」又或「收敛」的状态；

·                     从出现的故障中可以提炼、固化一些流程，提升效率的同时，同样或同类也可以避免出现同样的故障；

·                     从「蒙着打」变成「瞄着打」，让我们所有的动作更有目的性，清楚自己的目的是什么。

·                     看清故障背后的问题，找出故障背后真正的原因。

·                     发现解决问题的新思路或者新方法；

·                     更加客观的认清业务当前稳定性的现状，以便寻求最佳的解决办法。

「复盘」这剂药要该怎么服用呢？这剂药服用方法很简单，药品的使用说明上都有写，其实也就四个字母：RASA。

我们再翻看药盒的背面，上面写着有这剂药的禁忌：

·                     该药品需要在病状发作时2日内复用，如不及服用，可出现药力减弱甚至出现负作用；

·                     该药品处方药。不可单独1人服用。需要在专业医生的指导下使用；

·                     请严格按照「RASA法」吞服。如使用此药品单个疗程不见效果，请在专业医生指导下反复使用；

那么什么是「RASA」呢？简单点说服用「复盘」这剂药的整个过程。即Review(回顾),Analyze（分析），Summary(总结)，Action(行动)    。来来来，我们来逐一来讲解一下这四步要该怎么走。

    Step 1:Review

即回顾故障发生的整个过程。这一步是最简单，但同时也是最重要的。这一步只需要完整的记录下故障的发生、发现、原因定位、决策、处理、预案执行、回滚、故障解决等的关键人与关键时间点。这一点记录一定要尽可能的准确，这一步会直接关系到本次复盘的效果。为了保证信息尽可能的客观、准确，所以需要按照这剂药的禁忌上所写：

·                     故障发生并解决后尽快着手开始复盘，以避免因时间较长出现的偏差。按老军医的建议，最好是在故障出现后两日内完成；

·                     同样为了避免出现信息偏差，建议参与故障处理的相关人员、角色共同参与复盘；

    Step 2:Analyze

即分析故障的根本原因及故障处理过程中可以优化点。这一步需要本着抽丝剥茧、根因分析（RootCause）原则来进行开展。这个过程大概可以分成－    故障的原因是什么？

－    再往下想一层，这个故障发生是因为其它原因导致的吗？

－    再往下想一层，这是故障发生的根本原因吗？如果不是，请继续往下想一层

－    其次我们还需要分析在处理故障过程中是否有需要优化的点。比如处理时间是否可以缩短？如何缩短？

    Step 3:Summary

即总结本次故障及处理故障的过程。简单点说就是，故障进行定性、故障定责及总结本次故障带来的经验教训。

·                     为什么要对故障进行定性？简单点说有以下几个方面：

A.    通过故障定性，评估对业务带来的影响、损失及范围；

B.    通过故障定性，我们可以更加有序、科学的投入不同程度的资源来解决不同级别的问题；

C.    跳出本次故障本身，更抽象性的看待同级别、不同级别故障的共性或差异，以期更加系统化的解决有普实性的共性问题；

·                     故障定责这个就比较清晰了。即谁或哪个团队对本次故障负主要责任及次要责任。做到边界清晰、权责对等；

·                     由本次故障带来了哪些经验教训。包括得失的体会，以及是否有规律性的东西值得思考。

·                     除了上述之外，在总结这一步，还需要完善以下信息：

A.    故障的故障发生到最终解决的时长；

B.    监控是否发现？

C.    是否业务可用性是否受到影响

    Step 4:Action

即对上面的分析、总结确定进行后续相关的改进、优化的落地措施。所以制定的动作及措施都需要符合SMART原则，即：

·                     Specific：即改进项。我们需要改进、优化的单项、指标是什么？

·                     Measurable：即验收标准。指定改验收标准是什么？

·                     Attainable：即改进项是否可以达到。避免出现一些假大空、无法落地的改进；

·                     Relevant：即要与其他改进具有一定的相关性。即尽可能避免出现孤立的改进；

·                     Time-bound：即预期解决时间。这个时间建议最长不要超过三个月，避免改进流于形式；

除了SMART之外，还需要用5W1H原则进行补充：

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

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

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

实战  

某业务在业务高峰期出现异常，导致业务关键指标下跌超过30%。从表面上来看是业务在高峰期触发了程序的BUG导致，修正掉这个BUG即可解决问题。

但我们通过复盘发现了该业务基础技术结构耦合过重导致业务自愈能力弱、部分应急响应机制流程缺失、多个业务关键节点存在单点或弱备份等多种较为严重的问题。

后续我们通过多次针对此故障的复盘，并持续更有针对性的进行改进。使得同类型故障从原来的发生到恢复需要15~30分钟提升到目前的1~3分钟内由程序自愈解决。

总结  

我们通过使用故障复盘这把利器，更加系统化的解决业务问题的同时，也提升了整个团队的战争力。当然，故障复盘这剂药虽说是剂猛药，但还是需要坚持服用才能看到明显效果的。

（胡杨原创）