上线那天，从早上七点到夜里十一点，我一直在接电话。

不是系统崩了，是三种完全不同的问题在三个时段依次冒出来。回头看，这三个时刻像三次体检，各照出一处毛病。

早上七点：第一批账号登进去了

七点十分，第一批三十个账号在半小时内全部登录成功。这一步比预想的顺。

顺的原因是前一晚做了两件事。一是把账号清单按企业分组导入，每个企业一个管理员，管理员自己再建下级账号，我们只验企业管理员那一层。二是把登录方式统一到手机号加验证码，没另设密码。多租户SaaS的第一道坎就在账号上，几百个账号如果逐个建，光核对就要两天。

问题出在八点二十。一家企业的管理员说，他看不到自己昨天的测试数据。

查下来是租户标识没带对。测试阶段所有数据挂在默认租户下，正式切换时新建了租户，老数据没有迁过去。数据在库里，只是查不出来。

这个坑的教训很直接：上线前要把测试数据的归属理清，要么迁到正式租户，要么明确作废。挂在默认租户下的数据，上线后就是一批谁也不敢删的孤儿记录。

中午十二点：数据隔离第一次被认真问

中午吃饭时，一家企业的负责人问了一句：我们的数据，别家能不能看到。

这个问题早晚会被问，最好在上线前就准备好答案。多租户SaaS卖的是共享，客户最担心的恰恰是共享带来的串号。

多租户SaaS的隔离有三层。第一层是数据层，每条记录带租户标识，查询强制带条件；第二层是接口层，令牌里绑定租户，越权请求直接拒；第三层是展示层，前端不提供跨租户的筛选入口。

三层里，第一层最容易被偷懒。为了省事，有些实现会在部分查询里省掉租户条件，靠上层逻辑兜。这种写法在测试阶段看不出问题，因为测试数据少、租户少；到正式运行时，一次漏写就是一次数据泄露。

那天的回答是把三层的实现方式当场讲了一遍，并约定下周做一次越权测试：用 A 企业的账号尝试访问 B 企业的单据编号，看系统返回什么。测试结果留档，作为验收标准里的一项材料。越权这件事不能靠口头保证，要靠一次可重复的测试。

这个动作花不了半天，但它比任何口头承诺都管用。

夜里十一点：账单和权限对不上

夜里十一点，财务那边发来消息：这个月的账算不出来。

原因是权限配置和计费口径没对齐。系统里按「启用账号数」计费，实际配置时给每家企业都开了几个备用账号，从没登录过，但计在账上。企业看到账单的第一反应是「我们没这么多人」。

多租户的计费，最容易在这类细节上扯皮。可行的做法是把口径写进合同：按启用账号数、按活跃账号数、按业务单量，三种各有利弊。启用账号数好统计但容易虚高，活跃账号数公平但企业会刻意压低登录频次，按单量则要处理峰值。

那天临时定的方案是按活跃账号数重算，同时给每家出一份账号明细。事情解决了，但本来可以在上线前定好的。

三个时刻连起来看

三个问题的共同点是：它们都不是技术难题，是上线前没做完的功课。

实施培训也一样。数字化系统上线，培训不到位等于没上线。那天真正出问题的企业，都是管理员没参加过培训的——他们不知道怎么建下级账号，也不知道数据范围怎么划。培训这件事在实施计划里通常排在末位，实际应该排在账号导入之前。

运维迭代的节奏同样要提前说。上线第一周问题最多，第二周开始收敛，第三周如果没有新的反馈，多半是一线已经放弃在群里问了。这个规律在几个项目里都成立，所以第一周的响应速度，基本决定了这套系统后面能不能用起来。

上线那天真正考验的不是代码，是准备。准备得细，一天下来的电话都是小问题；准备得粗，一个小问题能拖成一星期的返工。