写给同行的工程笔记 | 业务持续运行，架构如何稳步演进

作者｜中电金信研究院 章澜

内容｜本篇共4923字，预计阅读时间11分钟

核心系统需升级，业务运行却不能因技术改造而中断。旧系统承载着多年积累的数据与业务规则，新架构需适应业务增长与创新。进入投产准备阶段，项目团队必须回答几个具体问题：新旧系统的处理结果是否一致，数据能否在约定时间窗口内完成迁移，异常能否及时发现，切换不符合预期时如何处置。

这些问题贯穿基础设施建设的全过程，也说明可靠运行与持续创新需统筹兼顾。技术选型不仅要考量功能和性能，还要评估迁移成本、运行风险与后续维护条件。一次建设的价值，既在于完成投产，也在于帮助企业形成应对后续变化的能力。

作为源启融合型数智基础设施中承担托底保障的平台，源启基础运行支撑平台将资源管理、运行服务、可观测与工程验证贯通衔接。依托中国电子自主计算产业链与合作生态，结合长期行业实践，平台支持企业从完整业务链路出发组织技术方案，在架构演进中保障业务连续运行与数据一致。

华润银行央企金融基础设施信创平台建设，统筹推进金融交易云与新一代核心、供应链金融、手机银行等系统的建设，金融交易云基于源启金融级数字底座，按照“一云多芯”策略组织基础设施服务，并配套安全与管理体系，采用两地三中心部署架构。

项目适配了16家合作伙伴的35款产品，体现了跨厂商、跨技术层次的适配与整合能力。其工程意义在于：通过分层解耦、接口规范与组合验证，减少应用开发对特定底层组件的依赖，并检验组合后的性能、稳定性与兼容性。这些工作为技术选型提供依据，也为后续升级与组件替换保留空间。

这一案例值得借鉴之处，在于规划业务系统时同步考虑运行基础。虚拟化、容器、网络与管理能力分层组织，为应用提供共用的运行环境；研发工具链与工艺规范配套建设，使技术路线、交付要求与运行管理能够衔接。平台提供统一基础，业务系统在此之上发展各自能力，减少各项目重复搭建底层技术环境的工作。

某金融基础设施机构的分布式底座建设，则进一步体现了开发、运行、运维之间的联系。项目将服务开发平台与框架、分布式运行组件、服务监控与管控组织为企业级技术体系，并与既有技术平台集成，支撑应用向分布式架构演进。

这套企业级技术体系的作用不限于提供中间件。权限、日志、事务等通用组件可在不同系统间复用，开发规范与运行要求能够相互对应，故障定位与应急处置也有共同依据。对企业而言，这样的底座减少了新应用的重复建设，也使后续升级能够沿用已有的技术与工程积累。

一笔交易流经应用、数据库、中间件、操作系统与计算资源，各组件单独通过测试，并不代表组合后就能满足业务要求。业务高峰与批处理叠加时，平时不明显的资源争用可能集中出现；网络抖动、缓存调整与数据库执行计划变化，也可能沿着调用链影响交易。

可靠运行依赖系统工程。项目团队需要沿着业务处理过程分析各层依赖，判断问题出在应用、配置还是资源。全栈适配不仅要解决组件之间的兼容问题，还要验证组合后的系统能否满足业务要求，并明确验证结论适用的负载、配置和运行条件。

杭州银行的实践，将验证推进到业务连续性要求更高的场景。项目建设“两地三中心”和“多地多活”架构的实验室环境，验证分布式核心系统在极端场景下的数据恢复与持续服务能力。在中试实践中，团队结合脱敏后的生产影子流量、故障注入和全栈可观测，对迁移、双活切换与数据库替换开展检查，不仅核验功能是否正常，也考察系统在复杂条件下的运行表现。

案例记录了非均衡负载、缓存重平衡与业务高峰叠加，以及SQL执行计划偏移等问题。这些现象提醒我们，系统的表现取决于组件如何共同工作。只有在验证中充分考虑实际运行条件，团队才有机会在投产前发现偏差、分析原因，并检验调整是否有效。

