运维标准化实践

运维标准化实践

现状

运维负责的事项有如下:

  • 维护现网机器运行状态
  • 接收上线单,完成应用上线
  • 对上线脚本进行审核

问题如下:

  • 没有办法对软件提供服务工程提供保证,也就是对外无法承诺时间,对内无法有效的反馈提升软件质量
  • 没有统一的资产管理平台,所有的资产均是通过excel交接
  • 对于流量等缺乏管控工具,无法提供可靠的无感升级以及可能存在的升级致使的事务中断,尤其涉及金融业务

对策

  1. 首先将零散的服务器资产的表格进行汇总,然后建设运维部门的统一管控平台
  2. 对资产进行标准化编号,避免需要运维人员去主动起名字,防止不同运维人员起名不统一
  3. 替换网关,由原来nginx替换为openresty+lua方案,用以解决优雅降级+流量切换
  4. 继续迭代原有账号服务,用来打通网关服务

最终实现效果

运维需要对流量进行控制,包括不限于

  • 能标记具体用户,要控制用户(包括不限于可能的真实环境测试账号)进入的服务器
  • 基于流量控制,能完成优雅降级和无感应用升级

将升级变成流量切换,时间短且可控
部署全部自动化

翻新系统实践

翻新系统实践

基本情况

  • freemark+jsp+java14的怪异组合
  • 有部分内部接口采用feign
  • 大部分接口采用nacos作为profile管理以及服务注册发现
  • 前端部分仅使用了以jquery和easyui为主的插件,工程化程度不高

需求说明

来自于上线时候的苦恼,每次更新代码总会引发未在版本规划内的前端代码提交,且升级时间较长,失败回滚时候还有cache问题

问题分析

  1. 交互代码和逻辑代码均由同一个开发人员完成,此时心智负担较大,在工期较为短的时候,非常容易造成误操作,且只有上线后才能发现
  2. 系统经历了十年左右的开发,每个开发人员有不同的技术栈喜好,例如早期约定使用Spring Cloud的早期版本,而在五年后发现Spring Cloud很多功能又要二次开发,转向了nacos为主的国产。成员变换中不习惯,有部分接口就干脆采取域名+Nginx网关直连的形式
  3. 除此之外业务系统的拧巴逻辑也是翻新的重大障碍

方案选择

经过和开发小组成员讨论,建议先从增量做起,避开旧有尚能完备运行的业务,其中最简单的是需要抽出一个专门的开发人力,进行前端框架的搭建。(目前使用vue2,开发人员易于招聘)

框架需要完成以下几个事项:

  1. 要替换掉原来依靠服务器进行状态管理的现状,将状态管理放在前端
  2. 要将功能路由管理放在前端框架进行管理
  3. 要维护一个列表,标记哪些路由是用于直接走原来的逻辑,哪些路由是新增的有前端管理的逻辑
  4. 需要后端软件新增接口用以维护新旧软件的状态(一次性开发成本)

在前端框架开发完成一个月后,选取更新频率最低的应用作为试点应用,避免与正在开发的任务同时进行

当前后端代码可以剥离完毕后,在考虑后端的技术栈提纯,不应将改造任务混杂

一些结局

  1. 成功改造了从外包厂商回收的代码
  2. 在重要业务中,成功替换了进门抬杆页面的代码
  3. 为后续的业务不中断升级铺平道路