Google Cloud 拒绝主机大爆炸式迁移，转向 AI 引导的迁移路径

Google Cloud 提出了一种分四个阶段推进的方案，以应对高风险的主机迁移：在切换前利用 AI 分析、代码生成、数据转换和并行验证。

这一方案挑战了企业面临的一种常见选择：继续维护日益老化的系统，或尝试大规模迁移，而其中的依赖关系往往只有在项目启动后才会显现。Google 认为，这两种选择都没有解决最棘手的问题：理解现有系统实际上在做什么。

其方案将 Mainframe Assessment Tool、Gemini CLI、Mainframe Connector 和 Dual Run 串联为一套连续流程。团队首先梳理业务规则和依赖关系，随后围绕经过审查的需求构建云应用，迁移相关数据，并在真实工作负载下对两个环境进行比较。

这一流程使其不只是又一次代码转换发布。核心竞争在于迭代式现代化与大爆炸式迁移之间的较量，而非云基础设施与主机硬件之间的对比。

Google 同样面临成熟替代方案的竞争。IBM 正在应用 AI，同时保留 IBM Z 的核心角色。AWS 则在推广一项智能体服务，可将生成的需求和代码追溯至主机源代码。各家供应商都认识到，仅靠代码生成无法判断替代系统是否正确。

因此，关键问题并不在于 Gemini 能否翻译 COBOL，而在于 Google 的连贯工作流能否在让企业以可控方式推进现代化的同时，保留数十年来隐藏的业务行为。

Google Cloud 将四种工具整合为一条迁移路径

最重要的变化在于，将评估、生成、数据迁移和生产验证连接起来。

Google 的现代化框架始于逆向工程。Mainframe Assessment Tool 会检查源代码、数据库结构、事务监控器、调度器配置，以及资产之间的关系。

它支持 COBOL 程序、复制簿、JCL 作业、过程、包含文件及相关工件。该工具利用 Gemini 从这些材料中生成摘要、技术规范和建议的业务规则。

业务规则是编码在应用程序中的策略，例如资格条件、利息计算或交易路由决策。它们之所以重要，是因为旧程序可观察到的行为往往超出仍存文档所记录的范围。

Google 表示，团队可在导出前审查、筛选和验证提取出的规则。这一人工检查点使该方案不同于简单地要求将每一行代码翻译为 Java 或其他现代语言。

评估还可以将一个系统资产集合划分为业务域和更小的可迁移单元。可迁移单元是由程序、数据和依赖关系组成的有边界集合，可以在不破坏相邻服务的情况下共同迁移。

这种划分奠定了迭代式项目的基础。一家银行可能会在触及支付授权之前，先隔离并迁移一个报告流程。一家保险公司则可能迁移文档处理服务，同时将理赔结算保留在主机上。

完成评估后，Gemini CLI 支持正向工程。这意味着团队利用经验证的需求规划目标架构并生成新代码，而不是将旧代码库视为目标设计。

该工作流可以为 Cloud Run、Google Kubernetes Engine、Compute Engine、BigQuery、Spanner、AlloyDB 和 Cloud SQL 提出数据模型及服务建议。这些建议仍需经过架构审查，因为生成的建议并不等于可投入运营的决策。

Mainframe Connector 则处理了另一个经常被低估的问题。它可复制并转换主机数据，包括 EBCDIC 编码记录，将其转换为 Google 服务可使用的格式。

EBCDIC 是与 IBM 主机环境相关的字符编码。要正确转换它，不能只改变文本表示形式，因为记录中可能包含压缩十进制数、复制簿布局以及应用程序特定的约定。

Dual Run 完成了这一建议流程的闭环。它会在现有主机环境和云环境中执行工作负载，并在生产切换前比较两者结果。

这一连贯流程改变了团队建立信心的方式。他们不再依赖一次性转换，而是在发现、规则审查、实施、数据测试和并行执行的各环节持续积累证据。

这正是此次发布的核心主张。Google 将现代化呈现为一套受控的证据体系，而不是单一的转型项目。

为什么主机现代化不是代码翻译工作

语法上正确的转换，仍可能重现一个错误的业务系统。

大型主机系统资产很少像整齐、相互独立的应用集合那样运行。一个夜间批处理作业可能更新次日早晨在线交易会使用的数据。一份共享复制簿则可能塑造多个业务部门使用的记录。

有些依赖关系存在于代码中，另一些则隐藏在调度器、数据库约定、运营运行手册，或维护某个工作负载数十年的员工知识中。

