五类文档保底
架构与依赖图、账号权限台账、监控告警与值班手册、变更与备份恢复记录、供应商与合同联系人。五类之外按系统特点补充，但这五类是接管后第一周就会用到的；缺任何一类，值班人都会在第一次异常时回头找原团队。
写到可复现
判断标准很简单：换一个没参与过项目的人，照着文档能否完成一次重启、一次切流、一次备份恢复。只写联系管理员处理的段落等于空白；把命令、路径、预期输出与失败后的下一步都写进去，才算合格。
存放位置唯一
文档应放在客户指定的知识库或代码仓库，带版本号与更新记录，禁止只存个人网盘或聊天记录。位置不唯一，半年后就会出现三份互相矛盾的说明，值班人只能凭经验猜，风险由此累积，交接也会变成反复确认。
签收与更新责任
每份文档要有编写人、复核人与签收人，签收不等于读完，而是确认可照做。系统发生变更后应由变更发起人同步更新对应文档，并在变更单里勾选；没有这条规则，文档在三个月内必然过期，之后没人敢依赖它。
文档不替代演练
文档再细也写不全判断经验，交接必须配一次现场演练：由客户值班人按文档操作，交付方只观察并记录卡点，演练后回补文档。跳过演练直接签字，等于把验证成本推给第一次真实故障，也会让签字失去意义。
适用与不适用
适合谁
- 需要把系统移交给客户自有运维团队的项目
- 多供应商协作、依赖关系复杂的系统
- 有知识库或文档平台可承载版本管理的组织
不适合谁
- 系统即将下线、没有接管需求的项目
- 拒绝安排演练、只要求提交文档的委托
典型场景
某设计院的图纸检索系统移交前，交付方把文档拆成五册，其中值班手册写到具体命令与预期输出。交接会上，客户值班人按手册独立完成一次索引重建与一次备份恢复，卡在两处路径差异，当场修订。安全岗核对权限台账后签字，文档随后迁入客户知识库并绑定版本号。
可执行步骤
- 按五类清点现有文档，逐份标注缺失、过期与不可执行之处，列出补写清单
- 以没参与过的人能否照做为标准，改写重启、切流与恢复段落，并补上失败分支
- 把文档迁入客户指定知识库，建立版本号、更新记录与访问权限，关闭个人网盘副本
- 组织一次照文档演练，由客户值班人操作，交付方记录卡点并当场回补文档
- 由编写人、复核人与签收人三方签字，确认文档可以照做，并把签字页归档
常见坑
- 文档只写架构不讲依赖，第一次模型接口超时，值班人不知道上游是谁，排查方向完全错，恢复时间翻倍。
- 把账号密码写进交接文档，权限回收后文档仍在流传，形成长期审计隐患与越权风险，事后难以追责。
- 文档散落在个人网盘与聊天记录，交接后出现三个版本，值班人按旧版操作导致配置出错，还找不到原因。
- 签收只统计份数不验证可用性，文档看着齐全，真出事时没有一段能照着执行，值班人只能打电话问人。
自检与验收清单
- 五类文档是否齐全，且都标注版本号与更新日期
- 关键操作是否写到命令、路径、预期输出与回退动作
- 文档是否存放在客户指定位置，并设置访问权限
- 是否完成一次照文档演练，并把卡点回补进文档
- 编写人、复核人与签收人是否三方签字确认并归档
常见问题
文档要写多细才算合格？
以可复现为准：换一个人照着能完成重启、切流、备份恢复三类高频操作，并能判断每步失败后的下一步。篇幅不是标准，命令、路径、预期输出与回退动作才是；写不到这个程度，文档只能算一份目录。
能不能直接用厂商标准文档？
可以作为附录，但不能替代交接文档。厂商文档面向通用场景，缺少本系统的地址、账号体系、业务峰值与历史故障；交接文档必须包含这些本地化信息，否则值班人仍要靠问人才能操作。
文档由谁维护更新？
建议由变更发起人负责同步更新，客户方文档管理员定期抽查。变更单里增加一项是否影响交接文档的勾选，能把更新动作嵌进流程；仅靠交接时的口头约定，三个月后文档就会与实际脱节。