上线项目引发的思考

《上线项目引发的思考》

说在开头的话

鼓励

昨天上线成功,团队里参与上线项目的小伙伴能一起为了上线熬到12点了,都很负责任是第一需要鼓励和支持的,其次是大家上线的状态也是很好的,且每个人很明确自己的分工和要做的事情,这是相对以前要好很多了,很是欣慰,可我主导的公司整个技术方向是:

以高效率为前期,不加班为辅,不将小伙伴变成工作的机器

接下来下面的内容主要以改善为主,精进为辅

改善和反思

虽然有提升,但是还是需要整理昨天发生的一些问题,也是以往一直发生的上线问题,如何反思这个事情,这个情况是正常现象吗(每次上线都要反复调试的现象)?是每次上线都必须熬到12点,甚至更晚,反复调试十几次吗?如果不是,我们应该怎么办呢?

情况描述

从昨天上线情况看,代码和程序更新操作十分不专业,检测环节不标准,调试环节更是存在隐患,首先昨天提到的平台系统没有测试环境,其次开发环境是基于本地开发的,第三测试环境能过,正式环境不能过的问题,从昨天的问题定位是整形溢出,正好测试数据是在最大的临界值附近,这个问题的确在研发过程中是不那么容易发现和确定的问题,第四操作服务器容器的方式仍然存在不规范,第五漏了部分环节的准备,比如说临时很随意的做卡,第六没有测试系统对上线的环境进行一个真实的模拟

存在的问题

这里说的问题不是个人问题,这里的问题是整个团队的,团队需要整理一个相对完善的上线规范及配套的上线调试系统
1. 平台系统没有测试环境
没有测试环境,可以归结成历史遗留问题,需要尽快安排跟上线环境一样的测试环境
2. 代码本地开发
本地开发环境是对代码而言的,据了解是使用phpstudy(这种相对初级的开发环境还是少用吧),这个问题要比上面的问题严重,因为环境检测的不严格,漏洞大多情况就是在这里产生的
3. 测试环境能过,正式发布环境不能过
这个问题按理是不应该出现的,因为部署的测试环境是需要完全模拟线上发布环境的,程序一致,环境一致,不该存在这个问题,如果出现,很可能就是数据不一致的问题引起的,那么最好的情况就是数据采用尽可能真实的数据进行测试
4. 服务器容器操作不规范
为了更方便调试,同事提到了通过服务器scp,我一直主账不给其他人可以访问服务器终端的权限,甚至是容器的权限都最好不给,因为人是会犯错的,这种错一旦在线上产生,错误的效果会演变成灾难,且不说会造成权限和密码泄露,即使是给一个非常谨慎且信任的人去操作,也需要经过各种备份的情况下,才能交出,一定要多提醒自己,切记切记,作为后端运维,最好不要直接让程序员操作服务端,这种犯错的概率太大了,甚至会出现很多意想不到的情况,让人措手不及,删库跑路的事情还是将其扼杀在萌芽中比较好
5. 上线准备环节不充分
这个环节特意拿出来提,是看到很多时候还在考虑测试数据逻辑是否正常,这里需要多花时间去思考的地方,最好的情况是把每个环节都考虑好,每一环的数据怎样才算正常,就类似程序里写断言一样,是有一定规律的,要摸清楚规律,才能把这些做好
6. 测试模拟系统基本上是人为,而非系统和程序
还是缺少一整套的一键模拟系统,虽然有postman进行一个接口调用测试和终端日志查看,但是还是不足,思考思考大型互联网公司上线,该怎样上线?他们的上线方案是否会有隐患?如何杜绝隐患?
7. 缺少一个完完全全的后端、前端、终端的日志系统
这个问题来自于日志查看部分,需要思考一套行之有效,研发能查日志,定位问题,而不用登陆服务器,操作容器的方式,且有权限分配

思考解决问题的方法

针对上面的问题,除了几个需要特别思考的问题外,其他几个解决方案是显而易见的

解决问题的实施方案

实施方案需要每个环节进行部署,充分测试,多准备

定好计划

  • 从目前情况出发,将研发人员的开发环境与线上环境保持一致,尽量采用容器环境
  • 在公司研发部门引导安全意识及建立上线标准,类似开发标准一样,形成文档化
  • 尽快完成CI/CD的部署和部分开发,提高上线效率
  • 配合研发部门完成单元测试、样例测试、黑盒测试等多项测试环节,扩大测试面
  • 打造一套集研发、测试、运维于一体的管理系统,包含日志的调试、权限的分配、测试模拟等功能,尽可能做到能用程序操作的就不要人为操作
点赞

Leave a Reply

Your email address will not be published. Required fields are marked *