负责人 何建力　·　状态 初稿　·　覆盖 51 个标书单元　·　 批注 6

非功能性技术要求（3.1.2.2）

1、适用对象、指标总表与测量口径

（1）适用对象：商用密码服务平台、数据集加工生产平台与运营服务管理平台

3.1.2.2 列在「3.1.2 安全软件建设要求」之下，其条款文义指向商用密码服务平台。本项目实际交付的软件不止一套，而评审、上线、运行、运维走的是同一条流程。我方因此把 3.1.2.2 各项条款的承诺适用于全部交付软件，适用对象为三套：商用密码服务平台（即软件采购清单中的安全软件）、数据集加工生产平台、数据集运营服务管理平台。三套软件使用统一的技术底座，对外称「奔牛数据智能平台」，全称天地奔牛煤机装备数据智能平台（b0743）。

甲方已建成十余套业务系统，覆盖设计与工艺、生产计划与工单、质量检验、库存与物流、设备过程参数采集以及在役装备远程运维，跨系统追一件事仍需人工对账。本项目再增加三套软件，三套共用同一套非功能性指标与验证方法：可用性口径、升级方式、国产化基线、漏洞门禁统一承诺、统一验证，避免各套口径不一导致运维重复处置同类问题。

本节与其他章节在同一套指标上分工，不另立口径。安全技术的实现细节（国密算法应用、等级保护测评、商用密码应用安全性评估、去标识与脱敏、审计与权限管控）在安全方案一节展开；本节承担的实施职责是给出安全性指标的量值与判定方法——表 4-1 所列类型与通用漏洞评分 7.0 分及以上的高危漏洞在上线前整改关闭并复测无复现，高危修复时限 7 个自然日、中危 30 个自然日，并组织静态应用安全测试、软件成分分析、动态应用安全测试与渗透测试四道检测，出具安全测试报告与渗透测试报告。运营服务管理平台各功能模块的服务分级与服务级别协议指标在运营平台一节展开；本节承担的实施职责是给出支撑这些服务级别的系统级指标——月度可用率不低于 99.5%、核心服务恢复时间不超过 30 分钟、结构化数据恢复点不超过 15 分钟，并建设达成这些指标所需的高可用部署、备份恢复与故障注入验证。这三个量值是首期基线，各自的判定方法与样本量在表 1-4 逐行固定：可用率按 60 秒周期的内外双路采集逐分钟判定、按自然月汇总；恢复时间在预生产环境按故障注入判定，每项注入重复 3 次取最差值，交付前一轮、质保期内每半年一轮；恢复点按月度备份恢复演练，比对故障时刻与可恢复数据的最后一致时刻。运行期按同一口径逐月核对，目标逐步接近月度可用率 99.9%、核心服务恢复时间 10 分钟、结构化数据恢复点 5 分钟。某一周期未达基线的，按表 1-4 失败整改一列定位整改后重测至连续三次达标；连续两个周期仍未达基线的，在月度运行报告中单列该项，连同根因分析与改进计划提交甲方，按整改单跟踪闭环。硬件型号、参数与质保条款在硬件选型一节展开；本节承担的实施职责是提出承载平台的冗余配置要求（双电源、双网口绑定、系统盘镜像、数据盘多副本或冗余磁盘阵列）、国产化判定规则与核算算式，并按该规则在上线验收时出具《国产化率核算说明》。

（2）指标的测量口径与复测处置

承诺值是写入合同与验收单的判据：招标文件给定量值的，取条款值本身；条款未给量值的，取我方承诺值。设计值是系统设计、选型与资源配置所依据的内部目标，时延类取承诺值的六成到七成，容量类取承诺值的一点五倍以上，为运行期的数据量增长与功能迭代留出余量。验收时以承诺值与下表固定的测量口径合并比对，实测值逐项记入验收记录。

响应时间一类指标须在验收方案中固定测量口径：同一个页面，在基准数据量下测得零点六秒，在十倍数据量且另有两百人在线的条件下可能是两秒；统计上取最大值还是取 P90，结论也不同。我方在《性能与可靠性验收方案》中对每项指标固定五个要素，并在合同签订后的需求确认阶段与甲方书面确认：

表 1-1　性能与可靠性指标的五要素口径（来源：招标文件 3.1.2.2.5、3.1.2.2.6 条款与本节承诺）

复测不达标时按三种情形分别处置，不混为一谈。属于实现问题的，按客户端、网络、应用、数据库、外部依赖五层逐层收敛，定位到具体层后整改并复测。属于测量口径偏离的，回到表 1-1 核对五要素，以书面确认的口径重测。属于运行条件变更的（数据量超出基准口径、并发超出设计容量、甲方侧网络或算力条件变化），按配置变更流程提出资源调整建议并书面确认新基准，原指标在新基准下重新验证。

（3）非功能性指标总览与测试规格

招标文件对非功能性的要求，一半给了数：页面打开不超过 1 秒、报表生成不超过 3 秒、登录不到 1 秒、软硬件整体国产化比率不低于 80%。另一半没有给数，写的是「具备高度稳定性和可靠性」「迅速定位问题并恢复系统正常运行」。后面这一半在验收那天是判不了的——系统半夜停了两个小时，算不算「不够稳定」，双方各有各的说法，到那时再谈就只能各让一步。

这在本项目上不是小事。首轮存量加工要把 63 万张历史图纸连同配套工艺卡解析入库，按测算是二十个工作日的连续机时（表 7-3）；这二十天里系统停一次，断掉的不是几个页面，而是整批作业的续跑与重算。产线与井下的感知设备又是不间断回传的，停机期间的帧与温度读数补不回来——井下测点损坏尚且按不补装处理，数据上本就留着一条从某天起断掉的线，再因为平台停机多添几条断线，后面做时序对齐时就分不清哪条断线是设备坏了、哪条是平台停了。所以「稳定」「可靠」这类词必须在投标阶段就换成数，并且换成的数要连着怎么测一起说清楚。

19 项指标因此摊开成三张表，一项指标占一行，三张表以指标项同序对齐：第一张定数（招标值、承诺值、设计值），第二张定条件（设计依据、测试环境、持续与峰值负载、数据量与并发），第三张定判法（测试步骤、采样与计算公式、判定阈值、证据、不达标怎么办）。分成三张而不压成一张超宽表，是因为三张的使用时点不同——技术评审看第一张是否逐条对上了招标值，系统设计与选型用第二张，验收现场拿第三张逐行走。若改成在七类要求下各写各的，19 项指标会被拆散复述七遍，而「条款没给量值的那九项，到底有没有被变成可测的数」这个最容易糊弄过去的问题，也就没有一处可以一眼看出来。

七类要求的指标、招标值、承诺值与设计值如下。招标值取招标文件条款原值；条款未给量值的，承诺值由我方设立，设立依据逐项见表 1-3。

表 1-2　非功能性指标总览：招标值、承诺值与设计值（来源：招标值抄录招标文件 3.1.2.2 各条款与 2.3 项目目标 b0677；设计值为我方内部设计目标）

招标文件已给定量值的十项，承诺值即取条款值本身，口径不改写、量值不下调。条款未给量值的九项（可用率、恢复时间、恢复点、定位时长、并发与容量等），由我方自定目标值，用途是把「迅速恢复」「高度稳定」一类定性要求转换为可实测、可验收的数值；这九项的设立依据逐项列于表 1-3，属对招标要求的补充量化，不替代、不改写招标文件的任何一条硬性要求。两类指标在验收时同表核对。其中核心服务恢复时间一项的量值口径，后文各表统一引用：首期基线取 RTO ≤30 分钟，判定方法为在预生产环境按 70% 设计容量施加背景负载逐项注入故障、每项重复 3 次取最差值，恢复时间自故障发生时刻起算至业务探针确认服务可用为止，交付前完整演练一轮、质保期内每半年演练一轮；目标逐步接近 10 分钟，达成路径是把健康检查间隔、实例重建与主备切换三段链路耗时逐段压缩并在演练中验证。某一轮演练超出基线的，定位到检测、决策、执行哪一环之后优化并重演，直至三次均达标；两轮演练仍超出的，在运行报告中单列该故障类型，连同根因分析与专项改进计划提交甲方评审，改进措施随下一版本上线后重新演练验证。

承诺值只是一个数，这个数在什么条件下成立，才是验收时真正要争的。同一个数据集检索页面，刚上线、库里几千条记录时测，零点几秒就出来了；等首轮 63 万张图纸连同工艺卡解析完、血缘与质检记录跟着铺满，同一个页面查同一个条件，走的索引、扫的分区、聚合的行数都变了。一个在空库上测出来的 1 秒达标，三个月后业务起来就不达标，这种达标对甲方没有意义。负载同理：产线与井下设备的回传并不均匀，班次交替那半小时的并发是平时的数倍，只给一个平均并发数，等于把最该验的那半小时漏掉了。

每项指标因此钉死四件条件：在哪套环境上测、常态负载多少、峰值负载多少、被测对象的数据量与并发多少。持续负载与峰值负载分成两列而不合成一个「并发」，就是为了不让班次峰值被平均掉；数据量单列，是为了把「按验收时点的实际在库量测、并另造满载态数据复测」写死，避免空库过关。最左边的设计依据一列约束的是我方自己：承诺值不能是拍出来的数，每一项都要指得回一个具体的工程配置——月度可用率指回双机互备接入层与数据库主备加仲裁的冗余度，核心服务恢复时间指回健康检查 5 秒间隔、实例重建 3 分钟、主备切换 2 分钟这三段链路耗时的合计，在线并发指回注册用户的在线比例与人均操作频次的推导（表 7-2）。依据站不住的，该改的是承诺值，而不是等到验收时再解释。

19 项承诺值各有一条工程上的来路，和一套可复现的测试条件；换一个人按同一行去测，测出来的数应当对得上。验收方案按同一行组织用例。

表 1-3　各项指标的设计依据与测试负载条件（来源：招标文件 3.1.2.2 各条款；负载条件与设计依据为我方承诺的测试口径）

验收现场最常见的争执，不是达没达标，而是「这个数怎么算出来的」。月度可用率扣不扣计划维护窗口、按分钟判还是按请求判，同一个月的运行数据能算出两个结论；恢复时间从故障发生那一刻起算还是从告警响起那一刻起算，中间差着一整个检测时延；响应时间取平均值还是取 P90，差距可以到一倍。甲方已建成十余套业务系统，跨系统追一件事至今仍要人工对账，根子正是各家口径不一致；非功能性指标若也留下这样的口径空档，质保期内每出一次争议都要从头谈一遍。

五列分别回答验收时的五个问题：怎么测、怎么采样怎么算、多少算过、拿什么留痕、不过怎么办。其中失败整改一列最容易被省掉，也最该写——只写到阈值为止等于只承诺了好结果，第一次不达标时双方无章可循。本节每一项指标都按首期基线、趋向值与回退路径三段给出：基线是表 1-2 的承诺值，趋向是表 1-2 的设计值，回退就是这一列——月度可用率连续两个月低于承诺值的，出根因分析与改进计划并按整改单跟踪至达标；核心服务恢复时间超时的，定位到检测、决策、执行哪一环之后优化并重演，直至三次均达标；软硬件整体国产化比率低于 80% 的，更换同类国产组件后重算并重做适配验证。把公式写进表里还有一层用处：采样次数、统计量、排除项都已固定，验收时不必临时商量怎么算，照着这一行跑一遍即可。

