这份清单面向正在推进信创研发管理平台选型的组织，按“环境适配—数据与迁移—权限与合规—集成与运维—试点验收”五个阶段逐项判断。每项写明检查内容、通过标准、所需证据和负责人；适配认证、兼容版本与价格以厂商书面材料或现场验证为准，未取得证据的项目不判定通过。涉及国产CPU、操作系统、数据库、中间件的适配项列为阻断项，未通过不进入下一阶段。
要点总览（TL;DR）
- 清单按环境适配、数据与权限合规、集成与运维、试点验收四个检查阶段组织，每项写明检查内容、通过标准、证据形式和负责人。
- 国产CPU、操作系统、数据库、中间件的适配证据列为阻断项，缺少书面证明或现场验证记录时不进入下一阶段。
- 通过标准以具体版本号和目标环境组合为准，接口文档只能证明有接口，联调记录才能证明已跑通。
- 未确认的条目统一标注待验证并写明补验方式与时限，不据此推断产品不支持。
- 试点验收覆盖关键研发流程，证据按检查项编号归档，与清单条目一一对应。
谁在什么时点使用这份清单
这份清单用于选型评审，不用于日常运维。它帮助评审人员在关键节点做“通过/不通过/待验证”的判断，并把判断依据留痕。日常监控、巡检、故障处理等操作规范应另行编制，避免把选型清单当成运维手册使用。
清单涉及五类角色，各自承担不同的检查责任：
| 角色 | 主要职责 | 在清单中的动作 |
|---|---|---|
| 研发效能负责人 | 确认平台能否支撑研发流程与协作方式 | 提出流程类检查项，参与试点验收 |
| 信息化/信创负责人 | 确认基础软硬件适配与部署可行性 | 核验CPU、操作系统、数据库、中间件适配证据 |
| 安全合规 | 确认权限、审计、数据留存满足要求 | 核验合规条目，判定合规类阻断项 |
| 采购 | 确认商务条件与书面承诺一致 | 收集适配证明、版本承诺等书面材料 |
| 运维 | 确认上线后的可运维性 | 核验备份、升级、监控与故障响应安排 |
清单在三个时点使用，每个时点的判断深度不同：
| 使用时点 | 使用方式 | 输出 |
|---|---|---|
| 需求确认后初筛 | 用环境适配与合规条目快速排除明显不满足的候选 | 候选名单及初筛结论 |
| POC/试点前评审 | 逐项核对证据，确定试点范围与重点验证项 | 待验证项清单与试点方案 |
| 上线验收 | 复核全部条目，确认阻断项清零、一般项有结论 | 验收结论与证据归档 |
清单覆盖信创环境适配与选型判断。具体竞品的替换路径、迁移实施方案不在本文范围，需在选型结论确定后另行规划。
第一阶段：环境适配核验项
环境适配是信创选型的第一道门槛。本阶段逐项核对基础软硬件的适配声明与验证方式，每项都要有可追溯的证据，口头承诺不计入通过。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| CPU架构适配 | 厂商书面声明支持目标CPU架构（如ARM、x86、LoongArch等），且在目标服务器型号上完成验证 | 适配证明、测试报告、现场验证记录 | 信息化/信创负责人 |
| 服务器型号适配 | 目标服务器型号在厂商兼容列表中，或现场部署验证通过 | 兼容列表截图、部署验证记录 | 信息化/信创负责人 |
| 操作系统兼容 | 目标国产操作系统及具体版本在兼容版本清单内 | 兼容版本清单、测试报告 | 信息化/信创负责人 |
| 数据库兼容 | 目标国产数据库及版本通过功能与性能验证 | 兼容清单、联调测试记录 | 信息化/信创负责人 |
| 中间件兼容 | 目标中间件版本完成部署与运行验证 | 部署记录、运行日志 | 运维 |
| 浏览器兼容 | 常用国产浏览器可正常访问核心功能 | 功能验证记录 | 研发效能负责人 |
| 部署形态匹配 | 本地部署或私有云部署方式与信创环境要求一致，资源需求明确 | 部署方案文档、资源清单 | 运维 |
核验时注意三点。第一，适配声明要落到具体版本号，笼统写“支持国产数据库”不足以判断。第二，测试报告应包含目标环境组合，跨版本推断的结论需要现场补验。第三，现场验证记录要写明环境配置、验证时间与验证人，便于复核。任一适配项缺少证据时，标记为“待验证”，在试点阶段补验，不直接判定通过。
第二阶段：数据、权限与合规检查项
本阶段判断平台能否承接历史数据、权限管理是否满足组织分级授权需要、合规要求是否有可核验的落实方式。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 历史数据导入方式 | 明确导入途径（接口、文件、脚本等），并完成样本数据导入验证 | 导入方案、样本导入记录 | 研发效能负责人 |
| 字段映射可验证性 | 关键字段（项目、工作项、状态、人员）映射关系逐项确认，抽样核对无丢失或错位 | 字段映射表、抽样核对记录 | 研发效能负责人 |
| 分级授权模型 | 支持按项目、角色、组织维度配置权限，并能验证越权访问被拦截 | 权限配置说明、越权测试记录 | 安全合规 |
| 日志审计 | 关键操作（登录、权限变更、数据导出）有审计日志，可查询、可导出 | 日志样例、查询演示记录 | 安全合规 |
| 数据留存 | 留存周期与清理机制符合组织制度要求，配置方式明确 | 配置说明、制度对照表 | 安全合规 |
| 等保相关要求 | 对照等保要求逐条核验，明确满足项与需配合项 | 合规对照表、厂商书面说明 | 安全合规 |
数据导入验证建议用真实结构的样本数据做一次完整演练，覆盖附件、关联关系与历史状态。权限核验要实际执行越权访问测试，仅查看配置界面不足以证明拦截有效。合规条目中，厂商侧责任与使用方侧责任要分开记录，避免把需要组织自身落实的要求误记为产品能力。核验中未能确认的条目统一标注“待验证”，写明补验方式与时限，不写成产品不支持。
第三阶段：集成与运维检查项
研发管理平台需要嵌入现有工具链，并在信创环境下长期稳定运行。本阶段检查集成方式是否可落地、运维安排是否可执行。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 代码仓库集成 | 与在用代码仓库完成对接，提交记录可关联到工作项 | 接口文档、联调记录 | 研发效能负责人 |
| CI/CD集成 | 流水线状态可回传，构建结果与需求、缺陷可追溯 | 接口文档、联调记录 | 研发效能负责人 |
| 单点登录 | 与组织统一身份源完成对接，登录与登出行为符合预期 | 联调记录、登录测试记录 | 运维 |
| 备份安排 | 备份范围、频率、恢复流程明确，并完成一次恢复演练 | 备份方案、恢复演练记录 | 运维 |
| 升级安排 | 升级方式、窗口期、回退方案明确，升级对信创环境的影响有说明 | 升级方案文档 | 运维 |
| 监控与告警 | 关键服务状态可监控，告警渠道与响应时限明确 | 监控配置说明、告警测试记录 | 运维 |
| 故障响应 | 厂商支持渠道、响应时限、升级路径写入服务约定 | 服务协议、支持流程说明 | 采购 |
集成项以联调记录为准，接口文档只能证明“有接口”，不能证明“已跑通”。备份与恢复要成对验证，只做备份不做恢复演练无法判断可用性。升级安排需特别关注信创环境下的依赖变化，例如操作系统或数据库版本升级对平台的影响，应要求厂商给出书面说明。
阻断项与完成条件
清单条目分为阻断项与一般项两类。阻断项未通过，选型流程不进入下一阶段；一般项未通过，可限期整改后复检。
阻断项范围包括两类。第一类是核心基础软硬件适配未取得证据：目标CPU架构、操作系统、数据库、中间件中任一项缺少书面适配证明或现场验证记录，即视为阻断。第二类是合规硬性要求未满足：等保对照中属于必须满足的条目未落实，或审计日志、权限拦截等核验未通过，同样视为阻断。
一般项的处理方式是：记录未通过原因，明确整改责任人与完成时限，复检时以同一检查项、同一通过标准重新判断。复检记录与原记录一并归档，避免结论前后不一致。
整体完成条件有三条：阻断项全部通过并有证据支撑；一般项均有明确结论（通过、整改后通过或有条件接受）；每个未通过项都有责任人与后续动作。三条同时满足，方可形成选型推荐结论。
试点验收与证据归档
试点用于验证清单中标记“待验证”的条目，并在接近真实的环境中观察平台表现。试点范围应覆盖关键流程：需求提出、任务分派、代码提交关联、测试缺陷流转、发布记录，以及权限配置与审计查询。验收指标包括关键流程是否完整跑通、常用操作响应是否可接受、连续运行期间的稳定性观察结果。性能与稳定性指标的具体数值应结合组织实际负载在试点方案中约定，不套用统一标准。
试点结束后按以下清单归档证据：
- 适配证明与兼容版本清单（厂商书面材料）
- 环境部署与现场验证记录
- 数据导入与字段映射核对记录
- 权限越权测试与审计日志样例
- 集成联调记录（代码仓库、CI/CD、单点登录）
- 备份恢复演练记录
- 试点验收签字与遗留问题清单
遗留问题逐条登记问题描述、影响范围、责任人与计划完成时间，并在复检时更新状态。证据按检查项编号归档，与清单条目一一对应，便于评审时追溯。
在试点与归档环节，检查记录、遗留问题和验收结论需要被持续跟踪并形成可查的评审记录。ONES 的工作项与文档管理可以承载这类检查条目：将每个检查项建为工作项，关联负责人、证据附件与状态，评审结论通过文档留存并按阶段流转，使选型过程与最终验收结论保持一致、可回溯。
常见问题
厂商提供了适配证明，但证明里的版本与我们要部署的版本不一致，这项算通过吗？
不算通过。适配证明需要落到具体版本号，笼统写“支持国产数据库”或证明覆盖的是其他版本，都不足以判断目标环境可用。处理方式有两种：要求厂商补充目标版本的书面材料，或在试点阶段用目标版本做现场验证并留存记录。在补齐证据之前，该项标记为“待验证”，按阻断项管理，不进入下一阶段。
清单里的检查项太多，初筛阶段是否要全部核验一遍？
不需要。三个使用时点的判断深度不同：需求确认后初筛只用环境适配与合规条目快速排除明显不满足的候选；POC/试点前评审才逐项核对证据，确定试点范围与重点验证项；上线验收复核全部条目。初筛阶段对无法当场确认的条目记录为待验证即可，把核验成本留到评审和验收环节。
等保相关条目中，哪些算产品能力，哪些需要组织自己落实？
核验时要把厂商侧责任与使用方侧责任分开记录。平台侧通常涉及审计日志的查询与导出、权限拦截机制等可演示的能力；组织侧通常涉及制度、人员管理和部分配置责任。建议用合规对照表逐条标注责任方，需要组织自身落实的要求不记为产品能力，也不因产品未覆盖而判定为不满足。责任划分不清的条目，要求厂商书面说明后再判断。
试点验收时性能指标怎么定，有没有通用数值可以参考？
没有适用于所有组织的统一数值。性能与稳定性指标应结合组织实际负载在试点方案中约定，例如按真实用户规模和数据量设定常用操作的响应观察项，以及连续运行期间的稳定性观察项。验收时以试点方案约定的指标为准，记录实际观察结果，不套用其他组织的标准，也不把未约定的指标作为否决依据。
一般项整改后复检仍不通过，选型还能继续吗？
可以继续，但需要有明确结论。整体完成条件要求一般项均有结论，包括通过、整改后通过或有条件接受。复检仍不通过时，由责任人记录原因、影响范围和接受条件，经评审确认后形成“有条件接受”的结论，并纳入遗留问题清单跟踪。阻断项则不同，必须全部通过并有证据支撑，不能以有条件接受的方式放行。
