故障管理：故障应急和故障复盘

故障管理：故障应急和故障复盘

上周咱们分享了故障管理中，应该如何对待故障，怎样作好故障定级和定责方面的管理工做。今天我就和你分享当故障真正发生后，咱们在故障通报和故障复盘方面的实践经验。服务器

故障应急

当故障真实发生后，带来的影响不只仅是技术层面的，更多的是业务层面的，好比用户和商家的批量投诉，交易量下跌，广告资损等等。而这些影响又会产生巨大的外部压力，并传递到技术团队，这时若是没有很好的故障应对机制，技术团队就很容易陷入慌乱，不知所措。网络

咱们可否有效应对这种突发且高压的情况，我以为有两个方面十分关键。架构

第一方面，业务恢复预案。

这也是咱们在故障应急状态下必定要坚守的第一原则：优先恢复业务，而不是定位问题。这就须要咱们事先有充足的预案准备以及故障模拟演练，这就跟咱们前面介绍的各类稳定性保障措施相关，经过稳定性平台的建设，与咱们可以预见到的，以及咱们经历过的故障场景相结合，当发生故障时可以第一时间执行对应的恢复预案。工具

同时，预案的执行不能仅仅在故障发生时才执行，而是应该把故障模拟和恢复演练放在平时。我在团队中常常传递的一个理念就是：凡是没有演练过的预案，都是耍流氓。也就是若是咱们在平常系统稳定的状态下都不敢执行预案，或者执行了没效果，那真到了故障发生后，在更为复杂的情况下，预案100%也是不敢作的，由于这种异常状态下，咱们还要考虑执行了预案是否会致使次生故障。学习

关于故障模拟，能够分为不一样层面来梳理，好比：开发

• IDC层面，如电力切换、UPS切换、核心网络设备切换，单设备故障等，这些故障是能够经过人为破坏进行模拟的，模拟手段相对简单，可是破坏力和影响面会很大，因此作以前必定要准备充分。咱们会按期1~2个月作一次相似的模拟演练，涉及机房配合的，也会提早跟运营商约定好时间；
• 系统层面，如CPU、磁盘IO、网络IO、网络时延、丢包等异常场景，这些都有开源或Linux系统自带的工具支持，好比Stress工具模拟CPU升高，dd模拟磁盘IO，tc模拟网络问题；
• 应用层面，最典型的就是RT升高，抛出异常，返回错误码等等，这里仍是会用Spring的注解功能，在运行时模拟异常情况，而后有针对性地看各类限流降级和开关预案策略可否生
  效。

关于故障模拟，我再次向你推荐Netflix的Chaos Engineering，介绍得很是全面。同步

第二方面，有效的组织协调。

故障发生后的排障和恢复操做，每每须要多个技术团队协做完成，这时就须要有必定的应急机制，来确保相关人员可以快速响应和高效协做。同时，由于对业务形成的影响致使业务团队会承受不少外部压力，这时也须要有统一的口径对外反馈，好比大体缘由（对外不用详细），影响面以及预估恢复时长等等，从而确保信息的透明，避免各类不着边际的猜想对公司信誉形成的影响。团队协作

这时，咱们前面介绍到的技术支持这个角色就起到了很是关键的做用。对内，要有效组织技术团队的集中和协做；对外，负责对接业务部门同步信息，同时屏蔽各方对技术团队和故障处理人员的干扰。监控

出现一个严重故障后，技术支持一般要作以下几个关键事项。配置

• 肯定故障影响面及等级。故障会经过监控、告警、业务反馈或用户商家投诉几个渠道反馈过来，这时技术支持会根据故障定级标准，快速作出初步判断，确认影响面，以及故障等级。
• 组织应急小组。对于没法立刻恢复或仍须要定位排查的故障，会直接将相关技术团队的主管和骨干开发人员召集到一块儿，一般是专用的会议室，并确认故障处理主要指挥者，一般是受影响业务的技术负责人，好比商品出现故障就由商品的技术团队主管指挥排障，交易出现故障就由交易技术团队主管指挥，若是是全站性的故障一般会由技术总监直接介入负责指挥。
• 信息通报。完成上述第一步后，一般会给相关技术和业务团队通报故障初步信息，包括登记、影响面、故障简述以及主要处理团队和责任人。完成第二步，组织起应急小组以后，每隔必定时间，如15~30分钟要对进展作一次信息同步。同时，若是等级和故障信息有变，也要同步出来，直至故障排除，业务恢复。为了保证沟通的顺畅，技术支持并不与处理故障的人员直接沟通，而是经过指挥者沟通，这样确保高效沟通，同时也确保处理故障的人员可以相对地专一在故障处理上，而不是响应来自各方的询问，甚至是质问。

因此，总体总结下来，故障应急过程就是：功夫要下在平时，注意建设各类工具和平台，同时要尽量地考虑和模拟各类故障场景。这就像一支军队在平时必定要作各类军事演习同样，而后就是临场发挥。当故障真正出现时，要有完善的应急机制，立刻可以有效运转起来，而不是慌乱无措。

故障复盘

上面介绍了故障应急，那接下来咱们再看故障管理的下一个阶段，也就是故障发生以后的复盘。

首先，咱们必定要先搞清楚复盘的目的。复盘的目的是为了从故障中学习，找到咱们技术和管理上的不足，而后不断改进。虽然咱们不肯意故障发生，可是从故障中学习，反而是提高团队和员工能力的最佳手段，因此咱们必定要辩证地看待故障这件事情。

