浅谈在数字化运营服务管理/ITSM中的事件管理中之“故障复盘”（二）——如何高效组织故障复盘

当前位置：首页 >> 关于我们 >> 新闻动态

浅谈在数字化运营服务管理/ITSM中的事件管理中之“故障复盘”（二）——如何高效组织故障复盘

发布者: 超级管理员发布时间： 2023-07-07

作者：秦鸿林紫羚云 CGO兼SaaS负责人

上一篇《浅谈在数字化运营服务管理/ITSM的事件管理之“故障复盘”（一）——故障复盘的重要性及总体要求》，我们只谈了故障复盘的必要性和价值。本篇着重分析如何高效组织故障复盘。并在下一篇中，重点阐述故障复盘中的一些注意事项，并给出一个故障复盘的检查表，从各个维度提升故障复盘的质量和效果。

笔者从公开渠道，收集了2023年以来发生的几起典型的故障：

2023年3月29日，3 月 29 日，#唯品会崩了#的话题登上热搜。

后续，唯品会发布了关于 329 机房宕机故障处理公告：此次南沙机房重大故障，影响客户达 800 多万，判定为 P0 级故障，对负责人予以免职处理。

同日，某云厂商发布公告称“监测到广州五区部分云服务异常（CLB、COS、Redis、WAF、TKE、控制台等）,目前工程师正在紧急处理中”，微信、QQ 等均出现功能异常。微信包括语音呼叫、账号登录、朋友圈以及支付在内的多个功能无法正常使用，QQ 文件传输、QQ 空间、QQ 邮箱等也同样出现问题。最终该云厂商将事件定级为“公司一级故障”，管理层认为，这次事故暴露出容灾设计方案和应急预案不完善的隐患，有关业务部门的风险防范意识不到位，所以对大量相关领导做出了处罚。其中一高级副总裁被通报处理，两位总经理和总监被处以降级和免职处罚……

3月21日，#东财崩了#登上微博热搜。

据悉，东方财富APP在当日上午、下午均出现长时间用户登录异常、持仓显示异常、无法交易等情况。3月21日A股下午开盘后，有网友反馈馈，东方财富软件再次崩了。

6月19日，“‘券商一哥’系统崩了”上了热搜……

按照2021年6月4日证监会发布的《证券期货业网络安全事件报告与调查处理办法》，当集中竞价交易系统以外的实时交易系统出现严重异常，且故障持续时间30分钟以上的属于重大事件；若故障持续时间10分钟以上的属于较大事件……不管是经济损失，还是对于券商本身的声誉、对券商信息技术部门的负责人的影响，都是不言而喻的。

这几起典型的故障，都是血淋淋的教训，影响、损失都非常巨大。一定不要浪费任何一个故障，不要浪费每次复盘，改进提升，避免更多更大故障，更大损失。

三、如何有效组织故障复盘？

首先，我们需要建立故障复盘的机制和文化，这里核心就是确定故障复盘的方式和模板，其次是鼓励相关干系人积极参与。

1、确定故障复盘的方式

故障复盘流程应该明确定义故障的复盘的模板，比如故障的时间线、哪些人参与、输出什么、责任方分类、改进措施模板等，团队内部各角色的职责，并明确涵盖审查及跟踪故障的信息、注意事项和随后必须采取的行动。

笔者之前的一个做法，就是每周至少定期组织一次，最近一周的故障一起上“故障复盘会”，在上会前，会要求各个责任人提前准备好故障处理报告初稿。这里的故障，主要是指的是影响到系统可用性的故障或重大的风险和隐患，包括基础设施和IT系统的故障，不包括桌面的故障和不影响系统可用性的故障，这里的故障，也不限于重大故障，也包括影响有限的，影响时长较短的故障，甚至是一些风险隐患。

2、团队成员积极参与

在故障复盘过程中，应该鼓励团队成员主动参与。与会人员还应该有足够的广度，足够技术深度，以便在分析故障时能够理解各种数据和工具。

这点非常重要，故障复盘，很多时候不是运维一家的事情，有时候需要将研发，甚至业务方或者产品线一起参与，涉及到厂家的，厂家的参与也是非常重要的。目的是提升参与度，从各个不同的岗位视角分析故障，一起改进。因为IT系统的故障，很多时候和架构、程序本身有关，甚至业务需求有关系，比如有些因为特殊的原因，仓促的上线，首次UAT修改缺陷形成的版本没有很好的回归测试导致的版本质量问题等。

组织会议复盘，当面沟通效率更高、能快速平息故障，解决问题。对于一般故障，也可以在运维小组范围内组织复盘会议。

在故障复盘会上，涉及到重大故障的，管理层的参与和专家的参与也是非常关键的。管理者和专家，因为经验和视野原因，可能会更快更好看到深层次的问题。管理层的参与，对于问题最终的解决，优化改进措施最终落地都是有帮助的。

注意：ITIL使用了LACMT模型：也就是领导者（Leader）、管理者（Administrator）、协调者/沟通者（Coodinator/communicator）、方法和技术专家（Methods and techniques expert）、技术专家（Technical expert），也可以用来参考在事件管理，包括故障复盘中各个参与角色及其职责。

