研发平台信创适配清单要能直接用于判断“能不能上、能不能验收、环境变了还能不能用”。一份可执行的清单通常围绕环境基线、平台功能、集成链路、数据迁移、性能与稳定性、安全合规、运维保障七类信息展开，每项写明通过标准、证据材料、负责人和检查时点，并把关键链路不通、数据校验不通过等设为阻断项。以下按使用场景和检查内容逐项说明，可直接作为清单模板使用。
要点总览（TL;DR）
- 清单围绕环境基线、平台功能、集成链路、数据迁移、性能与稳定性、安全合规、运维保障七类信息展开，每项写明通过标准、证据材料、负责人和检查时点。
- 环境基线要写到具体产品、版本号和补丁级别，形成组合矩阵；只写“支持信创”无法用于验收。
- 清单在选型立项、上线前验收、年度复检三个时点使用，立项看适配证据，验收看实测结果，复检看环境变更后的回归。
- 核心业务流程不可用、数据库或中间件不兼容、身份认证失败、数据迁移校验不通过、关键安全配置缺失等应设为阻断项，未通过不得进入下一阶段。
- 结论分为通过、不通过、有条件通过，有条件通过须写明条件与复检日期，到期未复检自动转为不通过。
清单由谁使用、在什么时点检查
这份清单面向五类角色：架构师负责环境基线与集成链路的技术判断，测试负责人负责功能、性能与稳定性实测，运维负责人负责部署、监控与运行期保障，安全与合规负责人负责权限、审计与合规材料核对，项目经理负责组织检查、跟踪整改并做放行决策。清单在三个时点使用，检查深度依次递进。
| 检查时点 | 检查重点 | 主要参与角色 | 输出物 |
|---|---|---|---|
| 选型立项评估 | 厂商适配证据、认证材料、环境组合是否覆盖本单位目标环境 | 架构师、安全与合规负责人、项目经理 | 适配证据核对结论、环境基线初稿 |
| 上线前验收 | 在目标信创环境中的实测结果，功能、集成、迁移、性能逐项验证 | 测试负责人、运维负责人、架构师 | 测试报告、验收结论、整改清单 |
| 运行期年度复检 | 操作系统补丁、数据库小版本、浏览器升级等环境变更后的回归结果 | 运维负责人、测试负责人 | 回归记录、环境变更台账 |
立项阶段以书面材料核对为主，允许部分项目标注“待实测”；验收阶段必须以本单位环境中的实测结果为准，厂商材料只作为参考；年度复检聚焦环境变更影响面，对受影响的检查项做回归，未变更部分可抽样复核。
环境基线：先固定要适配的信创组合
清单第一块内容是把“支持信创”拆成具体的产品、版本和补丁级别，形成组合矩阵。只写产品名的清单无法验收，因为同一数据库的不同大版本在驱动、SQL 语法和字符集处理上都可能不同。
| 层级 | 需记录的信息 | 示例（按实际环境填写） |
|---|---|---|
| CPU 架构与型号 | 架构类型、具体型号、核数与主频 | 鲲鹏、飞腾、龙芯、海光、兆芯等，写到具体型号 |
| 操作系统 | 发行版名称、大版本、小版本、补丁级别 | 银河麒麟、统信 UOS、麒麟信安、OpenEuler、龙蜥等 |
| 数据库 | 产品、版本、补丁、字符集、部署模式 | 达梦、人大金仓、openGauss 系等 |
| 中间件与运行时 | 应用服务器、消息中间件、JDK 或运行时版本 | 写明厂商、版本号与补丁 |
| 浏览器与办公套件 | 浏览器内核与版本、办公套件版本 | 国产浏览器、WPS 等，注明版本 |
矩阵的每一行是一种实际要部署的组合，而不是各层产品的简单罗列。若单位存在多套目标环境，例如办公网与研发网操作系统不同，应分别成行。每行附上厂商适配说明或互信认证材料的编号，作为立项阶段的证据。以 ONES 信创版为例，官方资料列示其适配鲲鹏、飞腾 CPU，银河麒麟、统信、OpenEuler、龙蜥等操作系统，以及达梦数据库，并说明已完成主流信创软硬件的互信认证；具体版本号、补丁级别和证书明细仍需向厂商索取书面材料后填入矩阵。
平台功能与客户端适配检查项
功能检查覆盖服务端与客户端两侧，每项都要给出可观察的通过标准，避免“页面能打开”这类无法判定的描述。
| 检查项 | 检查方法 | 通过标准示例 |
|---|---|---|
| 服务端部署与启动 | 在目标环境按部署文档完整安装并启动 | 全部服务正常启动，日志无持续性报错，重启后自动恢复 |
| 核心业务功能 | 走通需求、任务、缺陷、迭代的完整流程 | 完成一轮完整迭代流程，无阻断性错误，数据落库正确 |
| 代码托管与流水线 | 提交代码、触发构建、查看流水线结果 | 提交可触发构建，构建结果与制品可正常查看和下载 |
| 浏览器端页面渲染 | 在目标国产浏览器中逐页浏览主要页面 | 布局无错位，表单可提交，列表分页与筛选正常 |
| 附件上传下载 | 上传多种格式与大体积附件后下载比对 | 文件完整、可打开，大小与校验值一致 |
| 富文本与表格编辑 | 编辑含图片、表格、代码块的文档 | 保存后内容与格式完整，再次编辑无丢失 |
| 客户端或桌面端 | 在国产操作系统上安装并登录 | 安装无报错，登录成功，核心操作可用 |
| 打印、导出、消息通知 | 执行导出与打印，触发站内与邮件通知 | 导出文件可打开，打印版式正确，通知按时送达 |
功能检查建议按角色组织用例：研发人员关注代码与流水线，项目经理关注迭代与报表，测试人员关注缺陷流转。每个角色至少完成一条端到端路径，比逐页点检更能暴露真实问题。
集成链路与数据迁移检查项
研发平台很少孤立运行，集成链路不通往往比单个功能缺陷影响更大，因此这一部分应逐条链路单独检查。
- 代码仓库与流水线对接：验证提交关联工作项、合并请求状态回写、构建结果回传是否正常，检查接口超时与重试后的最终一致性。
- 制品库对接：确认制品上传、版本查询、下载校验在目标环境下可用。
- 统一身份认证：验证 LDAP、AD 或 OAuth 登录、账号同步、组织与权限同步，重点检查账号增删改后的同步时延与失败告警。
- 监控、日志与消息系统：确认指标上报、日志采集、告警与消息推送链路连通，断连后有可观察的告警。
- 历史数据迁移：核对记录数、附件数量与大小、权限关系、历史状态流转，抽样比对迁移前后内容一致性。
数据迁移的通过标准应写成可核对的数字，例如“工作项记录数迁移前后一致，差异为 0；附件抽样 100 个全部可下载且校验值一致；项目成员权限与源系统逐项比对无差异”。迁移后还需安排一段并行观察期，确认新数据写入与查询正常。
性能、稳定性与安全合规检查项
非功能检查以本单位实测数据为准，厂商提供的性能参数只作为参考基线。
| 检查项 | 检查方法 | 通过标准示例 |
|---|---|---|
| 并发性能 | 按典型并发用户数压测核心页面与接口 | 响应时间与资源占用在预定阈值内，无大量超时 |
| 长时间运行 | 连续运行观察 72 小时并持续产生业务负载 | 无内存泄漏趋势，无异常重启，日志无新增严重错误 |
| 账号与权限 | 抽查角色配置与越权访问 | 权限边界符合设计，越权访问被拒绝并留痕 |
| 审计日志 | 执行关键操作后检索日志 | 操作人、时间、对象、结果完整可查 |
| 传输与存储加密 | 检查配置并抓包验证 | 传输加密生效，敏感数据按策略加密存储 |
| 合规材料 | 核对等保、密评等材料 | 材料在有效期内且覆盖本单位使用场景，以实际取得材料为准 |
| 漏洞与补丁 | 执行漏洞扫描并核对补丁记录 | 高危漏洞已修复或有经批准的处置方案 |
安全合规部分要区分“厂商已取得的资质”和“本单位需自行完成的测评”。厂商资质可缩短评估周期，等保测评、密评等仍需按本单位系统定级和实际部署情况推进，清单中应分别列项，避免混为一谈。
每项检查的通过标准、证据与负责人
清单每行统一填写以下字段，保证结果可核验、可追溯：检查项、检查方法、通过标准、证据材料、负责人、检查时点、结论。负责人写到具体人名，部门名无法承担整改责任。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 检查项 | 一句话说明查什么 | 统一身份认证登录与权限同步 |
| 检查方法 | 可复现的操作或核对方式 | 用测试账号登录，修改角色后观察同步结果 |
| 通过标准 | 可观察、可判定的结果 | 登录成功，角色变更 5 分钟内同步生效 |
| 证据材料 | 测试报告、截图、日志、配置清单、厂商适配说明 | 同步日志截图与测试记录 |
| 负责人 | 具体到人 | 运维负责人姓名 |
| 检查时点 | 立项、验收或复检 | 上线前验收 |
| 结论 | 通过、不通过、有条件通过 | 有条件通过，注明条件与复检时间 |
“有条件通过”只适用于不影响核心业务、且有明确整改计划的事项，必须写明条件和复检日期，到期未复检自动转为不通过。证据材料随清单一起归档，便于年度复检时对照。
清单落地执行时，可以把每个检查项建成工作项，挂上负责人、截止时间和证据附件，用状态流转记录从“待检查”到“通过”或“不通过”的过程。ONES 的工作项与文档管理可以承载这类跟踪：检查项作为工作项分配给人，测试报告和截图作为附件归档，复检时按原清单逐项回溯。对于需要替换 Jira 等既有工具的单位，ONES 提供 Jira & Confluence 替换方案，并有 T 量级数据迁移案例，迁移范围与工作量需按实际数据量评估。
阻断项与完成条件
阻断项与普通检查项分开管理：阻断项未通过，不得进入下一阶段；普通项未通过，允许带整改计划推进。以下情形应设为阻断项：
- 核心业务流程在目标信创环境中不可用，或存在无法绕过的功能缺陷；
- 数据库、中间件或运行时与平台不兼容，导致部署失败或数据异常；
- 统一身份认证登录失败，或权限同步错误造成越权；
- 历史数据迁移校验不通过，记录数、附件或权限关系存在未解释的差异；
- 关键安全配置缺失，如审计日志未开启、传输未加密；
- 高危漏洞未修复且无经批准的处置方案。
整体完成条件为：全部阻断项结论为通过；非阻断项的不通过项均有明确整改计划、责任人和完成时间；有条件通过项已登记复检日期。清单本身应纳入版本管理，环境基线变更、检查项增删都记录版本号和变更说明，年度复检使用最新版本并保留历史版本，便于追溯每次放行依据。
常见问题
厂商提供的适配认证材料齐全，是否还需要在本地信创环境实测？
需要。厂商的互信认证和适配说明可以作为立项阶段的证据，但认证覆盖的是特定产品与版本组合，本单位实际使用的操作系统补丁级别、数据库小版本、浏览器版本可能不在认证范围内。上线前验收应以本单位目标环境中的实测结果为准，厂商材料作为参考基线。实测重点放在核心业务流程、集成链路和数据迁移上，这几类问题在书面材料中通常看不出来。
目标信创环境有办公网和研发网两套操作系统，清单要怎么处理？
把两套环境分别作为环境基线矩阵中的独立行，各自记录操作系统、数据库、中间件、浏览器版本，并分别安排功能与集成检查。如果研发平台只在其中一套环境部署，另一套环境涉及浏览器访问或客户端安装的检查项仍需覆盖，因为用户侧体验同样影响可用性。两套环境的检查结论分别记录，不合并成一个总体结论。
“有条件通过”和“不通过”在实际执行中怎么区分？
有条件通过适用于不影响核心业务、且有明确整改计划和复检日期的事项，例如某个非关键报表导出格式异常但数据正确。不通过适用于阻断项，或没有整改计划、无法给出复检时间的事项。有条件通过必须写明条件和复检日期，到期未复检自动转为不通过。项目经理在放行决策时，只依据阻断项是否全部通过来判断能否进入下一阶段。
年度复检时，环境只升级了操作系统补丁，清单要全部重跑吗？
不需要全部重跑。复检聚焦环境变更的影响面：操作系统补丁升级后，重点回归服务端启动、浏览器端页面渲染、客户端安装运行和依赖系统库的集成链路；数据库小版本变更则重点回归数据读写、迁移数据一致性和性能表现。未受变更影响的检查项可以抽样复核，但抽样比例和复核结论要记录在复检记录中，便于追溯。
清单里的检查项如何跟踪到人并保留证据？
可以把每个检查项建成工作项，分配负责人和截止时间，测试报告、截图、日志作为附件挂在对应工作项下，用状态流转记录从待检查到通过或不通过的完整过程。ONES 的工作项与文档管理可以承载这类跟踪，复检时按原清单逐项回溯历史证据。对于需要从 Jira 等工具迁移历史数据的单位，ONES 提供 Jira & Confluence 替换方案，迁移范围和工作量需按实际数据量评估。
