Google PCA: DevOps、交付工程与基础设施即代码 — 学习指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

属于 Google Professional Cloud Architect — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Cloud 上的 DevOps、交付工程和基础设施即代码 (IaC) 专注于通过强大的可追溯性、自动化和安全性来持续交付可靠的变更。架构应优化以实现短反馈周期、可重复的部署、不可变的基础设施以及随组织规模扩展的护栏。在 Google Cloud 上，这通常结合了源代码控制最佳实践；使用 Cloud Build 进行 CI；使用 Artifact Registry 进行工件管理；使用 Cloud Deploy 进行 CD；使用 GKE 上的 Kubernetes（采用 manifests、Helm 或 Kustomize）；用于配置漂移控制的 GitOps；以及使用 Terraform 或 Google Cloud 部署模板的 IaC。卓越运营需要渐进式交付（蓝绿部署、金丝雀发布、流量拆分和功能标志）、软件供应链控制（扫描、来源、签名）、测试和部署门禁，以及在速度、安全性、可审计性和所有权之间取得平衡的治理。

CI/CD、源代码控制和发布编排

• CI/CD 原则

  • 保持 master/main 分支可发布；实践基于主干的开发，使用短生命周期的功能分支。
  • 在每次变更时自动执行构建、测试、扫描和打包；要求代码审查，并设置强制性批准和状态检查。
  • 维护从提交 → 构建 → 工件摘要 → 环境发布的完整可追溯性；将提交的 SHA 和构建元数据嵌入到镜像和部署注解中。
  • 失败模式：长生命周期的分支、手动交接、不稳定的测试、不可复现的构建以及工件缺乏不可变性，这些都会导致意外问题和回滚。

• 源代码控制、分支、拉取请求、代码审查和可追溯性

  • 使用受保护的分支、强制审查和提交签名。为发布打上标签，并根据合并提交生成变更日志。
  • 应用 CODEOWNERS 和服务所有权元数据来强制执行领域管理权。
  • 将提交与问题和部署关联起来；将 CI/CD 日志和元数据导出到 Cloud Logging 和 BigQuery，用于审计和 DORA 指标分析。

• Cloud Build

  • 触发器：在 Git 事件（分支、标签、PR）、手动调用或 Pub/Sub 事件上触发。使用替换变量对版本、环境和功能标志进行参数化，以保持流水线 DRY（Don’t Repeat Yourself）。
  • 构建步骤：运行官方构建器或您自定义的容器；当步骤相互独立时，使用并行步骤以减少延迟；使用缓存来存储语言依赖项以加速构建。
  • 工件：将镜像推送到 Artifact Registry，使用不可变标签和摘要；存储 SBOM 和构建日志；将测试报告作为构建工件发布。
  • 安全的构建身份：使用具有最小权限的专用服务账号运行 Cloud Build，并尽可能为每个代码库使用 Workload Identity Federation。对于私有网络或避免出口流量，请使用 Private Pools。限制服务账号密钥的使用；优先选择短生命周期的令牌。
  • 示例（简化版）：
    • cloudbuild.yaml:
      • steps:
        • name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
        • name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
      • substitutions:
        • _ENV=staging

• Cloud Deploy

  • 发布和目标：通过跨目标（例如，dev → staging → prod）的提升来构建交付流水线模型。一次发布会捕获一个不可变的工件引用和部署配置。
  • 批准和提升：要求通过基于角色的控制进行手动或自动批准。由于工件和清单保持不变，提升操作应该是一个快速、低风险的动作。
  • 金丝雀部署和回滚：定义渐进式暴露、健康检查以及在 SLO 错误时自动回滚的策略。记录每一次提升、批准人和验证结果以供审计。
  • 失败模式：环境之间存在可变工件、在生产环境中手动执行 kubectl，或跳过部署前验证，这些都会导致配置漂移和无法追踪的故障。

基础设施即代码与配置管理

• Terraform

  • 模块：捕获可重用的模式（例如，VPC、GKE 集群、服务账号、IAM 绑定）。对模块发布进行版本控制和固定；发布内部模块注册中心。
  • 远程状态：存储在启用了版本控制、保留策略和 CMEK 的 Cloud Storage 中；启用锁定；通过 IAM 和统一存储桶级访问来限制访问；备份状态。
  • 计划与策略检查：在 CI 中运行 terraform fmt/validate/plan；要求对计划进行人工审查；强制执行策略即代码（OPA/Conftest、Sentinel 或 Policy Controller）以阻止违规行为（例如，公开的存储桶、宽泛的 IAM 绑定）。
  • 环境提升：为每个环境使用独立的工作区或独立的状态/后端；通过相同的模块版本和变量来提升变更；切勿手动编辑云资源。敏感输入应来自 Secret Manager 或自动化，切勿硬编码。
  • 故障模式：将密钥泄漏到状态中、无锁定的并发更改、带外编辑导致的漂移，以及破坏销毁/替换操作的隐式依赖。

