系统割接无小事。对于政企核心业务来说，把跑了多年的老系统替换为全新的 信创OCR，就像是在飞行中给飞机换引擎。任何一个环节的疏漏，都可能导致业务中断、单据积压，甚至引发严重的生产事故。

这份《系统割接与灰度发布方案检查清单》不是用来走过场的文档，而是实打实的“保命符”。建议您在项目组启动割接会议前，逐项对标排查。

第一阶段：割接前准备（底线防御）

在真实流量接入之前，必须确保信创底座和业务逻辑的“地基”已经完全打牢。

  • 1. 信创基础设施验收
    • [ ] 确认国产服务器（如鲲鹏、海光）及操作系统（如统信、麒麟）的各项内核参数已按 OCR 厂商要求调优。
    • [ ] 确认国产数据库（如达梦、人大金仓）与中间件连接池配置完毕，且通过了最大并发数压力测试。
    • [ ] 网络策略核对：新老系统双轨运行期间，跨网段防火墙策略是否已完全打通。
  • 2. 历史资产与数据迁移
    • [ ] 老系统中的自定义模板、业务校验规则是否已 100% 导入新的 信创OCR 系统。
    • [ ] 抽取 1000-5000 份真实历史样本进行离线回归测试，确认新系统的字段抽取准确率不低于老系统。
  • 3. 应急回滚预案（最重要的一环）
    • [ ] 明确熔断指标： 定义什么情况下必须停止割接（例如：连续 3 分钟接口响应时间超过 5 秒，或核心字段识别错误率激增）。
    • [ ] 一键回滚机制： 确认在路由网关层，能否在 1 分钟内将流量切回老系统，且不会造成已处理单据的数据脏写或状态混乱。

第二阶段：灰度发布与双轨运行（排雷阶段）

千万不要在周末搞“一刀切”的全面上线。灰度发布的本质是通过控制变量，在真实环境中暴露并解决纯国产软硬件底座下隐藏的 Bug。

  • 1. 影子模式（Shadow Testing）压测
    • [ ] 业务前端依然调用老系统，但网关将流量异步“镜像”一份发送给新的 信创OCR。
    • [ ] 每日自动输出《新老引擎识别结果差异比对报告》，由业务人员复核差异点，排查是新系统的算法缺陷还是底层兼容问题。
  • 2. 流量按比例/维度切分
    • [ ] 按白名单灰度： 先将 IT 部门或非核心边缘业务（如内部报销）的流量切至新系统。
    • [ ] 按比例放量： 确认系统无异常后，按照 10% -> 30% -> 50% -> 100% 的比例逐步放量。每次放量后至少观察 24-48 小时。
  • 3. 核心指标严密监控
    • [ ] 重点监控国产 CPU 的占用率是否存在异常飙升或内存泄漏。
    • [ ] 监控接口请求的 TP99 延迟（99% 的请求在多少毫秒内返回），确保国产算力能够支撑业务的并发波峰。

第三阶段：正式割接与上线后保障（平稳着陆）

当 100% 的流量平稳运行在信创底座上超过一周，才算进入正式割接的收尾阶段。

  • 1. 老系统下线评估
    • [ ] 确认老系统已连续 7 天无任何实质性业务流量。
    • [ ] 对老系统的数据进行最终冷备份并封存，随后正式关闭老系统服务器及授权。
  • 2. 运维与业务护航
    • [ ] 厂商技术骨干是否驻场或提供 7×24 小时的专属 VIP 线上保障通道（至少维持两周）。
    • [ ] 建立“业务纠错快速响应机制”：一线业务员发现新的异常识别或卡顿情况时，是否能在 1 小时内得到排查和修复反馈。

将系统平滑迁移到信创环境，考验的不仅仅是算法能力，更是厂商和政企 IT 部门的工程化管理水平。稳扎稳打、步步为营，把退路（回滚方案）想清楚，才能确保向前的每一步都走得踏实。