凌晨3点17分，支付系统宕机。唯一懂部署流程的人在飞往巴厘岛的航班上。剩下的工程师对着脚本发呆——那玩意儿对他们来说，和古巴比伦楔形文字没区别。
这是软件工程里著名的"巴士系数"（Bus Factor，指关键成员被巴士撞了项目就瘫痪的风险系数）最血腥的呈现。17人团队，核心知识锁在1个人脑子里。本文还原他们如何用4周把系数从1提到5，且没拖慢交付节奏。
第1周：先承认问题有多脏
团队没急着开会画架构图。他们做了件更务实的事：让每个人列出"如果XX今天消失，我完全搞不定的3件事"。
清单出来后人麻了。部署流程、支付网关配置、数据库分片策略、第三方API密钥轮换——全是一人垄断。CTO后来回忆，「那感觉像发现家里电路全接在一个老式保险丝上，你还不知道保险丝在哪」。
但他们没搞"全员培训"那种形式主义。而是选了条更窄的路：只挑最致命的3个单点故障，其他先记账。
支付系统、部署管道、核心数据库。这三样崩了，公司当天就能上新闻。
第1周的产出不是文档，而是一张带血色的优先级表。以及一个共识：知识转移不能靠"教"，得靠"一起做"。
第2-3周：结对不是看着，是抢着
传统结对编程像老中医带徒弟——慢，且徒弟容易走神。他们的改法很产品经理思维：让"徒弟"主导操作，"师父"只能动嘴。
具体执行：每次部署、每次故障排查、每次密钥轮换，必须由非核心人员主刀。原负责人坐旁边，手放桌上，像驾校教练。
前3次部署，时间从15分钟拖到47分钟。但第5次，新人开始比老人还快——因为老人当年写的脚本里有3个隐式依赖，新人看不懂直接问了，反而绕过了那些历史包袱。
数据库管理员Maria的观察很典型：「当你知道明天可能由你擦屁股，你提问的方式都变了。以前听讲解像听播客，现在像考前划重点」。
两周内，3个关键系统各培养出2个backup。不是"大概知道在哪"，是能独立处理凌晨3点报警的水平。
第4周：用"假葬礼"验收
最后一步是场压力测试：模拟Marcus真的被巴士撞了——断联48小时，团队能否自主运转？
测试选在周五下午，故意挑了人心最散的时候。支付系统被注入故障，部署管道触发回滚，数据库报警同时响起。
结果：27分钟恢复，比Marcus本人在场的历史平均还快4分钟。原因是新流程里加了他本人从没写过的运行手册——那些他以为"显然"的步骤，被显性化成了检查清单。
CTO的复盘很克制：「系数从1到5不是终点。下个月目标是到8，让任何2个人同时消失都不影响交付」。但他补了句狠的，「真正的收获是发现，很多'只有我会'的东西，其实是我没给别人机会试」。
这套方法后来被他们整理成内部文档，核心就三句话：先测再治（列出单点清单）、结对主刀（非核心人员操作）、假葬礼验收（模拟断联测试）。没有新工具，没有额外 headcount，只是把"知识转移"从培训室搬到了战壕里。
那个凌晨3点的支付故障后来成了团队梗。每次有人想说"这个只有XX懂"，就会有人接"巴厘岛警告"。 Marcus从婚礼回来后发现，自己居然能正常休假了——虽然他还是习惯性带电脑，但至少没人会在凌晨打爆他电话。
如果你的团队现在让某个人消失48小时就会瘫痪，你猜那个人的名单里，有没有你自己？
热门跟贴