前言
本週進行了處於異地內部網絡的JGDQ系統升級，發現了不少的問題，非常值得記錄和改進，有不少東西不去現場實際操作和體驗一下，真的是想不到要改進，趁着這個機會進行一下覆盤，以便日後改進。
結果
- 初步定位和解決之前操作系統無法啓動的問題
- 完成系統升級
- 完成現場測試
- 赴現場1人，實際升級共計4天，其中交通2天，升級1天，測試1天
- 升級準備，共計1人2天
優點
- 在訂機票前及時檢查了大數據行程卡狀態，發現異常，避免退票費用甚至不必要的隔離
- 人員行程異常的情況下，依然完成升級任務
不足
- 在現場升級後發現有一個地物更新的前端入口沒有包含在最終版中，只能現場憑記憶補充該入口
- 在現場更新之前沒有準備好系統更新說明，只能現場編寫
- 地圖證書更新的說明文檔不完善，只能現場聯繫技術人員，解決問題
- 地圖發佈服務的配置文件不完善，只能現場嘗試和調整
- 推演算法升級準備不足，導致現場多次嘗試後解決
- 缺乏升級後檢驗用的標準或測試用例，只能自己憑藉感覺做大體測試
改進事項
- 標準化系統升級準備過程和準備的資料，重大升級或是不熟悉的人員需要在模擬環境中進行模擬升級，，至少包括如下資料
- 升級所用的補丁文件
- 升級操作文檔
- 系統更新說明
- 系統升級所需要的硬件
- 檢驗所需的冒煙測試用例集
- 升級項檢查表
- 標準化系統升級過程，至少包括如下過程：
- 請干係人協調資源和各種批准
- 覈實系統版本和環境
- 備份關鍵數據
- 通知干係人確定時間
- 開始系統升級
- 更改啓動腳本
- 通過冒煙測試用例集驗證是否升級成功
- 請干係人確定
- 在實驗室中建立模擬測試環境，復現並驗證ubuntu+docker compose+不合適的日誌配置是否會造成系統崩潰
- 增加異常數據查詢入口，便於異常數據的檢查和修改
結論
異地內部系統升級確實有很多不可控的因素，需要一系列標準和規範來避免大家頻頻踩坑。當然一個靠譜的干係人是至關重要的。