手册

一个全球性应用需要为全球用户提供低延迟和高可用性。

→使用带有多区域后端（MIGs/GKE）的全球 HTTP(S) 负载均衡器，Cloud CDN 用于静态内容，以及 Cloud Armor 用于 DDoS 防护。

原因: 全球负载均衡器提供一个Anycast IP，将用户路由到最近的健康后端。CDN 在边缘缓存内容，减少源站负载和延迟。

参考↗

从 IoT 设备摄取并处理高吞吐量的实时数据以进行即时分析。

→使用 Pub/Sub 进行可扩展的消息摄取，Dataflow 流式管道用于实时处理和异常检测，并将结果写入 BigQuery 进行分析。

原因: 这是实时数据的规范无服务器模式。Pub/Sub 解耦摄取，Dataflow 通过自动扩缩处理复杂数据，BigQuery 支持流式插入以实现实时分析。

参考↗

游戏后端需要存储玩家状态和排行榜，并要求亚毫秒级读取延迟和高吞吐量。

→使用 Cloud Bigtable 存储游戏状态/排行榜，并使用 Memorystore (Redis) 进行会话缓存。

原因: Bigtable 为高吞吐量读写提供个位数毫秒级延迟，非常适合时间序列或大型分析数据集。Memorystore 为会话状态提供微秒级延迟。

一个全球分布式应用需要一个具有强事务一致性和水平可扩展性的数据库。

→使用多区域配置的 Cloud Spanner。

原因: Spanner 是唯一提供全球强一致性事务、SQL 语义和水平可扩展性的服务。Cloud SQL 需要手动分片才能达到这种规模。

参考↗

迁移一个要求高可用性、高性能且需要最少重构的、要求严苛的本地 Oracle 或 PostgreSQL 数据库。

→使用 AlloyDB for PostgreSQL。

原因: AlloyDB 是一个完全托管的、兼容 PostgreSQL 的数据库，具有卓越的性能、99.99% 的可用性以及 Oracle 兼容性功能，使其成为企业迁移的理想选择。

参考↗

将本地数据中心连接到 GCP，要求稳定、低延迟（<10ms）和高带宽（10+ Gbps）。

→使用带有冗余连接的专用互连（Dedicated Interconnect）。

原因: 专用互连提供私有的、高带宽、低延迟的物理连接。Cloud VPN 运行在公共互联网上，无法保证此级别的延迟或带宽 SLA。

参考↗

为需要集中式网络管理但分散项目所有权的多个团队/项目设计网络。

→使用共享 VPC 实施中心辐射模型。中央网络团队管理宿主项目，应用团队使用服务项目。

原因: 共享 VPC 允许集中控制网络资源（子网、防火墙），同时将服务项目中的资源管理委派出去。这比 VPC 对等连接更具可扩展性和安全性。

在 Google Cloud、AWS、Azure 和本地环境中一致地管理 Kubernetes 集群。

→使用 Anthos 为多云和混合集群管理、策略实施和可观测性提供统一的控制平面。

原因: Anthos 将 GKE 扩展到其他环境，实现整个集群舰队的统一操作和基于 GitOps 的配置管理（Config Management）。

数据科学团队需要在不管理基础设施的情况下，使用 GPU 加速训练复杂的机器学习模型。

→使用 Vertex AI Training（带自定义容器）和 Vertex AI Experiments 跟踪模型迭代。

原因: Vertex AI 提供了一个完全托管的训练服务，负责基础设施配置、扩缩和 GPU 管理。它与实验集成，用于跟踪和比较模型性能。

以低延迟、高可用性提供大型机器学习模型服务，并能自动扩缩。

→使用 Vertex AI Prediction（带自定义容器），部署到启用自动扩缩的托管端点。

原因: Vertex AI Prediction 针对低延迟模型服务进行了优化。它处理自动扩缩、流量分割（用于 A/B 测试）和基础设施管理，为开发者抽象了复杂性。

Cloud Function 或 Cloud Run 服务需要安全地连接到具有私有 IP 的 Cloud SQL 实例。

→配置无服务器 VPC 访问连接器，以连接无服务器环境和您的 VPC。

原因: 连接器在您的 VPC 中创建一个隧道，允许无服务器服务通过其私有 IP 地址访问内部资源，而无需将其暴露给互联网。

将使用本地会话存储的有状态应用迁移到 Cloud Run 或 GKE 等无状态、自动扩缩平台。

→将会话状态外部化到 Memorystore (Redis) 等托管内存存储中。

原因: 无状态计算要求会话数据外部存储，以便任何实例都可以处理任何用户请求。Memorystore 为此提供了一个共享的、低延迟的解决方案。

创建托管的持续交付管道，以在多个环境（预生产、生产）中推广发布并进行审批。

