如何设计自动化依赖链重做平台？
把影响分析、Job / Plan 克隆、状态与日志、止损、运行控制和恢复闭环组织成平台能力，并明确区分真实生产经验与教学演示架构。
把一次事故恢复变成可重复的工程能力
如何设计自动化依赖链重做平台？
前面七篇把一次事故从发现、范围判断、止损、重做、版本边界到下游闭环完整走了一遍。如果每次事故都要靠人工照着重来，恢复速度取决于个人经验。平台设计要做的，是把这套流程固化成可重复、可验证、边界清晰的工程能力。
设计一套重做平台，哪些能力必须做，哪些事情不能声称？
核心概念
依赖链重做平台（Reprocessing Platform）
在现有调度、血缘与数据服务之上，把事故恢复流程固化为可重复能力的工程层：影响分析、平行计划、状态与日志、止损、运行控制和恢复闭环。它消费现有系统的事实，不替代它们。
目标：把恢复流程产品化，不是重写调度器
一次事故恢复里，真正消耗时间的往往不是执行动作，而是判断：影响范围有多大、哪些实例要先停、ODS 验证是否可信、历史日期能不能直接重做、下游要不要重新装数。平台的价值是把这些判断的证据与动作标准化，让不同的人在同一套证据上得出可复核的结论。
因此平台是现有能力之上的编排层：血缘、依赖、状态与消费证据来自既有系统，平台负责把它们组合成恢复流程。把重做平台做成新的调度器，会同时放大维护成本和一致性风险。
- 平台处理恢复流程，不改变调度器与血缘系统的职责。
- 标准化的是证据与动作，而不是替换既有事实来源。
- 目标可复核：同样的证据得出同样的恢复范围与顺序。
六个能力模块
影响分析：联合 SQL 血缘、调度依赖与业务日期分区，输出影响闭包与逐条证据（14-2）。Job / Plan 克隆：为历史日期生成平行计划，绑定 business_date、复用当前依赖、使用最新程序、与正常计划隔离（14-4、14-5）。
状态与日志：显式状态机与按时间追加的日志，停止要确认副作用（14-3）。止损：自动停止 / 阻断受控实例，正常与重做互斥，无关链路不误停（14-3）。运行控制：按依赖顺序自动调用，失败按正常生产故障处理，补数满足跨天依赖（14-3、14-7）。恢复闭环：识别消费证据，重装 / 刷新 / 更正并跟踪确认（14-6）。
- 范围判断决定平台是否可信：漏一个下游就会持续污染。
- 止损与运行控制决定恢复是否安全：互斥与顺序缺一不可。
- 闭环决定事故是否真正结束：确认没有完成就不是完成。
依赖链重做实验 · E8 平台能力与边界
六个能力模块：真实经验与演示架构
逐个查看影响分析、Job / Plan 克隆、状态与日志、止损、运行控制和恢复闭环：每个模块都给出真实生产经验、本专题的演示架构与明确边界，并指向承载它的课程与实验。
正在加载交互实验…
真实经验与演示架构要分开写
本专题的案例、任务、日志与计划都来自教学建模：fixture 是合成的，模拟器不连接真实调度平台，也不执行真实的停止或重跑命令。但其中的工程约束来自真实生产语义：互斥、门禁、依赖顺序、失败处理、日志留痕与消费确认。
设计文档要把两者分开标注：哪些是普遍的生产约束，哪些是本模拟器的实现选择。这样学习者不会把「模拟器内部标识」误当成平台批次机制，也不会把「全局并发数 1」误当成默认配置。
- 真实约束：互斥、门禁、依赖顺序、失败语义、日志与确认。
- 演示选择：合成 fixture、模拟状态机、模拟标识与交互。
- 任何演示标识都要标注用途，不得冒充平台既有机制。
与现有系统的边界
血缘系统提供表与字段关系，调度系统提供实际依赖与运行状态，数据质量系统提供验证结论，数据服务系统提供消费与确认渠道。重做平台把这些事实聚合成恢复决策，但不能假设自己能替代其中任何一个。
边界还包括治理要求：谁有权发起历史重做、哪些操作必须双人确认、通知与报送如何留痕，这些属于组织与流程，工具只能提供证据和闸门。
- 不重造调度器、不代替血缘系统、不实现真实通知渠道。
- 治理与审批属于组织流程，平台只提供可追溯的证据。
- 消费方清单必须来自真实登记，不能靠推测补齐。
放在一起看
做与不做
平台设计中最容易失控的地方，是把能力边界写成产品承诺。
恢复流程的工程底线
- 影响范围可解释：血缘 + 调度 + 分区证据齐全。
- 止损与重做互斥，失败按正常生产故障流程处理。
- 日志时间戳可追溯，消费确认闭环可查询。
超出教学与工具边界的事
- 不接入真实银行数据，不执行真实生产重跑。
- 不引入轮次 / generation 机制，不虚构审批与发布能力。
- 不把模拟器标识、并发策略与命令当成平台通用事实。