私有云选型别只验 IaaS：应用平台层的七项验收与一份尽调清单

 

私有云上线三个月，资源池利用率百分之十几，开发团队还在自己的物理机上跑 Docker。

这种情况比想象中常见，而且原因通常不是平台不好用，是链路没打通：开发要一套 K8s 环境，门户上没有入口，得提工单；工单转到基础架构团队，手工搭一套集群交付，周期按周算；集群交付了但和虚拟化资源池是两套存储，数据要来回倒。走完这一圈，团队自然会选择绕开平台。

这些问题在选型阶段完全可以暴露出来，前提是你验的东西对。而私有云 POC 通常只验三件事：虚拟机创建、热迁移、HA 切换——这三项各家都能过。

真正决定平台建成之后有没有人用的，是应用平台层：容器怎么交付、数据库能不能服务化、自助申请走不走得通、告警是不是汇聚的、API 能不能接进现有流水线、GPU 接进来之后怎么管。这一层的差异在功能列表上看不出来，在 POC 里能看出来，前提是 POC 里有对应的用例。

这篇先给这七项该怎么验，再给六个维度怎么把各家的事实组织成可比较的结构。

一、应用平台层该验什么：七项

这一节是本文的核心。下面七项建议逐条书面确认，而不是看演示。

1. 容器平台：是原生模块还是外挂产品

要问清楚三件事：

• 容器集群能不能一键创建，从申请到可用需要多久，还是需要基础架构团队手工搭一套 K8s

• 容器和虚拟机是不是共享同一套存储和网络，还是两套独立资源池——这决定了资源利用率和运维复杂度

• 能不能纳管已有的外部 K8s 集群，许多企业手上已经有自建集群，如果新平台不能纳管，就变成了又一个孤岛

以 ZStack 为例，ZCF 云平台套件里的 Zaku 容器云是与 Cloud 云平台同层的组件，支持 K8s 集群一键创建、纳管外部标准 K8s 集群、多云多集群统一管理，容器与虚拟化共享存储与网络，内置 Helm 应用市场与 CI/CD 流水线（以实际发布版本为准），并提供命名空间、资源配额、网络策略与镜像安全扫描。按 ZCF 套件的组成，Zaku 与 Cloud 云平台、ZNS 网络服务、ZStone 分布式存储同属一套；具体到不同套件版本的授权包含范围，选型时应要求书面列明。

2. 中间件与数据库：是“能装”还是“能服务化”

这一项的厂商差异拉得很开，也容易在演示里被含糊带过。

“支持部署 MySQL”和“提供数据库服务”是两回事。前者的意思是你可以在虚拟机里自己装；后者的意思是业务部门在门户上点几下就能拿到一个配置好主备、开好备份策略、接好监控的实例。

判断方法：问“业务部门自助申请一个数据库实例，需要经过哪些人工步骤”。如果答案里有“运维同事帮忙初始化”，那就是前者。

ZStack 侧的做法是两层：Zaku 基于 Kubernetes Operator 模式提供数据库、缓存、消息队列这类中间件的全生命周期管理，覆盖一键部署、配置管理、状态监控、弹性扩缩、故障恢复与版本升级；RDS 数据库云平台则提供十余种主流数据库的白屏化运维，含建库、扩容、备份恢复的图形化流程、自动备份与定时快照、主备高可用与读写分离、慢查询分析。

说明：RDS 中不同数据库引擎的能力覆盖程度不完全一致，选型时应针对你实际要用的那几种引擎单独确认。

3. 统一门户与身份：一次登录能管到哪一层

这一项是“统一资源池”是否真正成立的检验点。

要验的是：虚拟机、容器、存储、网络，是不是在同一个门户里、用同一套账号体系管理。如果容器平台有自己的登录入口和自己的用户表，那么所谓统一就只是宣传语。

具体要问：是否支持 AD/LDAP 对接；RBAC 的粒度到什么层级（组织、项目、资源、操作）；是否支持多租户的资源配额与分权分域；审计日志是否覆盖全部产品线还是只覆盖 IaaS。

