手册

在整个组织中强制实施预防性防护措施，例如限制资源位置或禁用服务帐号密钥创建。

→在组织或文件夹级别应用组织策略限制条件（例如，`constraints/gcp.resourceLocations`、`constraints/iam.disableServiceAccountKeyCreation`）。

原因: 组织策略在 API 级别继承和强制执行，可在不合规操作发生之前进行阻止。这比被动检测和补救更有效。

参考↗

构建多部门、多环境组织，以有效管理策略和访问控制。

→设计文件夹层次结构，通常是：组织 > 业务单元（文件夹）> 环境（例如，prod, staging）（子文件夹）> 项目。

原因: 这种结构允许粒度策略继承。通用策略在业务单元级别设置，而环境特定策略（例如，`prod` 更严格的策略）在环境级别设置。

聚合所有项目的日志，用于合规性、安全分析和运营故障排除，同时优化成本。

→创建组织级别的聚合日志接收器。根据需要将日志路由到多个目的地：BigQuery 用于分析，Cloud Storage (Coldline/Archive) 用于长期/低成本归档，以及 Pub/Sub 用于实时流式传输到 SIEM。

原因: 这种分层方法优化了成本和能力。BigQuery 提供强大的查询功能，而 Cloud Storage 提供廉价归档。对于所有用例来说，使用单一目的地要么太昂贵，要么性能不足。

参考↗

防止 BigQuery 和 Cloud Storage 等托管服务的数据泄露，只允许来自授权网络或身份的访问。

→在包含敏感数据的项目周围创建 VPC Service Controls 边界。定义访问级别以允许来自特定 IP 范围（公司网络）或设备的访问。

原因: VPC Service Controls 在基于 API 的服务周围创建虚拟边界，通过阻止来自边界外部的访问来减轻凭据被盗或 IAM 策略配置错误带来的风险。

建立项目所有者无法覆盖的安全防护措施，例如阻止授予特定角色。

→在组织或文件夹级别实施 IAM Deny 策略。这些策略明确拒绝权限，并且始终会覆盖任何 `allow` 策略。

原因: 拒绝策略提供了一种强大的方式，可以在资源层次结构的较低级别强制执行组织范围的安全控制，确保一致的安全态势，并且无法被绕过。

确保所有新项目都以标准基线配置（网络、IAM、日志记录等）进行预置。

→使用基础设施即代码（例如，带有 Cloud Build 的 Terraform）创建“着陆区”。通过管道自动化项目创建和配置。

原因: 自动化确保一致性，减少手动错误，并加快项目预置。它将最佳实践编码化，使治理可审计和可重复。

允许外部系统（如 GitHub Actions 或本地 CI/CD）访问 GCP 资源，而无需使用长期有效的服务帐号密钥。

→配置 Workload Identity Federation。创建信任外部 IdP（例如，GitHub OIDC）的提供商，并将外部身份映射到 GCP 服务帐号。使用属性条件将访问权限限制到特定的仓库/分支。

原因: 这消除了管理和轮换服务帐号密钥的需要，这是一个主要的安全性风险。它提供了短生命周期的、基于身份的凭据。

集中管理网络（VPC、子网、防火墙），同时允许不同团队管理自己的项目资源。

→实施 Shared VPC。为网络资源创建“宿主项目”，为应用程序工作负载创建“服务项目”。授予服务项目身份 `roles/compute.networkUser` 角色。

原因: Shared VPC 将网络管理与项目管理解耦，提供集中控制和安全性，同时赋予团队自治权。对于此用例，它比 VPC Peering 具有更好的可扩展性和安全性。

从 Git 仓库声明式地管理 GKE 集群配置和应用程序。

→使用 Git 仓库作为清单的单一事实来源。在 GKE 集群中安装 Config Sync，以持续协调集群状态与仓库中的配置。

原因: GitOps 提供了一种可审计、版本控制和自动化的方式来管理 Kubernetes。它将 CI（构建工件）与 CD（同步状态）分离。

