去年冬天，漏洞区域我在一个做电商的漏洞区域朋友公司里坐着，看他临时拉了个技术群，漏洞区域让运维查一台服务器的漏洞区域日志。原因很简单：用户下单后，漏洞区域优惠券偶尔不抵扣，漏洞区域频率不高，漏洞区域但每天都有几单。漏洞区域运维查了两小时，漏洞区域说代码没问题。漏洞区域开发查了三小时，漏洞区域说数据库没问题。漏洞区域最后是漏洞区域一个刚来两周的实习生发现的——支付接口的超时重试逻辑里，有个分支没清空购物车里的漏洞区域临时标记，导致优惠券校验时读到了脏数据。漏洞区域

这个漏洞藏在两个系统的交界处。单独看支付代码，逻辑自洽。单独看优惠券模块，测试全过。但两者拼在一起，就裂开了一条缝。我后来把这类问题叫“漏洞区域”——不是某个具体的bug，而是系统与系统、人与人、流程与流程之间那片没人真正负责的灰色地带。

你去看任何一个线上事故的报告，根因几乎都不在某个单点的技术故障上。去年某云厂商的大规模宕机，起因是一个配置推送。推配置的工具没问题，配置本身也没问题。问题出在推配置的人不知道那个参数会影响另一个区域的流量调度。他以为自己在改A，实际动了B。而B的负责人正在休假，没人收到通知。这就是典型的漏洞区域：两个团队之间的信息断层，比任何代码缺陷都致命。

我观察到一个规律。团队规模在二十人以下时，漏洞区域很少。大家坐在一起，吼一嗓子就同步了。五十人左右开始出现。一百人以上，漏洞区域会像霉菌一样在组织架构的缝隙里疯长。原因不复杂——每个人都在自己的职责范围内做到最好，但职责范围的边界，恰恰是漏洞区域最肥沃的土壤。

有个做安全的朋友跟我讲过一句话，我记了很久。他说，渗透测试报告里最值钱的不是高危漏洞，是那些“设计如此”的漏洞。你提一个越权访问，开发说这是业务需求。你提一个信息泄露，产品说这是为了方便用户。这些被“设计”出来的漏洞区域，往往连修复方案都提不出来，因为没人觉得它是个问题。

更麻烦的是，漏洞区域会移动。今天你在支付和订单之间堵住了一个，明天它可能跑到日志和监控之间。系统越复杂，漏洞区域的表面积越大。微服务架构把单体拆成了几十个服务，每个服务内部都干净了，但服务之间的调用链、超时设置、重试策略、序列化协议，全是新的漏洞区域。有人统计过，微服务架构下，超过六成的线上问题出在服务间交互，而非服务内部逻辑。

那怎么办？我的经验很土，但管用。第一，让跨团队的关键接口有明确的主人。不是“支付团队负责”，而是“张三负责支付到订单的这层交互”。第二，故障演练要故意打穿边界。别只测单个服务能不能扛住，要测A服务挂了之后，B服务会怎么反应。第三，也是最反直觉的一条——允许漏洞区域存在，但给它装个报警器。你不可能消灭所有缝隙，但可以在缝隙里放个传感器，一旦有东西掉下去，立刻知道。

回到开头那个优惠券的事。实习生改完代码后，我问他怎么发现的。他说，他把支付和优惠券的日志按时间戳对齐，一行一行看，看到第三遍才注意到那个标记的清除时机不对。没有魔法，就是肯花时间去看别人不愿意看的那片区域。漏洞区域不会消失，它只会转移到下一个没人看的地方。你能做的，就是比昨天多看一眼。

(责任编辑：综合)