做助贷系统的团队，交付单上通常只写一句"已完成私有化部署"。这句话在工程上没法核——它给的是一个结论，没有留下可以对照的中间物。
结论核不动，中间物可以。环境装起来之后，至少有三个中间物是能单独查的：镜像仓库、备份副本、恢复演练，分别对应版本、数据、流程三件事。
下面逐项说清每一项查什么、怎么查。
一、镜像仓库：版本回不回得去
程序跑起来只是表面。真正决定往后能不能自己维护的，是镜像从哪来、按什么规则打标签、旧版本还留不留。这一项常被跳过，因为交付当天一切正常，没人会想到半年以后要退版本。
- 镜像从哪个仓库拉取。是交付方自建的私有仓库，还是某个公有仓库。公有来源的问题不在于安全性，而在于哪天上游把那个 tag 删掉或覆盖掉，手里这套环境就少了可重建的依据。
- 标签怎么打。用固定的语义化版本号，还是滚动更新的 latest。latest 是一个会移动的名字，今天拉到的和三个月前拉到的未必是同一份东西。
- 回退时取不取得到旧版本。这取决于仓库的保留策略。只留少数几个版本的仓库，回退时往往只能回一步，再往前就断了。
- 仓库在哪，容量多大。这套环境若是走独立部署、落在使用方自己的机器上，镜像仓库通常也在内网。内网仓库要留意的是配额与清理动作。
检查动作：问一句当前版本对应的镜像 digest 是什么，再看仓库里三个月前那个版本还在不在。
二、备份副本：数据回不回得来
备份这件事，问法不同，答案的差别很大。"我们有备份"和"我们有一份能用的备份"，中间隔着好几件事。
- 副本和主库是不是共用一套存储。共用一套存储、甚至共用一台机器，等于两样东西放在同一个篮子里；分散到不同介质、不同位置，才算两份。
- 多久一份，保留几份。频率决定能回到多近的时间点，保留份数决定能回到多远。两个数都要有，只答一个不够。
- 副本能不能被独立读取。有的备份文件必须依赖原来的程序与密钥才能打开，那么这份备份的可用范围，就受限于那套程序和那把密钥还在不在。
- 副本有没有单独加密。如果副本和主库共用同一把密钥，钥匙出问题就是两处一起出。
检查动作：让交付方把副本的存储位置、频率与保留份数写成一行，附在本机目录之外的文档里。
三、恢复演练：流程走不走得通
前两项准备的是东西，这一项准备的是流程。东西备得再全，到时候没有人知道怎么用，等于没备。
- 在什么环境演练。在同构环境里跑（机器配置相同、版本相同、数据量接近），和在开发机上试一遍，得出的结论不是一回事。
- 从开始到业务可用的耗时。这个数只有真跑过才有。没跑过的恢复时间，是估算，不是数据。
- 谁执行，谁在场看。执行人如果是交付方，使用方至少要有人在场，把流程从头看一遍。
- 记录上留下什么。日期、执行人、数据版本、耗时、卡在哪一步。缺了日期的记录，没法证明这件事发生过。
检查动作：要一份带日期的演练记录，看它上一次是什么时候。
四、三者是什么关系
三样东西各管一段，彼此不能替代。
- 镜像仓库管版本——出了状况退不回上一个版本。
- 备份副本管数据——数据缺了一块，有没有一份可用的副本补回来。
- 恢复演练管流程——真出事的时候，这件事有没有人做、要做多久。
前两样是物，第三样是人。只备物不练人，遇到情况仍要现场摸索。
五、常见的几处缺口
从见过的情况看，缺口很少出在技术上，多数出在记录上。
- 副本从来没被打开验证过。备份任务在跑，但没有人确认过文件本身的完整性。
- 演练做过，没有留记录。下次换人接手，这件事等于没有发生。
- 记录里只有一句"已完成"，没有日期也没有耗时。半年后没法判断这份结果还适不适用。
- 镜像只保留少数几个版本。等到要退版本时，发现旧版本已经被清理策略清掉了。
这四处在交付当天问一句就能发现，只是很少有人在那一天问。
六、写进交付清单里
把上面三样各压成一个可核项，交付时逐条对上：
- 镜像仓库：给出镜像 digest 与仓库地址，确认旧版本在保留范围内。
- 备份副本：给出副本位置、频率与保留份数，确认副本与本机分离。
- 恢复演练：给出上一次演练的日期、执行人与耗时。
再往下，还有几处常被并到一起问的事项：操作日志审计要覆盖哪些动作、数据导出权限管控由谁审批、录音归档保留到什么时间、工单流转经手的记录留在哪。这几处有一个共同点——留下的东西能不能被独立地读出来。能被独立读出来的才叫留下；只能通过原班人马才看得懂的，其实还是留在别人那里。
这三行不需要多高的技术门槛。它们的作用是让接手的人在半年之后，仍然知道这套环境当初是怎么交的。我们做鲲极（鲲鹏的鲲）这套系统时，这三项是落在清单里的，而不是在验收会上说一遍就过去。
