Google PCD: 成本、治理和可持续应用运维 — 学习指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

概述

在现代 Google Cloud 应用开发中，成本、治理和可持续运营是密不可分的。其目标是揭示和控制支出，设计可经济扩展的服务，并强制实施护栏以保持环境的安全、合规和整洁——同时平衡性能和可靠性。本节详细介绍了实用机制（结算和标签、自动扩缩容的调节、配额和策略）、特定工作负载的经济性（Cloud Run、GKE、数据平台），以及在不损害用户体验的情况下减少闲置浪费和碳影响的可持续性选择。

成本控制与可见性

结算帐号、标签、成本分配、预算、提醒和可见性
- 为每个业务单元或资金来源使用一个专用的结算帐号，以隔离所有权并实现精细的权限管理。将结算数据导出到 BigQuery 进行详细分析、预测和内部计费。
- 标签是附加于资源上用于成本归因的键值对。标准化标签键（例如 team、app、env、cost-center），并通过组织策略和 CI 检查来强制执行。注意：标签不是追溯性的；未标记的资源会使报告失真。
- 在结算帐号和项目级别使用预算和提醒。结合使用阈值（例如，50%、90%、100%）和基于预测的触发器。将预算通知路由到 Pub/Sub 并转发到 Chat/Ops 工具。预算只负责提醒，不强制执行。
- 对于共享平台（例如 GKE、BigQuery），使用基于命名空间或作业的标签，并将其附加到日志和用量数据中，以实现成本展示/内部计жба。

示例：添加标签 gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

配额、限制、用量预测和容量治理
- 配额可以保护服务并限制失控的成本。定期审查服务配额，根据每个项目的需求调整其大小，并在发布前申请提高配额。实施部署前检查，将预期的峰值用量与配额进行比较。
- 使用结算导出数据加上产品使用遥测数据（Cloud Monitoring 指标、基于日志的指标）来预测支出。对场景（预期的 QPS、扫描的数据量）进行建模，并在预生产环境中进行验证。
- 故障模式：在事故处理或产品发布中途达到配额会导致限流 (429/403)、部分中断或静默降级。过度配置的配额会增加故障作业的影响范围。

示例：列出 Compute Engine 配额 gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

弹性与计算经济性

规模调整、自动扩缩容、基于请求的计费、承诺使用和 Spot 容量
- 使用 Cloud Monitoring 和 Recommender 的洞察来调整 vCPU 和内存的规格；通过负载测试进行验证。分配不足会导致延迟峰值和 OOM/CPU 节流；分配过度则会浪费开销。
- 自动扩缩容将类似资本支出 (capex) 的过度预配转换为弹性的运营支出 (opex)。对 GKE 使用 HPA/VPA，对无服务器 (Cloud Run) 使用基于请求的自动扩缩容，以使容量与需求相匹配。
- 基于请求的计费 (Cloud Run、Cloud Functions、GKE Autopilot) 使成本与使用量保持一致，并减少空闲。注意每个请求的开销和冷启动问题；在适当情况下调整最小实例数。
- 承诺使用适用于稳态基线。对 Compute Engine 使用基于资源的 CUD，对符合条件的托管/无服务器产品使用灵活 CUD。不要对易变的工作负载过度承诺。
- Spot 容量可降低可中断、容错作业的计算成本。务必实现优雅终止处理程序；保持冗余和快速检查点。预计随时可能在短时间通知后被终止。
Cloud Run 并发与最小实例数的权衡
- 并发控制单个实例可同时处理的请求数量。
  - 更高的并发能提高利用率和成本效益，但可能因容器内的队头阻塞而增加尾部延迟。
  - 并发为 1 可以隔离请求（对 CPU 密集型或非线程安全的代码很有用），但这通常会增加实例数量和成本。
- 最小实例数以基线支出为代价，减少了冷启动并平滑了延迟。仅在 SLO 有要求时使用，并根据需求模式验证该下限值。

