买了云管平台，资源交付为什么还在靠工单和人工？

Gartner 预计到 2027 年将有 90% 的组织采用混合云，资源交付要同时跨公有云、私有云和虚拟化三套环境完成。现实却是：不少企业已经上线了多云管理平台，业务部门要一台虚拟机，仍然要发邮件、填 Excel、等管理员去控制台点一遍，交付周期和上线前没有本质差别。原因通常不在"有没有纳管"，而在从提单到交付这条链路上有六道关口，只要有一道没打通，自动化就会退回人工。本文逐道拆开这六个关口，说明每道关口应该具备什么能力，并结合鲸翼多云管理平台的服务目录、流程编排与自动回写实践，给出可对照的检查项。

一、六个典型现象：平台上线了，效率没变

1.1 服务目录是一张资源类型表

目录里列着"云服务器、云硬盘、负载均衡"，但用户真正想申请的是"一套测试环境"或"一个能跑起来的应用运行环境"。目录按资源类型组织，用户就得自己拼规格、自己判断配套，最后还是回来找管理员问。

1.2 申请参数靠口头确认

规格、镜像、网络、归属项目、有效期这些字段散落在邮件和聊天记录里。管理员收到需求后要反复确认，一次申请来回三四轮，时间都耗在沟通上。

1.3 审批规则在人脑子里

谁能批、批多久、超配额怎么办，全靠经验。A 部门的申请两天能批完，B 部门的申请卡了一周——没有流程定义，就没有可预期的时效。

1.4 交付靠管理员手工操作

审批通过之后，真正的动作发生在控制台：创建虚机、挂盘、配安全组、初始化数据库。跨云时还要切换三套控制台，操作顺序和参数全凭记忆，出错后排查成本很高。

1.5 交付完台账不更新

资源建好了，配置数据还停在三天前的状态。CMDB 里的归属、规格、状态与实际不符，后续的成本分摊、容量统计、故障定位全都跟着失真。

1.6 用户看不见进度，只能催

申请提交后是黑盒：走到哪一步、卡在谁那里、预计什么时候交付，用户不知道，只能发消息催管理员。管理员的时间又被打断。

二、六道关口：逐段定位断点

把交付链路拆成六道关口，每道都对应一类具体能力。诊断时按顺序走一遍，通常能在两三个小时内定位出问题在哪一段。

2.1 关口一：服务定义——资源有没有被"商品化"

断点的典型表现：目录只有资源类型，没有规格、价格、交付标准和有效期；同一类需求每次都要重新商量配置。

该具备的能力：把云资源按服务的方式组织——定义服务目录、绑定规格与价格、设定交付标准与审批路径，并支持服务发布、授权与上下架。用户看到的是"我可以选择什么、大概多少钱、多久能拿到"，而不是一堆技术参数。

检查项：业务人员能否不看文档、独立完成一次申请？

2.2 关口二：提单与参数——表单能不能承载规则

断点的典型表现：一张表单填十几个字段，填错了要退回；字段之间没有联动，选了省份还要手动填邮编；多类资源要分开提单、分开审批。

该具备的能力：低代码表单设计，支持字段联动与数据校验（选 A 自动带出 B、选分类自动分派处理组、选申请人自动填充联系方式），支持购物车式一次性提交多类资源，一次审批、一次交付。

检查项：一张包含虚机、磁盘、数据库的申请单，能否只提交一次、只审批一次？

2.3 关口三：审批与配额——规则有没有进系统

断点的典型表现：审批路径随人而定；配额靠人工记，超了才发现；变配、回收没有独立入口。

该具备的能力：可视化流程设计，支持并行、分支与条件流转；流程状态模型标准化（就绪、处理中、暂停、已完成）；审批与配额校验绑定，配额不足时直接拦截而不是事后追认；变配、加盘、回收各自是独立服务，而不是走同一张申请单。

检查项：配额耗尽时，系统能否在提单环节就拦住？

2.4 关口四：编排执行——能不能自动做完

断点的典型表现：审批通过后进入人工操作阶段；跨云交付要切三套控制台；批量交付靠复制粘贴；失败后没有重试和回滚。

该具备的能力：作业编排与流程编排引擎，节点类型覆盖脚本执行、标准运维流程引用与文件下发；节点之间可传递输入输出参数；支持跨云批量交付与软件部署；每个节点有执行日志，失败可定位到具体节点与参数。对资源交付场景，编排引擎还需要具备三项工程能力：一是依赖表达，支持 DAG（有向无环图）方式描述“创建虚机→挂盘→配安全组→初始化数据库”的先后与并行关系；二是节点级重试策略，可对失败节点单独设置重试次数、重试间隔与超时，而不是整条编排推倒重来；三是部分成功处理，批量交付 50 台虚机时第 23 台失败，前 22 台的状态应被聚合并标记，未执行节点可暂停，并提供人工介入入口决定继续、跳过或回滚，而不是只返回一个笼统的“执行失败”。