→使用 Cloud Deploy 定义交付管道，通过内置审批门来编排部署到目标环境（GKE、Cloud Run）。

原因: Cloud Deploy 是一个完全托管的 CD 服务，提供发布管理、可审计性和自动化回滚功能，而无需自行托管 Spinnaker 等工具的运营开销。

将容器化应用部署到生产就绪的 Kubernetes 集群上，并最大限度地减少操作和管理开销。

→使用 GKE Autopilot 集群。

原因: Autopilot 管理集群的控制平面和节点，包括供应、扩缩和安全强化。您只需为您请求的 Pod 资源付费，从而简化了操作和成本管理。

以最小风险和停机时间，逐步将大型单体应用迁移到微服务架构。

→应用绞杀者模式（Strangler Fig pattern）。在单体应用前面放置一个代理，并随着新微服务的构建和验证，逐步将特定功能的流量重定向到新微服务。

原因: 这种模式通过允许逐步、受控的过渡，避免了高风险的“大爆炸”式重写。随着新服务接管其功能，单体应用被慢慢“绞杀”。

以最小停机时间将大量本地 VM 迁移到 Google Cloud。

→使用 Migrate to Virtual Machines（原 Migrate for Compute Engine）从本地到 GCP 执行连续的块级复制，然后进行快速切换。

原因: 此工具专为“提升和转移”迁移而设计，通过保持源 VM 和目标 VM 同步直到最终切换，将停机时间缩短到几分钟。

一个团队正在采用 SRE 原则，需要建立其初始 SLO。

→首先定义以用户为中心的服务级别指标（SLI）（例如可用性、延迟）。分析历史性能数据以设置切合实际的初始服务级别目标（SLO）。

原因: SLO 必须基于用户体验（SLI）并且是可实现的。基于历史数据设置 SLO 可确保初始错误预算是切合实际的，并且不会立即被违反。

自动化新 GCP 项目的创建，并采用标准化配置（API、IAM、网络、安全）。

→使用“项目工厂”模式和 Terraform 模块，由 Cloud Build 触发。使用 Service Catalog 提供自助服务界面。

原因: 这确保所有新项目都符合组织标准和安全基线，减少手动工作和配置漂移。它实现了大规模治理。

防止对 Terraform 管理的基础设施进行手动更改（配置漂移）。

→对所有应用使用 CI/CD 管道（例如 Cloud Build），通过 GCS 后端实现 Terraform 状态锁定，使用组织策略限制控制台操作，并定期进行漂移检测。

原因: 需要多层方法。管道强制执行单一的更改路径，锁定可防止并发应用，组织策略提供预防性护栏。

管理具有共享模块但配置不同的多个环境（开发、测试、生产）的基础设施代码（Terraform）。

→使用一套可重用的 Terraform 模块，并通过单独的 `.tfvars` 文件或工作区提供特定于环境的配置。

原因: 这遵循了“不要重复自己”（DRY）原则。模块确保一致性，而变量文件提供了根据每个环境进行定制的灵活性。

实施 GitOps 工作流，将 Kubernetes 清单从 Git 仓库自动部署到 GKE 集群。

→使用 Anthos Config Management（或独立的 Config Sync）持续将集群状态与 Git 仓库中的配置进行协调。

原因: Config Sync 提供了一个完全托管的 GitOps 解决方案，可以检测并纠正配置漂移，确保 Git 仓库是集群状态的单一事实来源。

参考↗

为 Web 应用实施蓝绿部署，要求零停机时间和即时回滚能力。

→在 HTTP(S) 负载均衡器后面使用两个相同的托管实例组（或 GKE 部署）。通过在负载均衡器的后端服务中重定向流量来执行切换。

原因: 在负载均衡器级别的流量分割是即时的，并且可以通过简单地将流量切换回原始后端来实现轻松回滚。这优于较慢的基于 DNS 的方法。

安全地存储、管理和审计应用对 API 密钥和数据库密码等秘密的访问。

→使用 Secret Manager 和 IAM 进行访问控制，并使用 Workload Identity 从 GKE/Cloud Run 进行无密钥身份验证。

原因: Secret Manager 是一个集中式托管服务，具有版本控制、轮换策略和审计日志功能。使用 Workload Identity 可避免管理和分发服务账号密钥。

参考↗

防止 BigQuery 和 Cloud Storage 等服务中的敏感数据被访问或复制到未经授权的项目或位置。

→使用 VPC Service Controls 为敏感项目创建服务边界并限制数据流。

原因: VPC Service Controls 作为 Google 托管服务的防火墙，在 API 级别防止数据渗漏。这是 IAM 和网络防火墙之外的关键深度防御层。

参考↗

在 Google Cloud 服务中对静态数据进行加密，同时保持对加密密钥的完全控制。

