故障复盘中可能会出现以下一些常见问题：

       1.重心放置到解决方案上，而非原因分析上

       重心放置到解决方案上，而非深入分析根本原因。故障复盘的主要目的是分析故障发生的原因，而非仅仅找到解决方案。故障复盘应该更加关注问题的根本原因，并从哪里入手。

       具体问题可能只是表面现象，员工更多的是整个体系中的执行者，做得不到位，一定是体系设计上还存在不完善的地方或漏洞。因此深挖根因，才能做到治标又治本。

       做到这点，就需要层层递进做故障根因分析，最经典的就是采用5why分析法，也叫“丰田五问法”，“重复问五次为什么，问题的本质和解决办法显而易见”。

       2.忽视了对过程的分析

       在故障处理过程中，手忙脚乱，不能快速响应和定位问题，没有及时通报或升级也是问题，本身也需要改进。

       3.参与者的不足或混乱

       在复盘过程中，吸引和涵盖大量团队成员，让人们之间进行协作，可以促进问题的全面分析和解决方案的制定。参与者应该确保能够深入讨论，对事不对人，言者无罪，而不会受到任何干扰。如果是管理者参与，建议管理者在前期多听少发言，抱着参与者的态度多参与多引导大家发言。

       同时， 切忌将复盘过程和目的搞成追究责任或实施惩罚，这对于团队氛围和员工积极性的打击是非常大的。

       4. 解决方案的局部性

       虽然有时可能会有切实可行的解决方案，但请注意，尽管解决方案可以解决当前的问题，但可能不足以解决这类问题的根本原因。

       5. 在没有评估成本和利益的情况下实施解决方案

       通常，最直接和最快的解决方案可能会导致更高的成本和限制。在制定和实施解决方案之前，应该考虑到受这个解决方案影响的任何其他方面，并保证评估所采取的措施的成本和影响范围。

       6. 未能识别关键成功因素和绩效指标

       应该确定可衡量成功的重要因素，比如客户满意度、响应时间、工单关闭速度等，并且应该持续监控这些指标，并根据需要进行调整。

       7.不足的指导和服务支持

       这样的团队可能会丢失要点，难以与其他团队区别开来，以及难以应对眼前的困境。开展有意义的故障复盘需要一些指导，这些指导应该有效地解释流程，涵盖范围和报告程序，确保团队的用户可以理解复盘的目的的同时，给出高质量的建议。

       8.改进措施落地不到位

       一些改进措施，由于不符合SMART原则，或者跟进不及时，各方的关注不够，或者组织架构的原因（有些改进措施，涉及到运维之外的第三方）可能会部分石沉大海。

       改进措施，需要符合SMART原则，除此之外，在SMART的基础上，还可用5W1H原则进行补充：

• 明确相关改进项的负责人。负责人可以有多个，但主要负责人有且只能有一个，即这个人需要对这个改进项的落地全权负责。

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

       除了提出改进项，对改进措施做到闭环管理也很重要，有始有终，方能进步，包括对PDCA循环和RACI矩阵工具的运用。

       图片 丰田“五问法”的故事：

       有一次，丰田汽车公司副社长大野耐一发现，有一条生产线上的机器总是停转，原因是保险丝被烧断了。虽然每次都及时更换保险丝，但用不了多久又会被烧断，严重影响整条生产线的效率。他觉得，更换保险丝并没有解决根本问题。于是，大野耐一与工人进行了问答对话。

• 一问：“为什么机器停了？”答：“因为超负荷，保险丝被烧断了。”

• 二问：“为什么超负荷呢？”答：“因为轴承的润滑不够。”

• 三问：“为什么润滑不够？”答：“因为润滑泵吸不上油。”

• 四问：“为什么吸不上油？”答：“因为油泵轴磨损松动。”

• 五问：“为什么磨损了呢？”答：“因为没有安装过滤器，混进了铁屑等杂质。”

       经过连续五次追问“为什么”，才找到问题的真正原因，解决的办法就是在油泵轴上安装过滤器。

       SMART原则：

• S - Specific，表示改进项必须是具体的可以落地的。

       回答需要改进、优化的单项、指标是什么。例如“优化系统设计”就是泛泛而谈的，重新设计A系统对B系统的依赖关系，使其能够对异常进行兜底，这种就属于具体的。

• M - Measurable，即改进项是可衡量的可评估的。

       回答制定的验收标准是什么。比如说通过故障演练来检验依赖关系的有效性。

• A - Attainable，指的是在当前的技术环境下，这个改进项是可行的可达到的。
  

       避免出现一些假大空、无法落地的改进，也不要写未来太远的无法达到的事情。

• R - Relevant，即要与其他改进具有一定的相关性。
  

       如本次故障中其他改进项需要有关联性，避免出现孤立的改进。

• T -Time-bound，就是要有明确的截止期限。
  

       写清楚改进项的截止时间，这个时间段建议最长不要超过三个月，避免改进流于形式，在到期之后进行验收。

       最后，笔者也给一个真实的的故障复盘记录文件作为示例，也可以作为故障复盘模板参考（当然，也有需要改进提升的部分）：

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

       彼得圣吉曾说，“从本质上看，人类只能通过试错法进行学习”，但是没有思考的重复试错是没有意义的。只有学会从试错的经历中复盘，才能够得到成长，赢得螺旋式的成功。故障复盘亦是如此，你必须知道自己错在哪里，是什么原因导致错误出现，能采取什么措施改进，只有知道了这些，才能不在同样的地方摔跟头。

       故障复盘，是故障治理的一项重要工作，对运维工作是提升在线率，提升IT服务可靠性，减少由于服务不可用或降级而引起的损失和成本，减少业务风险，提升客户满意度，是减少重复事件和重大事件发生，也是达成SLA的重要手段，对于提升和改进事件管理有重要意义。对团队和个人更是提升和学习机会，提升个人技能和绩效的方式。

       所以，需要按照故障复盘的总体要求，需要持续做好故障复盘和定期的回顾。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>