这使得直接代码翻译成为一种不完整的模型。语言模型可以从 COBOL 例程生成看似合理的 Java，却可能遗漏该例程为何必须在另一项作业之后运行。它也可能保留企业已经不再需要的逻辑。

反向风险同样严重。生成的替代方案可能简化看似冗余、却用于处理某项罕见监管例外的行为。此类失败可能只会在罕见交易或季度末流程中显现。

Google 的评估优先设计试图让这些关系变得可检查。其文档称，该工具会生成调用树、依赖关系报告、业务规则摘要以及建议的可迁移单元。

该评估系统还支持 MCP 服务器，使 AI 智能体能够通过 Model Context Protocol 查询评估数据。MCP 是一种用于连接模型与外部工具及结构化上下文的标准接口。

这一架构为 Gemini 提供的不仅是一组源代码文件。它可以利用已发现的关系、经审查的规范，以及与特定应用领域关联的业务规则开展工作。

不过，更丰富的上下文并不能保证解释准确。生成的规范可能遗漏边缘情况，而静态分析无法观察通过运行时配置或外部操作形成的每一项依赖关系。

因此，人工审查仍是这一机制的一部分。领域专家必须判断某项建议业务规则是否有效、过时、不完整，或被误解。

这给面临人员流失的企业带来实际限制：当经验丰富的操作人员的知识最难替代时，该工作流恰恰最需要他们。AI 可以帮助组织他们的审查工作，却无法追溯性地补齐缺失的机构记忆。

Google 的方案也改变了遗留代码的用途。团队无需将每一条语句都视为必须保留的对象，而可以将整个系统资产视为有关预期业务行为的证据。

这种区别支持云原生重构。如果托管服务能够满足同一项经审查的需求，事务监控器就不需要一个字面意义上的对应物。当时序和一致性约束允许时，批处理流程可以转变为事件驱动服务。

然而，重构会扩大验证负担。目标架构与原始实现相距越远，逐行比较的价值就越低。

团队必须比较结果、副作用、时序、数据完整性和故障恢复能力。这正是 Dual Run 在 Google 的叙事中居于核心地位而非可选项的原因。

其承诺并非完美翻译，而是一条可追溯链路：从遗留系统证据，到经审查的规则、生成的实现，以及经过衡量的等价性。

真正的竞争是迭代式现代化与大爆炸式迁移

Google 最有力的论点是组织层面的：更小的迁移单元能够限制不确定性带来的后果。

大爆炸式迁移会将许多假设集中到一次切换中。团队必须在广泛范围内理解依赖关系、转换代码、迁移数据、测试接口、培训操作人员，并准备回滚流程。

一项错误的依赖关系判断就可能拖延整个项目。更糟的是，缺陷可能直到原始环境已难以恢复后才进入生产环境。

迭代式现代化降低了这一影响范围。团队可以选择一个边界明确的领域，记录其关系，构建目标实现，并在相邻工作负载保持不变的同时进行验证。

这并不会让现代化变得简单，但会改变失败发生的方式。

在一个迁移单元中发现的问题，可以改进下一个单元的评估规则。测试不匹配能够在企业投入更大范围的切换之前，揭示未记录的行为。

Dual Run 提供了运营层面的桥梁。Google 早期的并行测试模型会让主机继续作为主系统运行，同时让云端副本作为次级系统执行相同的工作负载。

随后，云端输出可与既有结果进行比较。反复出现的差异会暴露转换逻辑、数据转换或环境假设中的缺陷。

这对于交易密集型系统尤为相关。单元测试可以验证已知计算，但无法重现实时输入模式、调度条件和下游集成之间的每一种交互。

并行执行能够提供更广泛的证据，同时不会立即赋予新系统生产权限。团队可以设定验收阈值、调查差异，并在切换责任之前重复测试。

其代价是延长共存期。运行两个环境需要同步、监控、重复处理控制，以及明确决定每项输出由哪个系统负责。

过渡期间的成本也可能重叠。Google 并未消除这一运营负担，而是认为这项负担换来了一条比孤注一掷事件更安全的路径。

增量模型同样带来了治理问题。团队需要制定规则，用于选择迁移单元，并判断某个应用何时已证明具备足够的等价性。

他们必须跟踪哪些业务规则已获接受、由谁批准、哪些测试证据支持这些规则，以及验证后发生了什么变化。没有这些记录，迭代工作可能形成碎片化的混合系统资产。

架构纪律在这里至关重要。一连串孤立的云项目可能通过新的服务、队列、数据库和未记录的接口，重现主机系统的复杂性。

