从接手人明早要做的事开始
假设每天09:00需要生成前一天的订单汇总。原开发者离开后，接手人至少要回答：今天任务是否运行、原始订单在哪里、汇总结果存在哪里、失败后哪些订单需要补做。围绕这条业务流程交接，比打包一堆代码和截图更容易检查遗漏。
请接手人在交付环境中亲手跑一次示例批次。讲解者可以旁观，不能代为输入配置或临时找回文件。卡住的每一步都要补进运行说明，而不是记录成“已口头告知”。
用资产表把“知道地址”变成“有人负责”
| 资产 | 应交清的内容 | 接手验证 |
|---|---|---|
| 程序与运行入口 | 安装包或代码版本、启动方式、运行设备 | 接手人独立启动示例任务 |
| 数据与附件 | 原数据位置、输出目录、业务编号关系 | 从一行汇总找回原订单 |
| 账号与服务 | 组织所有者、使用角色、续费与失效日期 | 组织内人员能管理和恢复访问 |
| 配置与规则 | 目录、统计口径、字段映射、配置版本 | 解释一笔订单为何计入或排除 |
| 支持与记录 | 故障联系渠道、版本变更记录、已知限制 | 找到最近一次修改的内容和原因 |
账号清单只写保管位置和负责人，不汇集明文密码。人员离开时，交接组织所有权、撤销不再需要的权限，并更新其曾持有的必要凭据。外部服务由个人账号独占管理，是需要在交付时解决的具体缺口。
备份清单要对应一次实际恢复
先由业务方确定可以接受丢失多久的数据、停用多久，以及哪些历史版本必须保留，再决定备份频率和保存位置。只备份程序而没有订单数据与字段配置，不能恢复同一份报表；只同步一个文件夹，也不能自动证明误删后还有可用历史版本。
演练可选一份已完成的示例批次：将其数据与配置恢复到独立测试位置，生成汇总，核对订单数量、编号和总额。记录备份生成时间、恢复版本、耗时以及差异。演练过程中不要覆盖正在使用的环境，也不要把实际发送通知等外部动作一并执行。
停机时要有能继续工作的替代步骤
为每日汇总准备一页故障操作卡：暂时停止重复运行；确认最后一个成功批次；保留尚未处理的原表；由指定人员按已交接口径手工汇总；修复后只补做未完成范围。替代流程产生的结果也应有编号，防止系统恢复后重复发出同一报表。
支持约定应写接收故障的时间段、响应方式和联系人。响应时间与修复时间分别约定；第三方服务中断、数据本身缺失等情况，不能用一句“长期维护”覆盖。
把维护事项与业务变化分别登记
“按已约定口径漏算一笔订单”属于需要核查的故障；“新增一个门店并改变统计口径”可能是新需求。登记时附原约定、当前表现和期望变化，由双方判断处理范围。每次更新还要留下版本、配置变化、验证记录和可回退条件，接手人才知道系统为什么与上月不同。