生产上线事故记录--我们该相信什么

一. 起因

我是一个前端，爱吃小熊饼干。当下手里负责的是一个项目的 前端+中间层部分，整个项目涉及到前端，中间层，自动化部署，nginx，java后台等。昨天本来打算上线完了早早下班，结果一直上线到第二天凌晨1点。

二. 经过

初步解决-中间层的问题：

1. 第一次出问题是提示502，我用有权限的账号看了看中间层的日志（非pm2 logs），没有最新的打印信息，之前的打印信息也没有明显报错，猜想可能是中间层的问题。就想让运维看看pm2 list
2. 我不太确认中间层部署在哪台机器上，就把这台日常查看中间层的机器的ip发给了运维
3. 运维不在，等着
4. 运维回来了，有别的项目的人插队
5. 运维看了看pm2 list，发现服务stoped了，我让他restart，结果只要一访问页面，服务就又stoped了
6. 然后我让他重新构建一下中间层的服务，构建好了，502的错误也消失了。

---

终极噩梦-A.初步的自我怀疑（代码和中间层）

7. 干完加班饭以后，继续上线。502 的错误消失了。但是前端页面登录成功以后一直提示
   nullInjectorError：R3InjectorError(e)[e->e->e->e]
8. 显示代码错误，又是生成环境的压缩版本。无法直接定位源码错误，而且 在测试环境没有问题 。加之之前，也出现过类似问题：在测试环境npm run lint 并且打包以后没有问题的代码， 在生成环境自动化部署的时候，构建失败，提示语法错误
9. 所以初步定位这可能是代码错误。没有一点怀疑自动构建的问题。因为 之前自动化构建成功以后，项目100%就部署成功了
10. 在查看中间层日志的时候， 把打印日志的命令写成了打印错误日志 ，看到一直不输出有效日志，还 以为又是中间层的错误
11. 时间不早了，运维该下班 了，和运维要了jenkins账号密码，以及中间层所在的服务器的root密码
12. 由于自动化构建比较慢，前端项目update的话可能需要8-10分钟，depoly的话可能快一些。所以在 尝试了先后把之前各个版本自动部署以后 ，仍然出现 nullInjectorError：R3InjectorError(e)[e->e->e->e] 。处于崩溃的边缘，怀疑可能是nginx问题。 中间还有一个小插曲。我新建了一个新版本， 自动化部署jenkins 那里，突然选择不了版本了。一脸懵逼
13. 操作前端项目无效以后， 又去鼓捣了中间层。把前端项目和中间层的项目都选择了2个月之前的版本，重新构建以后。还是提示 nullInjectorError：R3InjectorError(e)[e->e->e->e] 。

---

终极噩梦-B.怀疑外部原因（nginx和服务器）

14. 此时已经过了8点了，该下班了。项目还没有好， 上面很着急，一会儿来问一下，会儿来问一下 。让我回滚，我说以前都是自动化部署的，我记得 上一个离职的运维，从上上一个离职的运维手里接过来以后， 和我说自动化部署没有备份。都是直接删除，然后新增的。
15. 后来我打算我自己手动部署，但是手里面只有中间层所在的服务器， 还是不知道前端项目实际部署在哪里以及nginx在哪里 。
16. 在自动化部署jenkins的脚本里面看见了一个存储目录， 猜可能是这个目录存储了前端项目。, 在中间层的服务器上，查了查没有这个目录。3脸懵逼。 在查看脚本的时候发现里面有backup这个单词， 猜测可能可能有备份。
17. 然后打电话问了问之前负责该前端项目的大佬，,大佬说可能在另一个部署着xxx项目的机器上面 。
18. 又和运维要了这个新机器的账号密码（这个机器是负载均衡，有2台机器ab，部署2次）。然后又在这个机器下面找了找之前在自动化脚本里面看到的 路径，还是没有找到这个路径 。 中间小插曲，这个机器b的root账号密码一直提示密码失败。后来才知道，需要登录到普通账号然后手动升级。

---

终极噩梦-C. 中场休息

19. 由于没有找到对应的nginx和存储目录。无奈，又考虑是不是代码问题。。。又自动构建了几次。发现页面的文件和自动化构建产生的文件不一样，猜测nginx有缓存。
20. 上面又催了，后台怕接口有问题，一直还没有走。 此时夜里11点了，他们不走，感觉过意不去，毕竟和接口没关系。
21. 我和上面说，先走吧，我回去用远程再看看。

---

终极噩梦-D. 迎来曙光（来自运维的帮助）

22. 回来以后，我构建了2次， 再次确认网页请求的文件和自动化部署产生的文件不一样。 打算先找到项目的文件，手动打包部署
23. 在运维的帮助下，找到了，项目存储在ab机器上的位置。
24. 手动rm -rf *以后，发现确实是项目目录。后来又自动化构建了一次，发现还是提示 nullInjectorError：R3InjectorError(e)[e->e->e->e] ，4脸懵逼
25. 此时要动手手动打包部署了，感觉只剩下只一种可能了。此时夜里12点多了，
26. 在此时，运维提议，<font color=’‘green’"> 回滚一下 。（和之前看见自动化脚本里面的backup的猜测吻合）
27. 回滚以后，正常了，c，终于好了，md。
28. 但是毕竟不是最新版本, 不过现在以后没有后顾之忧了，反正早上不成功，就回滚获取。手动打包部署了2次，最后项目终于正常了
29. 最后打算确认再自动化部署一次， 看看到底是不是自动化部署到服务器存储的问题
30. 后台直接和上面说好了，虽然又想不开心，但是毕竟运维和后台都这么晚了，还没有休息，就先这样吧。凌晨1点。

三. 技术总结

1. 自动化部署到服务器存储这个之前一直没问题，而且页面登录也能成功。这感觉就好像你一直爱慕的女孩子居然是个男人。
2. 代码error呈现是否一定是代码错误。
3. 上线的时候，等项目完全好了以后再离开运维那里。
4. 准备一个docker或者预上线环境
5. 先确保环境是正常的

四. 忆往昔

1 . 事件1-负载均衡和部署2次

1. 想起之前也有一次类似的错误，是另一个项目，上线一直提示代码错误，那是第一次遇见类似的问题，和运维（已离职）要了权限账号，就一直修改代码。最后把代码都撤回去了，还是提示代码错误，最后把代码都删除了，还是提示代码错误。后来发现一会儿刷新 提示代码错误，一会儿提示500 （提示500正常，因为代码都删除了）

2. 后来第二天上午，我问后台是不是nginx有缓存，可是我都清除缓存了，也重启了啊。后台说有负载均衡，有2台机器，需要部署2次。那是我第一次实际体会到什么叫负载均衡。

3. 后来我去问运维，运维说:“哦，是啊，想起来了，要部署2次”，他解释之前上上个离职的运维没和他说这个项目

2 . 事件2- 域名被限制（老太太碰瓷现场）

1. 又想起之前，又另一个项目，又一次上线，就更新了一张图片，然后3分钟不到项目崩了，提示接口各种错误。产品说让我撤回来，我就上了一张图片。。。。。后来发现，接口在浏览器正常，在postman就访问不了。。。后来推论出，是域名出问题了，不符合要求，被阿里限制了。而运维经理在半个月之前已经收到提醒邮件。

五. 生活教训

1. 不要小看每一个平凡人物，也不要高看任何一个所谓的大人物
2. 专业的事情交给专业的人
3. 一直相信的就永远不会出错吗

六. 感谢

1. 感谢运维，后台的帮忙和测试老铁的耐心等待，特别鸣谢运维老铁