示例：Cloud Run 配置 (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

GKE 的 resource requests 与 limits、Cluster Autoscaler 的行为以及空闲资源清理
- Requests 决定调度；limits 限制峰值用量。将 requests 设置为接近观察到的稳定需求，将 limits 设置得略高一些以允许短暂突发。过低的 limits 会导致 CPU 节流；过低的 memory limits 会导致 OOMKilled。远高于实际需求的 requests 会搁浅容量并阻塞调度。
- Cluster Autoscaler 根据无法调度的 pod（总 requests 不足）来扩缩节点池。它会遵循 PodDisruptionBudgets，并且无法驱逐某些 pod（例如，使用本地存储或具有限制性 PDB 的 pod），这可能会阻止缩容。DaemonSets 和节点污点/亲和性也可能阻碍扩缩容效率。
- Horizontal Pod Autoscaler 将扩缩容与 CPU/内存或自定义指标挂钩；Vertical Pod Autoscaler 随时间推移调整 requests 的规格。协调 HPA 和 VPA 以避免振荡；根据情况在推荐或自动模式下使用 VPA。
- 空闲资源清理：删除未使用的负载均衡器、永久性磁盘、快照和静态 IP。使用 Active Assist 建议和自动化清理程序来检测并移除空闲资产。

示例：带 requests/limits 的 GKE deployment apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

数据、分析和网络成本治理

存储类别、生命周期控制、数据库扩缩和网络出站设计
- 根据访问模式选择 Cloud Storage 存储类别：Standard 用于热数据；Nearline、Coldline 或 Archive 用于较冷的数据。注意较冷层级的检索费用和最短存储时间（提前删除会产生费用）。
- 生命周期规则可自动执行存储类别转换和删除操作。在可接受多区域延迟的情况下，使用双区域以实现弹性；将计算和数据置于同一位置以减少出站流量和延迟。
- 数据库扩缩：
  - Cloud SQL：谨慎地垂直扩缩；使用只读副本处理读取；启用存储空间自动扩缩；使用查询计划和连接池。高写入吞吐量可能需要分片或迁移到 Spanner/Bigtable。
  - Spanner：通过添加节点进行水平扩缩；使用多区域配置以实现高可用性和全局读取；设计 schema 和键以实现负载均衡。
  - Bigtable：设计行键以避免热点；分别扩缩集群节点和存储。
- 网络出站：避免跨区域流量；尽可能将客户端和数据放在同一区域。使用 Cloud CDN 提供互联网规模的内容，使用 Cloud Interconnect/Peering 实现混合云连接，使用 Private Google Access 或 Private Service Connect 私密访问 Google API。不必要的跨可用区/区域流量会增加成本和延迟。

示例：Cloud Storage 生命周期

undefined

BigQuery 查询控制、数据保留和分析使用成本
- 控制扫描的字节数：始终按分区/集群键进行过滤；避免使用 SELECT *；对重复查询使用物化视图和结果缓存；在可能的情况下使用近似聚合。
- 通过设置“计费的最高字节数”来限制扫描成本，并将非紧急工作的作业优先级设置为批处理，以减少干扰和成本。
- 选择定价模型：零星工作负载使用按需模式；稳定的大容量工作负载使用带承诺的预留 (slot)。使用单独的预留和分配来隔离团队。
- 数据保留：为实现治理，设置数据集/表和分区的过期时间；实施分层存储或导出以进行归档。
- 故障模式：未分区的大型表会导致成本激增；没有分区过滤器的查询会扫描全表；过于激进的过期策略会删除需要的数据；过度的 slot 争用会降低 SLA。

示例：限制查询成本

undefined

组织治理与环境规整

组织政策、资源命名、标记和项目分离
- 使用组织政策来强制执行护栏：限制资源位置、禁止外部 IP、要求使用 CMEK、限制允许的服务、控制 VPC 对等互连以及在需要时强制使用 OS Login。在组织或文件夹级别应用，并通过层次结构来构建例外情况。
- 标准化资源命名以编码环境、项目、应用和区域（例如，app-env-region-suffix）。通过 CI 检查或策略即代码 (policy-as-code) 来强制执行。
- 区分：
  - 标签 (Labels)：用于账单/运营归因。
  - 标记 (Tags) (一等公民)：附加到资源上，并用于 IAM Conditions 和组织政策的目标定位。
  - 网络标记 (Network tags)：用于 Compute Engine 上的防火墙规则。
- 项目分离：隔离环境（生产、预发布、开发）和敏感工作负载。使用 Shared VPC 实现集中式网络和最小权限的服务项目。这可以减小爆炸半径并简化 IAM。
环境生命周期、临时测试环境和清理自动化
- 通过 IaC (Terraform) 预配环境，并启用每个 PR 的临时环境。设置 TTL 标签，并在合并或不活动后自动拆除。
- 使用 Cloud Scheduler 加上 Cloud Run 作业或 Functions，按标签/存在时间扫描并删除过时资源。通过 Cloud Asset Inventory 导出资产清单以驱动审计。
- 故障模式：废弃的沙盒会产生费用；缺少 TTL 或标签会妨碍清理；过于激进的清理可能会删除活动资源——应添加白名单和宽限期。
可持续性感知架构以及成本、性能和可靠性之间的平衡
- 优先选择托管式和无服务器服务，以减少空闲并提高资源利用率。
- 在合规的前提下，选择碳强度较低的区域；在可行时，将批处理工作负载安排在无碳能源比例较高的时间段运行。
- 优化数据引力和缓存以减少网络能耗。调整自动扩缩和并发性以降低资源利用率不足的情况。使用性能分析来移除触发过多计算或 IO 的浪费性代码路径。
- 平衡：仅在 SLO 要求时才添加最小实例或副本；评估尾部延迟与并发性、冗余与 Spot 实例使用之间的关系。通过基于 SLO 的负载测试和成本/性能建模进行验证。

实际问题场景

NimbusMarket 是一家电子商务公司，在闪购期间会经历流量尖峰，同时其分析支出也在不断增长。他们在 Cloud Run 上运行客户 API，在 GKE 上运行后台工作程序，并在 BigQuery 中进行产品分析。领导层要求在不影响 99.9% API SLO 的前提下，将成本降低 25%。

方法：

建立成本可见性和护栏
- 为结算账号创建预算，并在预测支出达到 60%、90% 和 100% 时设置告警，通过 Pub/Sub 将通知路由给值班人员。
- 标准化标签（team、app、env、cost-center）并通过对 Terraform 计划的 CI 检查来强制执行；添加一项组织政策，将资源位置限制在已批准的区域内。理由：预算提供预警；标签可以生成各团队的报告；政策可以防止意外使用高出站流量费用的区域并提高合规性。
调整 Cloud Run 以实现经济高效的扩缩
- 在性能分析确认平均 CPU 时间为 30 毫秒且 IO 非阻塞后，将无状态 API 的 containerConcurrency 设置为 40。将 minScale=2 配置为在正常时段避免冷启动；设置一个计划策略，在夜间将 minScale 降至 0。理由：更高的并发性可提高利用率并减少实例数量；保持最少的稳定实例可以在有限的基线成本下维护 SLO，并在非工作时间移除这部分成本。
为 GKE 工作负载分配合理的资源并启用高效的自动扩缩
- 根据性能分析，为工作程序 Pod 应用 500m CPU/512Mi 的 requests 和 1 CPU/768Mi 的 limits。基于队列深度和处理延迟启用 HPA，并以推荐模式启用 VPA 来迭代优化 requests。验证 PodDisruptionBudgets 允许缩容。在节点池上启用 Cluster Autoscaler，并使用多个较小的节点。理由：准确的 requests 能驱动有效的调度和自动扩缩；HPA 使容量与积压任务量对齐；VPA 避免资源请求漂移；多个小节点可减少闲置容量并加快扩缩事件的速度。
为容错批处理采用 Spot 容量
- 将图像缩略图生成任务迁移到采用 Spot 实例并带有检查点机制的节点池。实现 preStop 钩子以刷出正在处理的工作，并使用一个控制器来重新调度被中断的作业。理由：缩略图生成是幂等且时间灵活的，这使其成为利用 Spot 实例节省成本的理想选择，且对用户体验影响极小。
降低分析扫描成本并隔离工作负载
- 按 event_date 和 customer_id 对事件表进行分区和聚类。为原始事件添加 180 天后过期的表设置。将市场分析师分配到一个带有槽位上限的独立 BigQuery 预留中；在他们的计划查询中强制执行 maximum_bytes_billed。将夜间报告转换为批处理优先级。理由：分区和聚类可以限制每次查询的字节数；过期策略强制执行治理；预留可以隔离“吵闹邻居”；批处理可以减少非紧急作业的资源争用和成本。
优化存储生命周期和出站流量
- 将产品图片存储在靠近客户的双区域中；通过生命周期规则将 30 天未访问的图片移动到 Coldline；通过 Cloud CDN 提供服务。将 Cloud Run 服务与 Cloud SQL 部署在同一区域，并启用 Private Service Connect 以连接到 Google API。理由：CDN 减少了出站流量和延迟；生命周期管理将冷内容转移到更便宜的存储；同地部署可最大限度地减少出站流量并提高性能。
实施清理自动化和可持续性检查
- 为临时环境标记 ttl-hours 标签，并每晚运行一个 Cloud Run 作业来删除过期资源。使用 Carbon Footprint 报告来考虑将批处理作业迁移到碳排放更低的区域，并将其安排在非高峰碳排放时段运行。理由：自动化清理可防止成本泄漏；碳感知调度可在不影响 SLO 的情况下减少对环境的影响。
通过 SLO 感知负载测试和成本模型进行验证
- 运行负载测试，重放闪购模式的流量；验证 p95 延迟和错误预算。使用账单导出信息中心比较优化前后的成本。理由：确认调优在满足可靠性目标的同时，也带来了与目标一致的可衡量成本节省。