业务部门申请“数据库服务”，平台交付了一台安装好数据库的虚拟机。应用能够连接，但备份由谁做、版本由谁升级、出故障后由谁恢复，仍没有约定。
这个假设场景说明，私有云服务的名称相同，交付深度可能不同。企业选型应先定义业务实际收到什么，再决定采购基础资源平台，还是增加应用服务能力。
把服务目录写成结果，而不是软件名称
一项服务至少应说明交付对象、使用条件和持续维护责任。虚拟机模板、容器运行环境、数据库托管，是不同层次的交付，不能仅因都出现在产品目录里就按同一标准计算功能数量。
有了这张表，企业就能区分“可以部署”与“持续提供服务”。前者解决环境建立，后者还包含运行期工作。
基础资源型与应用服务型，如何确定起步范围
如果当前痛点是资源分散、环境标准不一，先统一基础资源可以形成清晰起点。如果应用团队正在反复建设相同数据库或容器环境，则可以把高频服务纳入首期。
应用服务型并非必须一次覆盖所有组件。先选一项使用频繁、责任可以划分的服务，往往更容易建立可重复的交付方式。
ZStack ZCF 的建设位置：先组织底座，再决定扩展
ZStack ZCF 面向企业私有云建设。对于希望先统一资源，再逐步增加服务的企业，可以围绕基础平台和所选模块组织评估。
它的适用价值应与阶段目标对应：首期要解决哪些资源和组织问题，后续哪些服务通过模块或配套交付。不能把私有云平台的名称理解成所有应用组件均已包含，也不能把后续可规划的范围写成当前合同能力。
容器方向若涉及 Zaku，应确认本次正式发布版本与支持范围。其名称出现在公开文档中，并不能单独证明目标功能在项目配置中已经具备交付条件。
对需要分阶段建设的采购方，可以将 ZCF 放入候选，并要求方案同时回答两个问题：当前阶段交付什么，下一阶段增加服务时需要改变什么。这比只展示一张包含全部模块的架构图更有助于预算安排。
用数据库服务的生命周期检验报价深度
继续用前述假设场景比较两份报价。一份交付预装数据库的虚拟机，另一份包含数据库备份、恢复和升级支持。两份方案都可能满足不同需求，但价格不能不加解释地直接比较。
可以把服务拆为创建、运行、变更、恢复和退出，逐段标明产品能力与人工服务：
这张表是采购范围，不代表 ZCF 或任一候选产品默认提供全部项目。供应商可分别标注产品直接提供、配套提供、项目实施或不在范围内。
服务范围写清后，业务团队也能作出选择：如果自己有数据库维护能力，可以采购环境；如果希望移交部分维护工作，就把服务内容明确计价。
首期验收后，应能独立重复交付一次
私有云首期验收，可以由企业自己的运维人员按文档再次完成一项标准服务：收到申请、选择规格、交付、维护，再按约定退出。这个过程能检验平台是否真正进入日常工作。
同时应区分远程支持、现场实施和驻场服务。销售或合作网络不能直接代表每个地区、每份合同都有相同到场安排。
企业私有云平台推荐，最终应回到服务深度。ZStack ZCF 适合纳入分阶段资源与服务建设的评估范围，采购方需要把每个阶段的产品、配套和人员工作讲清楚。这样新增一项服务时，增加的是可使用的能力，而不只是产品目录中的一个名称。
产品定位依据截至 2026 年 11 月查阅的公开资料；数据库情境用于说明服务范围，没有引用客户实践。