防止部署具有严重漏洞的容器镜像。

→在 Artifact Registry 中启用自动漏洞扫描。在 Cloud Build 管道中，添加一个步骤，使用 Container Analysis API 检查漏洞，如果发现严重问题则使构建失败。

原因: 这在 CI 管道中创建了一个自动质量门，防止易受攻击的工件达到可部署状态。它将安全性“左移”。

在运行时强制执行，只有受信任的、已签名的容器镜像才能部署到 GKE 或 Cloud Run。

→实施 Binary Authorization。创建 attestor（例如，用于通过漏洞扫描、QA 签核）。配置 CI 管道以创建证明。在 GKE/Cloud Run 上强制执行策略，要求部署时提供特定的证明。

原因: Binary Authorization 在部署时提供强大的、基于策略的强制执行。它可防止部署受损或未经审查的镜像，即使它们已进入注册表。

参考↗

在 Cloud Build 运行期间访问敏感信息（如 API 密钥或密码），而不会将其暴露在日志或源代码中。

→将密钥存储在 Secret Manager 中。在 `cloudbuild.yaml` 中，使用 `availableSecrets` 字段将密钥作为环境变量或文件挂载。

原因: 这是原生、安全的集成。Cloud Build 处理身份验证并自动从日志中编辑密钥值，防止意外暴露。

建立软件工件的可验证保管链，以确保它们由受信任的系统从受信任的源代码构建。

→使用 Cloud Build 生成 SLSA 兼容的出处证明。将这些证明与镜像一起存储在 Artifact Registry 中。在部署前使用 Binary Authorization 验证出处。

原因: SLSA 提供了一个强化软件供应链的框架。这种工具组合提供了从源代码到生产的端到端、可验证的信任链。

运行需要访问私有 VPC 中资源的 CI/CD 作业，例如私有 Artifact Registry 或 Cloud SQL 数据库。

→创建一个 Cloud Build 私有池，并配置该池网络与您的目标 VPC 之间的 VPC Peering。配置在此池中运行构建。

原因: 私有池提供网络隔离，并允许构建安全地访问私有网络上的资源，而无需将其暴露给互联网。

自动删除旧的或未使用的容器镜像，以管理存储成本，同时保留重要的镜像。

→配置 Artifact Registry 清理策略。对 `production` 和 `latest` 等标签使用 `keep` 策略。根据年龄、标签模式和版本计数，对其他镜像使用 `delete` 策略。

原因: 清理策略提供了一种声明式、自动化的方式来管理镜像生命周期，平衡了成本节约与保留生产和最近开发工件的需求。

自动化从开发到预演再到生产的多阶段部署，每个环境都有批准和不同的策略。

→使用一系列目标（dev、staging、prod）定义单个 Cloud Deploy 交付管道。为生产目标配置 `requireApproval: true`，并为每个目标指定不同的部署策略（例如，金丝雀部署）。

原因: Cloud Deploy 提供托管式、可审计的持续交付服务。它通过集成的审批和回滚简化了金丝雀和蓝绿部署等渐进式交付模式。

定义衡量服务可靠性的指标，从用户的角度出发。

→根据面向用户的关注点定义服务水平指标（SLI）：可用性（成功请求的百分比）、延迟（快于阈值的请求百分比）以及正确性/及时性（正确处理或最新数据的百分比）。

原因: SLI 必须衡量用户满意度，而不是内部服务器健康状况。CPU 利用率等指标是原因，而高延迟是症状。SRE 专注于监控和管理症状。

足够早地收到 SLO 违规通知以进行响应，而不会因轻微的、瞬时问题而被警报淹没。

→根据 SLO 消耗率（错误预算被消耗的速度）配置警报。使用多窗口警报：短期内的高消耗率用于关键页面，长期内的低消耗率用于非紧急工单。

原因: 消耗率警报是预测性的。它根据故障的“速率”发出警报，这表明存在实际问题，而不是单个失败请求，从而减少警报疲劳并专注于重要的事情。

