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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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