线上故障解决流程解读

最近看了一篇关于线上故障解决的博客很受启发,下面我想根据目前实际工作情况讨论一个解决流程:

发现问题——>定位排除——>回溯

1、发现问题(在此阶段要将线上问题录入JIRA)(从上到下优先级增高)

  • 主动发现:研发运维查看生产环境error日志、例行检查(这个我公司运维人员有无在做不清楚)监控项发现异常。
  • 总对总告警总群:主要发出系统监控的告警群,通常包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常,可能是服务器出现了异常,但是业务还未受到大面积影响。
  • 总对总业务告警群:主要发出业务监控的告警群,通常包括各业务模块的告警如流量兑换失败、流量领取、未中奖等影响业务处理。
  • 生产事件上报:通常业务异常带来的影响传递到用户,用户再反馈到客服、运营,在我公司最后由产品人员统一收尾反馈给研发、运维(近期出现客服问题比较棘手直接由运营反馈给研发、运维进行分析,是否考虑这类问题由运营收口定期收集?),会存在一定时延,所以一旦有生产事件上报,这个时候严重性已经到了最高,技术人员的压力也会增大,因为会有领导的关注,业务的询问和催促,客户人员的焦虑带来的压力。

上述发现只是问题的苗头,所以要进一步确认这次发现是不是线上问题?尤其是对  “生产事件上报” 的线上问题做甄别——是个例、还是成规模?

线上故障解决流程解读_第1张图片

2、故障定位与排除

故障定位:收集信息--假设--验证--尝试

排除故障:原则是确保线上服务快速恢复,不能完全恢复的情况下,确保线上服务尽可能少地受到影响。

线上故障解决流程解读_第2张图片

3、问题回溯

故障回溯的目的是在故障排除后,冷静地回溯整个线上故障的发现/定位/排除过程,找出流程中/架构中/制度中的缺陷,并将该缺陷消灭掉,同时推而广之到其他系统。在‘跳坑’--‘填坑’之后,我们需要通过故障回溯的过程达到‘避坑’的效果,即要保证自己能‘避坑’,也保证团队/公司能够避开类似的坑。

线上故障无小事所以回溯建议以正式的形式进行,每周召开的周例会可以增加线上问题回溯。

 

回溯问题使用材料:问题列表(问题描述、问题提出方、问题解决办法、经验总结)。

 

问题列表提供方?运维、研发、产品、运营。一周一次提供?还是使用JIRA录入(大大小小的问题都要录入是否能够保证都录入?)?

 

转载于:https://www.cnblogs.com/conanwin/p/10370978.html

你可能感兴趣的:(线上故障解决流程解读)