首页 » 99链接平台 » 程序员如何快速处理生产事故(故障线上分析服务日志)

程序员如何快速处理生产事故(故障线上分析服务日志)

南宫静远 2024-11-24 01:55:29 0

扫一扫用手机浏览

文章目录 [+]

新手遇到复杂的线上故障,不知道该怎么下手。
对于线上故障,简单的比如从界面或者错误日志就可以直观地看到问题所在,但是有些故障没法直观看出来,比如内存一直在涨,CPU居高不下,遇到这种复杂的故障,通常新手就束手无策了。

高手一般会在实践中总结一套自己解决问题的步骤,遇到问题,会按照解决问题的步骤有条不紊地去分析和解决,步骤如下:

第一步,评估影响范围;

程序员如何快速处理生产事故(故障线上分析服务日志) 99链接平台
(图片来自网络侵删)

第二步,试图重现问题;

第三步,临时方案和终极方案;

第四步,风险评估以及持续优化;

如果我们还记得之前讲过的软件工程师的核心竞争力是什么中提到的,就知道这本质是一种解决问题的能力,一步步分析、解决和预防问题。

新手遇到线上故障,会想着马上修复Bug,但是这种匆忙之间打的补丁,如果没有经过充分的测试,可能会引入新的Bug,甚至更严重的Bug,如果要充分测试,意味着周期更长,线上故障的时间越长,意味着损失越大。

高手遇到线上故障,首先会对故障进行评级,看对用户的影响范围,如果是核心业务,大面积影响用户,当务之急是恢复生产,然后再考虑如何去修复Bug。

恢复生产并不一定要修复Bug,可以用一些临时性的方案,比如说回滚到上一个稳定的版本;重启服务看是否能恢复正常。
当然,在恢复之前,还要尽可能保留当时的日志、故障场景的截图、内存的Dump(当前内存数据保存的静态文件)等信息,用于后续定位故障使用。

所以,遇到线上故障,恢复生产、降低损失是第一要务,修复Bug是其次的。

新手遇到线上故障,不知道如何快速定位到Bug在哪,而高手会通过有效手段,逐步缩小问题范围,直到找到Bug在哪里,最常见手段是重现Bug,有了重现步骤,等于将问题的范围缩小,就很容易发现问题在哪,还有手段就是分析错误日志,通过错误日志直到错误在哪里,所以我们平时注意收集错误日志是非常重要的,还有可以通过缩小问题范围思路来定位,例如Bug是最近一次部署后发现的,并且回滚部署后恢复正常,这就说明问题是两次部署之间的代码变更导致的,可以通过分析变更代码来定位。

像内存泄漏或者CPU高的问题,一般可以通过分析内存Dump文件分析哪些线程占用资源多,线程运行的代码是什么。
排除法也是缩小范围的方法,架构比较复杂时,一个用户请求的操作可能经过多个服务,配合日志可以对一个请求经过的每一个服务进行日志分析,对于正常的服务可以逐一排除直到找到问题的环节,从而缩小问题范围。

新手解决完线上故障后,下次可能还会发生类似故障,而高手对于线上故障,会仔细分析Bug产生的原因,从根本上解决,避免类似的故障再次发生,然后总结复盘,内部交流学习总结分享。

那我们来看看大厂都是如何处理线上故障的。
我们看大厂的故障处理流程,会发现,大厂其实是把高手解决故障的方式变成故障处理的流程和操作手册,并且通过反复地故障演习,来强化流程,让系统更健壮,让新手更容易快速上手,做到高效处理线上故障。

首先,对故障进行评级。

根据故障影响范围,对故障进行评级,从而决定后续的处理方案,例如P0是最严重最紧急的,可能是大面积服务瘫痪,影响大量用户,需要紧急处理;P5可能是用户体验相关的,优先级低

其次,要马上恢复生产,避免进一步损失。

使用临时方案,恢复生产减少损失是第一位的,可以采用部署回滚、服务降级等处理手段。

另外,要分析故障原因,修复故障。

最后,记录故障发生处理全过程,分析故障原因,提出后续改进方案。

那大厂线上处理机制有哪些值得借鉴的地方呢?

故障报警和轮值机制

要做到最快速度处理线上故障,关键就是要让正确的人第一时间就可以去响应,正确的人就是对故障最熟悉的人,通常就是这个服务的开发人员。

实战演习

日常工作中对方案实习演习,去实际测试一下,最著名的就是Netflix的混乱猴子军团, 亚马逊的Chaos Monkey(混乱猴子)的系统就是在工作日期间随机杀死一些服务,制造混乱,来测试生产环境下的稳定性,我们也可以称之为“混沌工程”。

日志记录和分析工具

对于软件,线上出现问题,分析日志记录是最简单有效的定位问题的方式,我们平时开发时要注意对关键日志信息的记录,同时还要搭建像ELK或Splunk这样的日志分析系统,方便查询日志。

例如,一个API请求,出现了随机无法访问的故障,而这个API可能会经过5-10个服务,如何快速去定位是哪个服务出现问题了呢?

一个好的实践是这样的:对于每个请求,都会分配一个唯一的请求编号(requestId),经过每一个服务的时候,都带上这个请求编号,每个服务都把这个请求的输入输出、url参数、http的header、输出的状态码、内容大小、异常信息错误堆栈等记录下来,当出现故障的时候,找到一个有问题的requestId,根据这个requestId去日志分析系统查询相关的所有服务的日志,就能很快看出来哪一个服务返回的结果是有问题的。

当然还有一些其他好的实践,比如新功能上线时灰度发布的策略,通过开关控制让一小部分用户使用,如果出现故障,马上关闭开关,避免影响。

标签:

相关文章