可真正演练时，问题一个接一个冒出来。

有些决策权限，虽然写在制度里，但实际操作高度集中；

有些信息节点，看似开放，实际上依赖个人经验；

还有一些“默认共识”，一旦没有特定人确认，就会陷入停滞。

这些问题，并不是谁的错。

它们是组织自然生长的结果。

而试压的意义，就在于让这些“默认状态”，被迫显形。

林亮没有当场调整结构。

他只是让人把所有“卡住的地方”，完整记录下来。

“不是现在改。”他说，“是让它们在我们脑子里，留下痕迹。”

第三步，来自业务侧。

北岸被选为试压样本之一。

不是从销售，也不是从硬件，而是从使用端。

运营团队被要求模拟几种不太舒服的情况：

高峰时段突发维护；

关键设备短时降级；

部分公共空间临时调整使用方式。

这些情况，现实中迟早会发生。

区别只在于——

发生时，你是被动应对，还是已经预演过一次。

结果显示，大多数问题都能被妥善处理，但反馈链条略长。信息从一线传回中枢，再下达指令，存在几分钟的延迟。

几分钟，在日常中不算什么。

但在高频使用场景里，足以让体验变差。

林亮看完汇总，没有批评。

他只是在文件末尾，写了一句话：

“试压不是为了找问题，是为了记住问题长什么样。”

试压持续了整整一个月。

期间，没有任何对外动静，也没有内部通报。很多参与的人，甚至不知道自己正在“被试压”，只是觉得这段时间事情变得更细、更慢、更需要确认。

而这，正是林亮要的状态。

当试压结束时，他没有宣布“通过”。

因为系统从来不存在“通过试压”这件事。

它只存在于两个状态之间——

你知道自己的极限在哪里，

或者你假装不知道。

那天傍晚，他再次走到北岸。

这里一切如常。

灯光稳定，人流有序，风从海面吹来，被建筑温和地分解。没有任何迹象表明，这里刚刚经历了一轮内部演练。

但林亮心里很清楚——

这座建筑，这个体系，已经在没人注意的时候，被悄悄加过一次重量。

而它，没有发出危险的声响。

这并不意味着它无懈可击。

只意味着，当真正的压力到来时，它至少不会第一次感到陌生。

他站了一会儿，转身离开。

下一章，不会再是试探。

而是真正来自外部的——

不由你选择的压力。