日常解决线上问题:
- 首先会根据问题做简单的判断,然后再看问题在哪,然后具体排查
- 判断依据是功能,考虑一下这个实现这个功能依赖的组件。
- 一般问题分析步骤:
- 首先判断是报错,还是功能失效
- 然后根据功能判断下,可能存在的问题。这类问题如果存在也会对哪些功能有影响
- 比对下类似功能,看是否是一个类问题。如果是一类问题,那么分析这些功能之间的共同点,其实在你选择类似功能验证的时候已经有一个预判
- 如果只是个例,就具体分析。首先捋一下逻辑,分段检测,并逐步缩小问题范围
- BS架构首先看http报文,判断是前端还是后端问题
- 判断DB是否可访问,中间件是否可以访问
- 根据service接口方法在链路系统中查看是否有报错,或者查看后端的日志是否有报错。如可以还原问题现场(原来有类似的系统支撑,或用测试账号测试一下)查看日志或者调用链路,一般情况既然功能有问题,都有点蛛丝马迹
- 如果系统不反应,没有日志,请求也超时。那么就需要分析是否系统超负荷负载
- 如果是分布式微服务架构风格,微服务多的情况下,一般都有监控报警系统,查看邮件或者短信是否收到报警信息,如果么有类似系统,只能去服务器一台一台机器查看了。当然如果你的服务比较小,就几台机器,一台一台查看也比较快。
- 对单台服务器无非是CPU不够用,内存不够,磁盘满了,线程阻塞(死锁),当然也需要判断网络是否通着。这些都是操作层面的东西,只有定位到这几类中才可以继续往下核查
- CPU,内存,线程死锁 一般表现问题功能慢,超时
- 磁盘满了,会影响日志的打印,上传文件,表现出来的是报错,而不是超时
- 网络问题则更为直接,请求过不去,直接失败
- 具体技术下面在进行分类和介绍,线上问题首先是解决保证可运行,然后才是考虑优化,包括不限于硬件升级,架构调整,JVM调优,维护策略等
- 比如业务说上传文件有问题
- 首先确定是报错,还是慢
- BS架构的话看看是接口报错,http报文,判断是否报错,判断前端还是后端问题
- 比对其他类似功能是否OK,如有问题大概率是共同依赖的FS(文件系统)出了问题,或者服务器磁盘满了,无法生成中间临时文件等
- 如果是慢,测试下本地网络看看是不是慢;如果可以重现,根据日志看看慢在哪
- 如果服务器操作明显感觉卡顿,就有必要看看当前机器cpu,内存,磁盘
- 如果都没问题,看看日志是否打印和在某个地方卡顿
- 如果日志没用打印就需要进行线程分析
- 线程被阻塞,先根据功能分析卡顿在何处,卡顿一般都是需要等待阻塞而不是平白无故停在某个地方,如果代码分析不清楚就需要进行线程分析了
- 首先判断javaweb服务进程是否cpu,内存占比高,还是被其他进程影响
- 如果是自己问题,就需要打印线程栈,分析线程的阻塞情况;同时也需要注意是否GC导致的问题,如果是GC问题顶多是很慢,不是一直卡顿;如果资源禁止导致阻塞等待,就需要分析是否这个资源需要扩容