记录本周五项目上线失败经验总结

1、背景

本期迭代版本，需要上线同步用户信息功能，根据globalUserId查询出用户信息然后存入到公服数据库表中。触发方式是A系统调用我们B系统接口，然后将A系统用户信息存入到我们B系统公服中。
生产环境总共有两套环境，一个是灰度环境，一个是正式环境。项目上线都是先发灰度环境，一切验证通过，才会继续将代码包发布到正式环境。

2、问题描述

本周五晚上10点项目发版完成，测试进行生产环境验证，发现本次迭代功能未成功上线，紧急向开发质问原因，是否是生产环境系统bug。

3、解决思路

(1)刚开始同事小锋问我是不是生产环境，这是上线漏配了什么配置文件或者定时任务等等。我这边回复是本次迭代不涉及相关配置文件或数据库脚本操作。然后特地去检查了本次上线中自己写的代码逻辑，未发现任何逻辑错误问题。

(2)sit环境和uat环境都是测试通过的，按理说生产环境和uat环境上线后代码都是一致的，不存在这个问题啊，但是就是接口死活调不通，特地去生产环境拉去了最新的接口调用错误日志，分析本次上线代码可能有问题或者上线失败。但是检查了流水线情况，是顺利上线到灰度环境的。

(3)在拉取到最新的生产环境调用日志后，发现本次上线的接口日志没有正确输出，说明本次迭代的接口没有真正被调用！这里就是问题所在和突破点！因此，去慧眼（就是skywalking的封装）系统查询调用链，发现A系统调用我们B系统走的接口在服务器XX，它是正式环境服务器，不是灰度环境服务器，终于找到了上线失败原因！果断切换到正式环境，发现A系统可以正确的调用我们B系统了！至此，上线失败问题解决。

4、总结教训

从此次上线失败事件中，发现我们存在一个误区就是只要上线失败，就肯定是我们自己代码问题（虽然有时候确实这样）。但是既然经过了sit和uat两个环境的测试和检验，代码逻辑应该没啥问题！惯性思维有时候害死人！

如果我们先分析接口调用链路情况，可能就不会再费力的去分析错误日志和代码逻辑了！
有时候遇到问题，需要换种思路去分析，而不是盲目的自我怀疑。

还有就是生产环境出问题，不要慌张，要冷静的分析查找根本原因，如果自己都乱了阵脚，那么很容易陷入思维误区或者事倍功半。