1、背景目前架构团队负责公司很多核心服务包括商品中心、订单中心、优惠券中心、用户中心、网关等等服务。作为主链路的关键核心服务的稳定性和可靠性直接到影响到用户口碑和体验同时也影响到公司的营收所以线上服务的稳定性和可靠性是每位同学都需要重点关注的事情。当线上服务发生故障我们希望每一个团队或技术同学在应对故障的处理方式上都能做到合理和迅速地止损把业务影响和损失降到最小。那我们该如何做呢怎样才能让我们工作做得更好呢下面详细步骤就是我们要具体做得工作。2、故障反馈用户主动反馈1C端用户反馈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、故障复盘邀请参与人员反馈人、部门负责人、部门相关同事。故障处理过程回顾需要详细的记录下故障发现的时间什么途径发现的用了什么样的排查手段什么样子的处理流程处理过程中几点几分做了什么事情将整个过程都一一的记录下来。故障原因分析需要将团队成员聚在一起进行讨论分析故障发生的原因这里的原因不是指表象的原因需要剖析出问题的根源。故障改进计划针对当前故障要做哪些改进措施应对类似问题如何预防。给出可实施的方案以及时间计划。同时对故障等级进行认定以及团队成员责任的追究和备案但不提倡惩罚。注意复盘后发送邮件给相关部门和同事。随着故障处理流程标准化和规范化希望经过一段时间的积累沉淀一些宝贵的故障数据为系统优化提供参考。同时也希望小伙伴们对生产环境保持敬畏之心并加强故障的处理意识。
1、背景目前架构团队负责公司很多核心服务包括商品中心、订单中心、优惠券中心、用户中心、网关等等服务。作为主链路的关键核心服务的稳定性和可靠性直接到影响到用户口碑和体验同时也影响到公司的营收所以线上服务的稳定性和可靠性是每位同学都需要重点关注的事情。当线上服务发生故障我们希望每一个团队或技术同学在应对故障的处理方式上都能做到合理和迅速地止损把业务影响和损失降到最小。那我们该如何做呢怎样才能让我们工作做得更好呢下面详细步骤就是我们要具体做得工作。2、故障反馈用户主动反馈1C端用户反馈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、故障复盘邀请参与人员反馈人、部门负责人、部门相关同事。故障处理过程回顾需要详细的记录下故障发现的时间什么途径发现的用了什么样的排查手段什么样子的处理流程处理过程中几点几分做了什么事情将整个过程都一一的记录下来。故障原因分析需要将团队成员聚在一起进行讨论分析故障发生的原因这里的原因不是指表象的原因需要剖析出问题的根源。故障改进计划针对当前故障要做哪些改进措施应对类似问题如何预防。给出可实施的方案以及时间计划。同时对故障等级进行认定以及团队成员责任的追究和备案但不提倡惩罚。注意复盘后发送邮件给相关部门和同事。随着故障处理流程标准化和规范化希望经过一段时间的积累沉淀一些宝贵的故障数据为系统优化提供参考。同时也希望小伙伴们对生产环境保持敬畏之心并加强故障的处理意识。
