为何每次发版这么多挫折呢
经历几次的迭代发版,整体给人的感觉就是累,并且还会时不时地出现莫名其妙的问题,这里暂且不说发版的具体需要哪些流程,只讲述一下推送新版本至产线后为何会出现一些莫名其秒的现象,比如服务无法访问、数据库访问异常等等一系列问题。这些问题可能永远在本地、测试、UAT环境中无法复线,而一到产线环境就很有可能出现,这里说说个人的一些想法:
(1)第一点,网络环境不一致:规划工作者没有很好地意识到产线环境和本地环境、测试环境的差异性,比如说请求头信息,它们可能在本地环境、测试环境以及UAT环境中没有做要求,而在产线环境却是需要这些请求头信息的,这样的潜在隐患就是中转服务方可能没有透传请求头信息,导致某些服务在中转时就失败了。面对这种问题,只能是修改代码、重新部署了。
(2)第二点,资源配置不一致:某些资源配置在本地环境、测试环境、UAT环境和产线环境中不一致,比如说某种身份认证的地址配置情况,若在产线配置成了测试环境的地址,这样的话身份认证会一直通不过;不过面对这种情况还好,我们可以通过配置中心进行修改,重启服务就可以了。
(3)第三点,数据库配置不一致:先说说数据库配置不一致的情况会有哪些场景,一种是用户权限不够;二是不同的数据库部署在不同的服务器上;
针对第一种情况,可以让DBA给用户添加权限,可以暂时这样处理,不过后续还是要调整一下流程和恢复临时规避风险的配置。
针对第二种情况,场景是这样的:在本地、测试和UAT环境中所有的数据库都是配置在同一个服务器上的,而在产线环境中不同的数据库配置在不同的服务器上;可能会出现这样的操作:在非产线环境中同一个账号去访问同一个服务器上所有的数据库是正常的,但是在产线环境中同一个账号去访问一个服务器上不存在的数据库时就会抛出异常了,这种情况算是比较严重了,要么重新发版,要么就创建一些空的数据库,这样的话就没有数据可查了。
小结:上述三点情况,只要首次发生,就应该立即修复,后续就不应该再发生了,必须将它扼杀在摇篮中,不能重见光明。只有这样,后续发版才很顺畅,不至于反反复复定位问题,结果又是之前犯下的错误。不希望再听到“呀,忘记了”之类的话。只要严控流程、规范作业、统一资源,这样就能过避免一些重复问题的发生。若是后续发版还出现类似的问题,那很大程度上是管理上的失责,灌宣不到位、落实不到实处、纠正不及时。
相关文章
- 为何选择iText?java PDF开源库选择与iText发展历史
- 为何ChatGPT一出现让巨头们都坐不住?
- AI绘画,为何听不懂人话?
- MySQL:究竟为何?(mysql全是问号)
- 隐身飞机的奇怪设计:明明材料最强为何弃之不用?
- “拉达”级潜艇为何需要千呼万唤才出来?
- 有了三峡工程,为何长江防汛还这么紧张?专家释疑
- 今年北方沙尘天气为何频率这么高?
- 韩国年轻人为何热衷考公?
- “实习第三周就被侵犯” 职场女性为何这么难?
- 北大教授:研究23年,为何我不好意思说自己“搞机器人”?
- 从渡鸦科技发布 Raven H-1,看虚拟助手为何纷纷开始做硬件
- 和专车司机聊天:为何专车比出租服务好?
- 《环球时报》:阿里再遭舆论海啸 为何会有这般发酵力?
- 更有用为何SQL Server更有效率?(为啥sqlserver)
- 文件为何Redis需要创建配置文件(为啥redis要写配置)
- Oracle 为何久负大众羽翼之恩(Oracle为什么不开源)
- 究竟是为什么Redis为何越慢越缓(redis越来越慢)
- Oracle JDK版权为何重要(oracle jdk版权)
- 2021两会盘点 | 老年群体、器械审批、癌症防治,这些医疗关键词为何被频频提及?
- 大批量深度学习为何泛化效果差?西北大学联合英特尔给出了答案 | ICLR 2017
- 为何XML对Web服务很重要