→使用客户管理加密密钥（CMEK），密钥存储和管理在 Cloud KMS 中。

原因: CMEK 允许您通过 Cloud KMS 使用自己的密钥来保护其他 GCP 服务中的数据。您可以控制密钥轮换，并通过禁用密钥来撤销访问权限，从而提供加密擦除。

设计一个符合 HIPAA 规定处理受保护健康信息（PHI）的架构。

→使用 CMEK 进行加密控制，VPC Service Controls 防止数据渗漏，Assured Workloads 用于合规边界，Cloud Audit Logs 和 Access Transparency 用于审计。

原因: HIPAA 要求结合使用技术控制。CMEK 提供密钥控制，VPC-SC 防止数据泄露，以及广泛的日志记录（审计日志、访问透明度）提供必要的审计能力。

GKE Pod 需要安全地连接到 Cloud SQL 数据库，而无需使用密码或管理服务账号密钥。

→使用 Workload Identity 将 Kubernetes 服务账号绑定到 Google 服务账号。使用 Cloud SQL Auth Proxy Sidecar 和 IAM 数据库身份验证进行连接。

原因: 这种“无密码”模式是最安全的。Workload Identity 提供无密钥身份验证，Auth Proxy 加密流量，IAM DB 身份验证使用 IAM 进行数据库访问，而不是静态凭据。

强制执行一项策略，规定所有云资源只能在特定地理区域（例如欧盟）创建。

→在组织或文件夹级别配置组织策略约束 (`gcp.resourceLocations`)，指定允许的区域。

原因: 这是一种预防性控制，可在 API 层面阻止不合规的资源创建。它是跨整个组织强制执行数据驻留策略的权威方式。

确保只有受信任、经过扫描和授权的容器镜像才能部署到生产 GKE 集群。

→使用 Artifact Registry 进行漏洞扫描，并使用 Binary Authorization 强制执行需要有效证明（签名）的部署策略。

原因: 这创建了一个安全的软件供应链。Artifact Registry 扫描漏洞，Binary Authorization 作为策略执行点，通过加密验证镜像已通过所有必需的检查。

参考↗

为远程员工提供对内部 Web 应用的安全、上下文感知访问，而无需使用传统的 VPN。

→使用 BeyondCorp Enterprise，结合 Identity-Aware Proxy (IAP)、Access Context Manager 用于策略，以及 Endpoint Verification 用于设备姿态。

原因: 这实现了一种零信任模型，其中访问权限基于用户身份和设备信任授予，而不是网络位置。IAP 充当每个请求的身份验证代理。

受监管的工作负载要求加密密钥存储和处理在 FIPS 140-2 Level 3 认证的硬件安全模块（HSM）中。

→使用 Cloud KMS，密钥保护级别设置为 `HSM`。

原因: Cloud HSM 是一个完全托管的服务，提供 FIPS 140-2 Level 3 认证的 HSM。使用此保护级别生成的密钥永远不会以明文形式离开 HSM 边界。

自动发现并去标识 Cloud Storage 或 BigQuery 中的敏感数据（如 PII）。

→使用 Cloud Data Loss Prevention (DLP) 扫描敏感数据，并应用去标识技术，如掩码、标记化或编辑。

原因: DLP 为各种敏感数据类型提供预构建和自定义检测器，无需自定义脚本即可实现自动化和可扩展的数据保护。

允许来自多个身份提供商（例如 Okta、Azure AD）的员工访问 Google Cloud 资源，而无需创建 Google 账号。

→使用 Workforce Identity Federation 将外部身份提供商连接到 Google Cloud IAM。

原因: 这使您能够利用现有的身份系统作为事实来源，避免为员工同步用户或管理单独的 Google 身份。

处理高度敏感的数据，即使在使用中（在内存中）数据也必须保持加密状态。

→使用 Confidential VMs。

原因: 机密计算使用专用硬件功能（AMD SEV）在处理过程中加密数据。这可以防止内存抓取攻击，并为敏感工作负载提供额外的安全层。

优化大型数据仓库的 BigQuery 成本和性能。

→按日期实现分区，并对频繁过滤的列进行聚类。对仪表盘使用 BI Engine，对常见且开销大的聚合使用物化视图。

原因: 分区和聚类是减少每次查询扫描数据量的基础，这直接降低了成本并提高了速度。BI Engine 和物化视图减少了冗余计算。

参考↗

以尽可能低的计算成本运行大规模、容错的批处理作业。

→在托管实例组中使用 Spot VMs。确保应用是容错的并能处理抢占。

原因: Spot VMs 比按需实例节省高达 91% 的成本。它们非常适合无状态、容错且可以停止和重新启动的工作负载，例如许多批处理任务。

实施 FinOps 实践，为不同团队或部门提供成本可见性和问责制。

