故障处理流程和规范

白云coy

已于 2023-04-20 11:11:00 修改

阅读量6.1k

点赞数

分类专栏：研发流程系列文章标签：运维大数据数据库

于 2020-12-14 20:16:11 首次发布

本文链接：https://blog.csdn.net/icansoicrazy/article/details/111184483

版权

研发流程系列专栏收录该内容

3 篇文章 0 订阅

订阅专栏

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 (需确定任务、执行人、执行时间)