[技术]排查线上问题
简介
产品交付后对于项目管理人员往往就是工作接近尾声,但是对于一线开发和运维的小伙伴,那是维护工作的起点.
线上问题对于程序员来说其实就是生产环境中遇到的问题总称,优先级对于开发同学和运维同学来说是最高级别.当一位工程师遇到线上问题,一般都会放下手头的工作,优先全力解决线上问题.
往往系统运维工作和线上环境问题的解决会花费更高的人员成本.左耳朵耗子(https://www.coolshell.cn/)曾经说过,互联网产品拼的就是运维工作.
那么面对和处理各种各样的线上问题,是程序员和运维工程师的必修课.它不仅仅是一项纯技术操作,它还考察了开发或者运维的判断问题的能力以及决策解决方案的能力.
线上问题大致分为以下几大类:
- 用户操作问题
- 环境同步的问题
- 业务代码问题
- 线上系统性能问题
对于线上问题的解决步骤,个人认为大致分为四个步骤:
- 了解问题
- 定位问题原因
- 提出解决方案并实施
- 问题回溯反思
完成以上四个步骤之前一定切记:优先最快速的恢复线上服务.
了解问题
线上问题的反馈来源分为两种:主动发现,被动通知
- 主动发现包含开发或者运维同学查看日志报错,监控系统通知系统异常,业务监控系统通知业务异常.
- 被动通知一般就是指客户或者客服进行问题反馈.
获取了问题信息后,先要对问题进行简单的分析,它是属于线上问题分类中的哪一类,例如:用户反馈说账号登录不上去了?我们可以使用内部账号进行登录测试,
如果没有问题,就可以考虑是不是用户操作问题.
如果内部账号也登陆不了,我们可以考虑是不是大面积用户登录不了,还是个别账号问题.
如果是大面积登录不了,就可以考虑是业务代码出现问题或者底层服务(数据库)环境同步有问题,
从而把问题进行分类.
在分类的同时,我们已经在做了第二步的操作:定位问题原因.
- 对于用户操作的问题,我们可以先进行简单的教学,让用户学会使用系统,同时对于后期减少这类问题的产生,我们可以考虑完善用户手册.
- 对于环境问题,我们就要协调运维同学协作解决同步问题.
- 对于业务代码问题,就要找到相应的开发同学进行问题的日志跟踪和分析,解决代码业务错误,并快速上线.
- 对于性能问题就需要经验丰富的开发同学和运维同学一起对架构,环境,系统进行大致梳理,从而提出更好的架构方案和系统部署方案.
定位问题原因
定位问题是一个怀疑自己或者团队,然后又否定怀疑的过程.
定位一般怀疑的目标有以下几种:
- 线上版本代码变动
- 线上环境配置变动
- 线上数据库表结构变动
- 第三方服务出现问题
- 系统用户量激增
- 服务器网络出现故障
- 服务器遭受攻击
- 服务器系统故障
- 以前未知的bug被发现
- 应用(web服务)本身出现性能问题
- 应用本身版本兼容问题
- 数据库等第三方中间件出现使用问题
接下来我们就要针对上述的怀疑目标提供强有力的证据.
- 询问项目部署同学是否有做过相关问题的部署升级工作
- 配置同学是不是做过线上环境的配置修改
- 询问dba是不是做过表结构变更,是不是没有同步最新的表结构到生产环境
- 查看第三方系统监控或者尝试调用第三方服务.如果是外部三方服务提供商,就需要im或者电话进行询问(例如:短信服务商).
- 查看当前系统调用的频次
- 检查网络是否正常,对于云服务可能要询问相关客服
- 查看服务器登录是否正常(主要是测试服务器是否可用)
- 查看web服务的相关性能信息(对于常见Javaweb服务,查看内存使用情况,查看线程运行状况,查看GC回收情况)
- 查看版本更新业务代码兼容情况,询问相关业务开发人员
- 通知第三方中间件管理员查看监控和日志
上面只是大致罗列了可能产生问题的原因.
很多线上问题有可能是上面几个因素共同导致的,开发和运维同学也只能通过自己的经验进行更多信息的收集,产生怀疑然后分析出问题的原因.
这个过程其实会调动到多方资源,也是一个考察团队协作和沟通的能力.问题定位出来后,就会进入下一步解决方案的制定和执行.
提出解决方案并实施
其实问题的解决和实施在整个线上问题的处理流程中相对第二步较为简单,针对上面的几个问题产生的原因也有相对粗糙的操作方案.解决方案的提出和实施目的是尽可能保证生产环境基本可用.完美修复线上问题是一个需要持续投入人力和精力的工作.
针对如下的问题产生的原因
- 线上版本代码变动
- 线上环境配置变动
- 线上数据库表结构变动
- 第三方服务出现问题
- 系统用户量激增
- 服务器网络出现故障
- 服务器遭受攻击
- 服务器系统故障
- 以前未知的bug被发现
- 应用(web服务)本身出现性能问题
- 应用本身版本兼容问题
- 数据库等第三方中间件出现使用问题
大致的解决方案如下:
- 代码版本的变动,采用回滚的方式进行解决
- 配置变动采用恢复原有配置
- 表结构需要dba和开发人员共同更新或者回滚
- 第三方服务可以使用备选服务或者采用服务降级暂停使用
- 用户量激增导致服务压力过大,可以采用水平扩容的方式应对(前提是系统支持水平扩容)
- 服务器网络出现故障只能等待运维或者第三方云服务厂商解决
- 遭受攻击需要对攻击方式进行分类,如果是业务调用攻击,例如刷短信,可以采用频次控制等方式.如果是ddos攻击,可以考虑采购高防服务器.
- 服务器系统故障 例如磁盘空间不足,有限考虑删除无用日志,然后考虑硬件扩容.内存不足考虑硬件升级或者进行进程迁移.
- 未知bug 需要调用开发资源进行代码修复并快速上线
- 应用性能问题需要针对应用特点考虑硬件扩容,系统参数调整或代码优化
- 兼容性问题需要通过代码修复和快速上线
- 数据库等第三方中间件使用问题需要通过查看日志,分析错误日志从而找到相应的解决方案.
线上问题的解决还是讲究一个”快”字,减少线上服务的停机时间,从而提高用户的满意度,当线上核心业务流程受到影响时,要优先保证核心业务的可用.尽可能的满足用户的基本使用需求.
问题回溯反思
问题回溯是指在解决线上问题之后,对于平时开发流程和线上问题定位解决流程的反思,通过反思整个处理问题的过程,找出在处理问题流程中的不足,找出导致问题的原因,进而优化团队的开发模式和找出更适合自己团队的线上问题处理流程.例如:对于团队的开发同学的代码提出一些指导建议,对于运维中遇到的部署问题制定更详细的部署手册或者引入自动化部署,减少人工错误等等.
回溯的目的是为了提高团队的协作效率和工作质量,而不是为了批评或者指责导致线上问题的同学.另一方面也是积累经验,形成文档为大家提供学习素材,减少以后线上问题的产生.
总之,线上问题依然是开发和运维同学不可避免的”噩梦”,祝大家早日从梦中醒来.
--业务运维的痛点。。。
来自notalk.cc博客
-EOF-
