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

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）提取有用日志，能够用grep、tail、less等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 最后

运维和问题定位的知识不少，也很是重要，须要持续学习。本文仅讲述了本次过程用到的方法。更多的知识之后慢慢再介绍...

---

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

多读书，多分享；多写做，多整理。