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