参考↗

通过了解请求的完整生命周期，诊断微服务架构中的延迟问题。

→使用 OpenTelemetry SDK 检测服务，并将 traces 导出到 Cloud Trace。确保 trace 上下文在服务调用之间传播（包括通过 Pub/Sub 等消息队列）。

原因: OpenTelemetry 提供了一个供应商中立的检测标准。Cloud Trace 可视化端到端请求流，使得很容易发现哪个服务或操作是瓶颈。

确保 GKE 中的应用程序日志在 Cloud Logging 中正确解析、可搜索并具有适当的严重级别。

→配置应用程序以 JSON 格式将日志写入 `stdout`/`stderr`。包含一个与 Google Cloud 预期值（例如，“INFO”、“ERROR”）匹配的 `severity` 字段。

原因: GKE 的默认日志代理会自动从 stdout 获取并解析 JSON 日志，使其在 Cloud Logging 中结构化且可查询，而无需 sidecar 或自定义代理。

跟踪、可视化和警报服务的 SLO 合规性和错误预算消耗。

→使用 Cloud Monitoring 的服务监控功能。定义服务，创建 SLI（例如，来自负载均衡器的可用性），设置 SLO 目标，并配置消耗率警报策略。

原因: 此原生功能自动化了 SLO 合规性和错误预算的复杂计算，提供开箱即用的仪表板，并与警报系统集成。

通过关联指标、traces 和日志，快速找到问题的根本原因。

→确保结构化日志中包含 trace ID。在指标图表上使用 Cloud Monitoring 功能（如 trace exemplars），以便在指标异常期间跳转到特定 trace，然后从该 trace 跳转到相关的日志。

原因: 在可观察性三大支柱（指标、日志、traces）之间无缝切换的能力是缩短平均解决时间 (MTTR) 的关键。

为仅在日志数据中可用的应用程序特定事件（如用户注册或支付失败）创建自定义指标和警报。

→在 Cloud Logging 中，创建基于日志的指标。定义一个过滤器以匹配相关的日志条目，并配置指标类型（计数器或分布）。在仪表板和警报策略中使用此自定义指标。

原因: 基于日志的指标允许您将非结构化或半结构化日志数据转换为结构化时间序列数据，从而轻松监控和警报业务级 KPI，而无需更改应用程序代码。

诊断数据库性能问题，例如慢查询，而不会增加数据库负载。

→在 Cloud SQL 实例上启用 Cloud SQL Insights 和 Query Insights。使用仪表板识别高负载查询，分析执行计划，并查看性能趋势。

原因: Query Insights 提供轻量级、无代理的查询性能监控。它帮助 DBA 和开发人员查明低效率的查询，而无需传统分析工具的开销。

从外部角度主动监控关键用户旅程或 API 可用性。

→使用 Cloud Monitoring 正常运行时间检查进行简单的 HTTP/TCP 检查。对于多步骤用户流程（例如，登录、添加到购物车、结账），使用 Synthetic Monitors，它在托管环境中运行自定义脚本（例如，Puppeteer）。

原因: 合成监控模拟真实用户交互，使您能够在用户发现问题之前检测到问题。它从外到内测试整个堆栈。

平衡服务可靠性与发布新功能的需求。

→定义服务水平目标（SLO）（例如，99.9% 的可用性）。剩余的 0.1% 是错误预算。如果预算大部分完好无损，则发布功能。如果预算耗尽，则暂停功能发布并专注于可靠性改进。

原因: 错误预算提供了一个数据驱动的框架来制定风险决策，使工程、产品和业务团队在共同目标上保持一致。

从事故中学习以防止它们再次发生，同时培养心理安全文化。

→事故发生后进行无指责事后分析。将调查重点放在系统性因素、流程漏洞和工具故障上，而不是归咎于个人。输出应为一份可操作的改进项列表。

原因: 无指责文化鼓励诚实和开放的沟通，从而更准确地理解事故的根本原因并采取更有效的预防措施。

