经历几次的迭代发版，整体给人的感觉就是累，并且还会时不时地出现莫名其妙的问题，这里暂且不说发版的具体需要哪些流程，只讲述一下推送新版本至产线后为何会出现一些莫名其秒的现象，比如服务无法访问、数据库访问异常等等一系列问题。这些问题可能永远在本地、测试、UAT环境中无法复线，而一到产线环境就很有可能出现，这里说说个人的一些想法：
（1）第一点，网络环境不一致：规划工作者没有很好地意识到产线环境和本地环境、测试环境的差异性，比如说请求头信息，它们可能在本地环境、测试环境以及UAT环境中没有做要求，而在产线环境却是需要这些请求头信息的，这样的潜在隐患就是中转服务方可能没有透传请求头信息，导致某些服务在中转时就失败了。面对这种问题，只能是修改代码、重新部署了。
（2）第二点，资源配置不一致：某些资源配置在本地环境、测试环境、UAT环境和产线环境中不一致，比如说某种身份认证的地址配置情况，若在产线配置成了测试环境的地址，这样的话身份认证会一直通不过；不过面对这种情况还好，我们可以通过配置中心进行修改，重启服务就可以了。
（3）第三点，数据库配置不一致：先说说数据库配置不一致的情况会有哪些场景，一种是用户权限不够；二是不同的数据库部署在不同的服务器上；
针对第一种情况，可以让DBA给用户添加权限，可以暂时这样处理，不过后续还是要调整一下流程和恢复临时规避风险的配置。
针对第二种情况，场景是这样的：在本地、测试和UAT环境中所有的数据库都是配置在同一个服务器上的，而在产线环境中不同的数据库配置在不同的服务器上；可能会出现这样的操作：在非产线环境中同一个账号去访问同一个服务器上所有的数据库是正常的，但是在产线环境中同一个账号去访问一个服务器上不存在的数据库时就会抛出异常了，这种情况算是比较严重了，要么重新发版，要么就创建一些空的数据库，这样的话就没有数据可查了。
小结：上述三点情况，只要首次发生，就应该立即修复，后续就不应该再发生了，必须将它扼杀在摇篮中，不能重见光明。只有这样，后续发版才很顺畅，不至于反反复复定位问题，结果又是之前犯下的错误。不希望再听到“呀，忘记了”之类的话。只要严控流程、规范作业、统一资源，这样就能过避免一些重复问题的发生。若是后续发版还出现类似的问题，那很大程度上是管理上的失责，灌宣不到位、落实不到实处、纠正不及时。