故障处理流程与规范

故障反馈

用户主动反馈

1. C端用户反馈
2. 产品反馈
3. 业务反馈

服务负责部门自行发现

1. 系统报警发现异常
2. 服务日常巡检发现异常

故障确认

不管是收到报警信息，还是收到业务用户反馈，我们都需要进一步确认并验证服务或功能是否正常，确认问题的同时通知反馈方我们正在跟踪处理，让反馈方放心。

确定问题边界 根据反馈信息，快速判断问题归属。

1. 若是使用问题，直接通知反馈方。
2. 若是服务问题，协调对应服务负责人一起排查。

确定故障主导人

如何确定故障主导人

1. 如果问题只涉及一个服务，那么服务负责人就是故障主导人。
2. 如果问题涉及多个服务，那么由相关服务负责人协商并快速确定一个故障主导人。如果协商无果，则往上报，由上级直接指定一个故障主导人。（原则上不允许出现这种情况）

故障主导人的作用

1. 协调相关人员排查并处理故障
2. 及时跟踪汇总故障处理进度
3. 及时同步故障处理进度 确定故障主导人后，需同步出来 故障主导人：XXX 相关处理人：XXX、XXX、XXX 预计完成时间： 紧急处理方案：

故障分析

可根据经验来快速判断，若不能快速判断问题所在，则可结合日志和监控来分析。

故障处理进度同步

确认故障后，若故障非常严重，由故障主导人建立企业微信群，把相关负责人和小伙伴都加入进来，同时告知反馈方当前情况及解决预案或方案，让反馈方有心理准备，预留 buffer 时间做好应对措施。如果不能及时解决，不要等待或死磕问题，请迅速联系其他同事或者把问题上升来寻求支持和帮助。

同步格式

@相关人员
故障主导人：XXX
相关处理人：XXX、XXX、XXX
预计完成时间：2020-12-10 20:00:00
紧急处理方案：如回滚/重启/紧急更新等。核心是必须要在最短时间内快速修复问题。
后续优化方案：提供彻底优化方案。
后续优化时间：xxxx-xx-xx xx:xx:xx

注：故障恢复后务必通知反馈方，告知问题已解决。

故障恢复

确认故障后，首先要做的就是恢复故障，常用手段如下：

服务回滚

如果属于发版更新的代码BUG导致的问题，一般可通过回滚到上一个程序版本来迅速恢复。

重启

部分问题可以通过重启的手段来临时恢复，以保障系统的暂时可用，但后续还需有其他方法彻底解决问题。

紧急更新

在明确问题所在后，迅速修复代码，然后快速更新上线。比较依赖故障处理人技术和代码逻辑、应急处理能力。 紧急修复代码的情况下，需找一个人进行review代码，避免急而导致新的问题。

故障报告

首先要明确，并不是所有故障都需要写故障报告。如果能快速恢复且影响很小，就不用写。

故障报告格式

故障标题：YYYYMMDD-xxx操作引起xxx服务不可用
故障发生时间：
故障报告时间：
故障恢复时间：
故障持续时间：
故障影响范围：
故障等级：P0/P1/P2/… PN
故障处理人：xxx、xxx、xxx
故障责任人：xxx
故障描述：xxx
故障处理过程：xxx
故障原因分析：xxx
故障总结：xxx
后续改进：xxx (需确定任务、执行人、执行时间)

故障复盘

邀请参与人员：反馈人、部门负责人、部门相关同事。

故障处理过程回顾

需要详细的记录下故障发现的时间，什么途径发现的，用了什么样的排查手段，什么样子的处理流程，处理过程中，几点几分做了什么事情，将整个过程都一一的记录下来。

故障原因分析

需要将团队成员聚在一起，进行讨论，分析故障发生的原因，这里的原因不是指表象的原因，需要剖析出问题的根源。

故障改进计划

针对当前故障要做哪些改进措施，应对类似问题，如何预防。给出可实施的方案以及时间计划。同时对故障等级进行认定，以及团队成员责任的追究和备案（但不提倡惩罚）。 注意：复盘后，发送邮件给相关部门和同事。

随着故障处理流程标准化和规范化，希望经过一段时间的积累，沉淀一些宝贵的故障数据，为系统优化提供参考。同时也希望小伙伴们对生产环境保持敬畏之心，并加强故障的处理意识。

参考

内网总结