PG官网

  去年冬天，一个做仓储的客户给我打电话，说原开发公司关停了。微信群里最后一条消息是对方老板发的，说公司不做了，后续有问题找技术负责人。他打过去，号码已经停机。系统还在跑，出入库、对账、司机排队都在用，但服务器在哪、数据库密码是什么、域名挂在谁名下，没人说得清。

  他最初的想法很简单，把代码要到手，再找个人接着维护。真开始接才发现，代码只是一个压缩包，解压出来跑不起来。配置文件是空的，证书过期了，定时任务停在旧服务器上，短信和地图的账号还是用原公司名义注册的。

  这类事这两年听得越来越多。开发公司规模小，抗风险能力弱，团队一散，项目就成了孤儿。接手的人不是不努力，是根本不知道有哪些东西需要接。

一、先接住「能跑」，别急着接代码

  交接其实分三层。最下面是能跑，业务今天不断；中间是能改，代码能编译、能部署到新机器；最上面是能维护，账号、备份、监控都在自己手里。很多老板一上来盯的是代码，结果最下面那层先塌了。

  先确认几件最急的事。服务器现在谁能登录，域名和证书续费到哪一天，数据库有多大、备份放在哪，有没有监控和报警。今天夜里出故障，电话该打给谁。这些问题的答案，比源码放在哪个仓库重要得多。

  我见过一个客户，代码拿到手，部署时发现系统依赖一个已经停服的短信通道，接口调不通，验证码全发不出去，业务停了半天。后来查出来，短信账号是用原公司员工手机号注册的，人走了，验证码收不到，账号也找不回来。

二、代码之外，还有四样东西在别人手里

• 第一样是环境和配置。数据库连接、缓存地址、对象存储的密钥、支付回调地址、第三方接口的 appid 和 secret，这些通常写在服务器的环境变量或者配置文件里，不在代码仓库里。还有 SSL 证书、定时任务、消息队列、webhook 地址，少配一个，系统就少一块功能。

• 第二样是数据和备份。数据库账号密码只是入口，真正要接的是备份策略。每天几点备份，备份文件放在哪，保留多少天。最怕的是备份有，但从来没恢复过。真出事的时候才发现备份文件损坏，或者恢复出来少了最后三天的订单。

• 第三样是第三方账号。域名、云服务器、小程序和公众号、微信支付商户号、短信签名、地图授权、CDN、OSS，这些账号大多挂在原公司或者原公司员工名下。给密码不等于能接手，很多要过户。小程序主体变更要审核，支付商户号变更要重新签协议，域名备案主体不一致，后面续费都麻烦。

• 第四样是文档和知识。部署文档、接口说明、数据库表结构、运维手册、历史故障记录。有的公司只留一张截图，写着「按这个部署」，新来的人对着截图猜路径。文档不求漂亮，能把一套环境从零搭起来，就算合格。

三、接手顺序反了，后面全是坑

  正确的顺序是先摸家底，再动系统。第一步要只读权限和账单，把服务器、数据库、域名、第三方服务列成一张表，标清谁名下、到期日、负责人。第二步做全量备份，并且在另一台机器上恢复一次，确认备份真的能用。

  第三步在新环境里从零部署一遍。这一步最能暴露问题，缺哪个配置、少哪个账号、文档哪一步写错，都会在这里现形。部署成功之前，不要动生产环境，也不要改代码。

  第四步是并行。原技术负责人哪怕离职了，也尽量签一段顾问期，按小时付费，遇到说不清的地方能问。新老两套环境同时跑一段，把报表数字对一遍，确认没有漏单、没有重复。

  等前面几步都稳了，再交写权限、改密码、切监控告警。改密码别挑业务高峰，先给自己建管理员账号，确认能登录、能操作，再停掉对方的账号。这个顺序反过来，先重装服务器、先改代码，旧环境一没，文档对不上，重建的时间往往按周算。

四、合同里没写退出条款，只能靠谈

  还没签合同的，把退出条款写进去。源码和文档的交付清单、第三方账号的实名归属、交接期不少于三十天、尾款和交接验收挂钩。再加一条源码托管，代码定期推送到甲方或者第三方托管平台，真到那一天，至少东西在。

  已经摊上事的，筹码不多，但也不是没有。未付的尾款、未结的服务费、对方还想保住的行业口碑，都是能谈的东西。找不到人的，走平台申诉。域名找注册商，服务器找云厂商，小程序和公众号找平台客服，准备好营业执照、法人证明、历史付款记录，证明你是这个系统的主人。

  如果什么都拿不到，先算一笔账。重建要多少钱、多久，旧系统还能撑多久。不要在一个跑不起来的压缩包里无限投入，有时候及时重建，比到处找人解锁更省。

  回到那个仓储客户。后来靠着服务器账单和域名注册信息，一项一项找回来，用了三周把只读权限、备份、部署环境、第三方账号过完。中间停了两小时做恢复演练，之后再没接过夜里的电话。

  判断标准不复杂。把原开发方的电话关掉，你还能不能部署、能不能恢复数据、能不能续上域名和短信。三个都能答，交接才算完成；答不上来，就继续列清单，别急着签字付尾款。