1. 企业云迁移与现代化改造导论

企业上云早已不是“把服务器搬进云里”这么简单。真正决定迁移成败的，往往不是技术本身，而是企业是否想清楚了“为什么迁、迁什么、迁完要变成什么样”。本节作为整门课程的起点，先建立三个基本认知：迁移的驱动因素、现代化改造的维度，以及 Google Cloud 的核心服务全景，最后给出贯穿全课程的路线图。

一、迁移的驱动因素：从“成本”到“能力”

企业启动云迁移的动机通常可以归为四类。第一类是成本与资本结构：把一次性采购的固定资产投入转为按需付费的运营支出，避免为峰值容量长期买单。第二类是弹性与可用性：业务存在明显波峰波谷（如电商大促、月末结算），本地机房扩容周期以周计，而云上可以分钟级伸缩。第三类是创新速度：云上可直接调用托管数据库、消息队列、AI 推理等能力，团队不必再从零搭建中间件。第四类是合规与韧性：借助多区域部署、备份与灾备能力满足监管和业务连续性要求。

需要强调的是，这四类驱动因素对应的迁移策略并不相同。以成本为主要目标的迁移，往往优先做“平移”（Rehost），追求快速下线机房；以创新为主要目标的迁移，则更倾向于重构（Refactor）或替换（Replace），愿意接受更长的改造周期。因此在项目启动阶段，务必先明确首要驱动因素，它直接决定后续的技术选型和节奏安排。

二、现代化改造的六个维度

“现代化改造”不是单一动作，而是多个维度可以独立推进的组合。常见的六个维度如下：

• 计算现代化：从固定虚拟机转向容器与无服务器，例如把单体应用拆分为容器化服务，或把定时任务改为 Cloud Run 作业。
• 数据现代化：从自建数据库迁移到 Cloud SQL、Spanner、BigQuery 等托管服务，并建立数据分层与治理。
• 应用架构现代化：由单体走向微服务或事件驱动，解耦模块、独立部署。
• 运维现代化：用基础设施即代码（IaC）、CI/CD 和可观测性替代手工运维。
• 安全现代化：以身份为中心，落地最小权限、密钥管理和统一审计。
• 成本现代化：建立标签体系、预算告警和资源利用率治理。

这六个维度不必同时推进。一个务实的做法是：先选一个业务价值高、依赖较少的应用作为试点，在它身上同时验证 2～3 个维度，跑通后再复制到其他系统。

三、Google Cloud 核心服务全景

面对上百种服务，初学者容易迷失。可以按“计算—存储—数据—网络—运维安全”五层来建立心智地图：

记忆技巧是：先想“我要跑什么”，再想“数据放哪”，最后想“怎么连、怎么看、怎么管”。绝大多数迁移方案都可以在这张地图上找到对应位置。

四、课程路线图

本课程共 30 章，整体遵循“认知—评估—迁移—现代化—治理”的主线。前几章建立概念与评估方法，中间章节深入计算、存储、数据库、网络的具体迁移操作，后续章节覆盖容器化、数据分析、安全合规与成本治理，最后以综合案例收尾。下图展示了这一主线与各阶段的核心任务关系。

五、一个可落地的起步动作

在正式进入后续章节前，建议先完成一份“迁移候选清单”。它不需要复杂，但必须包含以下字段，作为后续评估的输入：

应用名称：订单中心
当前部署：本地 VMware，3 台虚拟机
依赖组件：MySQL 5.7、Redis、NFS 共享目录
日均请求：约 12 万次，峰值集中在 10:00-11:00
业务等级：核心（停机窗口 ≤ 30 分钟/月）
迁移倾向：Rehost 优先，后续评估容器化
首要驱动：弹性扩容 + 降低机房运维成本

这份清单的价值在于：它把“要不要迁”变成了“迁哪个、怎么迁、先迁谁”的具体判断。后续章节中，我们会围绕计算、存储、数据库、网络等对象，逐一展开这些判断背后的技术细节与操作方式。