19 项承诺因此都具备可执行的验收程序，不达标时的下一步也事先写定，不留到事后再谈。

表 1-4　各项指标的测试步骤、采样与判定（来源：招标文件 3.1.2.2 各条款；步骤、公式、阈值与整改方式为我方承诺的验收口径）

图 1-1　指标的承诺、验证与回退路径

图 1-1　非功能性指标的承诺、验证与回退路径。数据来源：招标文件 3.1.2.2.1 第（4）条上线评审要求（b0749、b0750）与 3.1.2.2.4 第（3）条测试报告要求（b0768、b0769）。

2、基本要求（3.1.2.2.1）

四条分别指向中文化、第三方授权、正版凭证与上线评审，共同点是都在交付环节产生可核对的凭证，因此每一条都配一份可供甲方逐项清查的台账或清单。

（1）界面与文档的中文化

系统功能页面支持中文，相关文档均为中文版（b0745）。中文化在本项目不只是界面翻译，还牵涉矿山装备制造的专业术语与中文数据处理，我方按以下六个层面落实。

界面层面，三套软件的菜单、按钮、字段标签、提示信息、报错信息、导出文件名与报表表头均为简体中文，不保留英文原文作为唯一显示；技术术语保留英文缩写时，在首次出现处给出中文全称，并在系统的术语表中可查。错误提示不直接抛出技术堆栈，而是给出中文说明、错误码与建议操作，错误码与中文释义的对照表随系统交付。

字符处理层面，数据库与应用统一采用 UTF-8 编码，字符集覆盖 GB18030 全部汉字范围，以容纳图纸标注与材料牌号中出现的生僻字与符号。中文排序支持拼音序与笔画序两种方式，供物料名称、文件名、专家姓名等列表使用。全角与半角字符在入库前做归一化处理，避免同一材料牌号因全角数字与半角数字差异而被识别为两种物料。

检索层面，中文分词采用通用词典加本项目行业词典的方式。行业词典由本项目的知识本体与数据标注规范派生，覆盖刮板输送机零部件名称、备料工序名称、热处理与焊接工艺术语、材料牌号等条目，首批词条规模不少于 3000 条，并在加工生产过程中按新发现的术语持续补充。分词词典的维护界面开放给甲方工艺与技术部门，由业务人员直接增补。

文档层面，交付文档均为中文版，包括用户手册、管理员手册、二次开发手册、数据字典、部署与运维手册、测试报告、验收文档与培训材料。涉及引用国际标准原文的部分，给出中文译名与标准号，必要时附原文条款号便于核对。

输入法与终端层面，手持终端与一体终端机的中文输入经实机验证，车间环境下的手套操作与扫码录入在同一界面内可切换，避免现场人员为输入一个工序名称反复切换输入法。

表 2-1　中文化落实清查表（来源：招标文件 3.1.2.2.1 第（1）条 b0745）

（2）第三方软件授权与知识产权

涉及的第三方软件均有原厂授权、无产权纠纷，甲方使用系统时不受第三方起诉（b0746、b0747）。我方按「先建台账、再定边界、后作担保」三步落实。

建台账是基础工作。三套软件涉及的全部第三方成分，包括商业软件、商业许可的国产操作系统与数据库、开源组件及其间接依赖，逐项登记为《第三方组件授权台账》。台账在首次版本提交评审时一并提交，此后随每次版本发布更新。登记粒度到具体版本号，间接依赖通过软件成分分析工具自动采集生成软件物料清单，避免手工漏登。

定边界是风险控制。开源组件按许可类型分三档管理：宽松型许可可直接使用，保留版权声明即可；弱传染性许可允许以动态链接方式使用，修改该组件本身的代码须按其许可要求处置；强传染性许可不用于与交付代码静态链接或同进程集成的场合，若业务上确需其能力，采用独立进程加接口调用的方式隔离，或改用功能等价的宽松许可组件。这一档的判定在组件引入评审时完成，不留到交付阶段再处理。

表 2-2　第三方组件许可档位与使用边界（来源：招标文件 3.1.2.2.1 第（2）条 b0746、b0747）

作担保是对甲方的承诺。我方承诺交付物不侵犯第三方的专利权、著作权、商标权与工业设计权；若甲方因使用本项目交付的系统而遭第三方以知识产权为由主张权利或提起诉讼，由我方负责应对与抗辩，承担由此产生的诉讼费用、赔偿费用与和解费用；如经判定确有侵权，我方在不影响甲方业务连续性的前提下，采取取得授权、更换为无瑕疵的功能等价实现、或修改实现方式三种方案之一，使甲方得以继续使用系统，相应工作不另行收费。承诺内容写入《知识产权无侵权担保函》，与投标文件一并提交。

台账的字段格式如下，便于甲方在验收与质保期内随时抽查。

表 2-3　第三方组件授权台账字段格式（来源：招标文件 b0746、b0747 及本节承诺）

（3）正版授权书与售后服务承诺书

投标方提供原厂正版软件授权书、售后服务承诺书（b0748）。我方按下列清单与时点提交：投标阶段随投标文件提交《售后服务承诺书》与《知识产权无侵权担保函》；合同签订后 15 个工作日内提交商业软件的原厂正版授权书原件或原厂出具的授权证明，涵盖操作系统、数据库管理系统、商用密码服务平台及其他按许可计费的商业组件；系统上线前提交与实际部署规模一致的许可清单与到期日台账。授权书上的授权主体、许可范围与许可数量以合同约定的部署规模为准，若运行期内甲方扩大部署规模，按许可条款补充授权，补充方式在合同中约定。

售后服务承诺书的服务分级与服务级别条款在售后服务方案一节展开。本节承担的实施职责是把两处数字锁成一套：承诺书中的故障响应时限、恢复时限与可用率条款，取表 1-2 与表 5-1 的同一组量值——一级故障 15 分钟内响应、核心服务恢复时间不超过 30 分钟、月度可用率不低于 99.5%；承诺书定稿前由我方技术与商务按表 1-2 逐行核签，核签记录随承诺书一并归档，两处不出现两套数字。该组量值同为首期基线，判定方法、证据与未达标处置统一按表 1-4 的同一行执行，承诺书不另立判法，其趋向值亦取表 1-2 设计值一列。

正版许可与授权证明的证据按下表引用。证据的提交时点、核验方式与归档位置逐项固定，甲方在验收与质保期内可按本表索引调阅。

表 2-4　正版授权与承诺书的证据引用（来源：招标文件 3.1.2.2.1 第（3）条 b0748；提交时点与核验方式为本节承诺值）

部署规模在运行期扩大的，按许可条款补充授权，补充授权书按同一表格追加登记，台账版本随之更新。

（4）上线前评审与整改

系统所有功能经甲方评审通过后才能上线，评审不通过及时整改，且不影响项目整体进度（b0749、b0750）。「评审通过才能上线」与「整改不影响进度」须同时满足，整改工作纳入排产计划，不得挤占关键路径或靠加班兜底。

我方的做法是把评审做成分批、前置、并行的闸门，而非集中在上线前的一道总评审。

分批是指按功能模块与数据集批次划分评审单元。本项目的交付物天然可分批：三套软件按功能模块分批，四大数据集按供需计划、产品工艺设计、制造过程、质量四个业务域分批，专项智能工具链按九类分批。每个评审单元独立送审、独立通过、独立上线，一个单元未通过不阻塞其他单元。

前置是指在正式评审之前完成内部三道测试并把结论一并提交，减少评审会上才发现基础问题的情形。三道测试为功能测试、性能与可靠性测试、安全测试，分别对应本节第五至第八部分的验证方法。评审材料在评审会前 3 个工作日提交，便于甲方评审人员预读。

并行是指整改与下一阶段工作并行推进。整改单按影响程度分三级，分级与时限见表 2-5。一级整改单关闭后方可上线，二级与三级整改单允许带单上线并在约定时限内关闭，带单上线需甲方书面同意并记录在评审结论中。与此配套的是里程碑缓冲：项目计划在每个阶段末预留不少于 5 个工作日的评审与整改缓冲，缓冲用于吸收整改工作量，使单个评审单元的整改不传导到后续里程碑。

表 2-5　上线评审整改单分级与时限（来源：招标文件 3.1.2.2.1 第（4）条 b0749、b0750）

评审材料清单固定为七项：评审单元的功能说明与操作手册节选、需求对照表（逐条对应招标文件与需求确认结论）、内部功能测试报告、性能与可靠性测试报告、安全测试报告、第三方组件授权台账增量部分、遗留问题清单与处置建议。七项齐备方提交评审，缺项由我方补齐后重新预约，不占用甲方评审时间。

图 2-1　功能上线评审闸门与整改回路

图 2-1　功能上线评审闸门与整改回路。数据来源：招标文件 3.1.2.2.1 第（4）条（b0749、b0750）；整改单分级与时限为本节承诺值。

3、开放性要求（3.1.2.2.2）

三条依次指向二次开发能力与配套文档、用户手册与在线帮助、跨平台迁移与版本升级兼容。数据集加工生产不是一次性工程，甲方在项目结束后仍要持续扩充数据集、新增加工算子、对接新的源系统；我方通过二次开发手册、数据字典与免费技术指导，支撑甲方自行扩展算子与对接源系统。

（1）二次开发能力与配套文档

提供个性化、定制化及二次开发能力，提供二次开发手册、数据结构、数据模型和数据字典，免费提供二次开发技术指导服务（b0752、b0753）。

二次开发能力在本项目上不是一句客套话。数据集不是做完一轮就定型的东西：备料工序今天是 28 道，产线改一次工艺就不止 28 道，工序编码、工序之间的先后约束、每道工序该采哪些参数都要跟着改；63 万张历史图纸连同配套工艺卡解析入库只是起点，此后每天仍有新图纸、新工艺卡产生；井下测点损坏按现行做法不补装，源系统那一侧会凭空少掉一列，下游得分得清这是设备坏了还是停产。

最能说明问题的是焊接。焊机吐出来的参数流是连续的，而工件与焊道是离散的——一件大型单部件的焊缝可达数百条、一条焊缝多层多道，要把某一段参数流归到某一条焊道上，靠的是甲方自己那套焊缝与焊道编号规则。这套规则是企业内部的工艺约定，随工艺文件改版而改；外面的人既写不出来，也不该每改一次就等我方派人改代码。这类事情只有两种结局：要么平台留出甲方自己能动手的地方，要么数据集的扩充速度被我方的排期卡住。

二次开发能力因此落在七个扩展点上，设计原则是新增能力不改主干代码，甲方的开发人员通过注册与配置即可接入自己的实现。七个扩展点按「改动落到哪一层」排：配置即生效、不需要改代码也不需要发版的，是自定义字段与表单、流程编排、报表与看板，再加上事件回调的地址注册；要写代码但不碰主干的，是加工算子；从外部调进来的，是对外接口与工具包。接入方式一列回答的是这件事要不要发版、要不要我方在场，它决定了甲方能不能当天改完当天用上。典型用法一列不是举例凑数：一张只写能力不写用处的清单，甲方读完仍不知道自己手上的哪件事能靠它解决，所以每一行都对上一件本项目里确实会发生的事——给备料工序数据集加一个本企业特有的工序编码字段、写一个专用的图纸标注规则算子、把数据集检索接进协同办公系统。若改按平台模块组织（加工平台的接口、运营平台的接口分开列），同一类扩展会散到多处，甲方想扩一件事得先弄清它归哪个模块管。