对准备推进改造的企业而言，验证范围也应从业务要求倒推。哪些交易必须优先覆盖，哪些批处理任务容易与高峰重叠，哪些外部接口可能延迟，都需要在设计场景时讨论清楚。验证越贴近这些约束，结论越能帮助团队判断投产条件，也越能为后续变更提供参照。

中试还应为后续决策留下可复核的依据。负载条件、配置版本、延迟曲线与恢复时序，都应与验证结论一同保存。后续更换组件或调整架构时，企业可以对照已有记录重新检查，而不是仅凭一次测试通过就认定长期可靠。

关键业务运行保障的工程能力

多地部署为保障业务连续性提供了基础，但还需明确：故障发生后，数据一致性如何保证，服务如何维持或恢复。一个节点失效时，交易能否切换到其他节点；跨中心链路中断时，数据一致性如何维护；范围更大的故障发生后，备份是否可用、业务以何种次序恢复。上述问题都需事先明确，并经过设计与验证。

某省级农商银行的分布式核心建设采用“三地五中心”架构，并将设计与验证、开发与测试、演练与投产分阶段推进。这一安排使高可用要求贯穿建设全过程：先明确关键场景及验证要求，再将方案落实到开发、测试和演练中，而不是等系统建成后才验证容灾是否有效。

这里需要区分两类能力：部分节点失效时，存活节点能否继续承接服务；多活节点均不可用时，可否依靠备份恢复数据和业务。两类场景的资源条件、恢复路径与时间要求不同，仅凭“多活”二字难以完全概括。数据恢复不等于业务恢复，还需核验交易、账务及上下游系统的状态。

某省级农商银行的“三地五中心”建设与杭州银行的“多地多活”实验室验证，分别对应了架构建设与工程验证的要求。需要指出的是，数据中心数量的多少并不能直接衡量保障能力，关键在于故障场景是否全面覆盖、切换过程是否经过验证，以及数据核验和服务恢复条件是否明确。企业应据此判断架构是否真正满足自身的业务连续性要求。

系统迁移的难点，往往出现在技术与业务的交界处。一个字段能顺利搬入新库，却未必保留原有的业务含义；一批数据完成转换后，还需确认账务关系、历史特例及下游使用是否正确。由于留给现场处置的窗口十分有限，投产当天每一步操作的范围、规则和责任，都需要事先明确。

某省级农信核心系统及信贷类系统数据迁移项目，将上述要求落实为“范围分析、迁移设计、迁移开发、迁移执行、迁移验证”的迁移流程。该项目通过映射规则与检核规则组织新旧数据转换，以投产时序和调度指令协调多个组件，并持续开展历史数据的清理与补录。

该项目经过16轮功能验证和5轮全真投产演练后完成投产，全量数据迁移的核心流程控制在4小时窗口内。上述结果来自该项目的具体实践；值得同行借鉴的，是任务安排、依赖分析与异常处置的方法，其通过反复验证逐步提高执行确定性的过程，同样具有参考价值。

演练既是对程序的检验，也是对组织的检验。某一步工作未按时完成，后续任务能否继续？检核出现差异，由谁判断原因？哪些情况需要暂停，哪些情况需要启动应急安排？这些都应在正式投产前形成清晰的执行依据。迁移工具负责组织作业过程，业务与技术团队共同确认结果。

正因如此，迁移工具平台需要与专业实施相结合。标准化工具可以减少重复开发，自动化映射、转换、检核与调度可以提升执行的一致性；但迁移范围、账务规则与回退条件仍需结合具体项目确定。工程能力的价值，在于让这些判断有据可依、执行过程可追溯。

系统投产并不意味着运行条件从此不变。业务量增长、应用发布、组件升级与资源调整，都可能改变系统行为。需要在持续运行中维持可靠性，并同步更新验证策略。

某城商联盟的混沌工程实践，体现了从临时演练走向持续验证的建设思路。围绕一云多芯环境下的新一代核心系统，项目将混沌工程与红蓝对抗相结合，分阶段开展基础覆盖、专项测试与实战演练。数据库、应用、主机、网络与中间件都纳入场景设计范围。