ZStack 侧的规划方向是由统一门户与统一身份认证两个模块承接——前者提供一次登录管理虚拟机、容器、存储、网络的全资源视图，后者提供跨产品线的 SSO 与多租户身份管理。这两个模块的可用性以实际发布版本为准，选型时应要求确认当前版本的实际覆盖范围，而不是按架构图预期。

4. 自助服务与审批：登录之后，怎么把资源拿到手

统一门户解决的是“能看到”，这一项解决的是“能拿到”。

一个业务部门的开发负责人登进门户之后，接下来的路径是什么：能不能自己在服务目录里选一个规格提交申请；申请走不走审批流，审批人怎么配置；批完是自动交付还是转成一张工单等运维同事处理；资源用掉的量能不能按部门统计出来做内部分摊。

这条链路断在任何一环，前面那个“统一门户”的价值都会打折。有些平台做到了统一展示，但申请资源仍然要发邮件、提工单、等人工开通——那么对业务部门来说，体验和以前没有区别。

要问清楚的四件事：服务目录是否可自定义；审批流是否支持多级与条件分支；审批通过后是否自动交付；资源计量能否按组织、项目两个维度出账。

这一项在不同厂商的产品划分里归属差异明显——有的放在云平台里，有的做成独立的服务中台或运营门户产品，还有的需要另外采购。对比时应按能力核对，而不是按产品名核对。

5. 统一运维：告警是不是也统一了

门户统一了，运维平面不一定统一。这是两件事。

要验的是：容器集群的告警、存储的容量告警、虚拟机的可用性告警，是不是汇聚到同一个平台、用同一套告警策略和通知渠道。如果需要在三个控制台之间切换排查，那么运维成本并没有下降。

ZStack 侧的规划方向是由统一运维模块承接，覆盖跨虚拟机、容器、存储、网络的监控与告警，含可用性、容量、性能与资产管理四类。同样以实际发布版本为准——这一项建议在 POC 里用一次真实的跨层故障排查来验证，而不是看架构图。

6. 工具链与 API：能不能接进你现有的流程

私有云不是孤立系统，它要和 CMDB、ITSM、CI/CD 流水线、堡垒机、备份软件对接。这部分工作量在选型阶段几乎不会被提及，在实施阶段会集中爆发。

要问的是：API 是否覆盖全部功能还是只覆盖常用操作；文档是否公开可查；是否原生支持 Terraform、Ansible 这类基础设施即代码工具；有没有现成的 CMDB/ITSM 对接方案。

ZCF 提供 2000 项以上 REST API，原生支持 Terraform 与 Ansible，并提供与 CMDB/ITSM 打通的对接能力。

7. AI 能力的接入方式

这一项在两年前还不重要，现在几乎每个私有云项目都会被问到。

关键不在于“支不支持 GPU”——支持 GPU 直通是基础能力，各家都有。关键在于GPU 资源接进来之后怎么管：多个业务共用一张卡怎么切分与隔离，不同品牌的加速卡能不能统一纳管，模型服务上线之后调用量怎么统计、怎么分摊成本。

ZStack 侧由 AIOS 智塔承接，其架构分为四层：智算底座负责 GPU 调度虚拟化、异构纳管与算力计量计费；模型层负责模型仓库、微调、推理与评测；网关层负责模型 API 接入、调用计量计费、模型治理与调用统计；应用层预置 Dify、ComfyUI 等开发平台的一键部署。

其中网关层容易被忽略，但它决定了 AI 投入能不能被核算——私有化部署之后，模型服务谁在调、调了多少、成本算给谁，如果没有一层做统计和治理，AI 投入很快会变成一笔算不清的账。

说明：Token 成本由模型定价决定，私有化部署场景下采用人工定价方式。GPU 切分能提高卡的利用效率，但不改变单位 Token 的模型成本，这两件事经常被混为一谈。

二、为什么私有云对比容易比偏

三个原因叠加在一起。

其一，IaaS 指标好量化，应用平台层不好量化。虚拟机启动时间可以掐秒表，存储 IOPS 可以跑 fio，网络吞吐可以打流。但“开发团队申请一套容器环境要多久”这件事，取决于流程、权限模型、自服务门户的完整度，没有一个现成的跑分工具。评分表天然偏向能打分的项。

