公司之前所有的 Node 项目，其环境都是 8.9.4 版本，发布于 2018 年的一个比较古老的版本。
老版本有两个比较明显的问题：
- Node 高版本的特性和方法都无法使用。
- 有些第三方新版本的包无法安装和升级，该包可能依赖比较高的 Node 版本。
之前在开发项目时就遇到第三方包自身的问题，必须升级或换个包才能解决，但因为 Node 版本的原因，无法替换，只能用其他方式来修补漏洞。
为了提升维护性和开发体验，还是决定升级 Node 版本，2021年升级过一次，升级到 14 版本。
但是因为一些奇怪的问题加上业务繁重，没有时间细究，就又回滚了，一直拖到今年的 7 月份，才继续推进升级的事情，本次会升级到 16.15 版本。
目前总共有 4 个 Node 环境需要升级，测试资源紧张，在升级后，是没有人力来验证是否有问题发生，所以只能靠自己想办法安全升级。
1）分项目阶梯升级
在 4 个待升级的项目中，有 3 个是对外的项目，有 1 个是对内的项目。
那么先升级对内项目的 Node 版本，这样有两个好处：
- 即使出问题了，影响范围也能最小。
- 响应也能最及时，因为有问题的话，在公司内部能马上反馈到我们组。
2）分环境阶梯升级
我们每个项目都会有 3 套运行环境：测试、预发和生产。
首先将测试环境升级，测试环境都是开发人员使用，影响最小，反馈最快。
观察一段时间后，再升级预发，预发环境与生产环境最为接近，数据库采用的也是一套。
最后才是生产，给真实用户使用，再获取反馈。
3）邀请内部人员体验
首先升级的是那个内部项目，所以在飞书上建了个群，将各个组的负责人拉进来。
邀请他们在预发环境体验各自的业务，再给出反馈。
在验收时发现了时区的问题，纠正后，再让他们验收。
4）部署自动错误告警
让人来验收，难免会有遗漏，所以让运维给加了个自动错误告警。
每分钟有 5 个 500 以上的错误，就自动在飞书上发告警信息。
这类规则比较适合接口，而定时任务的规则比较特殊。
因为任务可能是 5 分钟运行一次，那么报错的频率不会那么高。
因此改成 5 分钟内有一个错误就告警，免得告警太多，也比较烦人。
5）增加单元测试流程
在将对内的项目升级完成后，公司员工在访问一个服务时报错。
让运维查看后，发现是因为连接地址配置错了。
为了避免这种问题的发生，就需要有地方可以测试服务连接是否异常。
手动测试比较繁琐，最好的办法是在发布代码的流程中，加一环服务连接。
若成功，那么就继续后面的流程，否则就中断。
公司使用的是阿里云提供的发布系统，里面可以加一步单元测试。
服务连接是测试的一个场景，未来可以再加其他各类测试，保证项目质量。
从开始升级到全部项目升级完成，前前后后操作了 20 多天，因为在一个环境或项目升级后，就要观察几天，然后再升级另一个环境或项目。在升级完成后，还部署了阿里云提供的一款 Node 监控系统。