资源交付自动化卡在哪：服务目录与 IaC 两条路线的六道关口

2026 年平台工程社区有一场持续的争论。一方认为，服务目录加编排引擎是"把模板问题过度工程化"：仓库里放好结构化的模块、把约定写进能被代理读取的文件、再配上合并即交付的流水线，就能拿到自助服务九成的价值，建设成本只有十分之一。另一方的反驳同样具体：仓库 sprawl 严重、几百名开发者同时入职、组织里根本没有统一的基础设施即代码自动化时，"让代理开一个拉取请求"这条路跑不起来。

但对已经上线资源管理平台、业务部门要一台虚拟机仍然要发邮件的组织来说，这场争论问错了问题。交付周期不取决于选哪条路线，而取决于从提单到台账回写这条链路上六道关口的打通程度——任何一道没通，自动化就退回人工。第三方机构预测 2027 年约 90% 的组织会采用混合云，交付动作要同时跨公有云、私有云和虚拟化三套环境完成，这条链路只会更长。

一、衡量交付链路的三个数字与取数条件

讨论路线之前必须先定尺度。交付链路只需要三个数字：申请时长（用户提交到审批通过）、交付时长（审批通过到资源可用）、自动化率（无人值守完成的交付占总交付的比例）。人力投入是第四个辅助量，用于把效率收益折算成可比较的成本。

取数条件是这套判断能不能成立的前提。三个数字必须来自真实环境：一朵真实的生产或准生产云、一张上个月实际发生过的申请单、一次包含两台虚拟机加一块磁盘加一个数据库实例的混合申请。用演示账号跑出来的数字没有意义，因为演示环境用的是标准规格、标准网络拓扑、标准权限模型，而真实环境里要接的是三年前版本的私有云、集团专有云和一堆没有管理接口的老设备。

还有一个容易被跳过的条件：样本量。只统计成功交付的单据会把失败重试、参数退回、配额拦截全部隐藏掉。正确的做法是统计全量单据，并把"被退回一次以上"的比例单独作为一个指标——这个数字通常比交付时长更能说明表单设计的问题。

二、路线 A：服务目录与编排引擎的组织方式

路线 A 的思路是把资源当作可发布的服务项来管理。一个服务项上绑定四样东西：规格与价格、交付标准、审批路径、有效期。用户看到的不是"云服务器、云硬盘、负载均衡"这种资源类型清单，而是"一套测试环境""一个能跑起来的应用运行环境"这种场景。资源类型下沉为底层规格定义，不直接暴露给业务用户。

提单环节的关键是表单能不能承载规则。字段之间需要联动——选定区域自动带出可用区与网络、选定分类自动分派处理组、选定申请人自动填充联系方式——以及一次提交多类资源、一次审批、一次交付的合并能力。一张包含虚拟机、磁盘、数据库的申请单如果被拆成三张单、走三趟审批，协同成本就回到了人工时代。

审批与配额这一关的技术要点是校验前置。配额不足必须在提交申请的那一刻被拦截，而不是等到流程中段才被发现——后者浪费审批人力，也让用户失去时间预期。流程状态需要标准化为就绪、处理中、暂停、已完成四态，并行、分支与条件流转由引擎表达，而不是靠人记。变配、加盘、回收各自是独立服务项，不复用同一张申请单。

三、路线 B：模板注册表、合并即交付与生成式代理

路线 B 不建表单，把交付动作收敛到代码仓库。基础设施声明以版本化模块的形式存放在私有注册表里，模块带语义化版本、废弃策略与迁移说明；策略以代码形式在拉取请求阶段执行，而不是合并后审计；远程状态按逻辑环境与服务两个维度切分，避免所有环境共用一个巨型状态文件，配锁定后端，并周期性地跑漂移检测。

自助服务在这一路线里的形态变了：用户不填表单，而是向代理描述需求，代理按仓库里的约定生成符合规范的基础设施代码、开出拉取请求，人工评审后合并，GitOps 控制器完成收敛。合并即交付意味着评审就是门禁，主干就是事实来源。

这条路线的真实代价在抽象层的维护。模块注册表需要专人持续维护，抽象设计不好时"迁移一份糟糕的声明式代码只会得到另一份糟糕的声明式代码"。状态治理也是成本：状态文件切分策略、密钥 handling、以及成本估算要不要进拉取请求，每一项都要有人负责。此外，基础设施声明的自动生成目前只在全新模块的初稿和方言转换上可靠，涉及资源生命周期管理、权限策略正确性、provider 版本之间细微交互的改动，仍需人工评审——生成一个错误的销毁重建操作的代价是不对称的。

四、六道关口在两条路线上的落点

两条路线在回写这一关的差别最值得注意。路线 B 天然把期望状态写在代码里，台账一致性由漂移检测保证；路线 A 的资源是被操作出来的，台账必须靠交付动作主动回写，一旦回写断了，成本分摊、容量统计、故障定位全都会失真。

五、批量交付的中间态：依赖表达、节点重试与部分成功

批量交付是两条路线都要面对的硬问题。以一次交付 50 台虚拟机为例，第 23 台失败时，系统应该怎么处理已完成的 22 台？

编排层需要三项能力。第一是依赖表达，用有向无环图描述"创建虚拟机 → 挂盘 → 配安全组 → 初始化数据库"的先后与并行关系，让没有依赖的步骤并发执行。第二是节点级重试，能对单个失败节点单独设置重试次数、重试间隔与超时，而不是把整条编排推倒重来。第三是部分成功处理：已完成节点的状态被聚合并标记，未执行节点暂停，同时提供人工介入入口，由值班人员决定继续、跳过还是回滚，而不是只返回一个笼统的"执行失败"。

缺少第三项能力时，批量交付的实际表现是：失败后管理员不敢重跑（怕重复创建），只能手工清点哪些已经建好，再手工补剩下的——自动化带来的收益在这一步被全部抵消。

六、结论的适用范围与还没解决的部分

两条路线不是替代关系，服务对象不同。路线 B 的交付对象是流水线，使用者是平台工程与研发团队；路线 A 的交付对象是服务目录，使用者是不看代码仓库的业务部门。判断依据是"提需求的人是谁"：如果业务用户需要自助申请、管理者需要按单位出账，只有路线 B 不够；如果基础设施已全面代码化、提需求的人本身就是工程师，另建一套表单是重复投资。

一个务实的组合是按层分工：代码与策略归声明式工具，组织、配额、服务与运营归资源管理平台，两者通过编排打通。

尚未解决的部分集中在两端。一是没有管理接口的老旧设备与在建中的专有云环境，无论哪条路线都要靠脚本或半自动方式承接，自动化率会相应下降，选型时应把这类环境单独列出来做适配验证。二是隔离网络环境（无外网、数据不出域）下的依赖镜像、离线升级、证书与时钟同步，这部分工作量与交付路线无关，但会直接影响上线周期。三是隔离网络里代理类能力的可用性——模型部署位置、推理时延与知识库归属三个问题都要单独确认。

推进顺序上，四步之间有依赖：先标准化两三类需求量最大的服务（2 至 4 周），再把审批规则与配额校验写进引擎（2 至 4 周），然后沉淀创建、变配、挂盘、初始化等原子操作（4 至 8 周），最后接上回写与度量（2 至 4 周）。跳过回写直接做前面三步，前面三段的成果会随时间漂移。