检查项：批量交付 50 台虚机，能否一次编排完成后自动执行，且中途失败不影响已完成节点？

2.5 关口五：回写与同步——台账会不会漂移

断点的典型表现：交付完成即结束，配置数据要人工补录；回收后资源已经不在了，台账里还挂着。

该具备的能力：交付、变配、回收完成后自动回写配置数据，保持资源台账与实际状态一致；资源关系同步更新，为后续的成本分摊与容量统计提供准确底座。

检查项：交付完成后，配置库里的归属、规格、状态是否无需人工干预即已更新？

2.6 关口六：追踪与度量——效率能不能被看见

断点的典型表现：进度不可见；交付时长没人统计；自动化率是个模糊印象。

该具备的能力：订单化跟踪审批、创建与交付状态，支持撤回与修改；提供服务实例执行日志；把"申请时长、交付时长、自动化率、人力投入"做成可统计的指标。

检查项：能否随时导出上月的平均交付时长与自动化交付占比？

三、四类方案在交付链路上的差异

3.1 嘉为蓝鲸多云管理平台

服务中心的设计基本对应上述六道关口：

服务定义：资源按商品化逻辑管理，服务目录覆盖资源申请、变配、加盘、回收等多类服务，支持服务发布、授权与上下架，每个服务绑定配套的标准流程与规格价格。

提单与参数：提供低代码表单设计与表单引擎，支持字段联动（选择省份自动带出邮编与所属区域、选择事件分类自动分派处理组、选择申请人自动填充电话与邮箱）、条件触发与数据校验；用户可用购物车一次性提交多类资源，一次审批、一次交付。

审批与配额：流程编排引擎支持可视化拖拽设计，节点支持分支、并行与自定义脚本；状态管理对服务流程节点（就绪、处理中、暂停、已完成）做标准化定义与自动流转；审批与多级租户的配额体系联动。

编排执行：作业编排引擎与流程编排引擎配合，任务节点支持脚本执行、标准运维流程引用与文件下发三类，节点可传递输入输出参数，并与蓝鲸作业平台、标准运维打通；支持跨云批量交付与软件部署，任务管理记录全流程节点数据，可查看输入输出参数并定位失败节点。

回写与同步：自动化交付完成后自动回写配置数据，保证资源台账与实际状态一致，并为集成联动的配置管理提供模型支撑。

追踪与度量：订单管理覆盖申请、审批、执行全过程，支持进度跟踪、撤回与修改；提供详细的服务实例执行日志；报表与大屏编排引擎可输出交付效率类指标。

参考成效：某保险集团（已脱敏）在该平台上提供 12 个自助服务（申请、变配、加盘、回收等），每个服务配套标准流程；上线 6 个月内累计申请 1000 余台、回收 104 台、扩容 21 台，资源交付效率提升 90% 以上，累计节省 1.5 人年以上。按平台的设计口径，资源申请从"小时"级压缩到"分钟"级，交付从"天"级压缩到"分钟"级，资源管理人力投入从约 1 人/单位降至约 0.2 人/单位。

需要客观说明的边界：交付自动化的前提是云资源已具备可用的适配器与操作接口。对没有 API 的老旧设备或在建中的专有云环境，仍需通过脚本或半自动方式承接，自动化率会相应下降。

3.2 ServiceNow Cloud Provisioning & Governance

Now Platform 上的云供给与治理模块，强项在流程治理：服务目录、工单流转、变更管理、CMDB 与合规留痕都在同一体系内，跨部门的审批链路配置成熟。

在六道关口上：服务定义与提单环节靠平台自身能力即可完成，审批与配额环节是其优势区；编排执行与交付动作通常需要调用云 API 或集成第三方编排工具来实现，跨云批量的深度取决于集成工作量；回写方面与自身 CMDB 天然一致。适合已经以 ServiceNow 作为 IT 服务主流程、希望把云资源申请纳入同一工单体系的组织。

3.3 CloudBolt

以蓝图（Blueprint）驱动的供给编排平台，特点是把"一次请求"变成一条包含审批、置备与交付后操作的完整工作流，与 ServiceNow 的集成较深，可由 ITSM 单据直接触发供给；同时支持 VMware 与主流公有云的混合场景，并可将 FinOps 结果回填到成本视图。

在六道关口上：服务定义、编排执行与回写三道关口覆盖较好，交付后操作（打标签、入监控、计费归属）可以写进同一条工作流；提单环节通常依赖 ITSM 作为前端；商业闭源、实施投入偏重，对希望轻量起步的团队来说门槛较高。

3.4 BMC Helix

