PG官网

  项目验收后的第三个月，一种很常见的交接现场是，客户那边的 IT 主管提了离职。新来的人第一次进机房，先问服务器密码在哪。运维翻了两小时聊天记录，最后在一个已经退群的同事头像下面找到。系统没坏，业务也没停，但接手的人已经知道，这活不好接。

  很多公司以为项目上线就结束了。合同签了，验收单也签了，原团队撤场，后面的事交给客户自己的 IT 或者另一家服务商。真正难的阶段从这时开始。代码在，服务器在，数据库也在，可系统怎么跑起来、出了问题先看哪里、哪些操作不能碰，没人说得完整。

一、人走了，系统里断掉的不只是人手

  很多交接文档写得很厚，目录也漂亮。打开一看，前半本是需求说明书，后半本是数据库表结构，真正要用的东西没有。生产环境怎么部署，定时任务在哪台机器上跑，证书什么时候到期，第三方后台谁有管理员权限，出了问题先找谁。这些内容不在文档里，平时也没人记。

  一项对 133 个流行 GitHub 项目的研究发现，65% 的项目只要走掉两个核心开发者就会停摆。研究里把这叫卡车因子，意思是最少几个人离开，项目就会停。开源项目有公开代码和历史记录，仍然会这样。企业项目更依赖现场环境、客户口径和历史补丁，人员一走，断掉的地方只会更多。

  更麻烦的是，很多知识没有写下来的价值。某个报表每月月末要手工重算，因为财务口径改过；某个客户订单超过十万要走特殊审批，因为当年出过事；某台服务器重启后要先起某个服务，不然接口会超时。这些动作不在代码里，也不在需求文档里，只在原来那个人的习惯里。

  新人接手后，最常听到的一句解释是，之前就是这么处理的。再问为什么，没人知道。系统还能跑，判断却断了。一个人请假，项目还能顶住；一个人离职，整条链路就开始发虚。

二、交接清单里，文档只占一行

  交接要把一套系统交到别人手里，还得让这套系统继续做变更。文档只能说明设计，账号、环境、权限和判断标准才决定接手的人能不能动手。很多项目交接做了三天，结果只留下一个网盘链接，链接里的文件还没人打开过。

  先盘账号。服务器、数据库、云平台、域名、SSL 证书、短信、支付、地图、对象存储、日志平台、监控平台、堡垒机、VPN，每一个都要写清用途、当前持有人、管理员是谁、什么时候到期。很多项目出问题，原因不在代码，证书过期、短信欠费、支付密钥没人更新，都会让系统停。

  再盘环境。测试环境和生产环境差在哪，配置文件有哪些，密钥放在哪，定时任务有几条，哪些任务不能重复跑，数据库主从怎么切，备份在哪，恢复过一次没有。交接文档里写一句见附件，等于没写。接手的人要能照着清单把一套环境搭起来，才算真的交过。

  还要交判断标准。什么样的告警要立刻处理，什么样的告警可以先观察；哪些客户可以走标准流程，哪些客户必须人工确认；哪些数据能导出，哪些数据不能出内网。接手的人没有这些判断，遇到事只能打电话问，问不到就停着。

  账号和权限也要收口。原团队走了，管理员账号还留着，第三方后台还能登录，离职人员的 VPN 没停，这些都是隐患。交接时要做一次权限清理，把该收回的收回，把该转交的转交，把该改密码的改掉。权限清单不只是安全要求，也是责任边界。

  一份能用的交接清单，最终要落到动作上，让新人能独立完成一次发布、一次回滚、一次故障处理。做完这三件事，交接才算开始。只把文档放进网盘，最多算留了份资料。

三、监控只报挂了，等于没报

  很多系统有监控，CPU、内存、磁盘、网络，面板上一排绿灯。业务出问题时，这些指标可能全是正常。订单没进来，支付回调失败，工单卡在中间状态，库存没有扣减，监控看不到。等客户打电话过来，团队才知道系统已经停了半小时。

  监控要分三层。底层看服务器、数据库、网络和第三方接口，中间看应用进程、队列、任务和错误日志，最上面看业务指标，比如下单成功率、支付成功率、工单积压量、报表生成时间。三层里缺一层，故障就会从缺口漏过去。只盯服务器，业务停了也发现不了。

  还有两个细节。日志要能串起来，同一个订单从进入系统到完成，用同一个请求标识能查到全过程。告警要有人接，不能全丢进一个大群，到头来没人认领。什么级别的告警发给谁，多久没响应升级，谁来停机，这些要提前写。没有责任人的告警，响一夜也没人动。

  系统最怕的，是故障发生了，大家还在猜。猜是不是网络，猜是不是数据库，猜是不是客户浏览器。监控不能替人做判断，但至少要把问题缩小到某一层、某个接口、某段时间。接手的人有了这条线索，才敢往下查。

四、让接手的人敢动，得先让他真做一遍

  交接会上，原团队讲一遍，新团队点头，会议结束。这种交接最不牢。真正有效的方式，是让接手的人在原团队还在的时候，亲手做一次低风险变更，处理一次演练故障，恢复一次备份。做过一遍，心里才有底。

  变更要有回滚。发布前知道改了什么，发布后看哪些指标，出问题在多长时间内回退，数据库脚本能不能反向执行，开关能不能关掉。没有回滚的变更，接手的人不敢点。变更窗口、审批人、观察指标和回退时限，都要写在发布单上，不能靠口头约定。

  应急要有剧本。数据库连不上，先看什么；支付回调失败，先查什么；消息队列堆积，先限流还是先扩容；机房断电，备机能不能起。剧本不用写成长篇，一页纸就够，但要按系统实际情况写，不能抄模板。每半年演一次，演完把漏掉的步骤补上。

  责任也要写进合同和交接单。源代码、部署文档、账号清单、第三方服务合同、维保范围、响应时间、升级路径，都要有明确交接。项目结束后原团队还能不能支持，支持多久，怎么收费，提前说清。交接单上没有人签字，出了问题还是找不到人。

  任何项目都会有人员流动，原团队离开很正常。真正的问题是，他们走之前有没有把系统变成别人能接住的东西。代码能跑只是最低要求，新人敢改、出了问题有人能判断、业务能连续，这才算交接完成。