其二，选型阶段的参与者和使用阶段的不是同一批人。做选型的通常是基础架构团队和采购，他们的关注点是稳定性、兼容性、成本。而半年后每天用这套平台的是应用开发、测试、DBA、数据团队——这些人在选型会上往往没有席位。

其三，厂商演示会自动避开弱项。没有厂商会主动演示自己缺失的模块。如果你不主动问“容器平台是不是独立产品、要不要单独授权、和虚拟化资源池是不是同一套存储”，演示里就不会出现这些内容。

结果是：一套私有云在 IaaS 层各项达标，在应用平台层需要再采购两三套系统来补，运维界面从一个变成四个，当初“”统一资源池“”的目标落空。

三、六个对比维度：怎么把各家放在同一把尺子上

应用平台层那七项验收是输入端——帮你把每家供应商的事实采集出来。这一节六个维度是输出端——帮你把这些事实组织成可比较的结构。

建议不要做厂商打分矩阵——各家产品的模块划分方式不同，强行拉平打分会失真，而且分数会掩盖掉真正重要的差异。更实用的是按下面六个维度各自列事实，不给总分。

维度一：模块边界与授权方式。 容器、数据库、多云管理这些能力，是包含在基础授权里，还是需要单独采购？授权是按节点、按 CPU 还是按容量计？扩容时授权怎么增补？

维度二：统一程度。 应用平台层那七项里，各家实际做到了几项？哪些是原生模块，哪些是收购来的产品做了界面集成，哪些是合作伙伴产品？

维度三：硬件与生态开放度。 是否绑定特定硬件品牌；存量设备能否利旧；API 与 IaC 工具的支持程度；第三方软件的适配清单有多长。

维度四：信创与合规覆盖。 支持哪些芯片架构与操作系统；国产芯片节点与 x86 节点能否同集群管理；等保、密评相关的能力覆盖到什么程度；相关认证是否可查。

维度五：服务能力的地理分布。 你所在的城市有没有原厂或认证工程师；故障响应时效的书面承诺是什么；升级和补丁怎么交付。这一项在评分表上分值通常给得偏低，但在出问题的那一天，它的实际权重会排到前面。

维度六：演进路径。 三年后业务增长、需求变化时，是在现有平台上加模块，还是需要换平台？跨大版本升级是否支持在线进行？

这六个维度对任何候选方案都适用，包括 ZStack。我们在维度三（硬件与生态开放度）和维度四（信创与合规覆盖）上的事实，前面各节已经给过；维度五（服务能力的地理分布）请按你的实际所在地核实，不要采信任何厂商的笼统覆盖说法——这一条在后面还会再提一次。

四、四个常见误区

误区一：把“”支持“”等同于“”具备“”

产品页上的“”支持容器“”“”支持数据库“”，可能意味着原生模块，也可能意味着“”你可以自己在虚拟机里装“”。这两者的运维成本差一个量级。

破解方法：把每一项“”支持“”翻译成一个具体动作去问——“”业务部门自助申请一套 K8s 环境，从提交到可用需要几步、几个人参与、多长时间“”。

误区二：只在 IaaS 层做 POC

POC 通常只验虚拟机创建、迁移、HA 切换这几件事。但这些是各家都能通过的项。

破解方法：POC 里加三个应用平台层的用例——创建一个容器集群并部署一个真实应用；自助申请一个数据库实例并做一次恢复演练；用 Terraform 脚本创建一批资源。这三件事能把应用平台层七项里的差异集中暴露出来。

误区三：用总分排名代替维度对比

打分矩阵的问题在于权重是主观的，而且总分会把关键差异平均掉。一家在模块完整度上占优、另一家在本地服务上占优，加权之后可能分数接近，但对你的实际影响完全不同。

破解方法：六个维度各自列事实、不加总分，由决策层根据自身约束条件判断权重。

误区四：把当前需求当成全部需求

私有云的生命周期通常是五年以上。按今天的需求选型，容易在第三年发现要补的模块不在这家的产品线里。