七个扩展点要给出的结论是：甲方今后在数据集上要做的扩展都能在表内找到落点，其中四类当天配置当天生效，其余三类由甲方自行开发，均不需要我方改动主干代码。

表 3-1　二次开发扩展点清单（来源：招标文件 3.1.2.2.2 第（1）条 b0752、b0753）

手册写得再细，真正卡住甲方开发人员的常常是另一类问题：这个字段到底指什么、这张表和那张表靠什么对上。数据集元数据里的时效性按哪个时点算，模态占比的分母是条数还是文件数；28 道备料工序的工序编码在库里是一列值还是一张码表，改成 30 道时要动哪几处；63 万张图纸与配套工艺卡的配对关系落在哪张表上，一张图纸对多张工艺卡时主键怎么定。这些问题手册回答不了，只能由数据模型与数据字典逐表逐字段写死。

还有一类失效更隐蔽：文档交了初版就停在那里，半年后界面改了、字段加了、接口出了新版本，照着文档写出来的代码跑不通。甲方被绊住一两次之后就不再查文档、改为直接问人，二次开发能力也就名存实亡。所以这四类文档的交付不止于交出来，还要跟着版本一起走。

四类文档按「从怎么做到是什么」排：二次开发手册讲步骤，数据结构说明讲库怎么分层、实体之间靠什么约束，数据模型讲概念、逻辑、物理三层之间怎么映射，数据字典讲每一个字段的含义与取值。粒度要求一列是这张表的要害——这四类文档都可以写得很薄，也都可以写得真能用，薄的那种交了等同于没交；把粒度写进表里，验收就不是数文档份数，而是按每类扩展点有没有一个跑得通的示例、实体关系图有没有覆盖到全部业务实体、字段清单有没有漏项、码表给没给全取值来判。少了这一列，文档只能按份数验收，而份数与可用性无关。

四类文档合起来要达到的程度是：一个此前没接触过本平台的开发人员，照着它们可以不找我方的人就把一个扩展做完。接口文档的覆盖首期不低于对外接口的 95%，这一项在表 1-2 列为承诺值、在表 1-4 同一行列为判定阈值，两处同一个数：覆盖率以有文档的对外接口数除以对外接口总数计算，分母取契约库登记的对外接口清单，全量核对、不抽样，每次版本发布核对一轮，核对结果连同七类扩展点的沙箱实操记录一并归档。其后随版本逐批补齐、趋向逐一覆盖；某一轮核对低于 95% 的，在版本发布说明中列明缺口接口名与补齐时点，补齐后于下一版本发布时重新全量核对至达标，连续两个版本仍未达的在版本发布说明中单列该批接口并给出专项补齐计划，缺口期间由答疑窗口按售后服务方案的响应时限兜底。四类文档在系统首次上线前交付初版，内容大纲固定如下，随版本更新。

表 3-2　二次开发配套文档交付大纲（来源：招标文件 b0752、b0753）

免费技术指导服务按四种形式提供，不单独收费，服务期覆盖建设期与质保期：二次开发专题培训，面向甲方开发人员，不少于 16 课时，含实操；答疑窗口，建设期内工作日响应，质保期内按售后服务方案的响应时限执行；示例工程与沙箱环境，提供可独立运行的示例工程与一套与生产环境配置一致的沙箱，甲方可在沙箱内自由试验而不影响生产数据；年度技术指导人日，质保期内每年提供不少于 10 人日的现场或远程技术指导，用于甲方自主开发过程中的设计评审与问题诊断。

（2）用户手册与在线帮助

提供完整的用户手册和在线帮助文档，包括常见问题解答、最佳实践和开发指南（b0754、b0755）。

用户手册按角色编写，避免把全部功能塞进一本让每类人都读不完的手册。业务用户手册面向数据集的使用方与审批人，按任务组织章节，每章回答一件事怎么做；管理员手册面向平台管理员，覆盖用户与权限、配额与策略、监控与告警、备份与恢复、许可管理；运维手册面向系统运维，覆盖部署、升级、巡检、故障处置、日志与性能分析；二次开发手册见表 3-2。

在线帮助做三层：页面级帮助，每个功能页面提供入口，打开即是该页面对应的手册章节；字段级提示，对规则不直观的字段给出悬浮说明与取值示例，例如数据集元数据中的时效性口径、模态占比的计算方式；引导式教程，对首次使用的用户提供分步引导，覆盖数据集检索与下载、数据集上传与登记、质检结果查看、订单与审批四条高频路径。

常见问题解答按模块组织，首批不少于 120 条，内容来自三个来源：培训与试运行期间收集的实际提问、答疑窗口的工单记录、我方在同类系统运行中沉淀的高频问题。质保期内按季度更新，新增条目在版本发布说明中列出。

最佳实践取自本项目的真实加工场景，而不是通用性的操作建议。例如图纸批量解析任务的批次大小如何选择与机时的关系、标注一致性校验不通过时的返工判断、数据集版本在场景验证中被引用后如何处理缺陷修复与版本分叉、备料工序数据集在新增工序时的元数据扩展方式。每条最佳实践给出背景、做法与适用边界，不写成口号。

开发指南是二次开发手册中面向场景的部分，按「我要做什么」组织：新增一个加工算子、对接一个新的源系统、增加一个数据集元数据字段、把数据集检索嵌入自有系统、订阅数据集发布事件。每条给出完整步骤与可运行代码。

表 3-3　文档与在线帮助交付清单（来源：招标文件 3.1.2.2.2 第（2）条 b0754、b0755）

文档与系统同源维护：手册与在线帮助使用同一份源文件，一次编写两处发布，避免界面改了而手册没改。文档纳入版本管理，每次版本发布时文档的变更部分在发布说明中列出，甲方可据此判断本次升级影响到哪些操作。

（3）跨平台迁移、版本升级与向后兼容

支持在不同平台间迁移，支持版本升级，新版本向后兼容，现有系统和数据在升级后能正常使用（b0756、b0757）。

可迁移性靠四项设计保证，这四项在系统设计阶段就要定下来，事后补做代价很高。配置外置，全部环境相关配置从代码中剥离，集中在配置中心与环境变量，迁移时只换配置不改代码；应用无状态，会话与临时状态不保存在应用实例的本地内存或磁盘，实例可随时重建；存储访问抽象，文件访问经统一的存储接口层，底层可在本地文件系统、分布式文件系统与对象存储之间切换；数据库方言隔离，数据访问层不直接书写特定数据库的专有语法，专有能力经适配层封装，更换数据库时只替换适配层实现。

表 3-4　迁移场景与实施方法（来源：招标文件 3.1.2.2.2 第（3）条 b0756、b0757）

版本升级按滚动升级方式实施。升级前执行预检查脚本，核对当前版本号、数据库结构版本、磁盘余量、许可有效期与依赖组件版本，预检查不通过则终止升级并给出原因。升级时应用实例分批替换，负载均衡逐批摘除与回挂，升级过程中服务不整体中断。数据库结构变更采用可前滚可回滚的变更脚本，每个变更脚本配一个回滚脚本，变更前自动快照。升级完成后执行冒烟用例集，不通过则自动回滚到升级前版本。

表 3-5　向后兼容规则（来源：招标文件 b0756、b0757；各项保留期为本节承诺值）

兼容性的验证方法是契约测试。对外接口的每个版本维护一份契约（请求与响应的结构与约束），契约测试纳入持续集成，新版本代码若破坏任一已发布契约则构建失败，无法进入发布流程。数据集格式的读取兼容性以历史格式样本集回归验证，样本集随每次格式演进追加，不删除旧样本。

图 3-1　滚动升级与自动回滚时序

图 3-1　滚动升级与自动回滚时序。数据来源：招标文件 3.1.2.2.2 第（3）条（b0756、b0757）与 3.1.2.2.5 第（6）条（b0782）。

4、安全性要求（3.1.2.2.3）

安全技术的实现细节、等级保护测评与商用密码应用安全性评估的组织安排、去标识与脱敏的具体方法在安全方案一节展开。本部分承担三项实施职责，各配可判定的指标：一是给出低级安全漏洞的判定口径与放行门禁，表 4-1 所列十六类与通用漏洞评分 7.0 分及以上的高危漏洞在上线前整改关闭并复测无复现，高危修复时限 7 个自然日、中危 30 个自然日，质保期内按季度复扫；二是给出传输与存储保护的技术基线与指标，Web 应用启用 TLS 1.3（兼容 1.2）并禁用 TLS 1.0、TLS 1.1 与 SSL 3.0，敏感数据按分级加密、密钥统一由商用密码服务平台托管、不在应用侧留存；三是列出保密技术所依据的国家标准与法规，并在上线验收时逐项出具符合性说明。

（1）低级安全漏洞的判定口径与放行门禁

不允许出现低级安全漏洞（b0759）。这一条在验收时需要一个可判定的口径，否则双方对「低级」的理解可能相差很远。我方把低级安全漏洞界定为：可由通用安全扫描工具或常规渗透手法在不构造复杂利用链的前提下直接发现并验证的缺陷。按这一界定，本项目把下列类型列为低级安全漏洞，上线前须整改关闭并经复测验证。

表 4-1　低级安全漏洞类型清单与放行要求（来源：招标文件 3.1.2.2.3 第（1）条 b0759；类型划分参照通用漏洞分级与 Web 应用常见风险清单）

检测安排四道，贯穿开发与交付全过程，不是上线前才做一次扫描。第一道是静态应用安全测试，纳入持续集成，每次代码提交触发，发现表 4-1 第 1、2、3、5、12 类问题即阻断合并。第二道是软件成分分析，每日对依赖清单做一次扫描，比对已知漏洞库，高危漏洞的修复时限为 7 个自然日、中危为 30 个自然日，无可用补丁时作隔离处置并记入《安全缺陷台账》。

第三道是动态应用安全测试，在测试环境对全部对外暴露的页面与接口做扫描，每个版本至少一轮。第四道是渗透测试，在上线前对三套软件做一轮，由具备资质的测评机构或我方安全团队实施，出具渗透测试报告。

放行门限与残留处置：表 4-1 所列类型与通用漏洞评分 7.0 分及以上的高危漏洞在上线前整改关闭、复测无复现，方予放行；4.0 至 6.9 分的中危漏洞逐项进入《安全缺陷台账》，给出整改计划与时限，残留数量趋向零，上线时的残留项须经甲方书面接受并附补偿性控制措施（如访问收敛、监测加强）；4.0 分以下的低危漏洞按版本迭代处置。质保期内按季度复扫一轮，新披露的高危漏洞按上述时限处置，处置记录纳入季度运行报告。

