故障处理流程和规范

1、背景

目前架构团队负责公司很多核心服务，包括商品中心、订单中心、优惠券中心、用户中心、网关等等服务。作为主链路的关键核心，服务的稳定性和可靠性直接到影响到用户口碑和体验，同时也影响到公司的营收，所以线上服务的稳定性和可靠性是每位同学都需要重点关注的事情。

当线上服务发生故障，我们希望每一个团队或技术同学在应对故障的处理方式上，都能做到合理和迅速地止损，把业务影响和损失降到最小。那我们该如何做呢？怎样才能让我们工作做得更好呢？下面详细步骤就是我们要具体做得工作。

2、故障反馈

• 用户主动反馈

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

• 服务负责部门自行发现

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

3、故障确认

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

• 确定问题边界
  根据反馈信息，快速判断问题归属。
  1）若是使用问题，直接通知反馈方。
  2）若是服务问题，协调对应服务负责人一起排查。

4、确定故障主导人

• 如何确定故障主导人
  1）如果问题只涉及一个服务，那么服务负责人就是故障主导人。
  2）如果问题涉及多个服务，那么由相关服务负责人协商并快速确定一个故障主导人。
  如果协商无果，则往上报，由上级直接指定一个故障主导人。（原则上不允许出现这种情况）
• 故障主导人的作用
  1）协调相关人员排查并处理故障
  2）及时跟踪汇总故障处理进度
  3）及时同步故障处理进度

确定故障主导人后，需同步出来
故障主导人：XXX
相关处理人：XXX、XXX、XXX
预计完成时间：
紧急处理方案：

5、故障分析

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

• 根据SLS日志分析

根据反馈信息，快速排查日志并分析定位问题。
注：可先根据提供的信息找到trace_id，然后通过trace_id找到该请求相关的所有日志。

• 根据监控指标分析

包含ARMS、AHAS、数据库、Redis、MQ、ES等维度的监控分析。
具体指标见 日常巡检计划 中的巡检指标说明。

6、故障处理进度同步

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

• 同步格式

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

• 同步机制

每隔30分钟同步一次。
注：故障恢复后务必通知反馈方，告知问题已解决。

7、故障恢复

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

• 服务回滚

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

• 重启

部分问题可以通过重启的手段来临时恢复，以保障系统的暂时可用，但后续还需有其他方法彻底解决问题。（如pod日志太多导致磁盘告警就可通过重启来临时处理）

• 紧急更新

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

• 限流和降级

通过将部分非核心服务或接口进行降级和限流处理，来避免核心业务受到影响。

8、故障报告

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

• 故障报告格式

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

9、故障复盘

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

• 故障处理过程回顾

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

• 故障原因分析

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

• 故障改进计划

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

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