深圳地铁突然人人必检,像极了一次没做压力测试的全量发布

我在武汉，刷到热搜的时候第一反应不是吐槽排队，是职业病直接犯了：这上线，连灰度都没做啊？

12 个小时，从公告到全量执行

7 月 19 号晚上快 8 点发的公告，说第二天起进站全覆盖安检，行李过机、人人手检。前后隔了不到 12 个小时，第二天天早高峰直接全量执行，一点缓冲余地都没留。

坪洲、固戍、高新园这种早高峰本来就挤不上车的通勤大站，当场就爆了。队伍直接绕到站外三圈，不少人平白多排二三十分钟，上班直接迟到。

之前还能走的无包通道直接取消，所有人堵在同一个口子上，通行效率直接砍半。

需求没毛病，执行逻辑有毛病

平心而论，安检升级这个需求本身没毛病。安全第一，这个道理谁都懂，就像产品提的业务需求，出发点肯定是站得住的，但问题出在执行逻辑上。

要推行人人必检，对应的安检通道、工作人员、设备总得跟上吧？既没先挑几个大站试点跑一周摸摸底，也没提前算过早高峰的通行承载力。

说白了就是：产品拍板全量上新功能，运维没加服务器，测试没跑压力测试，直接就推去了生产环境。

结果可想而知。早高峰几百万人的并发流量一冲，系统直接卡在了安检口这个瓶颈上。就像个跑满负载的单核 CPU，队列越堆越长，最后直接溢出到站外。

我以前做安卓的时候，踩过一模一样的坑

有次赶版本节点，产品咬死了当天必须全量上线，硬生生把测试周期砍了大半，连高峰场景的压测都没跑完。结果上线不到俩小时，用户反馈直接炸了，一堆人闪退用不了。我们全组熬到凌晨三点推修复包，第二天上班个个眼睛都是红的。

从那之后我就认一个理：需求再正确，上线流程不对，最后买单的全是用户。

这波后续，就是标准的线上 hotfix

你再看这次的后续操作，简直和线上事故处理流程一模一样——

先手动降级：才到第二天晚高峰，小包就不用强制过机了，没带包的也不用人人手检，先把队列消下去再说。再打补丁：22 号发公告，加派安检人员、试点智能安检门，补系统的承载力。

标准的线上 hotfix 操作。

但总让人忍不住想问一句：这些优化措施，为什么不能在上线前就准备好？不是做不到，是从一开始，就没人把「系统承载力」和「需求落地」放在一起算账。

不是深圳独有的问题

我在武汉也碰过好多次，逢节假日或者办大型活动，突然就升级安检，本来顺畅的地铁站直接排成长龙。本质上都是同一个逻辑：决策层提需求，执行层拿现有资源硬扛，中间缺了最关键的一步——容量评估。

就像做系统只堆功能，从来不扩容服务器。平时流量小还能凑合撑着，一旦到了高峰，不崩才怪。

今天是深圳地铁，明天可能是任何一座城市的任何一个公共服务。只要这个逻辑没变，同样的事就还会重演。

说白了，不管是写代码还是搞公共服务，最怕的从来不是要求严，是拍脑袋就上量。

Frank 先森，前 9 年程序员。踩过足够多的坑，现在帮你提前看见。