先盘资产
域名、证书、云资源、依赖服务与第三方账号都要列清，并标注到期时间与责任人。为什么先做这一步：交接后最常见的故障是证书过期或域名欠费，而这些信息往往只存在原负责人的便签里，没人知道该去续。
运行手册可执行
手册写清启停、发布、备份恢复、扩容与降级的具体步骤，命令可直接复制。怎么写才可用：按真实操作顺序写，标出每步的验证方式与失败后的回退动作；只写架构不写操作的手册，接手人不敢用。
凭据双人移交
账号与密钥通过客户方统一的凭据管理移交，双人在场，移交后立即改密并回收临时权限。为什么不能发聊天工具：凭据一旦扩散就无法追溯，交接期恰恰是权限最容易失控的阶段，必须留下移交记录。
演练与观察期
让接手方独立完成一次发布与一次恢复演练，原团队只观察。交接不等于责任瞬间转移，建议设观察期，期间原团队做答疑与复核；演练不通过或问题清单未关闭，就不签最终交接确认，这是边界。
责任分界写清楚
交接当天责任不会自动转移，分界要写在纸上。做法：在确认单里写明交接完成时点、观察期长度、期间双方的职责与响应时限，以及重大故障的协同方式；观察期内原团队提供答疑与复核，操作与发布由接手方执行并承担，双方各自指定接口人，避免出了问题互相等待、各说各话。
适用与不适用
适合谁
- 由外部实施方交付的系统与部门及其实施团队
- 信息中心接管业务应用与部门及其实施团队
- 运维负责人发生变动的组织与部门及其实施团队
不适合谁
- 仍在开发、尚未上线的系统或演示原型
典型场景
某建筑集团的项目知识助手由外部实施方移交给集团运维中心。移交清单覆盖域名、证书、云资源与三个第三方账号；凭据通过统一平台双人移交；接手方独立完成一次发布与一次数据恢复演练。观察期内发现证书告警未配，补齐后签认。
可执行步骤
- 列出域名、证书、云资源、依赖服务与第三方账号及到期时间，完成后归档。
- 编写运行手册，覆盖启停、发布、备份恢复、扩容与降级，并留存记录。
- 通过统一凭据平台双人移交账号，移交后立即修改密码并回收旧凭据。
- 变更监控与告警的责任人、通知对象与升级链，记录执行人与时间。
- 由接手方独立完成发布与恢复演练，并约定不少于一个月的观察期。
常见坑
- 只交文档不交账号，或账号绑在原负责人个人手机号上，验证码收不到就寸步难行，事后难以补救。
- 备份策略写了但从没验证过恢复，真出事时才发现备份文件不完整或根本无法还原，恢复窗口被彻底错过。
- 定时脚本、手工改配置等隐性依赖只在某个人脑子里，交接后无人知道它存在，返工成本会上升。
自检与验收清单
- 资产清单是否含到期时间与责任人，并有书面确认
- 运行手册是否可直接照做并含回退步骤，并有记录
- 凭据是否双人移交并已完成改密，并有可核查的记录
- 监控责任人与升级链是否已变更，并有验收记录
- 是否完成发布与恢复演练并设置观察期，可现场抽查
常见问题
交接一定要有观察期吗？
建议有。观察期的价值不是替接手方干活，而是让问题在有人兜底时暴露出来；期间原团队只答疑不操作，接手方独立执行。观察期长度按系统复杂度定，关键是结束前把遗留清单关闭。
文档和演练只能选一个怎么办？
先演练。文档可以边用边补，演练暴露的是真实缺口；一次发布加一次恢复演练，能覆盖大部分交接风险。演练后把卡住的步骤补进手册，比先写一本厚文档更省时间，也更贴近实际操作。
交接后原团队还要负责吗？
责任随签认转移，但技术答疑可以约定一段时间。建议在确认单里写明观察期内的响应方式与时限，以及紧急联系人与升级条件；边界清晰，双方都不至于在出事时互相推诿，也便于后续审计。