乐趣区

运维记一次上线前的紧急定位与修复献上九条小经验

1 简介

本文介绍了作者所在团队在某次上线前测试发现问题、定位问题并修复上线的过程,最后给出几点经验总结,希望对大家有用。

2 过程

(1)今天需要上线,但昨晚才合并了所有分支,时间很紧迫。不幸的是,打包测试后发现有一个 Springboot 应用(模块 R)启动失败,但进程没有死,一直在输出 报错日志

(2)Google了相关的报错日志,并没有找到相关信息。查看了模块 R 的 代码变更 ,并没有什么改动,以为是环境问题;部署到其它环境后,发现问题依旧存在,而且这个问题从未出现过,基本 排除环境问题,问题还是出在代码上。

(3)启动模块 R 上一个版本(现生产环境)的代码,正常启动。所以问题还是出现模块 R 的改动上。

(4)对比 模块 R 的发布包的新版本与生产版本的差异,发现第三方依赖包都一致,但自己项目的依赖包不同。

(5)想到一个有效的办法,依次用生产版本 替换 掉自己项目的包,最终定位了问题出在 通用模块 D 上。

(6)查看模块 D 的 代码变更记录,改动比较大,比较难发现是哪里的改动造成的。

(7)重新 看日志 。为何要重看呢?并不是心血来潮,主要是想找关联。既然已经知道了问题在哪个模块代码上,通过 查看日志与该模块可能相关的信息,或许能找到蛛丝马迹。

(8)果然!!!重新查看日志发现,模块 R 启动时,报了一个其它错误 ErrorA,但被后面不断重复出现的错误 ErrorB 刷掉了,所以一开始并没有注意到它。通过该报错,与模块 D 的代码改动对比。终于定位出了问题!

(9)创建 hotfix 分支,修改代码提交,重新 merge,打包,测试通过,部署生产!!!

因为部署上线是有特定的时间窗口的,如果错过了时间,就要下次再上线,还好及时定位,及时解决!

3 经验总结

(1)不要放过任何日志,特别是报错的日志,日志是极其有用的。不要只看最后面的报错,也不要只看最前面的报错,任何报错都可能提供新的方向和线索。如果日志信息不够,可以尝试打开debug 模式,会有大量的日志信息,当然也要求你有足够强的过滤和整理信息的能力。

(2)提取有用日志,可以用 greptailless 等 linux 命令。

(3)组件化、模块化 很重要,能快速缩小问题范围。能通过只回退某个模块实现部分功能先上线。

(4)善用 对比 工具,如 diff 命令,BeyondCompare软件等。

(5)善用 代码变更记录,这是版本控制给我们带来的好处,可以方便我们对比代码改动了什么,什么时候改的,能加速问题定位;也能及时回退代码。

(6)上线前要做 充分的测试。这次问题的出现项目流程上的原因在于没有进行充分的测试。(1)写代码的人修改了通用模块,却没有测试依赖它的其它模块的功能会不会受影响,而只测试了自己那一部分;(2)合并代码后,没有足够的时间来进行测试。部署前一天,才合并了代码打包测试。所以时间非常紧迫,在短时间要定位问题并解决,容易造成压力。

(7)要有 独立的测试环境。这个是导致方向性错误的原因,经过是这样的:A 同学打包了自己的分支,这时刚好 B 同学稍晚一点也打包了分支,而打包的环境只有一个,B 同学的包覆盖了 A 同学的包。所以在 A 部署的时候,实际用了 B 同学的代码打的包,导致启动失败。所以一直以为是 A 同学代码的问题,这个方向性的错误浪费了很多时间。应该要让每个分支可以同时打包,但不会覆盖。

(8)不要先入为主。不要过早认定某个模块就是有问题的,请参考上一条。

(9)团队作战,分工合作。整个过程全靠团队一起协作才能快速定位并解决;打造一个开放包容、沟通顺畅的团队是多么的重要。

If You Want to Go Fast, Go Alone. If You Want to Go Far, Go Together.

4 最后

运维和问题定位的知识很多,也非常重要,需要持续学习。本文仅讲述了本次过程用到的方法。更多的知识以后慢慢再介绍 …


欢迎关注公众号 <南瓜慢说>,将持续为你更新 …

多读书,多分享;多写作,多整理。

退出移动版