作者：秦红林，紫凌云，CGO兼SaaS负责人。
在上一篇文章中，即“.** 数字运营服务管理 （ITSM） 中的事件管理中的“故障审查”（2）。———如何高效组织故障复核”。它侧重于如何有效地组织失败评审，以免浪费每次评审的机会，那么有效的组织就很重要了，包括确定评审的规则和模板，团队的积极参与，以及基于时间表回顾故障的全过程，深入分析原因和解决方案，分配责任，从各个方面思考改进的机会，一路达成共识，确定改进措施，并跟进持续改进过程。
在本文中，我们重点介绍了故障复核中的一些注意事项，并给出了故障复核的清单，从各个维度提高了故障复核的质量和效果。
在故障复核过程中，可能会出现以下一些常见问题：
1.专注于解决方案，而不是原因
专注于解决方案而不是根本原因。 故障审查的主要目的是分析故障原因，而不仅仅是找到解决方案。 失败评审应该更加关注问题的根本原因，从第一个开始。
具体问题可能只是表面现象，员工更多是整个系统中的执行者，如果没有到位，系统设计中一定存在不完善或漏洞。 因此，只有深入挖掘根源，才能标本兼治。
要做到这一点，就要对故障进行层层分析，最经典的就是采用5why分析法，又称“丰田五问法”，“重复问题五遍，问题的本质和解决方案都很明显”。
2.忽略了对过程的分析
在排查过程中，急于快速响应和定位问题，未能及时上报或升级也是问题所在，需要改进。
3.参与者的不足或困惑
在审查过程中让大量团队成员参与进来，并允许人们相互协作，可以促进对问题的全面分析和解决方案的制定。 参与者应确保他们能够深入讨论，他们没有罪，他们没有罪，并且他们不会以任何方式分心。 如果是管理者的参与，建议管理者在前期多听少说，多参与，引导大家以参与者的态度说话。
同时，重要的是不要将审查过程和目的变成问责或惩罚，这对团队氛围和员工积极性来说是一个非常大的打击。
4.解决方案的局部性
虽然有时可能有实际的解决方案，但请注意，虽然解决方案可以解决当前的问题，但可能不足以解决此类问题的根本原因。
5.在不评估成本和收益的情况下实施解决方案
通常，最直接、最快捷的解决方案可能会导致更高的成本和限制。 在制定和实施解决方案之前，应考虑受解决方案影响的任何其他方面，并保证评估所采取措施的成本和范围。
6.未能确定关键成功因素和绩效指标
应确定可衡量成功的重要因素，例如客户满意度、响应时间、工单关闭速度等，并应根据需要持续监控和调整这些指标。
7.指导和服务支持不足
这样的团队可能会失去积分，很难将自己与其他团队区分开来，并且难以应对眼前的困境。 进行有意义的故障评审需要有效解释流程、覆盖范围和报告过程的指导，确保团队的用户能够理解评审的目的并提供高质量的建议。
8.改进措施不到位
由于不遵守SMART原则，或缺乏及时跟进，各方关注不足，或组织原因（部分改善措施涉及运维之外的第三方），部分改进措施可能会部分丢失。
改进措施需要符合SMART原则，此外，在SMART的基础上，还可以辅以5W1H原则：
确定谁负责相关改进项目。 可以有多个负责人，但只能有一个负责人，即这个人需要对改进项目的实施负全部责任。
后续改进的状态如何？它是在准备、进行中还是已完成？
除了提出改进建议外，对改进措施进行闭环管理也很重要，包括使用PDCA循环和RACI矩阵工具。
* 丰田“五分钟问题”的故事：
有一次，丰田汽车公司副总裁大野奈一发现有一条生产线，由于保险丝熔断，机器一直停机。 虽然每次都及时更换保险丝，但用不了多久就会再次熔断，严重影响了整条生产线的效率。 他认为更换保险丝并不能解决根本问题。 因此，Naichi Ohno与工人们进行了问答对话。
有人问：“机器为什么停下来？答： “保险丝因过载而熔断。” ”
第二个问题：“为什么会超载？答：“因为轴承润滑不够。 ”
三个问题：“为什么润滑不够？答：“因为润滑泵不能吸油。 ”
四问：“为什么我不能吸油？答：“因为油泵轴磨损松动。 ”
五号问：“为什么会磨损？答：“因为没有过滤器，所以混入了铁屑等杂质。 ”
在连续五次询问“为什么”后，找到了问题的真正原因，解决方案是在油泵轴上安装过滤器。
SMART原则：
s - 具体，表示改进项必须具体且可以实现。
回答：哪些项目和指标需要改进和优化？ 例如，“优化系统设计”是一个通用术语，重新设计系统 A 对系统 B 的依赖关系，使其能够涵盖异常是特定的。
m - 可衡量的，即改进项目是可衡量和可评估的。
回答已建立的验收标准是什么。 例如，故障演练用于验证依赖项的有效性。
a - 可实现，这意味着在当前的技术环境中，改进是可行和可实现的。
避免一些虚假的和无法实现的改进，不要写那些未来太遥远而无法实现的事情。
r - 相关，即与其他改进有一定的相关性。
例如，需要将此故障中的其他改进相关联，以避免孤立的改进。
t-time-bound，即要有明确的截止日期。
写下改进项目的截止日期，建议最长期限不要超过三个月，以免改进成为一种形式，并在到期日后接受。
本文档提供了故障审查的清单，以供参考：
最后，笔者还举了一个真实的故障复核记录文件作为示例，也可以作为故障复核模板的参考（当然，也有需要改进的部分）：
彼得·生基曾经说过，“从本质上讲，人类只能通过试错来习学”，但不假思索地重复试错是没有意义的。 只有从试错的经验中学会回顾，才能成长，才能赢得成功的螺旋式上升。 故障复核也是如此，你要知道自己哪里错了，是什么原因导致了错误，可以采取什么措施来改进，只有知道了这一点，你才能不落到同样的地方。
故障评审是故障管理的一项重要任务，是改进运维工作、提高IT服务可靠性、减少因服务不可用或性能下降而造成的损失和成本、降低业务风险、提高客户满意度、减少重复事件和重大事件发生的重要手段，也是实现SLA的重要手段。 这对改进和改进事件管理具有重要意义。对于团队和个人来说，这是一个提高和习的机会，也是提高个人技能和绩效的机会。
因此，要按照故障复查的总体要求，继续做好故障复查和定期复查工作。