• Google Cloud 部署模板和声明式配置

  • 使用声明式工具（Terraform、Google Cloud Deployment Manager 或 Kubernetes Configuration as Code）来定义期望状态，而不是使用命令式步骤的脚本。
  • 首选不可变基础设施：替换实例模板并滚动更新 MIG；推出新的 GKE Deployment，而不是就地修补 Pod。不可变模式使回滚和审计变得简单。
  • Deployment Manager 支持用于 Google Cloud 资源的 Jinja/Python 模板，但仅限于 Google Cloud；Terraform 提供更广泛的生态系统和策略工具。根据组织标准化和技能集进行选择。

• Kubernetes 清单、Helm、Kustomize 和 GitOps

  • 清单：保留基础模板并附带环境覆盖层；仅参数化那些应因环境而异的内容（例如，副本数、限制、端点）。
  • Helm：使用 chart 来打包、模板化和版本化服务；锁定依赖项；固定镜像摘要。故障模式：过度模板化会掩盖意图并使审查复杂化。
  • Kustomize：管理覆盖层（基础 + 环境补丁）；当纯 Kubernetes 已足够时，它比 Helm 更简单。
  • GitOps：一个控制器（例如，Config Sync、Argo CD、Flux）持续将集群与 Git 中的期望状态进行协调；每个变更都是一个带有审查和审计跟踪的 PR。自动检测并纠正漂移。

渐进式交付、供应链、测试和验证

• 功能标志和流量管理

  • 功能标志将部署与发布解耦；用于逐步开放、A/B 测试和紧急关闭开关。确保标志状态有版本记录且可审计；淘汰过时的标志。
  • 流量拆分：在 Cloud Run 上，跨修订版本使用基于百分比的路由；在 GKE 上，使用支持加权路由的服务网格或 Ingress 控制器。对于单一主机名/TLS 下的 API，在 HTTP(S) 负载均衡器后面为每个路径保留独立的后端服务；路径路由可以清晰地隔离新旧版本，同时保留单一 URL 和证书。
  • 蓝绿部署：运行两个生产就绪的堆栈；通过负载均衡器、服务选择器或 Cloud Run 修订版本流量来原子化地切换流量。可以实现即时回滚，但会使稳定状态下的成本加倍。
  • 金丝雀和渐进式发布：从一小部分流量开始逐步增加，同时衡量黄金信号和业务 KPI；在出现回归时自动回滚。

• 软件供应链控制

  • 镜像扫描：启用 Artifact Analysis 漏洞扫描；当存在严重漏洞或已知有问题的基础镜像时，构建失败；保持补丁更新节奏。
  • 来源和签名：在 Cloud Build 中生成符合 SLSA 的构建来源信息；使用 Cosign 对工件进行签名；强制执行 Binary Authorization 策略，要求在部署前进行证明。
  • 依赖管理：固定版本和摘要，维护 SBOM，对关键依赖项进行 vendoring，并验证校验和。故障模式包括传递性依赖漂移和被攻陷的注册中心。

• 测试金字塔、部署门禁和部署后验证

  • 金字塔：强调快速的单元测试；增加集成测试和契约测试；运行有针对性的端到端测试。保持测试数据真实且已脱敏（使用 Cloud DLP 移除 PII）。
  • 部署门禁：在提升前强制执行测试通过率、漏洞状态、策略合规性和代码审查的阈值；当风险较高时，要求对生产环境进行手动批准。
  • 部署后验证：使用 Cloud Monitoring、Error Reporting 和 Trace 运行冒烟测试、综合检查和金丝雀分析。如果 KPI 下降，触发自动回滚并打开一个包含捕获上下文的事件。
  • 运维诊断：在需要的地方部署 Cloud Logging 代理，并为服务植入 Trace 和 Debugger。保留用于安全修复的运行手册（例如，在线调整永久性磁盘大小并以最小停机时间运行 resize2fs）。

治理、安全、可审计性和所有权

• 兼顾速度与安全

  • 基于主干的开发模式，配合短生命周期的 PR 和强制性审查，可在不牺牲质量的前提下保持开发流程的顺畅。
  • 为通用技术栈（如 GKE + Helm、Cloud Run、Dataflow）提供模板化的自服务流水线，可以加速团队开发并减少定制化带来的风险。

• 访问、身份和审批

  • 每个流水线阶段使用专用的服务账号，遵循最小权限原则，并采用 Workload Identity Federation；避免使用静态密钥。
  • 职责分离：开发人员负责构建；发布经理负责审批到生产环境的晋升；运行时运维人员负责运行时配置和预算。

• 可审计性与合规性

  • 将 Cloud Build、Cloud Deploy 和 Cloud Audit Logs 导出到 BigQuery。使用数据集视图和 IAM 与审计人员共享范围限定的审计数据。根据策略将指标长期保留，导出到 Cloud Storage 或 BigQuery。
  • 在部署元数据中记录构件摘要。为每个版本维护端到端的 SBOM 和来源信息。

• 所有权与 SLO

  • 每个服务都有明确的所有者、on-call 轮值、SLO 和用于控制发布的错误预算。将部署策略与 SLO 合规性挂钩，以避免在错误预算耗尽时推送变更。

