系统用了一段时间，要加功能、修问题、打补丁，都涉及升级。升级这件事本身不难，难的是怎么让业务不被打断，以及万一升出问题怎么退回来。
很多团队把升级当成技术操作，发个通知说今晚要停两小时，然后就动手。这种做法的风险在于，一旦超时或者升出问题，第二天上班业务就停摆。
一、升级前先评估改动范围
不是所有升级的风险都一样。改一个按钮文字和改一张表的结构，风险差几十倍。
可以按三类分。第一类是界面和文案调整，不动数据，风险最低，随版本走就行。第二类是新增功能模块，动了代码但不动已有数据结构，风险中等，需要回归测试已有功能。第三类是修改数据库结构，比如加字段、改字段类型、拆表，这类风险最高，因为一旦出错往往涉及数据本身。
评估清楚属于哪一类，才能定升级方案。第三类必须准备回退方案，前两类多数时候不用停机。
二、时间窗口要按业务低谷来定
选时间窗口有个基本原则，找业务量最小的时段，而不是找开发方方便的时间。
大多数办公系统，业务低谷在晚上和周末。但要注意例外。有的系统白天用得少晚上忙，比如涉及夜间作业的调度系统。有的系统月末周末反而最忙，比如涉及报表和结算的。这种要跟业务方确认清楚再定。
窗口长度要留足。按测试环境的实测耗时乘以两倍来安排，不要按乐观估计。升级没做完时间就到了，会面临一个很难受的选择，是让业务先等着，还是强行中断回退。留足时间就是为了避免这个选择。
通知也要提前发。至少提前一天告知使用部门，写清停多长时间、影响哪些功能、期间有什么应急办法。临时通知会让业务部门措手不及，也容易引发抱怨。
三、升级必须能退回上一版
回退能力是升级方案里最重要的部分，没有之一。
程序层面的回退比较简单，保留上一版本的程序包，出问题就把文件换回去。难点在数据库层面，如果这次升级改了表结构，又产生了新数据，回退就不只是换文件的事。
常用做法是升级前做全量备份，升级后如果发现严重问题，先把新产生的数据导出来，再还原备份，然后把导出的数据按旧结构适配回去。这套流程要在测试环境演练过才敢用。
更稳妥的做法是把结构变动设计成兼容式。比如加字段时允许为空，程序里做兼容处理，这样旧程序和新结构能共存一段时间。需要删除字段时，先停用不再读写，观察两三个版本之后再真正删掉。慢慢来虽然费时间，但每次升级的风险都压在可控范围内。
四、升级后要盯两天
升级完成不等于事情结束。刚升级完的一两天是问题高发期，因为测试环境覆盖不到所有真实场景。
这两天要做三件事。一是让开发方保持在线，随时响应业务报上来的问题。二是重点观察升级涉及的模块，看有没有异常日志、有没有用户反馈卡顿。三是准备一个临时通道，如果问题批量出现，能快速决定是继续修还是回退。
还有个容易被忽略的细节，升级之后要通知到一线人员。有些操作界面变了，不提前说明，用户会以为系统坏了。哪怕只是按钮换了个位置，也值得在群里说一句。