这里需要说清的是一个工程事实：安全漏洞的发现依赖于扫描规则与攻击手法的当期水平，新的漏洞类型会在系统交付之后被披露。我方的承诺因此分两段，交付时点承诺表 4-1 所列类型与高危漏洞关闭，质保期内承诺按季度复扫与上述修复时限持续处置，而不是承诺系统在任何时点都不存在任何漏洞。

（2）传输与存储的加密保护

支持将 SSL 协议作为 Web 应用的基础安全协议，敏感数据在传输和存储过程中得到保护（b0760、b0761）。

传输侧采用双栈并存：标准通道与国密通道。标准通道启用 TLS 1.3（兼容 TLS 1.2），禁用 TLS 1.0/1.1 与 SSL 3.0，密码套件按前向保密套件配置，启用严格传输安全响应头，证书由甲方信任的证书体系签发。国密通道按《GM/T 0024 SSL VPN 技术规范》与《GM/T 0054 信息系统密码应用基本要求》实现传输层密码协议，使用 SM2 证书与 SM4 加密、SM3 完整性校验，密钥与证书由商用密码服务平台与服务器密码机承载。

双栈并存的理由是一个需要正面讲清的工程约束：招标文件要求客户端兼容四类主流浏览器（b0777），而主流浏览器原生不支持国密传输层协议。若强制全站国密通道，普通用户将无法访问。我方的处置是在接入层做通道分流：面向普通业务用户的 Web 访问使用标准 TLS 通道，国密保护在网关之后的内部链路与数据存储层生效；面向管理员、审计员与对外数据交付的高敏通道使用国密通道，通过国密安全接入网关或国密客户端访问，并在管理端提供国密通道的接入说明。两条通道的密钥材料统一由密码服务平台托管，不在应用侧留存。

表 4-2　传输与存储保护的场景对照（来源：招标文件 3.1.2.2.3 第（2）条 b0760、b0761；一文一密与一数据一密能力对应 3.1.2.1 第（12）条）

敏感数据的识别依据本项目的数据分级分类结果。涉及个人信息、敏感地理信息、重要行业数据与企业秘密数据的字段与文件，在元数据中带敏感级别标记，加密策略、脱敏策略与可访问范围由标记驱动，不依赖开发人员逐处判断。分级分类的具体规则与去标识方法在安全方案一节详述。

（3）保密技术符合国家相关技术要求

数据和文档的安全保密技术符合国家相关技术要求（b0762）。我方按下列标准与法规实施，并在验收时逐项提供符合性说明。

表 4-3　保密技术依据的标准与法规（来源：招标文件 3.1.2.2.3 第（3）条 b0762）

文档侧的保密措施落在三处：平台内的数据集说明文档、质检报告与评测报告按敏感级别控制可见范围，下载时加动态水印并记录下载人、时间与用途；对外交付的文档经审批流程，审批记录与文档版本一并留存；项目组内部的资料按本项目保密协议管理，离场人员的账号与权限在离场当日关闭，所持资料当面交接。

5、可靠性要求（3.1.2.2.4）

五条依次指向故障处理能力、容错与快速恢复、交付前的可靠性测试与报告、负载均衡与硬件冗余、模块故障不扩散。可靠性对本项目的意义与一般管理系统不同：数据集加工生产的多数作业是长时间批处理，一张图纸的解析、一批工艺卡的标注、一轮质检的执行动辄数小时，作业中断的代价不是刷新页面重试，而是机时与进度的损失。因此本部分的设计重点放在两处，一是让已经跑了几小时的作业在故障后能从断点继续而不是从头重跑，二是让一个模块的故障不把正在运行的加工作业一起拖下去。

（1）故障处理能力：先看得见，再定得位

具有故障处理能力，遇到异常情况时迅速定位问题、采取补救措施、恢复系统正常运行（b0764、b0765）。迅速定位的前提是系统本身可观测，否则定位靠的是逐台登录翻日志。我方按三类观测数据建设可观测性，三类数据共用同一时间基准与同一关联标识。

指标数据覆盖四层：基础设施层的处理器、内存、磁盘、网络与文件句柄；中间件层的连接池占用、队列堆积、缓存命中率；应用层的接口调用量、错误率、响应时间分位值、线程池状态；业务层的加工作业数、作业成功率、单位时间处理量、质检通过率。采集周期 15 秒，保留 180 天，关键指标保留 2 年用于容量复盘。

日志数据按结构化方式输出，每条日志带时间戳、服务名、实例标识、链路标识、用户标识与业务对象标识。链路标识在一次请求或一个加工作业的全过程中贯通，跨服务调用时随请求头传递，使一次失败可以从入口一路查到失败点。日志集中采集，错误日志保留 180 天。

链路追踪覆盖对外接口与加工作业。接口调用记录每一跳的耗时与状态，加工作业记录每个环节（解析、清洗、标注、质检、入库）的开始时间、结束时间、处理条数与异常条数。作业级追踪对本项目尤为必要，因为一次加工作业可能跨十几个算子，失败时需要知道是哪个算子的哪一批数据出了问题。

时间基准统一是上述三类数据可关联的前提。全部节点与设备侧采集网关对接同一内网时间源，时钟偏差控制在 100 毫秒以内，偏差超限产生告警。本项目的设备侧数据（热成像测温曲线、焊接参数流、图像帧）需要与工件、炉次、焊道做时间对齐，时钟偏差直接影响对齐质量，这一要求不只是运维需要。

表 5-1　故障等级、响应与恢复时限（来源：招标文件 3.1.2.2.4 第（1）条 b0764、b0765；时限为本节承诺值，与售后服务方案同口径）

表中的时限需要把两件事定死，否则验收时同一次故障双方各算各的。

第一是起算时点。一级与二级故障由监测系统自动告警触发，响应时限自告警产生时刻起算，不自人工看到告警起算；三级与四级由用户报障触发，自工单受理时刻起算。告警时刻与受理时刻均由系统记录，不依赖人工填报。响应的判定标志是值守人员在故障单上留下首次处置动作记录，仅签收不计入响应。

第二是值守安排。一级、二级故障的响应时限按 7×24 小时值守兑现，通道为监测自动告警联动电话通知，一线值守接通后即进入分层排查树；三级、四级按工作日 9:00—18:00 受理。质保期与免费技术服务期内按同一口径执行，值班表与联系人随运行报告每月更新并报招标方备案。

遇不可归因于我方的情形——招标方侧网络或机房条件、甲方业务系统故障、不可抗力——响应与恢复时限相应顺延，顺延事实与证据记入故障单并在当月运行报告中列明。

表中一级故障的恢复目标即核心服务恢复时间的首期基线 RTO ≤30 分钟，与表 1-2 同源，按表 1-4 的注入演练口径判定——每项注入重复 3 次取最差值，交付前一轮、质保期内每半年一轮，目标逐步接近 10 分钟。实际处置超出时限的，在故障单中登记超出发生在检测、决策还是执行环节，恢复后 3 个工作日内出根因分析，改进措施并入演练清单下一轮复测；二级至四级的时限按同样方式统计达成率，逐月进入运行报告，连续两个月达成率下降的一并出改进计划。

定位的方法固定为一棵分层排查树，值守人员按树走而不是凭经验猜，排查过程与结论记入故障单。排查树的分层顺序是：先判断影响面（全局、单模块、单用户、单作业），再按接入层、应用层、数据层、依赖层、基础设施层逐层收敛，每层有对应的观测看板与判定依据。补救措施与定位并行，不等根因查清才动手：具备降级路径的先降级保业务，具备冗余的先切换，确有数据风险的先停止写入并保护现场。根因分析在恢复后 3 个工作日内完成，输出故障报告，同类问题的检测规则与预案一并补入运行手册与演练清单。

图 5-1　高可用部署与故障域划分

图 5-1　高可用部署与故障域划分。数据来源：招标文件 3.1.2.2.4 第（2）（4）（5）条（b0766、b0767、b0770、b0771、b0772）、3.3 硬件采购清单（b2150）、3.4 网络部分（b2154）。

（2）容错机制与快速恢复

具有容错机制，在硬件故障、网络中断等不可预见情况下系统能够快速恢复正常运行（b0766、b0767）。容错的做法按故障类型分列如下表，每一行给出检测方式、容错手段与恢复目标。表中的恢复时间为本节承诺值，设计值按表 1-2 的口径取承诺值的三分之一左右。

表 5-2　故障场景、容错手段与恢复目标（来源：招标文件 3.1.2.2.4 第（2）条 b0766、b0767；恢复时间为本节承诺值）

表 5-2 给的是单点故障的处置手段，下面把其中三件需要逐项落到数值与步骤的事分开写清：恢复点与恢复时间的逐对象承诺、切换与回退的触发条件与步骤、重试过程中的一致性保障。

恢复点、恢复时间与切换回退。 不同数据对象的恢复代价不同，用一个 RPO 与一个 RTO 覆盖全部对象，在工程上不成立：结构化数据可由增量日志逼近分钟级恢复点，而数据集制品是大体量不可变文件，逐分钟备份既无必要也无收益。因此按对象分列如下，每一行给出恢复点承诺、恢复时间承诺、切换触发条件、切换步骤与回退方式。

表 5-3　恢复点、恢复时间与切换回退（来源：招标文件 3.1.2.2.4 第（1）（2）条 b0764—b0767；量值、触发条件与步骤为本节承诺值）

切换与回退有两条通用约定。一是切换自动、回切人工：故障发生时的切换由监测与仲裁自动完成，不等人工决策；而故障恢复后的回切须经运维确认并择窗口执行，避免原节点未真正稳定就把流量带回去造成二次中断。二是每次切换与回退都留痕：触发条件、判定依据、执行时刻、业务影响面与数据一致性校验结论记入切换记录，记录随月度运行报告提交。

重试过程中的一致性保障。 容错依赖重试，而重试最容易带来的问题不是失败，是重复——同一笔入库执行两次、同一张图纸解析出两份结构化结果、同一条时序点位写入两次。本项目对重试路径逐类给出一致性手段，使重试在结果上等价于只执行一次。

表 5-4　重试路径与一致性保障（来源：招标文件 3.1.2.2.4 第（2）条 b0766、b0767；策略与判定依据为本节承诺值）

上表七条的验证方法均纳入故障恢复测试执行，结果进入《故障恢复与可靠性测试报告》；其中接口写入、加工作业算子与时序续传三条在质保期内每半年复测一次。

表中「边缘侧本地缓冲」一行需要说明其必要性。本项目的设备侧数据采集点分布在热处理车间与焊接产线，按硬件采购清单配置在线高温热成像设备 6 台、在线热成像设备 21 台、红外图像采集设备 15 台（b2150）。车间网络环境与办公网不同，瞬断较常见，若回传链路一断数据就丢，热处理炉次的温度曲线会出现缺口，而缺口恰好落在关键升温段时，该炉次的数据对质量场景验证即失去价值。因此边缘采集网关配置本地缓冲，按断链 24 小时的数据量预留存储，复通后按时间顺序续传，服务端按设备标识与时间戳去重。

备份策略按对象分列。备份不只是拷一份文件，关键在于恢复可验证，因此每类备份都配恢复步骤、恢复目标时间与演练频次。表中恢复时间与表 5-3 的 RTO 承诺同口径。

表 5-5　备份、恢复步骤与恢复演练（来源：招标文件 3.1.2.2.4 第（2）条 b0766、b0767；保留期、恢复时间与验证频次为本节承诺值）

