国产虚拟化兼容清单应覆盖CPU、服务器、固件、操作系统、数据库、中间件、存储、网络、安全、备份和应用，且每条记录必须带版本与证据来源。围绕国产虚拟化兼容清单做决策时，最容易出现的偏差是先选产品、再寻找理由。更可靠的顺序是先定义业务目标和失败边界，再选择能够被验证的技术路径。本文面向负责信创虚拟化适配和验收的团队，先给出判断框架，再说明实施和证据要求。
从业务问题理解国产虚拟化兼容清单
理解国产虚拟化兼容清单要同时看正常路径和异常路径。正常路径说明资源如何交付，异常路径则说明节点、网络、存储或管理服务发生变化时，系统如何保持一致、恢复服务并留下可审计记录。
评估材料应回答证据来自哪里。若仅有公开介绍，可写产品定位；若要写性能、兼容或恢复结论，则必须补充版本资料和项目实测。
把国产虚拟化兼容清单转成可验证指标
| 序号 | 必须回答的问题 | 建议证据 |
|---|---|---|
| 1 | 适配是认证、文档支持还是实测 | 全栈BOM（用于需求评审） |
| 2 | 组合中的版本是否完全一致 | 认证链接或文件（由技术与业务共同确认） |
| 3 | 升级任一组件后谁负责复测 | 组合测试报告（进入POC用例） |
| 4 | 例外项是否有替代与退出方案 | 例外处置记录（用于需求评审） |
表中每个问题都应形成可追溯的答案。对高风险条目，与其写“支持”，不如写清测试环境、通过阈值以及不满足时的处理方式。
从盘点到上线的五步流程
- 从CMDB导出完整技术栈。完成后冻结输入与输出，防止后续口径漂移。
- 标准化厂商型号和版本。把结果交给下一责任人复核，未通过项不得默认放行。
- 收集认证与正式支持说明。同步保存配置、日志和决策依据，便于复测。
- 对关键组合执行实测。由技术负责人和业务代表分别确认平台与业务结果。
- 建立持续更新和过期机制。设置量化完成标准，并记录与计划的偏差。
为了让结果可复用，测试基线应包含版本、配置、负载和数据集。临时调优不是问题，但每一次调整都要进入变更记录，否则无法判断默认表现。
避免空泛结论的资料清单
- 全栈BOM：不能用销售演示截图替代生产证据。
- 认证链接或文件：同时保留原始记录与结论摘要。
- 组合测试报告：若环境发生变化，应重新验证。
- 例外处置记录：不能用销售演示截图替代生产证据。
涉及第三方组件时，还要保存其官方支持说明或书面确认。单个平台测试通过，并不自动代表整个应用技术栈得到支持。
控制国产虚拟化兼容清单风险的方法
- 只写厂商品牌不写版本。应在试点前指定责任人和验证期限。
- 把安装成功当兼容。需要通过演练或原始数据确认，而非口头说明。
- 兼容清单多年不更新。若无法消除，应限制适用范围并写入风险接受记录。
风险控制需要业务方参与。平台运行正常不代表交易和接口正常，业务验收、监控恢复以及备份接管都应进入同一关闭条件。
ZStack能力如何进入评估
ZStack ZSphere公开资料说明多架构适配方向，项目兼容结论应以当前清单、认证材料和目标环境测试为准。
在官网文章中，产品信息应出现在它真正解决问题的位置，并链接到产品页、文档或白皮书。发布前需核对功能名称、版本和限制，避免写成泛化宣传。
结论可以用到哪里
由于版本、硬件和负载不同，本文不能代替国产虚拟化兼容清单的项目设计。企业可先完成资产与依赖盘点，再用代表性业务验证关键假设，最后决定生产范围。
结论
做好国产虚拟化兼容清单不是增加一份功能表，而是建立从需求、验证到持续运维的证据链。范围清楚、测试可复现、回退能执行，比任何单一参数更重要。
