系统升级那天晚上，最怕什么？

台系CIM入门解说 · 第23篇 ｜ 主线案例：Lot L261029-A01-001｜12寸晶圆｜产品A01

升级不是换灯泡

给一座正在满负荷生产的晶圆厂升级CIM系统，是这行里公认的高危动作。

厂里不能停：一天投进来几千个Lot，每个Lot二十五片晶圆，几百台机器昼夜连转。系统却必须动——新版本要修旧毛病、加新功能。这就好比在高速上开车换轮胎，车不能停，胎还得换。

阿凯第一次经历升级前，以为流程就是"晚上停机、装新版本、开机收工"。老周给他泼了盆冷水："换灯泡才叫停机装新的。我们这个，是全厂几千个Lot挂在系统上，每一秒都有报文进来。一个Lot在机台上干活，一秒钟能吐几十条状态报文，几千个Lot同时跑——你新版本只要慢半拍，全厂的货就开始堵在半路。"

"所以升级那晚，我们最怕的不是系统崩。崩了看得见，可以回退。最怕的是它没崩，只是变慢了——慢，是要过一阵子才看得见的，等你看出来，货已经堵死了。"

灰度：先让一个班试用

这次升级，系统改了派工模块。派工是全厂最敏感的部件——几百台机器等着它分活，它一卡，全厂堵。没人敢直接全厂换新。

老周的做法叫灰度发布。他打了个比方："新菜先让一个班试用，没吃出问题，再端给全厂。哪有头一天就全厂换菜单的道理。"

计划是这样：新版本先只接管夜班一条刻蚀线，十二台机器。这条线的货单独标记，其余两千多台机器照旧走老版本。两条路并行，互相不干扰。夜班跑满三个晚上，数据没问题，第二天白天再扩到半个厂；再稳两个星期，才敢全量切换。

灰度还有个附带的好处：就算新版本把这条线派乱了，损失的也只是这一条线的排产，掐掉开关立刻回到老版本，别的线一根毫毛都不少。范围小，才敢试。

灰度的三个晚上也不是白熬的。第二晚一点多，夜班班组长打来电话："你们这个新系统，把一盒货排到 ET07 去了，那台机器的腔体 B 昨天刚换过件，我按老规矩给它降了载，你们怎么还往里派？"阿凯一查，新版本的机台状态表少同步了一条降载标记。好在灰度期间人是兜底的，班组长手动改了派工，没人受损。这类问题，全量上线之后再来一次，就不是一盒货的事了。

阿凯后来跟老周感叹："那个班组长等于是我们的免费测试员。"

"不是免费，是请不起，"老周说，"测试环境造不出真夜班——真夜班有急单、有机器闹脾气、有干了一整晚犯困的人。灰度请的就是这些测试造不出来的条件。"

那晚的事：0.3秒变成了8秒

全量切换定在月底一个周六的夜里。晚上十一点整，新旧版本开始交接，凌晨零点四十分，切换完成。监控大屏一片绿，值班室里有人已经开始收拾东西准备吃夜宵。

一点三十二分，阿凯扫了一眼监控曲线，愣住了：派工响应时间，从平时的零点三秒，爬到了两秒。他还没来得及叫人，数字跳到了五秒，又过了一分钟，八秒。

八秒是什么概念？平时Lot出站到机台开工，四十秒内全链路走完；现在光等派工就要八秒，全厂几千个Lot同时压过来，等待的队列像早高峰的高速路口，越堵越长。机台没活干，一片一片空转，对面的厂长电话已经打到了值班室。

"为什么测试的时候好好的？"阿凯手都在抖。

老周盯着屏幕，反而很冷静："测试是三百个Lot压出来的，今晚是六千个。性能要按最忙的时候算，不是按平时算。平时再快，峰值顶不住，就是不合格。"他抓起对讲机，"执行回滚。现在。"

从发现到拍板，不到二十分钟。

回滚不是按一个按钮

阿凯以为回滚就是按一个"撤销"键。实际上远不止。

为什么这么狠？老周给他算过一笔账：那晚全厂六千个Lot在跑，派工每慢一秒，几百台机台里就有一批在空等，按一分钟的白花成本算，堵上半小时，损失就够这个项目组发半年奖金。所以在预案里，"派工延迟超过三秒并持续两分钟"就是明确的红线，触线即回滚，不许开会讨论。"红线是上线之前定好的，"老周说，"凌晨两点半的会议室里做不出理智的决定，能把决定权留给白纸黑字，就别留给人。"

那二十分钟里，值班组按的是一份提前演练过三遍的清单：先把派工开关切回老版本——这一步最急，一分钟内必须完成，机台有活干了，堵料就止住了；然后把新版本这四十分钟里产生的派工记录一条条对出来，哪些Lot被新版本派过、派去了哪，要跟老版本的账对平，不然会出现"系统说货在A机器，货其实在B机器"的鬼账；最后还要把六千个Lot的状态重新刷一遍。

整个回滚，从切开关到账目对平，用时四十六分钟。凌晨两点半，全厂派工延迟回到零点三秒。厂长在电话里就问了一句："货有没有伤着？"答：没有一片废。电话就挂了。

这次能全身而退，是因为回滚方案在测试环境里演练过三遍，每一步谁动手、几分钟内完成，白纸黑字写在预案里。"回滚方案没演练过的升级，等于没有退路，"老周在复盘会上说，"出了事现想，你想出来的每一步都是错的。"

事故之后：一次彻底的体检

回滚只是止血，病因还没找到。接下来一周，团队把那晚六千个Lot高峰段的全量报文拉出来回放，逐段排查，最后定位到一个数据库锁：新版本把两个原本分开的查询合并成了一个大事务，Lot一多，大家排队等同一把锁，越等越慢。修复方案改完，又在测试环境按峰值的两倍——一万两千个Lot——压了整整三天，同样的曲线再没爬起来过。

一个月后，新版本重新灰度、重新全量，这次派工延迟全程没超过零点五秒。

老周在总结会上说的那句话，后来被写进了团队的升级手册扉页："能回滚，才敢升级。升级方案里没有退路，就不配定上线日期。"

防住了升级夜里的惊魂，算是守住了"变"的风险。可系统还有另一类威胁——不是你要改它，而是天要动你厂：跳电、断网、机房进水。系统还能不能活？下一篇：【断电、断网、机房进水，系统还能不能活？】