需要正面说明一处边界：招标文件的硬件采购清单未包含存储设备与通用服务器，网络建设由招标方负责（b2154）。本期的高可用与备份恢复按甲方提供的同一数据中心内的计算与存储资源设计，我方负责给出资源测算依据、分层策略与配置方案，并在资源到位后实施。跨数据中心的异地容灾不在本期采购范围内，待甲方基础设施条件具备后按图 5-1 的故障域划分扩展，扩展方式在运维手册中预留设计说明。

（3）交付前的可靠性测试与报告

在系统交付前进行可靠性测试，包括压力测试、稳定性测试等，提供压力测试报告、稳定性测试报告（b0768、b0769）。

可靠性测试要回答的是一个很具体的担心：这套系统在真正忙起来的那几周里撑不撑得住。本项目最忙的一段是可以预见的——首轮存量加工把 63 万张历史图纸连同配套工艺卡集中消化，按测算是二十个工作日的连续机时（表 7-3），这二十天里加工作业、质检回流与在线检索同时压在一套系统上；而 42 台感知设备的回传并不配合，班次交替那半小时的并发是平时的数倍。只在空闲时段点几个页面看看响应快不快，得出的结论对这二十天没有参考价值。更麻烦的是另一类问题：内存一点点涨、文件句柄一点点漏、连接池一点点占满，单看任何一刻的读数都正常，跑到第三天才崩——这种毛病只有连着跑才露头。

四类测试因此按「验的是哪一种撑不住」分，而不按测试工具或阶段分：压力测试验的是加压到什么程度开始垮、拐点在不在设计容量之上；长稳测试验的是连着跑会不会慢慢劣化；容量测试验的是数据堆到三倍五倍以后关键查询还走不走得动——这一条对本项目尤其要紧，图纸解析产物与血缘记录是只增不减的；故障恢复测试验的是坏了之后多久能回来。缺掉任何一类，都会留下一个在验收时看不出、在首轮加工期才暴露的口子：只做压力测试会漏掉缓慢泄漏，只做长稳测试会漏掉峰值拐点。通过判据与交付报告逐行对齐，是为了让每一类测试都落到一份可以交、可以查的文件上，而不是停在「已测试」三个字。

四类测试合起来要证明的是：这套系统在首轮加工那二十天的负载下有余量，连续运行不会自己退化，坏了能在承诺的时间内回来，而且这三件事都有报告为凭。四类测试的方案与判据如下。

表 5-6　可靠性测试类型、方法与判据（来源：招标文件 3.1.2.2.4 第（3）条 b0768、b0769）

两条劣化判据是首期基线，各自配一套固定的测法与未达标处置。长稳测试的响应时间劣化，以 72 小时内首小时与末小时的每小时 P90 相比计算，公式与采样周期见表 5-8，探针每 5 分钟一轮、每轮不少于 200 次，交付前完整跑一轮、质保期内每半年随版本复跑一轮；首期基线为劣化低于 20%，目标逐步接近 10%。容量测试按 1 倍、3 倍、5 倍基准数据量分别对关键查询与报表取样，每条关键查询与每张报表各采样不少于 200 次取 P90，交付前一轮、其后每年随在库数据量增长复跑一轮；首期基线为 5 倍数据量下劣化低于 50%，目标逐步接近 30%。任一条未达基线的，按索引、分区、预计算与只读副本分层定位整改，整改后重跑完整轮次，不以局部复测替代；重跑仍未达的，在报告中单列该查询或该报表，连同扩容建议与改造计划提交甲方，按计划实施后复测，复测结论补入报告。

故障注入按下表逐项执行。每项在预生产环境注入三次、取最差值，注入时背景负载按 70% 设计容量施加，记录注入时刻、检测时刻、恢复动作、恢复完成时刻与业务影响面，形成注入记录表并入报告。

表 5-7　故障注入清单与判定（来源：招标文件 3.1.2.2.4 第（2）（3）条 b0766—b0769；注入方式与判定阈值为本节承诺值）

稳定性测试的采样与判定单列如下。长稳测试的价值在趋势而不在某一时刻的读数，因此判据以斜率与劣化幅度表述，并固定采样周期与计算方式，避免验收时以某个瞬时峰值争执。

表 5-8　稳定性（长稳）测试的采样与判定（来源：招标文件 3.1.2.2.4 第（3）条 b0768、b0769；采样周期、计算方式与阈值为本节承诺值）

报告由我方测试组按统一模板出具，模板含测试环境配置、测试数据规模、测试用例、原始采样数据、结论与建议六部分，原始数据随报告移交以便复核。报告的出具与复核方式按两档执行：我方出具为基础档，四份报告（压力、稳定性、容量、故障恢复）在系统交付前提交；甲方要求第三方机构复核的，我方提供测试环境、测试数据、用例与原始数据并配合现场复测，复核结论作为报告附件一并归档，复核安排在需求确认阶段确定并写入验收方案。

（4）应用负载均衡与硬件故障冗余

具有应用负载均衡和硬件故障冗余机制（b0770）。

应用负载均衡分三层。接入层采用双机互备的负载均衡，对外提供单一虚拟地址，支持四层与七层转发，按最少连接数与响应时间加权分发，健康检查间隔 5 秒、连续 3 次失败即摘除后端、连续 2 次成功即回挂。应用层的服务间调用采用客户端侧负载均衡，结合服务注册与发现，实例上下线对调用方透明。加工算力层按作业队列分发，调度器按工作单元的剩余配额、作业优先级与数据本地性分配任务，单个工作单元故障时其未完成的任务重新入队，由其他工作单元接手。

密码服务的负载与前三层机制不同，依托商用密码服务平台的虚拟密码网关实现：密码服务按分组注册，应用与服务分组动态绑定，单个密码服务不可用时由同组内其他服务承接，避免密码服务单点故障导致应用瘫痪。这一能力对应安全软件功能要求中的密码服务负载与密码服务调度条款，其功能实现在安全方案一节详述。

硬件故障冗余按设备分列。服务器密码机按技术参数要求配置冗余电源、具备 4 个电口与 4 个光口（b2150），网络接入采用双上行；接入连接器配置双冗余热插拔电源与两块固态硬盘（b2150）；承载平台的通用服务器与存储按甲方资源配置，我方提出的冗余要求为双电源、双网口绑定、系统盘镜像、数据盘多副本或冗余磁盘阵列；车间侧的采集设备按点位冗余设计，同一炉台或产线的多台设备互为参照，单台故障时该点位的数据标记为缺失并告警，不中断其他点位采集。硬件型号、参数与质保条款在硬件选型一节详述。

（5）单一模块故障不扩散

平台具备稳定性与可靠性，单一功能模块出现问题不引发系统其他功能异常（b0771、b0772）。我方通过隔离边界与资源配额限制故障扩散，采取六项隔离手段，并给出可验证的扩散上限。

部署隔离，功能模块按独立部署单元划分，各单元独立进程、独立容器、独立发布，不共享运行时内存空间。资源配额隔离，每个部署单元配置处理器与内存上限，单元内的失控进程不抢占其他单元资源。连接池与线程池分池，数据库连接、缓存连接、外部接口调用按模块分配独立池与独立配额，一个模块把自己的池打满不影响其他模块取连接。

调用熔断，模块间调用设超时与熔断阈值，错误率或超时率越限即断开并返回降级结果，避免故障沿调用链堆积。降级开关，每个模块配置功能级开关，开关表随系统交付，运维可在不发版的前提下关闭故障模块的入口，保留其余功能。前端隔离，页面按模块独立加载，单个模块的前端资源加载失败或脚本异常不阻塞其他模块的页面渲染。

表 5-9　单一模块故障的扩散上限与验证方法（来源：招标文件 3.1.2.2.4 第（5）条 b0771、b0772；判据为本节承诺值）

六项验证场景纳入故障恢复测试，结果进入《故障恢复与可靠性测试报告》，并在质保期内每半年复测一次，复测结果进入运行报告。表中的扩散上限是首期基线，配套的测法为：每个场景在预生产环境注入三次取最差值，注入时背景负载按 70% 设计容量施加，未被注入的模块各以探针采样不少于 200 次，接口成功率＝成功请求数÷总请求数，响应时间劣化＝（注入期 P90－注入前 P90）÷注入前 P90。首期基线为其他模块接口成功率不低于 99.9%、响应时间劣化不超过表中各场景所列幅度，随隔离边界与资源配额在运行期逐轮调优，目标逐步接近成功率 99.95%、劣化收敛到 10% 以内。某一场景未达基线的，定位到是哪一道隔离手段失效（部署隔离、资源配额、连接池与线程池分池、调用熔断、降级开关、前端隔离），补齐该手段后重新注入验证；连续两轮未达的，该场景在报告中单列，加固措施排入下一版本，上线后重新注入复测。

6、运行要求（3.1.2.2.5）

（1）正版操作系统与数据库管理系统

系统基于正版的操作系统、数据库管理系统部署，正版许可由投标方提供，支持最新稳定成熟版本，核心系统不使用免费版数据库管理系统（b0774、b0775、b0776）。

许可由我方提供并随合同交付授权书。操作系统与数据库在招标文件国产化要求列举的范围内选型（b0790、b0792），最终型号与版本在需求确认阶段与甲方共同确定后写入《软硬件配置清单》。

「最新稳定成熟版本」需要一个判定口径，否则容易出现两种偏差：一种是追最新，选了刚发布的大版本，上层组件尚无互认证明，上线后踩兼容问题；另一种是过于保守，选了即将停止维护的版本，质保期内无法获得安全补丁。

我方的判定口径为四条同时满足：属于原厂的长期支持版本；发布满 6 个月且已有补丁更新记录；在本项目计划的质保期结束之后仍处于原厂维护期内；与本项目上层组件（中间件、运行时、密码服务）有可查的兼容性互认证明或经我方适配测试通过。四条判定的核对结论记入《版本基线说明》，随配置清单一并提交评审。

核心系统不使用免费版数据库，落实为三条约定。承载业务数据、数据集元数据、订单与审计记录的核心库，采用商业许可的国产数据库，许可由我方提供，许可规格覆盖合同约定的部署规模。承载时序数据、全文检索、分布式缓存、消息队列的组件按其技术定位配置：这些组件不作为核心业务数据的唯一存储，其中的数据均可由核心库或对象存储重建，采用商业许可或商业支持版本，并在《第三方组件授权台账》中标明其许可类型与数据可重建性。数据集制品与原始件存放于对象存储，其元数据与校验值在核心库中，制品丢失可按元数据重新生成或从备份恢复。

表 6-1　软件许可与数据可重建性对照（来源：招标文件 3.1.2.2.5 第（1）条 b0774、b0775、b0776）

许可台账记录每项许可的授权主体、许可范围、许可数量、生效日与到期日，到期前 90 天自动提醒。质保期内的许可续期责任按合同约定，我方在质保期内承担已交付许可的维保与补丁获取。

（2）浏览器与终端兼容

客户端支持主流浏览器，支持多种终端设备使用，包括个人计算机、一体终端机、手持终端及各类移动终端（b0777、b0778）。