有效协调对重大事故的响应，避免混乱和重复工作。

→实施具有明确定义角色的事件指挥系统 (ICS)：事件指挥官（全面协调）、操作主管（技术调查/修复）和通信主管（利益相关者更新）。

原因: ICS 提供了一个标准化、可扩展的事件响应结构，确保清晰的职权和沟通，这对于快速解决复杂问题至关重要。

衡量软件交付组织的绩效。

→跟踪四个关键 DORA 指标：部署频率（多久一次）、变更前置时间（从提交到部署的速度）、变更失败率（导致失败的部署百分比）和服务恢复时间（MTTR）。

原因: 这四个指标提供了开发速度和运营稳定性的平衡视图，并已被证明与高绩效组织相关。

SRE 团队在手动、重复的运营任务（苦差事）上花费了太多时间，没有时间进行工程项目。

→识别并量化最耗时的苦差事。优先处理并自动化这些任务（例如，实施自动扩缩而非手动扩缩，对常见警报进行自动修复）。将苦差事限制在工程师时间的 50% 以下。

原因: 苦差事会降低生产力并影响士气。通过自动化系统地减少苦差事，可以解放工程师，让他们从事长期的可靠性改进工作。

在共享基础设施中，将云成本准确归因于不同的团队、服务或环境。

→实施一致的标签/标记策略。在 Cloud Billing 报告中使用这些标签进行筛选。对于 GKE，启用 GKE 成本分配以按命名空间或工作负载细分成本。

原因: 准确的成本分配提供了可见性，从而推动了问责制。能够看到支出的团队有能力对其进行优化。

优化不同工作负载（稳定、可中断、开发/测试）的计算成本。

→将工作负载与定价模型匹配。对稳定的 24/7 工作负载使用 Committed Use Discounts (CUD)。对容错、可中断的作业（例如，批处理）使用 Spot VMs。安排开发/测试环境在工作时间之外关闭。

原因: 计算定价的一刀切方法效率低下。为作业使用正确的工具可以在不影响性能的情况下显着节省成本（>70%）。

通过确保 pod 请求适当的 CPU 和内存量来优化 GKE 成本和性能。

→以 `recommendation` 模式部署 Vertical Pod Autoscaler (VPA)。分析其建议以调整 pod 资源 `requests`。一旦确定，切换到 `auto` 模式以进行持续的资源大小调整。

原因: 过度预配 pod 会浪费金钱，而预配不足会导致性能问题（节流、OOMKilled）。VPA 使用实际使用数据进行准确的大小调整建议，从而提高效率和稳定性。

减少 Cloud Run 服务因冷启动引起的延迟。

→配置 `min-instances` 值以保持一定数量的实例处于预热状态。此外，优化容器镜像（更小的基础镜像，更少的层）和应用程序启动代码（延迟初始化）。

原因: `min-instances` 是减少冷启动最直接的方法，但它会产生费用。将其与容器和代码优化相结合，提供了性能和成本的平衡方法。

优化具有可变查询模式的大规模 BigQuery 分析工作负载的成本。

→从按需定价切换到 BigQuery Editions（槽位）。为可预测的负载购买基线槽位承诺，并为峰值启用自动扩缩。此外，通过使用分区/集群表并避免 `SELECT *` 来优化查询。

原因: 对于一致的工作负载，基于槽位的定价比按需定价更具成本效益。自动扩缩为突发提供灵活性，同时控制成本。查询和表优化减少了处理的数据量，直接降低了成本。

降低全球分布式应用程序的高网络出站流量成本。

→使用 Cloud CDN 在边缘缓存静态内容，更靠近用户。对于动态流量，选择适当的网络服务层级（Premium 用于性能，Standard 用于成本节约）。在区域内处理数据以最大程度地减少跨区域流量。

原因: 出站流量是主要的成本驱动因素。CDN 从源站分流流量，直接减少出站流量。深思熟虑地使用网络层级和区域数据处理可以显著降低成本。