3. 迁移改造需求分析与目标设定

迁移改造项目最容易失败的方式，是把它当成一次“换设备”或“换软件”的工程：只要新平台上线、旧平台下线，任务就算完成。但企业密码平台承载的是密钥、证书、签名、验签、加解密和身份信任，一旦迁移过程中出现业务中断、密钥不可用、合规审计断链或性能下降，影响会直接传导到支付、开户、合同、发票、身份认证等关键业务。因此，需求分析的核心不是罗列功能，而是把“业务连续性、合规监管、性能容量、安全等级、可量化成功标准”这五类约束转化为可设计、可验证、可验收的目标。

一、业务连续性要求：先定义“不能停”的边界

业务连续性要求要回答三个问题：哪些业务不能中断、允许中断多久、中断后如何恢复。密码平台通常处于交易链路的关键路径上，例如网银签名、支付报文加解密、电子合同签章、数据库透明加密、KMS密钥调用等。迁移改造时，必须区分“在线热迁移”和“停机窗口迁移”两类场景。

以某银行密码服务平台迁移为例，假设其日均调用量为 8000 万次，峰值 TPS 为 3200，涉及 12 个业务系统。若采用停机迁移，核心支付系统只能接受不超过 5 分钟的窗口，而证书更新、密钥轮换等操作可能超过该窗口。因此，需求应明确：核心支付链路必须支持双轨运行和灰度切流，迁移期间新旧平台并行，通过流量比例从 1%、5%、20%、50% 逐步放大，任一阶段出现错误率超过 0.1% 或 P99 延迟超过 200ms，立即回切。非核心系统可安排在夜间窗口，允许中断 30 分钟，但必须提前完成数据备份和回滚演练。

连续性目标不能只写“保证业务不中断”，而应写成可验证指标：RTO（恢复时间目标）≤ 5 分钟，RPO（恢复点目标）≤ 1 分钟，关键链路切换成功率 ≥ 99.99%，回滚操作 ≤ 3 分钟完成。这些指标将直接决定后续架构设计是否需要双活、是否需要密钥同步、是否需要流量染色和快速回切能力。

二、合规与监管约束：把外部要求转成内部规则

密码平台的合规约束通常来自《密码法》《网络安全法》《数据安全法》、商用密码应用安全性评估（密评）、等保 2.0、行业监管细则以及 PCI DSS 等。迁移改造不是简单“换国产密码设备”，而是要证明新平台在密钥管理、算法使用、审计留痕、权限分离、证书生命周期等方面持续合规。

需求分析阶段应把合规条款拆成可执行规则。例如：密钥必须由硬件密码模块（HSM）生成并保护，密钥分量不得以明文形式出现在配置文件或日志中；管理员、审计员、操作员三权分立；所有密钥操作必须记录操作人、时间、对象、结果和来源 IP；SM2/SM3/SM4 算法使用需符合 GM/T 系列标准；证书签发、更新、吊销需保留完整链路。对于跨境业务，还需考虑数据出境和境外密钥托管限制。

一个实用的做法是建立“合规条款—平台能力—验证证据”映射表。例如“密钥不得明文存储”对应“HSM 密钥句柄 + 加密密钥库”，验证证据为配置截图、密钥导出测试失败记录和密评报告。这样迁移验收时，合规不再是主观判断，而是有证据链的检查项。

三、性能与容量指标：用数据决定架构规模

性能与容量目标必须基于现状和增长预测，而不是拍脑袋。需要采集旧平台的日均调用量、峰值 TPS、平均延迟、P95/P99 延迟、密钥数量、证书数量、并发连接数、HSM 利用率等基线数据。假设旧平台日均 8000 万次调用，年增长 30%，则迁移后第一年需按 1.04 亿次/日设计，峰值 TPS 按 3200×1.3≈4160 预留，并保留 30% 余量，即目标峰值不低于 5400 TPS。

容量规划还要区分不同密码操作的开销。SM2 签名、SM4 加解密、SM3 摘要、证书验签对 HSM 的资源消耗差异很大。若新平台采用“HSM 集群 + 密钥缓存 + 连接池”，需要明确单台 HSM 的基准性能、集群线性扩展比、会话复用率和超时重试策略。例如单台 HSM 实测 SM2 签名为 8000 TPS，集群 4 台理论 32000 TPS，但受网络和调度影响，实际按 70% 估算为 22400 TPS，足以覆盖目标。若不足，则需增加节点或优化调用批处理。

性能目标应写成：P99 延迟 ≤ 200ms，错误率 ≤ 0.01%，HSM 利用率 ≤ 70%，密钥查询响应 ≤ 50ms，证书链验证 ≤ 100ms。这些指标要纳入压测和上线验收。

四、安全等级目标：明确保护强度与信任边界

安全等级目标决定平台需要达到的保护强度。可按等保三级/四级、密评三级、金融行业增强要求来设定。核心是明确：哪些密钥属于最高等级、哪些接口必须双向认证、哪些操作必须多人授权、哪些数据必须加密存储、哪些日志必须防篡改。

例如，根密钥和 CA 根证书应达到最高保护等级，必须离线保存、多人分段保管、使用需审批；业务密钥可在线管理，但必须绑定业务系统和访问策略；测试密钥与生产密钥严格隔离，禁止交叉使用。迁移过程中，旧平台密钥导入新平台时，必须经过密钥包装、传输加密、导入校验和销毁确认，避免密钥在迁移链路中泄露。

五、可量化的成功标准：让验收有据可依

成功标准应覆盖业务、合规、性能、安全和运维五个维度，并尽量量化。例如：迁移期间核心业务中断时间为 0；灰度切流期间错误率不超过 0.01%；全量切换后 P99 延迟不高于旧平台的 110%；密评整改项全部闭环；密钥和证书迁移完整率 100%；回滚演练成功率 100%；审计日志完整率 100%；运维人员独立操作新平台完成日常密钥轮换和证书更新。

下面用一张关系图把本节五类需求与目标之间的约束关系集中呈现，便于在方案评审时快速对齐。

把上述五类需求写成一份可评审的目标清单，迁移方案才有稳定的判断依据。实际项目中，建议在需求分析阶段就组织业务、安全、合规、运维和厂商共同确认：哪些指标是硬性门槛，哪些可以分阶段达成，哪些必须通过演练证明。只有目标清晰、量化、可验证，后续的架构选型、迁移步骤、测试方案和上线验收才不会反复摇摆。