浏览器兼容按内核基线而非品牌逐个适配。招标文件列举的四类主流浏览器分属两种内核，我方以这两条内核基线组织开发与测试，可覆盖同内核的其他浏览器，也避免因某一品牌版本号变动而反复返工。前端不使用依赖特定内核私有特性的实现，不使用已废弃的插件技术。

表 6-2　浏览器与终端兼容矩阵（来源：招标文件 3.1.2.2.5 第（2）条 b0777、b0778）

手持终端的适配有三处是现场提出来的而不是通用要求，列在此处是因为它们影响前端实现方式。车间人员多戴手套作业，触控目标尺寸与手势复杂度须据此放宽，滑动类手势不作为唯一操作路径；车间局部区域光照强烈且有弧光，界面采用高对比配色并提供亮度适应；车间无线信号存在盲区，现场录入类功能（工序确认、交检拍照）支持离线暂存与联网后自动提交，提交结果以消息回执确认，避免人员重复录入。

（3）本地化与私有云部署

支持本地化、私有云部署环境（b0779）。三套软件按本地化私有部署设计，不依赖公网服务，不要求甲方开放外网访问。为此提供四项配套：离线安装介质，包含全部镜像、依赖包与安装脚本，介质内自带校验清单；内网镜像仓库与依赖仓库，部署在甲方内网，升级包经审批后由介质导入；许可激活采用离线方式，按设备指纹生成许可文件，不回连厂商服务器；时间源、证书颁发与域名解析均使用甲方内网服务，部署前核对清单由我方提供。

系统的外部依赖逐项列入《外部依赖清单》，标明是否必需、离线替代方式与缺失时的影响，便于甲方在网络策略审批时逐项核对。清单随部署方案一并提交。

（4）物理机与虚拟化等多种部署方式

支持物理机部署、虚拟化部署等多种部署方式（b0780）。

部署形态在本项目上不是一道单选题，原因在负载本身就是两种脾气。存量图纸与工艺卡的首轮消化是一次性的集中投入，机时按表 7-3 测算；这一轮过去之后转入增量加工，日常机时需求落下一个量级。若一开始就按首轮峰值把算力固定在物理机上，加工期一过，这批资源大半时间闲着。另一头，核心数据库与密码服务对时延和隔离敏感，处理器一旦超分，同样的查询今天零点三秒、明天一秒二，容量测算就失去了意义，这类负载反过来不适合放在共享的虚拟资源上。

三种形态因此按「哪一类负载该落在哪种资源上」排，而不是按产品形态罗列。应用层与数据层分成两列，是因为这两层对资源的要求正相反——应用层要的是能随队列水位伸缩，数据层要的是性能可预期；合成一列会把这个对立藏起来，甲方照着选就容易把数据库也放进可超分的资源池。资源供给特点一列点明超分与否，是后续容量测算能不能成立的前提：表 7-6 的算力测算默认内存不超分、处理器仅在应用层适度超分，换一种供给方式，测算结论要跟着重做。

应用层采用容器化封装，三种形态下的应用交付物一致，差异集中在资源供给与编排方式，这是支持多形态的前提。由此可得的结论是：甲方按自己的机房与资源条件选形态，甚至三种混用，都不需要我方改造应用，只需按下表核对各层的资源供给是否满足前提。

表 6-3　部署形态与资源供给对照（来源：招标文件 3.1.2.2.5 第（3）（4）条 b0779、b0780）

本项目建议采用混合形态。理由是加工负载的波动很大：首轮存量加工（63 万张历史图纸的解析与标注）需要集中投入机时，之后转入增量加工，机时需求下降一个量级。把工作单元池放在可弹性伸缩的资源上，首轮加工期扩容、转入运行期缩容，比按峰值配置固定资源更经济；而核心数据库与密码服务对时延与隔离敏感，放在物理机上性能可预期。资源测算见表 7-3。

（5）页面打开与报表生成响应时间

应用页面打开响应时间不超过 1 秒，报表生成响应时间不超过 3 秒（b0781）。两项的承诺值、设计值见表 1-2，设计依据与测试负载见表 1-3，测试步骤、采样周期、计算公式与判定阈值见表 1-4，测量五要素按表 1-1 固定。页面打开的实现手段与第七部分的三项响应时间同源，见第七部分第 6 节的七组性能保障手段。报表一类另需一道口径划分，因为报表的数据量跨度很大，用一个数字覆盖全部报表在工程上不成立。

报表按结果集规模分两类，分界线在需求确认阶段逐张报表确认后写入验收方案。预置报表与常用统计属于同步类，由预计算与物化视图支撑，生成响应时间不超过 3 秒；跨年度全量明细、数据集全量清单导出、审计日志全量导出一类属于异步类，采用提交即返回加后台生成加完成通知的方式，提交动作的响应时间不超过 3 秒，生成完成后在消息中心与邮件中给出下载链接，生成进度在界面上可见。两类报表在界面上有明确标识，用户提交前即知道是即时出还是稍后取。

大结果集报表采用「提交响应不超过 3 秒 + 异步生成」：若将全量导出做成同步请求，页面长时间无响应易导致前端或网关超时、用户反复点击与后台重复生成，既不满足响应时间又加重负载。测点按表 1-1 与验收方案执行。

（6）升级易操作且不影响接口

系统升级易操作，不影响与其它模块的接口（b0782）。

升级操作的形态是一条命令或控制台上的一次操作：运维人员在控制台选择目标版本并发起升级，系统自动执行预检查、快照、分批替换、冒烟验证四个步骤，每一步的结果在界面上可见，任一步失败自动回滚并保留现场日志。升级手册给出操作步骤、预计时长、回滚方式与验证清单，升级操作不需要掌握底层细节。升级流程与回滚时序见图 3-1。

接口不受影响由三层保障。契约层面，对外接口与模块间接口的每个版本维护一份契约，契约测试纳入持续集成，破坏已发布契约的变更无法进入发布流程。兼容规则层面，按表 3-5 的七项规则约束变更内容。验证层面，升级前执行接口回归用例集，用例集覆盖全部对外接口与模块间关键调用，升级后的冒烟验证再跑一遍关键链路；与甲方其他系统的集成接口纳入回归范围，升级窗口与甲方侧的验证窗口在运维计划中对齐。

升级影响评估在每次升级前出具，内容包括：本次变更涉及的模块与接口、兼容性影响判定、数据库结构变更项与回滚方式、需甲方侧配合验证的接口清单、预计升级窗口与回退时限。评估单经甲方确认后执行升级。

7、性能要求（3.1.2.2.6）

（1）三项响应时间指标的口径与实现

登录响应时间小于 1 秒（b0784）、简单页面操作平均响应时间小于 1 秒（b0785）、复杂页面操作平均响应时间小于 2 秒（b0786）。

承诺值与设计值见表 1-2，测量五要素见表 1-1。这里需要先解决一个定义问题：什么叫简单页面操作、什么叫复杂页面操作。若不预先划分，验收时容易出现把一个跨六张大表的多维统计算作「简单页面操作」的争议。我方给出的划分规则如下，并在需求确认阶段逐个功能点归类后写入验收方案。

表 7-1　页面操作分类与响应时间承诺（来源：招标文件 3.1.2.2.6 第（1）（2）（3）条 b0784、b0785、b0786 与 3.1.2.2.5 第（5）条 b0781）

登录链路的耗时构成需单独说明，因为本项目的登录不是单纯的口令校验。按安全性要求，管理员与审计员采用口令与证书结合的双因素认证，认证过程涉及证书校验与密码服务调用。为把登录控制在 1 秒内，我方在实现上做三件事：证书校验结果在会话有效期内缓存，不每次请求都回密码服务；密码服务调用经虚拟密码网关做连接复用，避免每次建链；登录后的首屏数据与登录认证解耦，认证完成即跳转，首屏数据异步加载并带骨架屏，使用户感知的等待时间就是认证时间。

图 7-1　响应时间的构成与测量点

图 7-1　响应时间的构成与测量点。数据来源：招标文件 3.1.2.2.5 第（5）条（b0781）、3.1.2.2.6 各条（b0784—b0786）与本节表 1-1 口径。

（2）并发与容量规划

招标文件的性能要求给出了三项响应时间，未规定并发量与数据容量。响应时间离开并发与数据量无法独立成立，因此本部分先把业务量推导成并发量，再把并发量与样本量推导成存储与算力，形成一条可代入复核的测算链。

业务量的推导起点是人与班次，不是经验数字。甲方按两班制组织生产，设计与工艺、生产计划、质量检验、库存与物流、设备运维五类岗位是平台的主要使用方；通用问答类场景面向全员开放，因此注册用户按在册人员规模取值。推导分四步：在册人员 → 注册用户 → 在线用户峰值 → 事务并发。第一步按在册人员全量开通计，基准取 2000 人（该值在需求确认阶段按甲方核定的实际使用人数调整，调整后按同一算式重算后三步，重算结果写入验收方案）；第二步按班次交替时段同时在线比例 25% 计，得在线用户峰值 500 人；第三步按人均每分钟 12 次页面级操作、每次操作折合 1 个事务计，得峰值事务并发 500×12÷60＝100 TPS；第四步取常态在线比例为峰值的 70%，得持续负载 350 人、70 TPS。

持续负载与峰值负载分开承诺，两者用途不同：持续负载是容量规划与资源配置的基准，也是长稳测试的加压点；峰值负载是响应时间承诺成立的边界条件，也是压力测试的判定点。表中设计值为内部设计目标，按峰值的 1.5 倍取。

表 7-2　并发与容量规划：业务量推导、持续负载与峰值负载（来源：响应时间指标对应招标文件 b0784—b0786；并发量与推导算式为我方承诺值）

时序写入量的测点推导式为：写入速率＝Σ（设备类别台数 × 单台测点数 × 采样频率）＋平台自身监测指标数÷采集周期。按本项目配置代入：二十七台热成像与高温热成像设备各取点、线、区域标量测点 100 个、采样 1 赫兹，得 2700 点/秒；十五台熔池相机各取派生特征标量 20 项、采样 10 赫兹，得 3000 点/秒；热处理群控与焊接电源等工艺侧参数按接入点位 2000 个、采样 1 赫兹，得 2000 点/秒；平台自身监测指标按节点数 ×400 项÷15 秒采集周期估算。四项合计约 1 万点/秒为常态，承诺值取 5 万点/秒，留出甲方测点清单核定后扩充与采样频率上调的余量。测点总数与采样周期清单在需求确认阶段与现场勘察后核定，核定值代入上式重算，重算结果写入验收方案；承诺值在重算结果超出时按表 1-1 的条件变更流程重订。

（3）数据加工生产的吞吐与存量消化测算

本项目的性能压力主要不在在线交互，而在加工生产的批量处理。四大数据集的规模是预训练数据集 615 亿 Token、指令微调数据集 89 万条、强化学习偏好数据 6.6 万组、基准测试数据集 0.95 万条，历史工艺样本 63 万张图纸，备料工序 28 道。按这些规模测算的加工吞吐与机时如下，每一行给出单元吞吐、工作量与机时算式，可代入复核。

表 7-3　加工吞吐与存量消化测算（来源：数据集规模与历史样本量依招标文件 2.2 业务范围 b0683 与需求说明书；单元吞吐与机时为我方测算值）