→使用资源层次结构（每个团队一个文件夹），应用标签进行成本分配，并将详细账单数据导出到 BigQuery，以便在 Looker Studio 中进行分析和可视化。

原因: 这种组合提供了一种结构化的方式来组织资源，通过标签精细跟踪成本，并构建自定义的、团队专属的仪表盘以进行成本回溯/分摊。

优化具有可变负载的应用的 GKE 集群成本和性能。

→使用 Horizontal Pod Autoscaler (HPA) 根据指标扩缩 Pod，并使用 Cluster Autoscaler 根据需要添加/删除节点。

原因: 这种两级自动扩缩方法确保应用（Pod）和基础设施（节点）都随需求同步扩缩，防止过度配置并确保性能。

机器学习训练作业显示 GPU 利用率低（<30%），表明存在瓶颈。

→诊断并优化数据输入管道。使用 `tf.data` 并结合预取和并行读取，或使用 Cloud Storage FUSE 来提高 I/O 性能。

原因: GPU 利用率低几乎总是数据 I/O 瓶颈。GPU 在等待下一批数据时处于空闲状态。优化数据加载是提高训练效率的第一步。

降低向互联网或跨区域提供数据时产生的高网络出站成本。

→使用 Cloud CDN 缓存静态内容。对于区域间流量，对非延迟敏感的工作负载使用标准网络服务层级。

原因: CDN 从边缘提供数据，这比源站出站更便宜。标准层级通过公共互联网而不是 Google 的高级网络路由流量，为批量数据传输提供更低的成本。

降低仅在工作时间需要的开发和测试 VM 的成本。

→使用 Cloud Scheduler 触发 Cloud Functions，这些函数根据预定义的时间表自动启动和停止实例。

原因: 这种“实例调度”模式自动化了在资源不使用时将其关闭的过程，显著降低了非生产环境的成本。

关键应用需要一个具有自动故障转移功能的，以应对区域故障的关系型数据库。

→配置 Cloud SQL 实例并启用高可用性（HA）选项。

原因: HA 配置会在不同区域创建一个备用实例，并进行同步复制。在主实例或区域发生故障时，故障转移是自动的，通常在 60 秒内完成。

自动检测并从无响应或失败的 Compute Engine 实例中恢复。

→在托管实例组（MIG）中部署实例，并配置基于应用的健康检查的自动修复。

原因: MIG 自动修复会主动探测每个实例上的应用。如果应用未能通过其健康检查，MIG 会自动重新创建该实例，从而确保服务可靠性。

设计一个灾难恢复计划，其 RTO 小于 1 小时，RPO 小于 15 分钟。

→在辅助区域实施热备用。使用 Cloud SQL 跨区域副本、多区域 Cloud Storage 以及用于计算的预配置实例模板。

原因: 这种方法平衡了成本和恢复时间。数据几乎同步复制以满足 RPO，并且运行最少的基础设施（热备用）以实现快速扩缩以满足 RTO。

为微服务应用实施全面的可观测性，以实现快速故障排除。

→使用带关联 ID 的结构化日志记录，Cloud Trace 用于分布式跟踪，Cloud Monitoring 用于指标，以及 Cloud Error Reporting 用于自动化错误分组。

原因: 日志、跟踪和指标（“可观测性的三大支柱”）的组合至关重要。关联 ID 和分布式跟踪对于跟踪跨多个服务的单个请求至关重要。

防止一个微服务的故障导致整个应用的级联故障。

→在每个服务间通信点实施弹性模式，如熔断器、带指数退避的重试和激进超时。

原因: 这些模式隔离了故障。熔断器阻止对故障服务的调用，防止调用服务耗尽其资源并反过来导致自身故障。

实施 SRE 最佳实践，以降低新部署导致的生产中断风险。

→使用金丝雀部署逐步推出更改，功能标志将部署与发布解耦，并根据 SLO 监控设置自动化回滚触发器。

原因: 这些实践限制了不良部署的“爆炸半径”。金丝雀部署首先将新版本暴露给一小部分用户，自动化回滚最大限度地减少了平均恢复时间（MTTR）。

使用 SRE 错误预算来平衡功能开发速度与可靠性。

→定义错误预算策略：当预算即将耗尽时，暂停新功能部署，并优先处理提高可靠性的工作。

原因: 错误预算是做出权衡决策的数据驱动机制。当预算健康时，它允许团队承担风险；当预算不健康时，它强制团队专注于稳定性。

使用 Cloud Spanner 的全球分布式应用在某些区域遇到高写入延迟。

→分析应用的写入模式，并将 Spanner 实例的主导区域配置为地理位置上靠近大多数写入操作的区域。

原因: 在 Spanner 中，所有写入都通过主导区域路由以确保一致性。将主导区域放置在靠近主要写入源的位置，可以最大限度地减少这些事务的网络延迟。