以下是日常如何有效组织故障复盘的几个步骤：

1、回顾，收集故障的信息和数据

作为第一步，回顾故障，需要整理相关故障的信息和数据，可以按照时间线来梳理。这些数据可以来自团队成员、日志记录、监控系统等。在这个过程中，还应该包括有关故障的影响范围以及对用户、客户的影响程度。这里就是前面提到的时间线，从故障发现到处置完毕的整个环节做回顾，包括故障发生、故障发现、响应时间、尝试处置时间、诊断时间、应急预案启动时间、应急恢复时间等，通过时间线，还原整个故障处理行动。

2、分析故障原因

利用收集到的故障信息和数据，团队可以分析这个故障的原因，从根本上确定必须采取哪些措施避免再次发生。包括：

--分析故障发现、定位、恢复过程的问题，定位时间是否可以更短？

--处理过程中可观测可感知能力，异常部分是否有监控？是否有告警？告警是否及时准确？

--收到告警后的响应、处理、分析判断是否及时、准确？

--是否有按照要求进行必要的通报、升级？

--是否有应急预案，以及启动应急预案是否正确？

--应急处理的协同是否有效？

--分析故障对业务的影响？影响到的服务，业务，用户情况。

--对可用性指标的影响？

--故障的根本原因是什么？是否有设计原因？在架构层面是否有脆弱点？

--日常运维保障是否到位？应该做的例行工作（例如巡检）是有按照要求做到位？

--故障是临时解决，还是永久解决？

3、总结及制定解决方案和改进措施

确认大家分析清楚，达成一致意见后，根据分析结果，制定解决方案，并且准备计划执行故障解决措施。

总结本次故障带来的经验教训并达成一致的意见。

这里很重要的工作，就是对故障进行定性、定级、定责（这个要慎重，在坚持原则的基础上，要尽可能充分讨论、分析达成一致，避免异议甚至申诉），要是不涉及到考核和绩效，可以尽快确定下来，反之，涉及到绩效，和外部供应商涉及到商务事宜的，要慎之又慎。关于故障的定级定责，后续再专门写一篇文档来分享。

这里总结一些常见的要点：

--总结对业务的影响、损失、范围；

--业务影响时长，对业务的受影响的程度；

--总结观测和感知方面的问题，涉及到监控告警、发现、响应、定位等过程；

--总结设计问题，包括基础架构、软件架构、产品研发、上线等；

--总结应急处理协同的问题；

--总结定性：包含代码质量、测试质量、流程规范、变更操作、容量规划、产品逻辑、硬件设备、预案失效、原厂故障等等；

--定级：对事件级别的一个正式确定。

--定责：运维、开发、测试、产品团队、第三方厂商等；

--总结改进措施，如何减少和防范类似故障的再次发生？

--如果再次发生，又如何快速发现？是否可以快速解决？哪些活动可以自动化?

--研发和测试环节，是否可以改进，可以提前发现或规避问题？方案是否可以优化？

--软件架构是否可以做得更好？是否有技术债需要消除？如果是有变更控制不严格，还涉及到变更流程的优化改进。

--容量管理是否需要改进？

--是否涉及到安全相关工作的改进？

这里其实可以比较多，因为从ITIL事件管理的活动来说，就涉及到其它大量的ITIL实践，从多个相关的实践总结和改进是完全可能的和必要的：

上面提了一些总结的维度，其实价值流和流程、组织和人员、信息和技术、合作伙伴和供应商也是一个不错的维度，也是一个不错的思考框架：

4、发布故障复盘总结

至关重要的一环是记录措施的确定与结束。故障复盘的记录应该识别在复盘过程中确定或制定的任何措施。这些记录有助于存档，监督并检查系统或服务的改善和稳定性。对于复盘的结果、故障处理报告，需要正式通报利益相关方，包括风控部门、责任部门、业务部门，视故障是否涉及机密，扩大范围让其他人引以为戒。

故障处理报告，也要及时上传到ITSM知识库，纳入到知识库管理。

5、跟进改进措施落地情况

随着解决方案的得出，还应该进行后续跟踪活动，以保证问题彻底消失，并避免其再次产生。这里的除了在例会，下一故障复盘会跟进之外，尽可能考虑在线化，比如是部分需要深入分析的和改进的，纳入问题管理流程来管理，涉及到变更的，及时提交RFC等。

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

上一篇《浅谈在数字化运营服务管理/ITSM的事件管理之“故障复盘”（一）——故障复盘的重要性及总体要求》我们重点谈了故障复盘的必要性和价值。本篇又着重分析了如何高效组织故障复盘，不要浪费每个故障的复盘机会，那么有效的组织就非常重要，包括确定复盘的规则和模板、团队的积极参与，基于时间线对故障整个过程的回顾，深入分析原因和解决方案，定级定责，从各个方面思考改进的机会，一直到达成共识，确定改进措施，并跟进持续改进过程。