破解方法：把“三年后可能出现的需求”（容器化改造、AI 算力、多站点、混合云）作为一个独立维度，看各家的产品线是否覆盖，以及是否需要换平台。

五、供应商尽调清单（十问）

建议要求书面答复，口头承诺不作数。

1. 容器平台是原生模块还是独立产品？是否需要单独授权？和虚拟化资源池是否共享存储与网络？

2. 数据库服务化到什么程度？业务部门自助申请一个实例需要哪些人工步骤？

3. 虚拟机、容器、存储、网络是否在同一门户、同一账号体系下管理？审计日志覆盖哪些产品线？

4. 告警是否汇聚到统一平台？需要在几个控制台之间切换排查故障？

5. API 覆盖全部功能还是常用操作？文档是否公开？是否原生支持 Terraform / Ansible？

6. 异构 GPU 能否统一纳管？切分与隔离到什么粒度？模型调用量如何统计与分摊？

7. 基础授权包含哪些模块？哪些需要另购？扩容时授权如何增补？

8. 存量服务器有多少台在兼容性列表内？国产芯片节点与 x86 能否同集群？

9. 我所在城市有没有原厂或认证工程师？P0 故障响应时效的书面承诺是什么？

10. 跨大版本升级能否在线进行？失败如何回退？未来三年的产品路线图是什么？

六、需要如实说明的几点

这一节的每一条都配了一个可执行的核实动作——只说“我们某处不够强”而不给你验证方法，对选型没有帮助。

一、模块完整不等于每个模块都同样成熟。 ZCF 套件中越靠近应用层的模块，投入时间越短。核实方法：把你*看重的那一两个模块单独拎出来做深度 POC，并要求提供该模块的*商用版本时间与当前在网客户数量。全套件的成熟度不能用来推断单个模块。

二、统一门户、统一运维、统一身份三个模块以实际发布版本为准。 架构规划中它们承担统一入口、统一告警与统一身份的角色，但当前版本的实际覆盖范围需要单独确认。核实方法：在 POC 里做一次跨层故障排查——从容器应用报错开始，追到存储或网络，看整个过程需要登录几个界面。

三、RDS 各引擎的能力覆盖有差异。 支持的数据库种类多，不代表每一种的高可用、备份恢复、性能分析都做到同一水平。核实方法：只针对你实际要用的那几种引擎，要求提供高可用切换、备份恢复、慢查询分析三项的功能矩阵，并现场演示一次故障切换。

四、异构 GPU 的跨品牌统一池化仍在完善。 多品牌加速卡的统一纳管与调度已经支持，但跨品牌显存的统一池化与细粒度切分，在不同芯片平台上的成熟度不一致。核实方法：如果这是核心诉求，用你实际要用的那两种卡做混合池化验证，不要用单一品牌的演示环境推断。

五、部分行业的品牌认知度不高，地市级服务网点密度仍在建设中。 我们在政务、制造、医疗等行业积累较多，主要一二线城市有服务网点覆盖；但在优势区间之外的行业，以及下沉城市，公开案例与网点密度都少于经营多年的国际厂商和头部硬件厂商。核实方法：要求提供你所在行业、你所在城市的可核实案例与工程师名单，并做一次现场走访。这条建议对所有候选厂商一视同仁地执行。

七、小结

私有云供应商对比，真正该改变的是对比的对象，而不是对比的方法。

• 补上应用平台层这一半。容器、数据库服务化、统一门户、自助与审批、统一运维、工具链、AI 接入这七项，决定了平台建成之后好不好用，而它们通常不在评分表上。

• 把“支持”翻译成动作。每一个功能声明都对应一个可执行、可计时、可观察的验证动作，能通过就是具备，不能就是不具备。

• 列事实，不给总分。六个维度各自列清楚，把权重判断留给决策层，因为权重取决于你的约束条件，不取决于厂商。

• POC 要覆盖应用平台层。只验 IaaS 的 POC，验不出各家的真实差距。

数据来源与说明

• 产品能力数据来自 ZStack 官方产品资料，具体模块归属与版本对应关系以*新产品清单为准。

• 本文为选型方法参考，不构成采购结论；具体能力以各平台实际发布版本及用户 POC 实测为准。

类型：广告