Google 的工具能够映射和生成工件，但企业仍需要一套连贯的目标架构。对于每个被云端替代的主机组件，企业还需要制定退役计划。

当迭代带来累积性的简化时，这一方法便能成功；当每个迁移单元都新增一座通往遗留系统资产的永久桥梁时，它便会失败。

这就是为什么竞争并非速度与谨慎之间的取舍。仓促的大爆炸式迁移可能以戏剧性的方式失败，而无休止的增量项目则可能悄然失败。

衡量标准是已完成的业务能力。每个迁移单元都应实现经过验证的生产运行，并移除相应的遗留职责。

Google Cloud 与 IBM 和 AWS 的竞争路径不同

三家供应商如今都在使用 AI，但它们对于现代化工作负载应部署在何处、如何证明等价性，存在不同看法。

IBM 的立场始于大型机持续存在的价值。其面向 Z 的 watsonx Code Assistant 支持发现、解释、重构、代码生成、优化和转换，同时保留 IBM Z 作为重要的运行环境。

IBM 表示，其助手可以解释 COBOL、PL/I、REXX、Assembler 和 JCL。它还可以将选定程序重构为模块化服务，或将 COBOL 转换为面向对象的 Java。

该公司的 AI 现代化工具包括用于验证语义等价性的自动化单元测试。该术语意味着，即使结构发生变化，新代码也应产生与原始代码相同的预期行为。

对于希望改进开发实践、但不愿将所有工作负载迁移至超大规模云的企业，这一路径可能很合适。它还让团队围绕大型机开展现代化，而不是将这一平台视为必须处理的期限问题。

AWS 的立场更接近 Google 的云端目标，但其当前信息强调代理式执行和可追溯性。AWS Transform for mainframe 覆盖评估、业务规则提取、需求、代码生成、测试和部署。

AWS 表示，每项生成结果都可以从需求追溯到原始源代码。其代理式工作流还可通过开放协议，与 Kiro 等编码代理及现有开发环境集成。

这种可追溯性瞄准了与 Google Dual Run 相同的信任缺口。它为审查者提供审计路径，说明某项需求或生成组件的来源。

Google 的差异化在于，将上下文评估与数据转换及工作负载级并行验证结合起来。Gemini 协助理解和生成，而 Dual Run 则针对作为记录系统的操作系统测试行为。

这些并非界限分明的产品类别。IBM 同样提供发现和测试功能。AWS 也声称具备自动化功能等价性验证。每家供应商都在向完整生命周期扩展。

因此，竞争压力将转向实施证据。买方需要了解每种工作流在其环境中能够处理哪些语言、调度程序、数据库、事务系统和数据格式。

他们还需要区分产品能力与服务交付。大型机项目往往涉及系统集成商、内部专家、供应商专家，以及多年的应用历史。

没有任何模型能够脱离这种交付结构独立运行。AI 可以减少人工分析、起草规范和生成代码，但集成决策仍取决于每个具体环境。

供应商锁定是另一项考量。生成的架构可能倾向于某一家提供商的数据库、计算平台、监控系统和 AI 服务。

这种一致性可以简化部署。但当企业日后调整云战略，或需要在多个环境中保留工作负载时，它也可能提高切换成本。

因此，企业应评估交付物，而不仅仅是演示。可导出的规则、可读的规范、可移植的测试和可追溯的审批，其重要性不止体现在初始转换阶段。

市场正趋向 AI 辅助现代化。尚未解决的竞争在于：人类在何处验证工作、供应商如何衡量等价性，以及哪一平台拥有最终成果。

Google Cloud 的 AI 工作流仍无法保证什么

该工作流降低了特定迁移风险，但不能证明生成的业务规则或目标代码是正确的。

第一项不确定性出现在发现阶段。静态分析可以识别源代码关系和声明的调用，但动态行为可能依赖于运行时值、操作员选择或外部系统。

AI 生成的摘要也可能比其证据所允许的程度更显确定。审查者可能因为解释清晰易读而予以批准，即使其中遗漏了不常发生的分支。

这会造成自动化偏见，即人们过度信任系统建议的情况。一份精致的规范会掩盖底层环境中存在的模糊性，因此可能加剧这一风险。

Google 自身的工作流为提取出的规则保留了审查步骤。企业应将这一步视为控制措施，而非行政检查点。

审查需要明确的责任人、关联证据和清晰的处置结论。在指导生成代码前，一项规则应被标记为已接受、已拒绝、已修订或未解决。