表中机时数与人日数的对比说明了一件事：机器处理的瓶颈不在算力而在人工复核。因此加工排产的组织方式是按业务域分批流水，机器处理与人工复核错峰并行，而不是等全部机器处理完成再开始复核。工作单元数在首轮存量加工期按表 7-2 的设计值配置，转入增量加工后缩容，对应表 6-3 建议的混合部署形态。

（4）设备侧数据回传的带宽与存储测算

本项目的感知与检测设备按硬件采购清单配置红外图像采集设备 15 台、在线高温热成像设备 6 台、在线热成像设备 21 台（b2150）。这些设备的原始数据率远高于一般业务系统，若按全量回传设计，车间网络与存储都承担不起，因此采用边缘侧按业务事件抽帧的方式，把回传量压到百分之几。测算如下。

表 7-4　设备侧数据回传测算（来源：设备台数与参数依招标文件 3.3.1 硬件采购清单 b2150；数据率与回传量为我方测算值）

抽帧不是为了省带宽而牺牲数据价值，抽帧规则由场景验证的数据需求反推确定。焊接场景需要的是起弧、稳定段与收弧三个时刻的熔池形貌，以及异常时段的连续画面；热处理场景需要的是升温段与保温段的温度曲线与关键节点的温度场分布。按事件触发留帧，恰好留下这些有用的部分，而连续录制的大部分画面是重复的。抽帧规则在数据标注规范中固化，并随场景验证结论调整；原始连续数据在边缘侧按滚动窗口保留 72 小时，期间可按需回溯调取，超期覆盖。

（5）存储与算力容量测算

存储与算力资源不在本项目的硬件采购清单内，由甲方申领配置。申领要有依据，而依据不能是一个总数——报一个「需要若干 TB」的数字，甲方既无法判断这笔资源该分几批到位，也无法在到位量不足时判断先保哪一块。本项目的量又确实不小：63 万张历史图纸的原始件接近 1 TB，解析产物与渲染图是原始件的两倍多，42 台感知设备还在按班次不间断回传熔池画面与温度场数据，这几项的增长节奏完全不同——图纸是一次性存量，设备数据是按天累积的流量。

测算因此按数据对象分行，而不按存储设备分行。这样排的好处是每一行的量都能从一个可核对的现场事实推出来：张数乘以单件大小、台数乘以帧率乘以留存时长，算式摆在行里，甲方拿自己的数代进去就能复核，不必接受一个无从验证的汇总值。所在层一列把冷热分开，是因为历史留档没有必要占高速盘，而数据集制品要随时可取；不分层的报法会把归档量按在线层的单价一起算进去，资源申领的盘子被放大，反而拖慢到位。

存储按在线层与归档层两层规划。在线层承载近期需访问的数据与全部数据集制品，归档层承载历史留档。读完这张表应当能得到两件事：总量从哪里来，以及资源分批到位时按什么次序保——在线层优先，归档层可后置到首轮加工完成之后。

表 7-5　存储容量测算与冷热分层（来源：数据规模依招标文件 b0683 与本节口径；容量与冗余系数为我方测算值）

冷热分层的迁移规则由策略驱动：设备侧留档超过 6 个月自动转归档层，时序数据按分区超过 12 个月转归档，数据集制品的非当前版本按数据治理章节的版本保留策略转归档。归档层的数据仍可检索其元数据，取回时按异步方式处置并给出预计时间。表 7-5 中带暂估值的两项（既有非结构化文档、时序数据）在需求确认阶段按甲方清点与现场勘察结果核定，核定值代入同一算式重算，重算后的资源需求以书面方式提交甲方。

算力资源按两类负载分开测算，不合并成一个数：在线交互负载的资源需求由并发量决定，波动小；批量加工负载的资源需求由样本量与工期决定，首轮存量加工期与转入增量后相差一个量级。两类负载使用不同的资源池（见本部分第 6 节的资源隔离），因此测算也分开列出。

表 7-6　算力与资源测算（来源：样本量依招标文件 2.2 业务范围 b0683 与需求说明书；并发量依表 7-2；资源配置与算式为我方测算值）

表 7-6 的配置是向甲方提出的资源需求，不是本项目的采购内容。承载平台的通用服务器与存储不在本项目硬件采购清单内，资源到位配置低于上表的，按本部分第 7 节末段的约定重做容量核算并提交，由双方确认调整后的承诺值。

（6）性能保障手段

响应时间与吞吐指标的达成依靠下列七组手段，每组给出其针对的瓶颈。

前端侧，静态资源按模块分包与按需加载，首屏只加载当前模块；长列表采用虚拟滚动，不一次性渲染全部行；静态资源在内网缓存并带版本指纹，升级后自动失效；首屏数据与认证解耦，认证完成即跳转。

接口侧，读写分离，统计与报表类查询走只读副本；按业务对象设计接口粒度，避免前端为一个页面发起十几次请求；批量接口支持一次取回多个对象，减少往返次数。

缓存侧，热点数据（工序字典、物料主数据、数据集目录、权限信息）进分布式缓存，设置过期时间与主动失效；缓存键按数据版本构造，数据更新即换键，避免脏读；缓存击穿与雪崩按空值缓存与随机过期时间处置。

数据库侧，慢查询阈值设为 200 毫秒，超阈值查询自动记录并进入每周治理清单；索引按实际查询模式设计并定期复核；时序表按时间分区，图纸与加工明细表按业务域与批次分区，查询带分区键；大表的统计类查询用物化视图或预计算结果表支撑，预计算任务在低峰时段执行。

异步化侧，长任务统一走任务队列，提交即返回任务号，进度与结果经消息中心回传；导出类任务生成文件后给出下载链接，文件按保留期清理。

算力调度侧，加工作业按优先级与配额调度，场景验证所需的数据集优先排产；工作单元按队列水位弹性伸缩；作业带检查点，可中断可续跑，使高优先级作业可以插队而不浪费已完成的处理量。大模型调用经统一网关，网关侧做并发控制、批量调度、失败重试、超时控制与调用成本统计，避免单个作业把调用额度占满。

资源隔离侧，在线交互与批量加工使用不同的资源池与不同的数据库连接池，加工作业的资源占用不影响在线操作的响应时间。这一点对本项目尤其重要：首轮存量加工会长时间满负荷运行，若与在线交互共用资源，用户会在加工期间感到系统明显变慢。

（7）性能测试与性能回归

性能测试在三个时点执行：模块上线评审前、系统整体上线前、每次版本升级前。前两次按表 5-6 的压力测试与稳定性测试方案执行，第三次执行性能回归用例集。

性能回归纳入持续集成。关键接口与关键页面的响应时间基线保存在基线库中，每次构建后在标准测试环境跑一轮性能用例，与基线比对；P90 响应时间劣化超过 20% 则构建失败，需定位原因并处置后方可进入发布流程。基线在每个大版本发布后重新采集并归档，形成可比较的历史曲线。

质保期内每季度做一次性能复测与容量复盘，内容包括：按表 7-1 的分类复测响应时间、核对实际并发与数据量相对表 7-2 设计容量的占用率、按增长趋势给出扩容建议。复盘结果进入季度运行报告。实际数据量或并发超出表 7-2 设计容量时，按表 1-1 第五行的条件变更流程重订基准。

响应时间承诺的成立条件是其所对应的数据量与并发量，二者须与承诺值一并固定。

同一个页面操作，在十万条记录上和在一亿条记录上，响应时间不是一个量级。本项目的数据量在建设期内持续增长——预训练子集按 615 亿 Token 承接，数据集条目、血缘记录、质检记录随加工批次累积，三年后的数据规模与上线初期相差数十倍。若只承诺一个响应时间而不绑定数据量，这条承诺在第一年成立、第三年必然不成立。

因此本方案的性能承诺与表 7-2 的设计容量绑定：在表 7-2 所列并发与数据容量范围内，表 7-1 的响应时间承诺全程成立（登录 <1 秒、简单 <1 秒、复杂 <2 秒），不另设随数据量分档下调的承诺值。建设期内数据量增长通过容量复盘与扩容建议消化；实际并发或数据量超出表 7-2 设计容量时，按表 1-1 第五行的条件变更流程重订基准，不以默示放宽表 7-1 作为处置。

验证安排与上述口径一致：竣工验收与建设期阶段验收均按当时实际数据量实测表 7-1；交付前按表 7-2 满载规模造测试数据做压力测试并出具报告，终验收前用实际数据复测一次。模拟与实测的差异如实记录，差异超过约定幅度时，说明容量规划的假设需要修正，并给出修正后的资源需求。

需要说明的是，上述承诺以招标方提供的服务器资源达到容量规划所列配置为前提。本项目采购清单不含通用服务器，若实际到位配置低于规划，我方在收到实际配置清单后十个工作日内重做容量核算并提交，由双方确认调整后的承诺值——这一条在系统集成章节的前置条件表中同样列明，两处口径一致。

8、国产化要求（3.1.2.2.7）

（1）国产化适配的技术路线

支持国产化硬件设备，包括国产服务器、中央处理器、存储设备、网络设备、个人计算机、移动终端等（b0788、b0789）；支持国产化操作系统（b0790、b0791）；支持国产化数据库（b0792、b0793）。

国产化适配的工程难点不在「能不能跑起来」，而在三件事：一是避免架构锁定，二是避免对特定数据库专有语法的依赖，三是识别并补偿国产栈上的性能折损。我方的技术路线按这三点组织。

避免架构锁定靠多架构构建。持续集成流水线对同一份源码产出多架构的容器镜像，覆盖国产处理器常见的指令集架构与通用架构，镜像以同一版本号发布、按目标节点自动选择。涉及本地编译的组件（如图像处理、压缩、加解密库）在流水线中对各架构分别编译并跑适配测试，不以「在某一架构上能跑」代替全架构验证。

避免数据库专有依赖靠方言隔离层。数据访问层统一使用标准结构化查询语言子集，分页、序列、字符串函数、时间函数、层次查询一类在各数据库间写法不同的部分，经适配层按数据库类型分派实现；存储过程与触发器尽量不用，确需使用时在适配层登记并对每种目标数据库各提供一份实现；数据库结构变更脚本由统一的变更工具生成，按目标数据库方言输出。

识别性能折损靠基线对比测试。对同一组关键操作，在国产栈与通用栈上分别采集性能基线，逐项记录差异。差异在可接受范围内的直接采用；差异较大的按三条路径处置：参数调优（连接池、并行度、内存配置、执行计划）、实现调整（改写查询、增加预计算、调整索引策略）、资源补偿（按折损比例上调资源配置）。处置后仍不满足表 7-1 承诺值的，按表 1-1 的条件变更流程与甲方书面协商。折损评估结论随《国产化适配测试报告》提交。

图 8-1　国产化适配的分层与验证

图 8-1　国产化适配的分层与验证。数据来源：招标文件 3.1.2.2.7 各条（b0787—b0793）与项目目标中的国产化比率要求（b0677）。

（2）国产化适配矩阵

