这是什么
Ubuntu 26.04 升级到一半，一个 37.8MB 的第三方软件包把整条流水线拖到 6KB/s——平均每秒钟下载不到 7 个汉字。这是上周一位运维工程师的升级实录里，三个坑中最表面的那一个。
他要把一台跑了三年的 Ubuntu 22.04 服务器逐级升到 26.04。官方不支持跳级，必须先升到 24.04 再升到 26.04，像接力赛一样，每一棒都要完整跑完。
三个坑依次是：
- apt full-upgrade（Ubuntu 的全量升级命令）卡在 NodeSource 的 37.8MB 软件包上，速度只剩 6KB/s，整个升级流程被串行排队拖住；
- 第一次 do-release-upgrade（Ubuntu 官方的版本升级工具）启动几十秒就退出——下载的升级工具包实际大小（1275049 字节）和镜像索引里登记的大小（1267251 字节）对不上，镜像正好在同步新旧版本，他抓到了不一致的那份；
- 最隐蔽的一次：升级器干脆说"没有可用的 LTS 版本"。可 26.04 已经发布半年多了。根因是元数据里一个标志位没有翻转，升级器"看不见"新版本。
整个过程约 1.5GB 下载、两次重启、两个多小时——多出来的时间几乎全是学费。
行业怎么看
这事在运维圈不算新鲜，但每次出现都让人头疼。
支持"追新版"的一派认为，正是这种逐级、保守、可控的节奏，让 Ubuntu 成为企业服务器的事实标准之一——LTS（Long Term Support，长期支持版本）五年支持窗口给了规划空间。
反对意见更值得听：不少资深运维主张"能不动就别动"。一个被广泛认同的观点是，生产环境的稳定性优先于追新版本。第三方源、镜像同步、隐藏的元数据标志位——这些坑每个都不致命，但叠在一起就是事故。文章作者给出的解法（暂时禁用第三方源、切换镜像、重试）全是手动操作，没有"一键完美方案"。
值得一提的还有文章最后的一句话：升级脚本支持"交给 AI Agent 执行"模式。但反过来说明，AI 自动化在这类任务里扮演的更多是执行者，不是判断者——它能跑命令，但"该不该升、何时升、哪个坑该绕"还得人来定。
对普通人的影响
对企业 IT：即便是"例行升级"，也可能被第三方依赖、海外镜像同步这种不可控因素卡住。供应链可见性和回滚预案不是奢侈品。
对个人职场：这解释了为什么 IT 同事说"升级要排期、要看窗口"——不是拖延，是真有不少坑。提需求时多一份耐心，少一份催促。
对消费市场：你用的很多互联网服务底层跑在 Linux 上，这类升级事故虽然不直接面向用户，但会反映在服务可用性和数据延迟上。