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