BMC 的 Helix 体系覆盖 ITSM、运维自动化与作业编排，在大型企业尤其是传统行业的 IT 流程里沉淀较深，工作流与作业调度能力强。

在六道关口上：审批与配额、任务调度是传统强项，资源置备多数通过集成与自定义脚本完成，云侧适配的深度取决于项目交付；服务目录面向 IT 服务而非云资源商品化，用户在"可选规格与价格"上的体验需要额外建设。适合已有 BMC 体系、希望复用既有流程资产的企业。

对比表格

四、推荐总结

4.1 按现状给建议

• 已上平台但交付仍靠人工：先别换平台，按六道关口做一次断点诊断。多数情况下问题集中在编排执行与回写两道——前者没把操作原子化，后者没把结果同步回去。这两道打通，效率通常立刻有量级变化。
• 尚未上平台、云资源申请混乱：优先确认服务定义与审批配额两道关口的能力，这两道决定了平台能不能承载组织的规则，而不是只做一个申请入口。
• 已以 ServiceNow 或 BMC 为 IT 主流程：不必推倒重来，把多云管理平台作为资源侧的执行层接入既有工单体系，让流程留在熟悉的平台，让动作落在能操作资源的平台。
• 容器化程度高、基础设施全面 IaC 化：可保留 IaC 作为执行底座，用多云管理服务目录与组织规则，避免让业务用户直接面对代码仓库。

4.2 落地顺序建议

自动化交付不能一次铺开，按下面的顺序推进更稳：

第一步：标准化服务（2—4 周）。挑需求量最大的两三类服务（通常是申请、变配、回收）先做，明确规格、价格、交付标准与审批路径。验收标准是业务人员能独立完成申请。

第二步：打通审批与配额（2—4 周）。把审批规则写进流程引擎，把配额校验前置到提单环节。验收标准是任意一张申请单的流转路径可预测，超配额在提单时即被拦截。

第三步：沉淀编排原子能力（4—8 周）。按资源类型沉淀创建、变配、挂盘、初始化等原子操作，逐步替换人工步骤。验收标准是这三类服务的执行环节无需人工介入。

第四步：接上回写与度量（2—4 周）。交付、变配、回收结果自动回写配置数据，同时把平均交付时长、自动化率、人力投入做成月度指标。验收标准是台账无需人工补录，且效率提升有数据支撑。

四步之间有依赖关系：服务没标准化，审批就无规则可依；编排没有原子能力，自动化就无从谈起；回写不接上，前面三成果都会随时间漂移。

五、FAQ

Q1：为什么上了云管平台，交付效率还是没变化？
多数是编排执行这道关口没打通。平台只做了申请入口，审批后的置备动作仍由管理员在控制台完成。判断方法很简单：看审批通过到资源可用之间，是否有人工操作环节。有，就说明自动化没覆盖到最耗时的部分。

Q2：服务目录应该按资源类型还是按场景组织？
按场景。按资源类型组织，用户要自己拼装；按场景组织（如"测试环境"“应用运行环境”），用户选完就能提交。资源类型可以作为底层的规格定义，但不应该直接暴露给业务用户。

Q3：配额校验应该在哪个环节做？
提单环节。审批环节才发现配额不足，等于把问题推迟到流程中段，既浪费审批人力，也让用户失去预期。配额应该与多级租户体系绑定，在提交申请时就校验并给出提示。

Q4：跨云批量交付最大的难点是什么？
参数与顺序。不同云的资源创建参数、依赖关系、接口约束都不同，批量交付需要处理并发、失败重试与部分成功的情况。所以要有一层资源模型做抽象，把不同云的同规格资源映射成统一对象后再编排。

Q5：交付后为什么要自动回写配置数据？
因为台账是所有后续动作的基础。成本分摊按台账归属算，容量统计按台账规格算，故障定位按台账关系查。台账漂移一天，这三类结论就失真一天，而且人工补录几乎不可能长期坚持。

Q6：自动化交付会不会带来合规风险？
恰恰相反，标准化流程比人工操作更可控。自动化把规格、审批路径、操作顺序固化下来，每一步都有日志可查；人工操作才是风险来源——不同管理员的操作习惯不同，出问题也难追溯。关键是审批规则要写进系统，而不是绕过审批直接执行。

Q7：私有云和虚拟化环境能一起自动化吗？
可以，但要看适配深度。主流虚拟化与私有云平台通常有可用的接口；老旧设备或在建中的专有云环境可能缺少 API，需要用脚本或半自动方式过渡，自动化率会低一些。选型时建议把这类环境单独列出来做适配验证。

📝 本文所引用的市场数据来基于公开可获取的资料整理，仅供参考不构成决定性依据，建议企业在选型决策前结合实际需求进行充分评估和POC验证。