前言
本周进行了处于异地内部网络的JGDQ系统升级,发现了不少的问题,非常值得记录和改进,有不少东西不去现场实际操作和体验一下,真的是想不到要改进,趁着这个机会进行一下复盘,以便日后改进。
结果
- 初步定位和解决之前操作系统无法启动的问题
- 完成系统升级
- 完成现场测试
- 赴现场1人,实际升级共计4天,其中交通2天,升级1天,测试1天
- 升级准备,共计1人2天
优点
- 在订机票前及时检查了大数据行程卡状态,发现异常,避免退票费用甚至不必要的隔离
- 人员行程异常的情况下,依然完成升级任务
不足
- 在现场升级后发现有一个地物更新的前端入口没有包含在最终版中,只能现场凭记忆补充该入口
- 在现场更新之前没有准备好系统更新说明,只能现场编写
- 地图证书更新的说明文档不完善,只能现场联系技术人员,解决问题
- 地图发布服务的配置文件不完善,只能现场尝试和调整
- 推演算法升级准备不足,导致现场多次尝试后解决
- 缺乏升级后检验用的标准或测试用例,只能自己凭借感觉做大体测试
改进事项
- 标准化系统升级准备过程和准备的资料,重大升级或是不熟悉的人员需要在模拟环境中进行模拟升级,,至少包括如下资料
- 升级所用的补丁文件
- 升级操作文档
- 系统更新说明
- 系统升级所需要的硬件
- 检验所需的冒烟测试用例集
- 升级项检查表
- 标准化系统升级过程,至少包括如下过程:
- 请干系人协调资源和各种批准
- 核实系统版本和环境
- 备份关键数据
- 通知干系人确定时间
- 开始系统升级
- 更改启动脚本
- 通过冒烟测试用例集验证是否升级成功
- 请干系人确定
- 在实验室中建立模拟测试环境,复现并验证ubuntu+docker compose+不合适的日志配置是否会造成系统崩溃
- 增加异常数据查询入口,便于异常数据的检查和修改
结论
异地内部系统升级确实有很多不可控的因素,需要一系列标准和规范来避免大家频频踩坑。当然一个靠谱的干系人是至关重要的。