国产化在招标文件里是一句比率和一串类别名，真正会出事的地方却在运行期：某个组件在国产处理器的指令集上编不过去，某个驱动在国产操作系统上装不上，某台感知设备的取流接口只提供厂商自带的封装而拿不到带时间戳的原始帧——任何一处卡住，牵动的都不只是那一个部件，而是整条采集到入库的链路要重排。本项目的适配对象也不止于平台自身，还连着 42 台感知设备的取流、密码机的接口与甲方已有的十余套业务系统。

十一类对象因此逐类列适配要求，而不按厂商或型号列。型号要到需求确认阶段才与甲方共同确定并填入《软硬件配置清单》，先锁型号等于把供货周期的风险提前锁进合同，适配结论若与型号冲突也再无调整余地。每一类都带验证方法与证明材料两列，是因为「支持国产」这四个字本身不构成交付——说支持而拿不出跑过的报告和可查的凭证，在验收时与没做没有区别；把验证方式写在同一行，这一类将来由谁测、测什么、交什么，当下就已定下。

由此可得的结论是：型号待定不等于责任待定——十一类对象的适配方式、验证方式与应交凭证都已逐类写明，型号确定后填入清单即可执行。

表 8-1　国产化适配矩阵（来源：招标文件 3.1.2.2.7 b0788—b0793、3.3.1 硬件采购清单 b2150）

表 8-1 是按类别逐项列的适配要求，但国产化在运行期是以组合形态出现的：一套国产操作系统配一种处理器架构、再配一种国产数据库，三者两两适配不等于三者同时可用。逐类验证通过而组合未验的，问题通常在上线后才暴露。因此在逐类适配之外，另按组合做一轮验证，组合清单如下。

表 8-2　国产化组合验证矩阵（来源：招标文件 3.1.2.2.7 b0788—b0793；组合划分与验证内容为我方承诺的验证口径）

组合验证的执行方式与判据：组合一为生产主用组合，须通过全部验证内容，是上线放行的前置条件；组合二至组合五各为一条替换路径，须通过其所列内容，用途是在某一层出现供货或适配问题时可按本部分第 4 节的回退路径切换；组合六不作为交付形态，只用于采集通用栈基线，与组合一逐项比对得出折损幅度。各组合的性能基线按表 1-4 的采样与计算方式采集，响应时间取 P90，组合一的结果须满足表 1-2 的承诺值；组合二至组合五允许相对组合一有折损，折损超过 20% 的按参数调优、实现调整、资源补偿三条路径处置，处置结论写入《国产化适配测试报告》。组合验证在系统整体上线前完成一轮，质保期内发生底座版本升级时就受影响的组合补测一轮。

兼容性互认证明材料按从严口径提供：操作系统、中央处理器、数据库、中间件四类基础环境每类不少于 3 份，合计不少于 12 份，与安全方案一节对该项的提交口径一致，不另立份数标准。

（3）国产化率的核算口径与承诺

项目总体目标要求数据库、安全软件、云平台、服务器、存储、网络、芯片等软硬件设备整体国产化比率不低于 80%（b0677），技术服务要求中亦明确国产化率不低于 80%（b2219）。国产化率是一个需要先约定分母的指标，因此我方给出核算口径如下，并在需求确认阶段与甲方书面确认。

核算范围以本项所采购或开发的软硬件为限，这一边界取自招标文件原文「仅针对本项所采购或开发的软硬件」（b1208）。甲方既有存量设备，以及以服务形态提供、不在本项采购清单内的计算与存储资源，按同一套判定规则纳入《国产化适配测试报告》的登记与验证范围，但不计入比率分母——这部分资源的国产化情况不由本项目决定，计入分母等于把不可控项写进可核算的承诺。登记而不计入，与不管不问是两件事：登记项同样要出具适配结论与兼容性证明，只是不参与比率计算。甲方既有设备的接口对接按需求确认阶段确认的边界执行。

核算采用采购金额单一口径，不用台套数口径，也不取两者中的较低者。理由是台套口径不稳健：分母中四十二台感知设备占到七成以上，比率几乎完全由这一类设备的判定结果决定，一个判定争议点就能把结论从达标推到不达标；金额口径的分母由硬件采购、软件许可与自研交付几块构成，单项得失不会翻转结论。

分子与分母逐项定义如下，不留解释余地。

分母＝本项所采购或开发的软硬件条目的含税金额合计，由四块构成：一是硬件采购，含服务器密码机 1 台、接入连接器 3 台、红外图像采集设备 15 台、在线高温热成像设备 6 台、在线热成像设备 21 台，共 46 台；二是外购软件许可，含操作系统、数据库管理系统、中间件与商用密码服务平台；三是自研交付软件，含数据集加工生产平台与运营服务管理平台 2 套；四是随上述软硬件一并交付、按许可或按节点计费的配套组件。不计入分母的是甲方既有存量设备，以及以服务形态提供、不在本项采购清单内的通用服务器、存储与网络资源。

分子＝分母各条目中判定为国产的条目的含税金额合计。判定按整机级与制品级作出，依据四条：设备或软件制品的厂商归属；计算类设备的处理器与操作系统来源；信创适配认证；国密产品认证。「芯片」一项穿透至计算芯片（处理器），不穿透至成像与红外探测等非计算器件——这一档次与硬件选型一节的选型准则、安全方案一节的密码产品判定取同一条规则。

比率＝分子÷分母。达标条件可以写成一行算式：记感知设备本体含税金额为 Hs、分母中其余构成合计为 Other，则比率不低于 80% 等价于 Hs ≤ 0.25 × Other。厂商报价到位当天即可代入验证，不必重做判定。

全卷一套口径。 上述分母边界、金额单一口径、四条判定依据与穿透档次，与硬件选型、安全方案、总论各节取同一套，不在各章分别核算：硬件选型一节给设备的国产化选型准则与证明材料，安全方案一节给安全软件与密码产品的信创适配与认证材料，两节的判定结论直接作为本表的输入；总论引用的比率结论取本表的核算值。核算表是唯一依据件，任何一章出现与本表不一致的比率或口径，以本表为准。

表 8-3　国产化率核算表（来源：招标文件 2.3 项目目标 b0677、3.1.2.2.7 b0788—b0793、3.3.1 b2150、第 6 章技术服务要求 b2219）。招标文件点名的数据库、安全软件、云平台、服务器、存储、网络、芯片七类，在表中逐类均有对应行：数据库对应数据库管理系统行；安全软件对应商用密码服务平台行；服务器、存储与网络分别对应服务器密码机、接入连接器与通用服务器、存储与网络资源三行；芯片与云平台各单列一行，前者随计算类整机计入、后者在本项无采购条目并按不计入分母处理，两类的结论均写在本表内。表中判定按上文四条依据作出，穿透档次限于计算芯片；感知设备按整机厂商归属判定，核心成像器件来源以原厂说明为凭，与硬件选型一节「在满足全部技术参数的前提下优先国产化」的选型口径一致。若甲方要求把穿透档次下延至成像与红外探测器件，感知设备须逐台另行举证，此时台套数口径的结果会大幅下移，而金额口径仍按上文达标条件判定——这是不采用台套数口径作为承诺口径的直接原因。穿透档次在需求确认阶段与分母边界一并书面确认。

核算结论在两个时点出具：合同签订后的《软硬件配置清单》中给出预计核算值，系统上线验收时按实际到货与部署情况出具《国产化率核算说明》。核算说明的附件固定为五项，与硬件选型、安全方案两节的证明材料同源、不重复采集：设备与软件条目清单（型号、数量、厂商与厂商归属地、含税金额）；计算类设备的处理器与操作系统来源说明；信创适配认证与兼容性互认证明材料（四类基础环境每类不少于 3 份）；《商用密码产品认证证书》；自研软件的著作权登记证明与底层技术平台自主可控说明。五项附件随核算说明一并提交，供甲方按分子分母逐条复核。

（4）适配风险与回退

国产化适配存在三类可预见的风险，我方在方案中预置回退路径，而不是等问题出现再处置。

第一类是某一国产组件在本项目负载下的性能不达预期。回退路径为：先按参数调优与实现调整处置，仍不达标则在 b0790、b0792 列举的范围内更换同类国产组件（方言适配层与存储抽象层的设计使更换成本可控），更换后重新执行适配用例与性能基线对比。

第二类是某一第三方组件无国产架构的可用版本。回退路径为：寻找功能等价的可跨平台实现或开源实现并自行编译适配；无等价实现时将该组件的功能下沉到适配层由我方实现，或将依赖该组件的功能部署在通用架构节点上并在国产化率核算中如实计入。

第三类是适配所需的兼容性互认证明材料不足。回退路径为：由我方组织实测并出具《适配测试报告》作为补充证明，同时向原厂申请互认测试；安全软件的互认证明材料按招标文件对该项的要求份数提供，具体安排在安全方案一节说明。

三类回退的触发条件与处置时限纳入项目风险登记册，按项目管理章节的风险管理流程跟踪。

国产化适配按四层分别作出结论，每层的判定对象、验证方式与证据不同，适配结论不以单一布尔值表述。

第一层是运行层：操作系统、数据库、中间件、运行时。这一层的适配结论是二值的——能装、能跑、能通过功能回归即为适配。验证方式是在目标环境上跑完整的功能回归集与性能基线集，出具适配报告。

第二层是依赖层：业务代码所依赖的第三方组件。这一层的风险最高，因为组件的国产化替代往往不是一对一的——某个组件在国产环境上没有对应版本，需要换用功能相近但接口不同的替代品，业务代码要改。本方案的处置是在设计阶段即完成依赖清单的国产化可得性核查，逐个组件标注「有原生支持 / 有替代品 / 需自行实现 / 暂无方案」四档，前两档直接采用，第三档评估工作量并排期，第四档上报并与招标方协商技术路线。这份清单在蓝图设计阶段提交，不留到实施期才发现。

第三层是性能层：同样的功能在国产环境上跑得动，但吞吐与延迟可能与参考环境有差异。本层的吞吐与延迟以目标环境的实测数据为准，交付方式是实测并说明：在目标环境上实测性能基线，与容量规划的假设对比，差异超过约定幅度时调整资源配置或优化实现，调整过程与结果写入适配报告。

第四层是生态层：驱动、工具链、运维工具、监控探针。这一层的问题通常不影响功能，但影响运维效率。处置是列出受影响的运维动作与替代办法，纳入运维手册。

验收按四层逐层核对：某一层存在差异的，只就该层出具遗留项与处置计划，不整体判为未适配；运行层通过的，也不据此推定其余三层已适配。《国产化适配测试报告》按四层出具，每层给判定结论、实测证据与遗留项。

9、验证方法、交付物与验证时点汇总

非功能性要求的验证方法、交付物与验证时点汇总如下，供评审与验收逐条核对。验证时点分模块评审、上线验收、质保期复测三类，分别对应表 2-5 的评审闸门、系统整体验收与质保期内的季度或半年度复测。

表 9-1　非功能性要求的验证方法与交付物汇总（来源：招标文件 3.1.2.2 全部单元 b0743—b0793，并列入与本部分一并核验的国产化比率条款 b0677、b2219）

质保期内的持续保障按三个节奏执行：月度做备份恢复验证与运行指标巡检；季度做性能复测、容量复盘、安全复扫与常见问题解答更新；半年度做故障注入演练与故障隔离复测。各项结果进入运行报告提交甲方，指标偏离承诺值时按表 1-1 的回退流程处置。