在国产操作系统上验证研发平台的安装、升级和恢复，关键是把三类动作拆成可复算的验收项：安装看首次部署成功率与依赖满足情况，升级看升级成功率、数据迁移完整性和回退可用性，恢复看备份还原点与恢复时长。每项都要写明样本数、时间窗、分母和通过标准，并在同一套信创环境基线上重复执行，避免把单次成功当成整体结论。
要点总览（TL;DR）
- 安装、升级、恢复要拆成三类独立验收项：安装看首次部署成功率与依赖满足情况，升级看升级成功率、数据迁移完整性和回退可用性，恢复看还原点与恢复时长。
- 每项指标写明分子、分母、时间窗和单位；分母为零或样本不足时标注“样本不足”，不计算比率，也不写成0%或100%。
- 三类动作在同一套信创环境基线上按安装、升级、恢复的顺序执行，记录操作系统、CPU、数据库版本组合，换环境就重新记录，不合并计算。
- 证据以安装升级日志、配置与数据快照、恢复记录为主，按“指标—样本编号—证据文件—结论”建立索引，保证第三方可复算。
- 单轮通过只代表当时基线和样本范围内的结果，不能推断长期稳定；适配认证与版本兼容以厂商适配清单和认证信息为准。
验证要回答的三个问题与通过标准
安装、升级、恢复对应三类不同的风险，验收目标不能混在一起。安装验证回答“平台能否在目标国产操作系统上从零部署成功”；升级验证回答“从既有版本升级后，功能与数据是否完整，出问题能否回退”；恢复验证回答“发生故障或误操作后，能否从备份还原到可用的业务状态”。三类动作各自有独立的通过标准，最终结论才具备可解释性。
通过标准的设定要落到可观察的结果上。安装类可以设定“在指定版本组合下，首次部署成功率达到约定阈值，且失败项均有明确原因归类”；升级类可以设定“升级成功率达到约定阈值，升级后核心数据条数与升级前一致，回退演练成功”；恢复类可以设定“在约定恢复时间目标内完成还原，还原后关键业务数据可读可用”。阈值由团队根据业务重要性和历史基线确定，本文不给出通用达标线。
统一基线环境是三类结果可比的前提。国产操作系统涉及不同发行版，CPU 架构和数据库组合也会影响安装与升级行为。每次验证都应记录操作系统名称与版本、CPU 架构、数据库版本、中间件版本和平台版本，形成一份环境基线清单。同一轮验证中，安装、升级、恢复都在该基线上执行，换环境就要重新记录，不能把不同基线的结果合并计算。
| 验证类型 | 要回答的问题 | 通过标准示例 | 关键观察对象 |
|---|---|---|---|
| 安装 | 能否在目标国产操作系统上从零部署成功 | 首次部署成功率达到约定阈值，失败项有原因归类 | 依赖包、系统服务、端口、权限、初始化脚本 |
| 升级 | 升级后功能与数据是否完整，能否回退 | 升级成功率达到约定阈值，数据条数一致，回退演练成功 | 数据库迁移脚本、配置文件、插件、回退包 |
| 恢复 | 故障后能否还原到可用状态 | 在约定恢复时间目标内完成还原，关键数据可读可用 | 备份文件完整性、还原脚本、恢复后登录与核心流程 |
指标与范围：样本、时间窗与分母
指标要能复算，必须写清分子、分母、时间窗和单位。安装成功率的分母是“在统计时间窗内发起的安装尝试次数”，分子是“其中首次部署成功且通过基础健康检查的次数”。升级成功率的分母是“在统计时间窗内发起的升级尝试次数”，分子是“升级完成且升级后校验通过、无需回退的次数”。恢复成功率的分母是“在统计时间窗内执行的恢复演练次数”，分子是“在约定恢复时间目标内完成还原且关键数据校验通过的次数”。
时间窗和样本量要事先约定。建议以一轮完整的适配验证周期作为一个统计窗口，例如一次版本发布前的集中验证，窗口内每类动作至少执行若干次，具体次数由环境数量和风险等级决定。样本量过少时，比率只能作为参考，不能作为放行依据。对于多环境组合，可以按操作系统发行版或 CPU 架构分组统计，再汇总，避免某一环境的高成功率掩盖另一环境的失败。
分母为零或样本不足时要单独标注。某一时间窗内没有发生升级尝试，升级成功率记为“样本不足”，不计算比率，也不写成 0% 或 100%。样本量低于约定下限时，同样标注“样本不足”，并在结论中说明该指标不参与整体判定。缺失数据要记录缺失原因，例如环境未就绪、依赖未到位，不能直接剔除失败样本。
| 指标 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|
| 安装成功率 | 首次部署成功且通过基础健康检查的次数 | 发起的安装尝试次数 | 百分比 | 一轮适配验证周期 |
| 升级成功率 | 升级完成、校验通过且无需回退的次数 | 发起的升级尝试次数 | 百分比 | 一轮适配验证周期 |
| 恢复成功率 | 在恢复时间目标内还原且数据校验通过的次数 | 执行的恢复演练次数 | 百分比 | 一轮适配验证周期 |
| 数据迁移完整性 | 升级后与升级前一致的核心数据条数 | 升级前核心数据条数 | 百分比 | 单次升级 |
| 平均恢复时长 | 各次恢复演练从启动到可用的时长之和 | 有效恢复演练次数 | 分钟 | 一轮适配验证周期 |
数据口径与证据：日志、截图与配置快照
证据的作用是让第三方能按同一口径复算指标。安装与升级日志要覆盖开始时间、结束时间、执行账号、执行的命令或安装包版本、报错堆栈和退出码。日志采集点应固定在安装脚本入口、依赖检查环节、数据库初始化环节和健康检查环节，确保失败时能定位到具体阶段，而不是只留下“安装失败”一句结论。
配置与数据快照用于证明升级前后状态一致。升级前留存平台配置文件、数据库核心表记录数、关键业务对象的抽样清单；升级后按同一清单复核。恢复验证要留存备份文件生成记录、备份校验结果、还原开始与结束时间、还原后登录验证和核心流程走查记录。截图适合作为辅助证据，需带时间戳和环境标识，不能替代日志和快照。
证据与指标要逐项对应。每一条安装尝试记录对应一条安装日志和一次健康检查结果；每一次升级对应升级前后快照和回退演练记录；每一次恢复对应备份记录和恢复时长记录。建议为每轮验证建立证据索引，按“指标—样本编号—证据文件—结论”组织，便于复核时快速定位。验证任务、用例执行结果和失败项缺陷可以在 ONES 中登记与追踪，测试用例与需求、任务关联，未通过的用例可直接创建缺陷任务并在测试与研发团队间流转，使证据和结论留在同一套记录里。
计算与评估步骤：从环境准备到结论
第一步是准备信创环境基线。按目标操作系统发行版、CPU 架构和数据库版本准备环境，记录版本信息，确认网络、存储、时钟同步和依赖源可用。环境准备完成后先做一次基线快照，后续每次安装、升级、恢复都从该快照或约定的初始状态出发，减少环境漂移带来的干扰。
第二步是按顺序执行三类动作。先做安装验证，因为升级和恢复都依赖一个可用的初始部署；安装验证通过后，在同一环境上执行升级验证，覆盖从上一版本升级到目标版本的路径，并安排至少一次回退演练；最后执行恢复验证，使用升级后的环境生成备份并演练还原。三类动作的执行顺序固定，样本编号连续，便于追溯。
第三步是记录与判定。每次执行后立即填写记录表，包含样本编号、环境标识、动作类型、开始与结束时间、结果、失败原因分类和证据索引。统计时先按环境分组计算，再汇总；分母为零或样本不足的指标单独标注。判定时逐项对照事先约定的通过标准，任何一项未达标都应在结论中列出，并说明影响范围。
- 环境准备：记录操作系统、CPU、数据库版本，完成基线快照。
- 安装验证：执行首次部署，采集日志，完成健康检查。
- 升级验证：执行版本升级，比对升级前后数据，完成回退演练。
- 恢复验证：生成备份，执行还原，记录恢复时长与数据校验结果。
- 汇总判定：按环境分组计算指标，标注样本不足项，形成结论。
一个可复算的例子
以下为演示情景，数字仅用于说明计算过程，不代表任何产品的实际表现。假设某轮适配验证在两种国产操作系统环境上执行，统计窗口为一轮验证周期。安装尝试共 40 次，其中首次部署成功且通过健康检查 36 次；升级尝试共 20 次，其中升级完成、校验通过且无需回退 18 次；恢复演练共 10 次，其中在约定恢复时间目标内完成还原且数据校验通过 9 次。
按公式代入：安装成功率 = 36 ÷ 40 = 90%；升级成功率 = 18 ÷ 20 = 90%；恢复成功率 = 9 ÷ 10 = 90%。若进一步看数据迁移完整性，升级前核心数据条数为 120000 条，升级后一致条数为 119880 条，完整性 = 119880 ÷ 120000 = 99.9%，差额 120 条需要逐条说明是正常清理还是迁移遗漏。恢复时长方面，9 次有效演练总耗时 270 分钟，平均恢复时长为 30 分钟。
解读时要结合分组和失败原因。若 4 次安装失败集中在同一操作系统发行版，说明问题可能与特定依赖或系统服务有关，应单独列出该环境的成功率，而不是用 90% 的整体数字覆盖。若升级失败的 2 次均发生在回退环节，则升级成功率的下降反映的是回退可用性问题，需要与数据迁移完整性分开描述。样本量较小时，比率波动大，结论应写成“本轮验证结果”，并注明环境组合和样本数。
解读与限制：哪些结论不能下
单次通过不等于长期稳定。一轮验证中安装、升级、恢复均成功，只能说明在当时的基线环境和样本范围内动作可完成，不能推断在长期运行、数据量增长或并发压力下仍然稳定。要观察稳定性，需要多轮验证和更长时间窗的数据，并把环境变更、版本变更记录在案。
环境差异会直接影响结果的可比性。不同国产操作系统发行版、不同 CPU 架构和数据库版本组合，安装依赖、服务管理和迁移脚本的行为可能不同。把不同基线的样本合并计算，会掩盖局部失败。结论中应写明覆盖了哪些环境组合，未覆盖的组合不能默认通过。
指标反映的是结果分布，不直接说明原因。安装成功率高，不代表依赖管理没有问题；恢复成功率高，也不代表备份策略足够。指标需要与失败原因分类、日志证据和回退演练记录一起解读。适配认证和具体版本兼容结论应以厂商提供的适配清单和认证信息为准，验证结果用于补充自身环境的实测证据，不能替代官方认证结论。ONES 信创版适配银河麒麟操作系统、麒麟信安操作系统、统信操作系统、OpenEuler 操作系统、龙蜥操作系统，并适配鲲鹏 CPU、飞腾 CPU、达梦数据库，具体版本组合与认证范围仍需按实际清单核验。
常见问题
一轮验证里安装、升级、恢复都成功了，能不能直接作为放行依据？
可以作为本轮验证的结论，但放行还需要看样本量和覆盖范围。一轮验证中三类动作均成功，说明在当时的基线环境和样本范围内动作可完成；如果每类动作的样本量低于事先约定的下限，比率只能作为参考。放行判定建议同时满足三个条件：各类指标达到约定阈值、样本量达到下限、覆盖的环境组合与目标上线环境一致。未覆盖的操作系统发行版或CPU架构组合，不能默认通过。
升级后数据条数少了，但业务方说差额是正常清理，这种情况怎么记录？
把差额单独列为待说明项，不直接计入迁移遗漏，也不直接判定通过。做法是：在升级前快照中记录核心数据条数，升级后按同一口径复核，差额逐条归类为正常清理、归档或迁移遗漏，并保留归类依据。数据迁移完整性指标仍按“升级后一致条数÷升级前条数”计算，同时在结论中注明差额构成。若差额无法逐条说明，该项按未通过处理，因为无法证明数据完整。
恢复演练的恢复时间目标怎么定，没有历史数据时怎么办？
恢复时间目标由业务重要性决定，没有历史数据时可以先按业务可接受的中断时长倒推，再通过首轮演练结果校准。首轮演练记录每次从启动还原到登录可用、核心流程走查通过的时长，取有效演练的平均值作为基线，下一轮再据此设定目标。目标一旦确定，同一轮验证内不随意调整，否则恢复成功率的分母口径会变化，结果不可比。恢复时长按分钟记录，保留每次演练的起止时间。
多个国产操作系统发行版的结果，应该分开算还是合并算？
先按环境分组计算，再汇总，并在结论中同时呈现分组结果。不同发行版在依赖包、系统服务和迁移脚本行为上可能存在差异，合并计算会让某一环境的高成功率掩盖另一环境的失败。分组维度建议至少包括操作系统名称与版本、CPU架构；数据库版本不同时也应单独分组。汇总值只用于整体概览，判定是否达标时以目标上线环境对应的分组结果为准。
验证任务、用例执行结果和失败项，怎么管理才能让证据可追溯？
把验证用例、执行记录和失败项放在同一套记录体系里，按样本编号关联。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；未通过的用例可以快速创建缺陷任务，在测试与研发团队间流转。这样每次安装、升级、恢复尝试都能对应到具体用例、执行结果和证据文件，复核时按样本编号即可定位日志与快照。ONES 信创版适配银河麒麟操作系统、麒麟信安操作系统、统信操作系统、OpenEuler 操作系统、龙蜥操作系统，并适配鲲鹏 CPU、飞腾 CPU、达梦数据库，具体版本组合与认证范围需按实际适配清单核验。