其中值得关注的一点是，不同验证任务的要求不同，需要分别安排相应的环境。UAT环境侧重测试与问题排查，隔离环境用于控制影响，在生产环境开展的演练则需要明确范围与处置条件。验证真实性与运行风险需兼顾，不能把主动故障注入理解为不加约束地制造故障。

这种方式也检验着团队是否具备应对能力。告警能否及时触发，人员能否识别业务影响，预案能否执行，业务恢复后能否确认正常，都需要在演练中观察和检验。发现问题后，还须完成整改和复测，记录处理过程，为下一轮验证提供参考。

源启将混沌工程与可观测能力相结合，为这些工作提供工具支持。可观测工具关联日志、指标与调用链，帮助团队理清异常的传导路径；场景与演练记录则使验证得以重复开展。借助这些工具与记录，保障可靠运行逐步从依赖少数专家的临场判断，转变为团队共同掌握的能力。

随着模型与智能体进入企业，基础运行支撑平台需要承接新的工作负载。训练任务可能集中消耗资源，推理服务关注响应与并发，而既有交易系统仍需保持稳定运行。新增设备可扩大供给，但设备如何分配、任务如何调度、成本如何衡量，同样决定着算力能否真正服务业务。

某大型银行的算力池管理平台建设，正是从异构设备管理分散、资源利用不足的问题出发，基于源启算力加速平台，推进统一纳管、智能调度、GPU虚拟化切分与监控运维，将资源供给从整卡独占拓展为按需分配。

这一变化使算力能够根据任务需要灵活分配。各团队需要多少资源、使用多久，哪些任务优先执行，出现异常如何处理，均可通过统一平台协调。平台还提供资源看板与成本分析功能，支持按部门或项目分摊算力成本，为后续扩容与投资提供依据。

对企业而言，算力建设既要提高资源利用效率，也要保障业务平稳运行。评估利用率时，还需关注响应速度、资源隔离与服务质量。随着使用算力的团队和任务不断增多，平台需要明确访问权限与资源配额，持续监测运行状态，避免个别任务占用过多资源，影响其他业务。

在源启整体体系中，基础运行支撑平台提供算力与运行环境，AI工厂则支持模型、知识与智能体的建设和运营，两者共同支撑具体应用落地。可治理的AI原生工程，同样需要落实到日常运行中：资源如何分配、权限如何设置、异常如何发现与处置，都需作出明确安排。随着智能应用的使用范围不断扩大，运行保障也需同步跟进。

从华润银行的金融交易云，到某金融基础设施机构的分布式底座，再到多中心容灾、迁移演练与算力运营，这些实践共同指向同一条主线：企业如何将业务要求转化为可执行的技术方案，并借助验证来判断其是否适用。

因此，基础运行支撑平台的价值，不仅体现在资源和服务能力上，也体现在企业能否逐步掌握选型、迁移、验证与运行的方法。开放适配为技术选择创造条件，工程验证帮助判断选择是否适用，运维与反馈则使这些判断随业务变化而持续更新。

单个项目留下的配置、测试用例和处置记录，也需要进一步整理：哪些方法适用于何种架构，哪些故障与特定版本相关，哪些规则已经失效，都需有清晰的说明，并明确维护责任。知识工程在运行领域的作用，正是为每条经验记录来源、界定适用条件、留下验证结果，让原本散落在项目里的经验与方法，成为更多团队可理解、可检索、可复用的知识资产。

某省级农信案例中所沉淀的投产操作手册、应急及回退预案、问题速查手册，正是这类知识资产的具体体现。它们既能让后续项目少走弯路，也划清了复用的边界：真正可复用的是经过验证的方法与工具，而新的环境和业务要求仍需逐一重新核对。

对关键行业而言，基础设施的可靠性不仅取决于设备与组件，更取决于企业能否及时发现问题、控制影响、恢复业务。基础运行支撑平台的工程价值，正体现在技术选择有据可依、架构变更经过验证、运行经验得以持续复用。只有将这些经验沉淀为可维护的知识资产，企业才能在业务与技术不断变化的过程中保持稳定运行，也才能让下一次建设建立在可复用的积累之上。