• 常见的权衡与陷阱

  • 蓝绿部署的成本 vs. 回滚速度；金丝雀发布的置信度 vs. 全量发布所需的时间。
  • GitOps 的一致性 vs. 运维的灵活性；允许有控制的“紧急破窗”操作，但需有日志记录和后续的 PR 跟踪。
  • 过度模板化会降低可读性；保持配置的显式和最小化。
  • 中心化策略可以防止错误配置，但必须迭代式地推出，以避免不必要地阻塞团队。

实践问题场景

公司：Borealis Fintech

挑战：Borealis 公司正在 GKE 上推出一个新的支付 API，同时需要在同一个主机名和 TLS 证书下维护 v1 和 v2 版本。他们需要端到端的可追溯性、使用金丝雀发布和功能标志的渐进式交付、强大的供应链管控，以及跨开发、预发和生产环境的、经过审计的晋升流程。他们还希望使用 GitOps 管理集群配置，使用 Terraform 管理平台资源。

方法：

1. 建立源代码控制和分支策略

   • 创建一个包含服务目录的 mono-repo，以及一个独立的基础设施仓库。强制执行主干分支保护、强制性 PR 审查、CODEOWNERS 和签名提交。理由：实现基于主干的开发流程，具有清晰的所有权和可供审计的历史记录。

2. 使用 Cloud Build 和 Artifact Registry 构建构件

   • 定义 cloudbuild.yaml 文件，用于构建并推送镜像，镜像使用 $COMMIT_SHA 作为标签，并附带 SBOM 和来源信息的注解。使用具有最小权限的专用 Cloud Build 服务账号和 Private Pool。理由：实现可复现、隔离的构建，并生成可追溯的摘要。

   • 示例：

undefined

3. 实施软件供应链管控

   • 在 Artifact Registry 中启用漏洞扫描。在 Cloud Build 的构建后步骤中生成来源信息并使用 Cosign 对镜像进行签名。配置 Binary Authorization，要求在部署到 GKE 之前必须有签名并通过漏洞扫描。理由：在强制执行阶段阻止不受信任或存在漏洞的构件。

4. 使用 Cloud Deploy 建模交付流程

   • 定义一个交付流水线，其目标环境包括 dev、staging、prod，并为 prod 环境配置金丝雀发布策略。要求对 prod 的部署进行手动审批，审批者基于角色分配。理由：实现不可变的晋升流程和可审计的审批。

   • clouddeploy.yaml (摘录):

undefined

5. 在同一主机名下路由 v1 和 v2 API
   • 配置一个外部 HTTP(S) 负载均衡器，为 /v1 和 /v2 路径设置独立的后端服务，每个后端服务指向相应的 GKE NEG。理由：实现清晰的基于路径的隔离，共用相同的证书和 DNS，并能独立部署。

   • 示例 (摘录):

undefined

6. 使用 Terraform 管理基础设施
   • 为 VPC、GKE、Artifact Registry、服务账号和 IAM 创建模块。将远程状态存储在受 CMEK 保护、启用版本控制和保留策略的 Cloud Storage 存储桶中。在 CI 流程中强制执行 OPA 策略，以防止高风险变更。理由：实现可复用、可审查且受治理的平台置备。

undefined

7. 使用 Helm/Kustomize 和 GitOps 配置 Kubernetes

   • 使用 Kustomize 维护 API 的基础清单以及每个环境的覆盖配置。使用 Config Sync 或 Argo CD 将集群状态与 Git 仓库的状态进行同步。理由：实现声明式、可审计且抗配置漂移的运维。

8. 使用金丝雀发布和功能标志进行渐进式交付

   • 对生产环境使用 Cloud Deploy 的金丝雀发布，并使用功能标志 SDK (OpenFeature) 来控制新逻辑的启用。从 5% 的流量开始，在 SLO 健康的情况下自动晋升；在服务质量下降时自动回滚，并使用功能标志作为紧急关闭开关。理由：减小变更的爆炸半径，并将部署与发布解耦。

9. 质量门禁与验证

   • 流水线阶段：单元测试 → 针对临时环境的集成测试 → 容器扫描 → 策略检查 → 预发环境的端到端测试 → 生产环境金丝雀发布，并进行基于 SLO 的自动化验证 (Cloud Monitoring, Error Reporting, Trace)。理由：尽早获得快速反馈，在生产部署前提供强有力的安全保障，并在部署后进行客观的健康检查。

10. 运维、日志和审计

    • 为支持性的虚拟机安装 Cloud Logging/Monitoring 代理，并启用 GKE 工作负载的日志/指标。将 CI/CD 和审计日志导出到 BigQuery，并为审计人员提供范围限定的视图。维护运行手册（包括安全回滚和紧急 DNS 或 LB 切换程序）。理由：通过可观测性实现快速修复，并提供满足合规性要求的证据。

该设计通过基于主干的流程和自动化流水线来保证速度；通过金丝雀发布、功能标志和 Binary Authorization 来保证安全；通过不可变构件、审批流程和集中式日志来保证可审计性；并通过 CODEOWNERS 和 GitOps 控制的环境来保证清晰的所有权。

← 运维、可观测性与平台自动化 · 所有领域 · 成本、性能与可持续云设计 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →