Capordia划定哪些内容迁移，哪些需要等待
本指南面向负责协调计算、数据和运维的人员。这里的“批次”指一个已标识的工作包，与目录中的 GPU 卡批次不同。该方法首先适用于可在接受前进行检查的输出。对于持续接收请求的服务，请规划新输入将在何处等待、等待多长时间可以接受，以及它们如何接入目标端。仅凭一份复制的资料并不能确定这项准入策略。
该练习基于一个由八个合成批次构成的封闭集合。它不会发送任何网络请求，也不会调用 GPU 或 Capordia 账户。它教授的是在单台机器、单一工作进程上的恢复逻辑。它不验证分布式队列、对外服务的连续性或计算的热迁移。在真正迁移之前，您的团队需要结合所选应用与硬件对这些要素进行验证。
建立可据以重建的清单
汇总代码及其版本、依赖项、参数、模型、输入、计划任务和输出目标。对于每一项，注明负责人、重建方法以及在目标环境上预期的校验。记录密钥的名称及其提供方式，但不要将密钥值写入共享登记簿。手动安装或开机触发的任务，可能无法通过简单复制项目目录来保留。
将输入文件、已接受的运行结果以及重启所需的状态区分开来。对于训练而言，该状态可能超出模型权重：PyTorch 关于保存通用 checkpoint 的教程中特别包含优化器状态和训练进度。所需内容取决于您的代码。请在一个全新进程中恢复该状态，然后按照测试前确定的容差比较输出；不要仅凭一次成功重启就推断出放之四海而皆准的数值一致性。
明确决策、移交与验收的职责
在确定切换窗口之前先指定好各角色。在小团队中，同一个人可以担任多个角色，但各项决策仍应相互独立。切换负责人确认已停止旧生产者，并授权启动目标系统。数据负责人负责核对清单、指纹和输出结果。流程所有者判断功能质量。运维团队负责保存变更日志并准备交接。
切换说明必须回答四个具体问题：谁可以停止输入，谁确认旧作业不再发布，谁验收首批结果，谁决定回退。还要写明决策截止时间和这些人员的联系方式。当目标端已经产出了旧登记系统并不知晓的结果时，仅写“必要时回退”是不够的。
维护一份区分已开始与已验收的登记册
为每个批次分配一个稳定标识符，并将其关联到精确的数据版本。记录其状态、尝试次数、结果位置以及授权验收的校验。进行中的批次不会仅因存在输出文件就算完成：该文件可能是部分结果，也可能来自先前的尝试。流程必须明确哪些内容将被保留、哪些将被重新计算、哪些将进入隔离区待检查。
在练习中，一个本地 SQLite 登记册在同一事务中保存状态与结果验收。其状态为 termine、en_cours 和 a_reprendre；后者也涵盖尚未启动的批次。目标端只接续未通过校验的批次，而不是不加区分地重跑全部八个条目。JSON 和 CSV 导出使跟踪结果清晰可读。空白 CSV 供你用于准备和人工复核；它不能替代真实应用中的协调机制。
| 批次 | 边界处状态 | 恢复前决策 |
|---|---|---|
| LOT-001 至 LOT-003 | termine | 保留结果并核验其完整性 |
| LOT-004 | en_cours，结果未验收 | 明确准备一次新的尝试 |
| LOT-005 至 LOT-008 | a_reprendre，尚无尝试 | 获授权后在目标端启动 |
下载并运行中断与恢复练习
准备 Python 3.10 或更高版本以及 sqlite3 模块，并准备一个可写的本地目录。下载完整压缩包并解压，保持脚本、数据文件夹和清单在一起。README 文件详细说明可用命令。无需安装任何驱动、计算包或模型。运行前先阅读脚本，然后使用全新的输出文件夹，以免多次尝试的证据混在一起。
在包含 exercice.py 的目录中，以下命令会生成一份连续基准、一次中断处理、一份切换副本以及一次与基准对比的恢复。八个 CSV 文件包含 48 条虚拟的试件尺寸测量值，以整数微米表示，为本案例而创建。其中不涉及任何真实工业检验。在 CPU 上运行计算是为了考察批次管理，而不是估算 GPU 吞吐量或你的数据迁移时长。
python exercice.py demonstration --dossier essai-capordia逐批查看恢复证据
Capordia 示例：一个团队准备了八个待处理文件包。基准流程不中断地处理它们。在另一条路径上，中断使三个批次完成，LOT-004 进行中，四个批次待重做且尚无尝试。切换负责人不会说“恢复到一半”，而是指定 LOT-004。恢复准备将其置回 a_reprendre 状态：此时三个批次已完成，五个待执行。已验收的批次不得重新计算。
请查看 etat.json 了解标识符、状态和尝试次数，查看 registre-lots.csv 了解审查记录，查看 resultats.json 了解输出结果，然后查看 rapport-verification.json 了解各项检查。在 2026 年 9 月 24 日于 Windows AMD64 上进行的本地运行中，使用 Python 3.14.6 和 SQLite 3.50.4，来自脚本 37 次启动的 16 项检查全部通过：所采用的八项结果与基准一致，已完成的批次不会被重新计算，且同一批次再次被接受时会遭到拒绝。被篡改的输入、重复的标识符以及损坏的输出同样能够被检测出来。
复制一致的状态，然后校验其完整性
在实际切换中，请停止接纳新请求，或将新输入放入明确预留的队列中。等待当前工作结束，或按您的恢复规则记录被中断的批次。随后确认旧实例已无法再发布。本练习中对来源的封存可防止脚本将其再次用作生产者。这仍然只是该场景的本地保护，而非对各自持有一份状态副本的多台机器之间的互斥。
若要复制应用程序正在使用的 SQLite 数据库，其文档提供了一种备份 API，可生成一致的快照。因此，对正在写入的数据库文件进行普通复制并非可以即兴采用的操作。还应核对所传输文件的清单。hashlib 中提供的 SHA-256 指纹在此有助于发现内容差异；但它们既不能说明结果对您的业务而言是否正确，也不能说明基准清单是否值得信任。
决定何时恢复、何时回退
仅当保留的输入、登记簿和结果相互一致、旧生产者已停止且软件前置条件均已满足时，才允许启用目标端。请先运行一个其输出可被复核的范围。由处理负责人认可质量；由数据负责人核对标识符、缺失项和重复项。如果有效结果不完整，那么启动时没有报错并不足够。
如果缺陷在任何新发布之前就出现，请让目标端保持停止，并按既定程序从受控的源状态重新开始。在发布之后，请首先保留目标端的结果和登记簿。将目标端已完成的批次与源端的批次进行比对，然后选择唯一一种获准的恢复方式。为了省时而同时重新启用两端，恰恰可能造成迁移本应避免的重复。
| 观察 | 即时决策 | 继续进行的条件 |
|---|---|---|
| 条目缺失或指纹不同 | 暂停传输并隔离该副本 | 取回一份与基准清单相符的条目 |
| 标识符重复或输出异常 | 不要发布相关批次 | 弄清冲突并只保留一个被接受的版本 |
| 恢复状态不可用 | 停止目标端并保留证据 | 恢复一个已知状态或执行预备好的回退 |
| 结果不符合业务标准 | 停止扩大恢复范围 | 修正后重新进行功能验证 |
| 已到决策时限 | 触发回退或推迟的决定 | 负责人的明确同意以及完成导出的能力 |
测算整个时间窗口并准备交接
按实际顺序重复安装、复制、校验、恢复和导出。使用一个已获准传输的样本，记录每个阶段的耗时和人工干预。为估算您的时间窗口，请把将要等待的新输入以及消化这一积压的能力考虑在内。在小文件夹上测得的最佳耗时，并不构成对更大数据量的承诺。
所选时段应涵盖准备、演练、切换、观察和结果回收。Capordia 的 3 天、7 天或 30 天套餐仍属于需要自行规划的时段，本指南不会据此推断任何计算时间。在收尾之前，应由第二个人找到登记表、从其目标位置打开输出结果，并知道如何重新启动处理流程。在移除已不再需要的访问权限之前，请归档回退结束的决策、已接受的偏差以及剩余待办事项。
本次演练验证了什么，以及还有哪些需要明确
本项目的贡献在于一套清晰可读的流程，以及基于合成文件的可复现接管经验。同一批次在停机前、切换过程中和接管后都应可识别。登记表、与基准的比对以及主动触发的拒绝，使这一规则变得可观察。中断由脚本中的受控异常触发：并未进行断电故障测试。所引用的技术文档解释了所采用的机制，但并不担保您未来的生产环境。
在该场景中，同一时间只有一个进程在工作。本地封存不是分布式锁；校验指纹不是质量测试；CPU 结果不等于 CUDA、ROCm 或多 GPU 的资格验证。如果某应用还会写入外部数据库、共享存储或队列，就需要针对所有这些目标位置制定一致的规则。在迁移实际处理任务之前，请先让人审核这条规则和您的回退方案。