同时，切忌将复盘过程和目的搞成追究责任或实施惩罚，这对于团队氛围和员工积极性的打击是很是大的。这一点在前面的内容中已经详细介绍过，这里就再也不重复了。

在复盘过程当中，技术支持仍然要起到关键做用。

• 召集复盘会议。会提早将故障信息发给故障处理的参与方，准备复盘过程当中须要讨论的问题，视状况决定是否邀请业务方人员参会；
• 组织会议流程。协调和控制会议中的讨论，也就是俗称的控场；
• 对故障定级定责。起到相似“法官”的判决做用，根据前面讲到的标准执行；
• 明确后续改进行动及责任人，录入系统并按期跟踪。

复盘会议中，一般会有哪些关键环节呢？

• 第一，故障简单回顾。主要针对故障发生时间点，故障影响面，恢复时长，主要处理人或团队作简要说明。
• 第二，故障处理时间线回顾。技术支持在故障处理过程当中会简要记录处理过程，好比每一个操做的时间点，责任人，操做结果，甚至是中间的沟通和协做过程，好比几点几分给谁打了电话，多长时间上线的等等，这个过程要求客观真实便可。业务恢复后，会发给处理人进行核对和补充。这个时间线的做用很是关键，它能够相对真实地再现整个故障处理过程。
• 第三，针对时间线进行讨论。回顾完上述时间线以后，咱们会提出过程当中存在的疑问，这一点会对主要处理人产生必定的压力，因此必定要保持对事不对人。一般咱们会针对处理时长过长、不合理的环节提出质疑，好比为何告警没有发现问题，而是用户投诉反馈的？为何从发生故障，到有人上线响应拖了很长时间？为何对应的场景没有限流、降级和开关等预案？为何预案执行了没有生效？为何没有作灰度发布和验证等等？经过这些问题和细节的讨论，咱们会找出明显的不足，记录下过程当中的改进点。
• 第四，肯定故障根因。经过讨论细节，咱们对故障根因进行判断，并再次对故障根因的改进措施进行讨论。在这个环节和上个环节中，一般会有不少讨论甚至是争论，技术支持要发挥的做用就是控制好场面，就事论事，必定不要让讨论失控，演变成相互指责和批斗会，一旦有这种苗头，技术支持必定要及时干预并给出警告。
• 第五，故障定级定责。根因肯定后，结合前面已经确认的故障影响面，就能够对故障定级定责了，这里还要依赖前面咱们介绍到的故障标准。不过，定责时，咱们会让责任方团队和相关处理人员在场，小范围告知，这样作主要是考虑责任人的我的感觉。若是无异议，就造成故障完结报告；若是有异议，则能够向上级主管反馈，直至技术团队负责人（CTO或技术VP）为止。
• 第六，发出故障完结报告。故障完结报告的主要内容包括故障详细信息，如时间点、影响面、时间线、根因、责任团队（这里不暴露责任人）、后续改进措施，以及经过本次故障总结出来的共性问题和建议。这样作的主要目的是保证信息透明，同时引觉得戒，指望其它团队也可以查漏补缺，不要犯一样的错误。

按期总结故障案例

除了例行的故障应急和故障复盘，咱们还会按期对一个时期内的故障案例进行总结。好比按照一个季度、半年和整年的周期，这样能够更容易地发现一些共性问题，以便于研发团队在稳定性建设方面的规划。

举个例子，2017年年末，咱们总体总结了整年的故障案例，对P0~P2严重级别的故障进行分类汇总，就发现整年第三方缘由的故障，以及数据类的故障占了很大比例。

咱们再往细节分析，发现第三方缘由的故障，多数是机房IDC的电力、网络切换，单台服务器硬件故障致使的。这些在单次故障复盘时，很容易归因于第三方，可是从整年来看，咱们认为根因上，仍是咱们的系统健壮性不够，在限流降级以及平常的故障模拟演练上，还有很大的提高空间。因此，咱们就拉上研发团队的主管和骨干员工，从新看这些故障，从新制定出稳定性提高的改进措施。

同时，在故障定级定责方面，由第三方缘由致使的故障，后续再也不做为故障根因，而只做为触发因素。因此，在故障复盘时必定要制定出咱们自身须要改进的措施。

针对数据类故障，咱们总结后发现大多集中在“有状态业务”发布过程当中。代码和配置发布能够走发布系统，有完善的流程支持，但数据的变动却更多地依赖人工操做，且流程和周边部件的配合上也不成熟。因此，咱们就明确下来，要加大对有状态业务的发布和数据变动工具的支持，将经验固化下来，而不是靠人。

总结

上述这些经验，同时又能够推广到整个研发团队，在不断总结的过程当中，整个系统的稳定性不断提高，技术架构也不断完善。

到这里，咱们整个故障管理的内容就介绍完了。

总结一下，咱们首先要对故障有一个正确和理性的认识，既不能听任无论，也不要谈之色变；同时咱们也须要科学的管理方式，跟业务结合，制定出对应的故障等级和定级定责制度。

其次，结合咱们前面介绍的稳定性保障体系，在平常要作好各种预案和模拟演练，当故障真实发生时，可以作到冷静处理和高效地组织协调。

最后，在故障复盘中总结出咱们的不足，而后不断地改进。

关于故障管理的内容，你还有哪些问题想和我交流，欢迎你留言讨论。