我的朋友 Priya 负责管理一个 34 张床位的医疗病区的排班，两年来一直靠一个没人按顺序阅读的群发短信来处理换班请求。她想要一个护士们在休息时能在手机上打开的工具，发布一个需要有人顶班的班次，然后在护士长不得不手动重新调整排班表之前，有人能主动接下这个班。我用了三周的晚上时间把它做了出来。这是它真正上线那天的记录——发布、自定义域名、真实的护士、真实的班次——因为“测试环境下能跑通”和“早上七点病区人手短缺两人时也能跑通”之间的落差，本身就是一堂课。
早上 6:58 — 发布
我前一天晚上就已经把部署目标设为 Priya 自己的域名，所以这一步平淡无奇：点击发布，看着构建的验证记录跑完各项检查：
- 路由是否正常解析
- 换班认领接口返回真实响应而非占位数据
- 短信通知钩子确实已配置好，而非处于演练模式
全部通过。我在早上 6:58 把链接发给了 Priya，因为我知道她正好在那个时间点走进她的班次，我想让她在这一天开始之前就看到它已经上线，而不是事后才知道。
早上7点15分——第一位真实用户做了我没测试过的事
普里娅在二十分钟内为当晚发布了一个空缺班次，这比我预期的要快，意味着在我还没喝完咖啡之前，第一个真实数据点就已经出现了。然后一位叫丹尼斯的护士认领了它，四分钟后取消认领，接着又重新认领了。我完全不知道为什么——也许她在认领的过程中查看了自己的日程，发现自己有个牙医预约。应用处理得很顺利。我没测试过的是三个人在同一个十秒窗口内尝试认领同一个班次，因为在三周的单人测试中，这种场景从未出现在我脑海里。现在也没有出现在我脑海里。它是大约五小时后出现在现实中的。
上午9点40分——安静，而这种安静让我紧张
接下来两个半小时什么都没发生。没有认领，没有发布，日志里也没有错误。我还是查看了四次仪表盘，这是个我大概应该改掉的习惯——没人在用的构建并不是坏了，只是还没人用而已，这是两个完全不同的问题，需要不同的解决办法。我强迫自己关掉标签页，去做点正经工作。
上午11点52分——那个缺陷
认领接口把三个请求都接受了，因为我把「标记为已认领」的逻辑写成了一个简单的「若开放则更新」检查，没有加锁，在正常的单用户测试下，这种竞态条件根本没有发生的空间。而在三部不同手机同时点击的情况下，空间就足够了。三位护士都收到了确认短信，说她们已经接下了这个班次。丹尼斯是其中之一，那天已经是第二次了，这一次她很生气。
我想诚实地说明我是怎么发现这个问题的——我不是从监控里发现的。普里娅给我发了这条短信，还带了个大笑的表情，虽然我觉得她不是真心觉得好笑，因为这确实给她的下午带来了麻烦：
app说三个人抢到了同一个班次哈哈
中午12点10分——进入构建对话
我用大白话描述了这个缺陷：如果多个人在差不多的时间点击，就可能多人认领同一个班次，而本应只有一次认领生效。我没有先自己动手修复，一部分原因是我当时正在停车场用手机，另一部分原因是精确地描述失败现象通常比精确地诊断问题更快。智能体追溯到认领表缺少行锁，提出改用原子条件更新——只有当班次状态仍为「开放」时认领才会成功，由操作本身决定谁获胜，而不是那种「先检查后写入」、让三个请求同时看到「开放」状态的方式。这就是这个缺陷用一句话概括的本质，也是那种一旦说出来就显而易见、但不被逼到眼前就完全隐形的问题。
中午12点34分——修复上线，我让普里娅等一等
补丁很小。我仍然没有在班次进行中直接把它推到正式域名上——我先在预览版本上运行了它，请普里娅那位不当班的护士长同事，用三个浏览器标签页同时点击尝试同样的场景。结果稳住了：一次认领成功，另外两次收到「该班次刚被他人认领」的提示，而不是虚假的确认。我在12点34分把它推上了线，距离缺陷发生大约四十二分钟，那一刻感觉很慢，事后看来其实很快。
下午2点到6点——无聊却美好的部分
- 11 个新发布的班次
- 9 个顺利认领
- 2 个过期未被认领，转入普里娅仍在手动管理的表格——这没关系，这个工具不需要在第一天就解决所有问题，它需要解决那个具体出问题的地方
- 0 次重复认领
我盯着数字看，而不是去想象各种结果，这是一种截然不同、也平静得多的活动。
我会做出哪些不同的选择
两件事。
- 我本该在最初的构建提示里就描述这个并发认领的场景，而不是在实际运行中才发现——「多个用户，同一个操作，同一时刻」就是一句话，并不是什么高要求，我只是没想到要加上它，因为我自己的测试天生是顺序进行的；我一次只会点一个按钮。
- 在第二周，我在短信通知文案上投入了过多精力——重写了三次，而没人对那条确认短信提过意见——却在恰恰是并发这种边界情况上投入不足，而一整层楼休息时都盯着手机的护士们，第一天就必然会撞上这个问题。
下次发布时，我会少花点时间打磨没人会挑剔的文案，多花点时间问「如果五个人同时这么做会怎样」，因为对任何拥有不止一个真实用户的产品来说，早晚都会有人这么做。