安全性又增加了一层考量。Google 表示，Mainframe Assessment Tool 会将收集到的评估数据保留在其部署的虚拟机内。其文档还称，源代码会上传至 Gemini Enterprise Agent Platform。

同一文档指出，模型不会使用从该代码中提取的信息进行增强。组织仍需验证其工作负载的区域控制、访问策略、保留行为和合同要求。

测试同样存在局限。Dual Run 可以发现观察到的输出之间的差异，但等价性取决于覆盖范围和比较质量。

如果两个环境只接收常见交易，罕见情形仍将得不到测试。如果比较逻辑忽略时序、排序或下游副作用，两项输出可能看似相等，而系统实际行为却不同。

并行测试也可能复现糟糕的遗留行为。在迁移期间，与大型机保持一致很有用，但这并不能证明所有继承的规则都合理，或符合现行政策。

团队必须区分两个问题：云端实现是否与原始系统行为一致，以及原始行为是否应当保留？

第二个问题需要业务、法律、安全和运营方面的判断。仅靠代码分析无法回答。

性能主张也需要接近生产环境的证据。生成的服务可能通过功能测试，却在峰值负载下造成不可接受的延迟、基础设施消耗或数据库争用。

运营恢复同样值得重视。团队应在转移责任前，测试重试、部分失败、延迟消息、重复交易和回滚流程。

最后，该工作流无法保证项目完成。企业可能产出出色的评估和原型，却没有淘汰任何一个大型机工作负载。

成功需要为每个迁移单元设定退出标准。这些标准应涵盖功能证据、运营准备度、数据对账、安全审批、成本预期，以及实际的遗留系统退役。

Google 的策略之所以更安全，是因为它能更早让不确定性显现。它并不会仅仅因为 AI 参与其中就变得安全。

当 Google Cloud 从方法走向证据时，应关注什么

下一项检验在于，这种分阶段方法能否带来可重复的生产切换，而不是生成更具说服力的代码。

第一个信号是与已完成迁移单元相关的客户证据。买方应寻找已通过并行测试、并转移记录系统职责的具名生产工作负载。

一份有价值的案例研究应说明范围、支持的工件、发现的依赖关系、验证时长、差异处理方式，以及最终退役的大型机组件。有关分析速度更快的笼统表述所提供的信息较少。

反复完成的切换将强化 Google 关于该工作流能够扩展到经过精心挑选的单一应用之外的论点。只有评估而没有生产退役，则会削弱这一论点。

第二个信号是整个工具链中更深入的可追溯性。Google 的发布历史显示，其持续推进业务规则提取、MCP 访问、语言覆盖范围和大规模环境分析。

重要的进展将是把每项获批规则与源代码证据、生成组件、测试、比较结果和人工审批关联起来。这条链路将使审计和后续维护期间的审查更加容易。

它还将帮助团队识别错误在哪个环节进入流程。一次不匹配可能回溯至错误的提取、被修改的需求、生成的代码、转换的数据或验证工具链。

清晰的可追溯性将强化迭代模型，因为知识可以在各迁移单元之间积累。碎片化的工件会让每个单元都像一个独立项目。

第三个信号是 IBM 和 AWS 如何以可比的验证证据作出回应。功能清单已经存在重叠，因此供应商需要展示其方法如何处理真实依赖关系和困难的切换。

IBM 可以主张，现代化并不要求放弃 IBM Z。AWS 可以强调从源代码到输出的可追溯性和自动化测试。Google 则必须证明，上下文评估加上 Dual Run 能够提供更好的风险边界。

这种竞争应当会使企业买方受益。它将讨论从原始代码生成演示转向证据、治理、可移植性和已完成的成果。

对于技术领导者而言，当下的行动不是批准全环境迁移，而是选择一个有实际意义的领域，并测试完整链路。

该领域应包含真实依赖关系和业务后果，同时又不至于成为不可逆的第一步。其评估应涵盖代码、数据、计划、接口和运营知识。

团队应记录有多少提取规则需要修正、并行结果出现差异的频率，以及解决每项差异所需的时间。这些指标比生成代码的数量更能说明问题。

他们还应决定成功切换后哪些内容应当终止。如果原始工作负载、许可证负担、运营流程和支持职责都继续保留，迁移单元便是不完整的。

Google Cloud 正为企业提供一条介于无限期维护与危险的“大爆炸式”迁移之间的路径。这条路径之所以可信，是因为它将现代化视为发现、重建和证明的过程。

其价值将取决于客户能否在复杂环境中反复执行这一周期，而不制造永久性的混合架构迷宫。下一次生产切换将比下一次 AI 生成演示更重要。