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

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 最后

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



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

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

原文地址:https://www.cnblogs.com/larrydpk/p/11854639.html

时间: 2024-10-25 18:57:32

【运维】记一次上线前的紧急定位与修复-献上九条小经验的相关文章

MySQL数据库企业级应用实战(Linux运维必学) 套餐上线了。

为了满足广大运维朋友的要求,国内运维界顶尖实战加教育专家老男孩老师亲自主讲的 MySQL数据库企业级应用实战(Linux运维必学)上线了 http://edu.51cto.com/roadmap/view/id-66.html 本套餐一共16套核心DBA课程,祝你掌握运维人员需要掌握的数据库核心重点知识,春节前优惠发布(节后会恢复原价),想掌握DBA的运维伙伴们请抓紧下手,学习课程只是一个连接纽带,选择一个好的优秀的导师,作为自己的前进指路灯,是成就自己的关键. 本课程100%企业实战积累的精华

linux运维面试前,先来检查这些基础知识忘了没?

知乎上有这样一个问题:一个新手面试 Linux 运维工作至少需要知道哪些知识?其中有一个答案对这一话题的解读非常深入,今天特别分享给大家. 一.什么是大型网站运维? 首先明确一下,全文所讲的”运维“是指:大型网站运维,与其它运维的区别还是蛮大的:然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范.知名度.服务器 量级.pv量等考虑,其它因素不是重点:因此,我们先定义服务器规模大于1000台,pv每天至少上亿(至少国内排名前10),如sina.baidu. QQ

[转载]系统运维秘诀大分享专题

系统运维秘诀大分享专题 本专题整合收录了有关系统运维/系统管理员工作和个人成长方面的各种心得分享.经验总结.以及必须牢记的一些准则,适合所有在运维领域有追求的技术人阅读.有些分享的层次比较深,有些则是运维的基础课,但通过翻看他人的心得,相信你总能有所收获. 1 Dormando的系统运维秘诀三部曲... 4 1.1 技术篇... 4 1.1.1 为变化而设计.... 4 1.1.2 使用自动的,可重复的构建过程.... 4 1.1.3 使用冗余.... 4 1.1.4 使用备份.... 5 1.

Linux运维的8个小时工作时间都做什么

跟着运维工程师的工作越来越香,不断增加的人选择它来开端自个的工作生涯.那么你想不想深化了解运维工程师的日子?他们的一天是怎样度过的?小编我就从baidu贴吧.知乎上整理了些运维大小牛们的自述,看看是不是有你的影子? 陈湛翀,从事运维工作在我面试了一些运维职位的同学以后,我觉得在中国很大一部分运维的同学都是每天过着我以下要提到的,我最不喜欢的最典型的一天.我最不喜欢的一天:早上一来到公司,就被一个跑过来的同事打断:他有一个需求.其他的同事在IM.邮件和电话中也分别提出了他们的需求.没办法,只能默默

linux运维文章

运维中关键技术点解剖:1 大量高并发网站的设计方案 :2 高可靠.高可伸缩性网络架构设计:3 网站安全问题,如何避免被黑?4 南北互联问题,动态CDN解决方案:5 海量数据存储架构 一.什么是大型网站运维? 首先明确一下,全文所讲的”运维“是指:大型网站运维,与其它运维的区别还是蛮大的:然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范.知名度.服务器 量级.pv量等考虑,其它因素不是重点:因此,我们先定义服务器规模大于1000台,pv每天至少上亿(至少国内排

运维技术规划

运维中关键技术点解剖:1 大量高并发网站的设计方案 :2 高可靠.高可伸缩性网络架构设计:3 网站安全问题,如何避免被黑?4 南北互联问题,动态CDN解决方案:5 海量数据存储架构 一.什么是大型网站运维? 首先明确一下,全文所讲的”运维“是指:大型网站运维,与其它运维的区别还是蛮大的:然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范.知名度.服务器 量级.pv量等考虑,其它因素不是重点:因此,我们先定义服务器规模大于1000台,pv每天至少上亿(至少国内排

浅谈运维规模化可持续构建实战

如今的互联网时代,运维早已不再是被动的那一方.过去的运维,由于种种限制,工作繁重.复杂,效率低下,很难适应目前互联网产品快速的迭代节奏.而如今,随着虚拟化.容器技术以及持续构建技术的成熟,运维工作的模式有了很大的变化,通过自动化技术的应用使得更少的人为参与,有更高的效率.为了确保项目高质量的快速迭代,必须构建一套高效的可持续构建的运维管理体系. 互联网项目最大的特点是版本迭代节奏快(同一个系统一天上线数次都有可能),需求变化频繁,且每天可能都有项目新增.服务维护.运维架构调整等需求.而常见的运维

运维85条军规

1) 承载能力优先 ——随后再进行优化 —— 不遵守这条规则必定带来故障停机时间.不要在故障停机时间的压力下进行优化——要先集中精力提高承载能力. 2) 以Postgres为例,一定要确保你的每一个网络都能匹配得上你的WAL文件.Slony复制.快照技术以及基于磁盘的DB版本化(快照的衍生品) 3) 不要把问题‘优化’到你的架构之中.为了解决问题而新加进来的一些东西往往后来都会变成运维沉重的负担. 要确保在运维工程化中开发出来的工具交接完整.过后再回头进行进一步的开发往往不灵.更重要的是,变更请

运维工程师的职责和前景

运维工程师的职责和前景 运维中关键技术点解剖:1 大量高并发网站的设计方案 :2 高可靠.高可伸缩性网络架构设计:3 网站安全问题,如何避免被黑?4 南北互联问题,动态CDN解决方案:5 海量数据存储架构 一.什么是大型网站运维?首先明确一下,全文所讲的”运维“是指:大型网站运维,与其它运维的区别还是蛮大的:然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范.知名度.服务器量级.pv量等考虑,其它因素不是重点:因此,我们先定义服务器规模大于1000台,pv每天