1. 企业云项目交付全景

企业云项目交付不是“把资源开出来”这么简单。它更像一条从业务目标出发、经过架构设计、落地实施、上线切换，最终进入持续运营的完整链路。Google Cloud 的交付生命周期通常可以划分为六个阶段：评估与规划、架构设计、基础环境搭建、应用迁移与现代化、上线切换、运营优化。每个阶段都有明确的输入、输出和验收条件，前一阶段的交付物往往是后一阶段的输入，形成可追溯的交付链条。

在评估与规划阶段，核心任务是摸清现状并定义目标。典型输入包括业务系统清单、现有 IDC 或云环境拓扑、合规要求、SLA 目标、预算约束。输出则是上云策略报告、迁移优先级矩阵、总体里程碑计划。例如，某零售企业计划将 120 个应用上云，按“业务影响度 × 迁移复杂度”排序，优先迁移 30 个低耦合、高收益的 Web 应用，作为首批试点。这个阶段的关键角色是交付经理与云架构师，前者负责范围、进度和风险，后者负责技术可行性判断。

架构设计阶段要把业务目标翻译成可落地的技术方案。Google Cloud 上常见的交付对象包括：资源层级（Organization / Folder / Project）、网络拓扑（VPC、Shared VPC、Cloud Interconnect）、身份与权限（Cloud Identity、IAM、Org Policy）、安全基线（VPC-SC、SCC、KMS）、可观测性（Cloud Monitoring、Logging）。这一阶段最容易被忽视的是“非功能需求”：如果业务要求 RTO ≤ 30 分钟、RPO ≤ 5 分钟，那么数据库选型、跨区复制、备份策略就必须在架构图中明确体现，而不是等到上线前再补。

基础环境搭建阶段，交付团队通常以 Landing Zone 为核心。一个可用的 Landing Zone 至少包含：组织与文件夹结构、集中日志与审计项目、Shared VPC 网络、IAM 基线、Org Policy 约束、KMS 密钥环。以某金融客户为例，其 Landing Zone 采用“1 个组织 + 3 个文件夹（生产/非生产/沙箱）+ 12 个项目”的结构，生产项目强制启用 VPC Service Controls，所有数据加密使用 CMEK。这些约束通过 Terraform 模块固化，避免人工在控制台误操作。

迁移与现代化阶段是交付工作量最大的部分。Google Cloud 提供四种常见迁移路径：Rehost（直接搬迁）、Replatform（小幅改造）、Refactor（重构）、Retire（下线）。选择哪条路径，取决于应用耦合度、团队能力、时间窗口和长期收益。例如，一个基于 VM 的 Java 应用，如果依赖本地文件系统，可以先 Rehost 到 Compute Engine，再逐步将状态外移到 Cloud Storage 或 Cloud SQL。迁移过程中必须保留数据校验记录：源端与目标端的行数、校验和、抽样比对结果，作为切换决策的依据。

上线切换阶段的核心交付物是 Runbook。一份合格的 Runbook 应包含：切换前检查项、DNS/Traffic 切换步骤、验证命令、回滚触发条件与回滚步骤、联系人清单。以 DNS 切换为例，建议先将 TTL 调低至 60 秒，切换后观察 15 分钟错误率与延迟，若 P99 延迟超过基线 20% 或错误率超过 0.5%，立即执行回滚。这个判断阈值应在切换前与业务方确认，而不是临时决定。

运营优化阶段不是“项目结束”，而是交付价值的延续。团队需要定义 SLO（如可用性 99.95%、P99 延迟 ≤ 300ms），并基于错误预算决定发布节奏。同时，通过 Cloud Billing 预算告警、Committed Use Discount、Right-sizing 建议 控制成本。一个常见的成功标准是：上线后 30 天内，月度成本偏差不超过预算的 10%，且无 P1 级事故。

最后，成功标准需要可量化、可验收。建议在项目启动时就与业务方确认五个维度：业务连续性（RTO/RPO）、性能与容量、安全与合规、成本可控、可运营性。每个维度都要有明确的指标、测量方法和验收人。例如，“安全与合规”可以定义为：所有生产项目 100% 启用 Org Policy 约束，SCC 高危发现项在 7 天内闭环。只有把成功标准写进验收清单，交付才不会变成“上线即结束”的一次性任务。