2024 年 7 月 19 日 04:09（世界协调时），CrowdStrike 给它的 Falcon 安全软件发出一个小小的配置文件。这类更新是用来帮软件识别新的攻击手法的，此前已经顺利发过好几次。
它一次性推给了客户装着 Falcon 的 Windows 电脑。没有先发给一小批，也没有停下来看看效果。当时在线、收到它的机器，一台台蓝屏崩溃。
05:27，CrowdStrike 撤回了文件，之后才上线的机器安然无恙。可微软后来估计，这时已有 850 万台 Windows 设备中招。这不到全部 Windows 电脑的百分之一，但微软说，波及之所以这么广，是因为「使用 CrowdStrike 的企业运行着许多关键服务」。那一天的其余经过，见案例。
18 天后，CrowdStrike 发布根因分析，列了六条发现。最后一条只有一句话：「每个模板实例都应分阶段发布。」现在，每次更新先发给一小批「金丝雀」机器，再一圈圈扩大范围，每扩一圈都停一停，收集数据看它表现如何。客户也可以自己选在哪儿、什么时候接收更新。
先小后大
一批，就是你一口气做完、交出去的那一份：一次发布，一车货，一个代码合并请求，一天的表格。把它变小，有两个好处。
一是反馈来得早。研究软件团队交付方式的 DORA 项目说得很直白：小批量能缩短「拿到改动反馈所需的时间，让分诊和修复问题更容易」。头十台机器崩了，你是从十台机器上知道的。
二是真出了错，波及得少。亚马逊从 2017 年那次 S3 事故里得出了同样的教训：一条输错的命令，打垮了所有请求都离不开的一个子系统。它的修法之一，是加快把这个子系统拆成更小的单元（它叫 cell），以缩小故障的「爆炸半径」，也让恢复更快。
小批量还能少等。大批量里的活，要等同批其余的都做完才算完，哪怕排在第一个的也一样。这又是利特尔法则：完成速度不变时，系统里堆的活越多，每件平均待得越久。
四十张请柬
设想有人要寄四十张聚会请柬。看起来高效的做法是：四十张先全折好，再全装进信封，再全封口，再全贴邮票。第一张做完的请柬，要到晚上快结束才出现。要是卡片根本塞不进信封，这事要到装第一个信封时才发现，而那时四十张已经全折完了。
一张一张做，第一张一分钟就好。信封有问题，装第一张就露馅，另外三十九张还没折错尺寸。
小批量也不是白来的。每一批都有固定成本：准备、交接、检查。DORA 指出，团队做大批量的原因之一，就是交接的固定成本太高；持续交付想做的，正是改变这笔账，让小批量做得起。另一个坑是：活拆小了做，交付前又重新攒成一大包，早来的反馈就这么扔掉了。
AI 的活也要小批量
AI 编程工具往反方向推。它几分钟就能写出一整个功能。DORA 的指南说，AI「很擅长快速生成大块代码，但大改动很难安全地审查、测试和集成」。它还说，审查机器写的代码，「每行花的心力可能比审查人写的代码还高」。它称自己的研究显示，小批量工作「放大了采用 AI 对产品表现的正面作用」。
落到实处，就是让智能体一次只做一个小改动，看过一个再要下一个，而不是最后收下一个巨大的改动。让智能体上岗也一样。一个新的客户回复智能体，或者给老智能体换了一套新指令，可以先让它回一小部分真实来信，有人逐条看它发了什么，再让它接下全部。
CrowdStrike 的那次更新本身很小。出事，是因为它一次大范围推了出去，没有先拿一小批试过。