软件修改的风险，常被一种直觉带偏：改得少，影响应该也小。可一行价格配置可能影响所有订单，一个权限设置可能决定所有文件对谁开放。
代码行数与业务后果，不是一张能直接换算的表。
设想一个排课工具，原来把上课地址存在一个字段里，后来拆成城市、街道和门牌号。新页面看着更清楚，开发者也觉得这只是整理数据。但如果旧字段被删掉，一旦新版本出错，即使换回旧程序，它也可能读不到原先需要的内容。
“撤回代码”和“恢复业务”，在这里成了两件事。数据已经变了，旧程序回来了，也未必认得新的数据。
这就是为什么一些发布会先面向少量用户。Google 的工程手册把这类做法称为金丝雀发布：在有限范围和时间内运行变更，再评估是否继续扩大。资料：Google 发布指南
它不只是把新版本给几个人试试。判断标准也得跟着业务走。结算页面能打开，却把优惠算错；报表成功导出，却少了一类订单，这些问题未必会表现成系统报错。观察“有没有运行”，与观察“运行得对不对”，距离不小。
还有些后果根本收不回来。消息发出后，退回旧版本不能让用户忘记它；文件已经交给外部系统，恢复代码也不会自动撤销对方的操作。所谓退路，有时包括解释、补发和核对，而不是一个回滚按钮。
我觉得，理解变更风险之后，对“上线”这个词会更有耐心。它包含把新东西交出去，也包含看清真实结果，以及发现问题后还有没有处理空间。
小范围试用并不保证万无一失，少量用户也未必能覆盖所有情形。它的意义，是在可能的情况下，让问题先出现在较小范围内。
真正危险的“只改一行”，往往不是那一行特别复杂，而是没人继续追问：这行内容后面，究竟连着多少人的工作。