Google PCA: 运维、可观测性与平台自动化 — 学习指南

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

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

概览

Google Cloud 上的运营、可观测性和平台自动化可确保服务是可诊断、可维护并能持续改进的，同时还能控制安全性和成本。一个内聚的设计涵盖了日志记录、指标、跟踪、可审计性、运行手册、事件响应、配额与容量治理以及自动化。其目标是获得与服务水平目标 (service-level objectives) 挂钩的、可操作的、低噪声信号，并结合确定性自动化来减少重复性工作 (toil) 和配置漂移。

日志记录和可审计性

Cloud Logging 集中管理来自 Google Cloud 服务、GKE 和虚拟机的日志。推荐使用结构化日志 (JSON)，并为 request_id、user_id、service、version、latency_ms 和 severity 使用一致的键；结构化数据有助于实现精确查询、基于日志的指标和策略评估。在虚拟机和 GKE 节点上，安装 Ops Agent (首选) 或旧版 logging agent 来收集系统和应用日志；确保解析器为您的框架生成 JSON 格式。

• 日志存储桶和保留期：使用区域级日志存储桶以满足数据驻留要求和使用 CMEK。默认存储桶包括 _Default 和 _Required；后者用于存储 Admin Activity、System Event 和 Policy Denied 审计日志，并具有固定的长期保留期。为每种数据类别 (例如，应用、安全、分析) 创建专用存储桶，并配置定制的保留期和 CMEK。更长的保留期有助于取证，但会增加成本；当不需要在 Logging 中保留时，可导出以进行长期归档。

• 日志接收器和导出：使用 Log Router 通过接收器将日志路由到 BigQuery (用于分析)、Pub/Sub (用于 SIEM 或流水线) 和 Cloud Storage (用于归档)。使用 BigQuery 分区表来管理数据量和成本。始终授予接收器服务账号对目标的最小权限写入访问权限，以避免静默失败。不要将导出的日志重新注入 Logging，以避免路由循环。

• 查询和基于日志的指标：使用 Logs Explorer，并通过 logName、resource.type、severity、labels 和 jsonPayload 字段进行筛选。为错误率 SLI 和延迟直方图派生基于日志的指标 (计数器或分布)，以支持告警。通过规范化高方差字段来控制基数。

• Cloud Audit Logs：Admin Activity (控制平面写入)、Data Access (用户数据读/写)、System Event 和 Policy Denied 日志提供了管理层面的可观测性。Data Access 日志量很大，在许多服务中默认禁用；仅在需要时启用，并将其路由到具有适当保留期和 CMEK 的存储桶。Policy Denied 日志有助于及早发现权限和组织策略违规。确保监管隔离：安全团队通常拥有并访问审计日志，而其他团队的视图则受限。

• 故障模式和权衡：

  • 过于宽泛的接收器会导致 BigQuery 成本激增；应精确筛选并设置分区过期。
  • 高基数的 JSON 字段 (例如，完整的 URL) 会降低查询性能；应进行清理并提取规范化的标签。
  • 保留期不足会影响调查；导出到 GCS 或 BigQuery 可缓解此问题。
  • Agent 缺失或解析器配置错误会导致日志静默丢失；应对 Agent 心跳和注入错误设置告警。

示例：创建一个具有自定义保留期的区域级日志存储桶，并导出一个经过筛选的审计接收器。

• gcloud logging buckets create app-logs –location=us-central1 –retention-days=30
• gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT/datasets/audit –log-filter=“logName:cloudaudit.googleapis.com AND protoPayload.serviceName:*” –use-partitioned-tables

监控、跟踪和应用诊断

Cloud Monitoring 收集系统和应用指标，支持仪表盘、告警、正常运行时间检查、通知渠道和服务水平目标。

• 指标和仪表盘：使用 Google 服务的内置指标，并通过 Cloud Monitoring API 或 OpenTelemetry 创建自定义指标。重点关注四个黄金信号：延迟、流量、错误、饱和度。审慎应用标签；避免使用无边界的标签值。使用 Metrics Scope 聚合多项目视图。在需要时使用 MQL 进行富有表现力的查询。

• 告警和通知渠道：为 SLO 实施多窗口、多消耗率 (multi-burn-rate) 告警，以平衡快速检测和降噪。定义通知渠道 (电子邮件、短信、Pub/Sub、webhook、第三方事件工具)，并在告警文档中包含运行手册链接和上下文。使用通知速率限制和事件自动关闭功能来防止告警风暴。

• 正常运行时间检查：从多个区域探测关键端点，并进行 TLS 验证、DNS 和内容匹配。将正常运行时间检查与告警和服务 SLO 挂钩。请注意，正常运行时间检查不验证内部依赖项；应通过综合性事务和内部健康检查来补充。

• SLO 和 SLI：为可用性、延迟和正确性定义 SLI。在 Cloud Monitoring Service Monitoring 中配置 SLO 并跟踪错误预算。针对预算消耗而非原始错误进行告警，以与客户影响保持一致。使用发布门禁或渐进式交付来确保不超出剩余的错误预算。

• Cloud Trace、Error Reporting、Profiler：使用 OpenTelemetry 在服务间进行分布式跟踪，以使用请求和依赖元数据来注解 span。按服务和路径动态调整采样率，以确保覆盖关键流程，同时控制成本。Error Reporting 会自动聚合日志中的异常，按堆栈跟踪去重，并触发通知。Profiler 以低开销在生产环境中提供持续的 CPU、堆和墙钟时间 (wall-time) 分析；用它来消除热点路径并降低成本。

• 故障模式和权衡：

  • 指标基数过高会增加成本并减慢查询速度；在发出前进行聚合。
  • 低跟踪采样率会隐藏尾部延迟问题；对慢速路径以更高的速率进行采样。
  • 未校准的 SLO (例如，过于严格) 会导致告警疲劳；应使用真实流量数据进行迭代。
  • 正常运行时间检查可能通过，但内部依赖项却已失败；应使用感知依赖项的 SLO。

平台运维、运行手册和事件管理

严谨的运维可以缩短发现、缓解和学习的平均时间。

• 运行手册与上报机制：每个警报都必须链接到一个确定性的运行手册，其中包含前置条件、诊断步骤、回滚方案和沟通模板。定义清晰的值班轮换和上报策略。将运行手册存储在版本控制系统中并进行测试。

• 事件管理与事后复盘：使用标准化的严重性级别、角色（事件指挥官、沟通、运维、SME）和渠道。优先使用 ChatOps 和状态页面进行广播。撰写无指责文化的事后复盘，记录时间线、促成因素、检测差距、客户影响以及与负责人和日期绑定的具体跟进行动。

• 配额管理与容量信号：通过对使用率设置警报来监控 Service Usage 和 serviceruntime 配额指标。主动申请提高配额，并将自动扩缩容的限制与配额对齐。使用 CPU、内存、文件描述符、连接池和队列深度等容量信号。对于 GKE，调整 HPA/VPA 和集群自动扩缩容器；对于 GCE MIGs，在适当情况下设置冷却时间和预测性自动扩缩容。

• 服务健康与故障排查：结合使用 Logs Explorer 实时尾随、基于日志的指标、仪表盘和 Trace 来降低 MTTD。启用 VPC Flow Logs 和 Firewall Rules Logging 进行网络分诊；使用虚拟机串行控制台处理启动失败问题。将抓包和内核跟踪作为运行手册中的紧急破窗程序。

• 故障模式：

  • 配额耗尽看起来像服务中断；在使用率达到 80% 时发出警报，并对上游进行速率限制。
  • 未经预热的自动扩缩容会导致冷启动；为关键路径使用最小副本数。
  • 缺乏综合监控会掩盖客户可见的故障；实施金丝雀事务。

自动化、资源清单、策略与漂移

以最小权限和幂等性原则，实现可重复任务的自动化。

• 工具：使用 Cloud Shell 进行安全的、临时性的管理员操作，其 $HOME 目录是持久化的；将辅助二进制文件放在 ~/bin 中以实现 PATH 持久性。使用 gcloud、REST API 和客户端库进行自动化。使用服务账号和工作负载身份来消除长期有效的密钥。

• 调度器和编排器：使用 Cloud Scheduler 按 cron 计划触发 HTTP 和 Pub/Sub 作业。使用 Workflows 来编排多服务自动化，支持重试、退避、补偿和超时。确保操作的幂等性，并在日志中添加关联 ID。

• 常规自动化示例：

  • 每日将资产导出到 GCS 和 BigQuery，用于生成清单和漂移报告。
  • 自动计算 SLO 消耗率并发布到仪表盘。
  • 针对组织策略和 IAM 异常情况，进行定期的策略评估。

• 资源清单和策略评估：Cloud Asset Inventory 提供资源、IAM 绑定和组织策略的时间点快照和实时变更 Feed。将其导出到 BigQuery 进行历史分析和漂移检测；订阅 Pub/Sub 以近实时地对策略违规进行分类处理。使用 Policy Analyzer 和 Recommender 来检测过于宽泛的 IAM 权限和未使用的权限。使用 Organization Policy 强制执行约束，并使用策略即代码 (policy-as-code) 在部署前验证配置。

• 配置漂移：通过声明式 IaC 和持续验证来防止漂移。检测到漂移后，要么自动协调，要么隔离资源。为资源打上来源标签（例如，deployment_id）以区分托管资源和临时资源。

• 用于安全性、可靠性和成本的可观测性架构：

  • 安全性：将审计日志路由到受 CMEK 保护且访问受限的存储桶；导出到一个专用的安全项目。通过 Pub/Sub 集成 SIEM。
  • 可靠性：基于 SLI 和跟踪数据驱动仪表盘和告警；使用 Workflows 演练事件自动化流程。
  • 成本：控制指标基数，按存储桶调整日志保留策略，对 BigQuery 导出进行分区，并使用 Profiler 优化热路径。

示例：安排每日资产导出并执行一个工作流。

undefined

undefined

实际问题场景

Contoso Commerce 正在启动一个基于 GKE 的多区域结账平台。需求：可审计的管理、由 SLO 驱动且噪声最小的告警、端到端请求追踪、每晚自动化的合规性清单以及严格的成本控制。

方法：

1. 建立日志记录和审计基础

• 为应用、安全和分析日志创建带有 CMEK 的区域性日志存储桶；应用日志保留 30 天，安全日志按要求保留 400 天以上。将 Admin Activity、System Event 和 Policy Denied 日志路由到安全存储桶；仅为支付服务启用 Data Access 日志。
• 理由：按敏感度隔离可减少爆炸半径和成本；CMEK 满足合规性要求；限定 Data Access 日志范围可避免流量激增。

2. 实现结构化的应用日志记录和采集

• 在 GKE 节点上部署 Ops Agent，并使用 sidecar/daemonset 采集器将应用日志以结构化 JSON 格式发送，其中包含关联 ID（trace_id, span_id）以及经过 PII 脱敏处理的用户/会话标签。
• 理由：结构化日志支持精确查询、基于日志的指标以及与跟踪数据的关联；关联 ID 支持分布式诊断。

3. 部署分布式追踪、错误聚合和性能剖析

• 使用 OpenTelemetry SDK 对微服务进行插桩，将数据导出到 Cloud Trace；为结账和支付路径设置更高的采样率。为所有运行时启用 Error Reporting，并为 CPU/内存密集型服务启用 Profiler。
• 理由：跟踪数据能按服务跳数定位延迟；Error Reporting 对堆栈跟踪进行分组以加速分类处理；Profiler 可降低计算成本和尾延迟。

4. 定义 SLI/SLO 并配置告警和仪表盘

• 定义 SLI：p90 和 p99 的结账延迟、结账 API 的可用性以及支付成功率。设置 SLO（例如，99.9% 的可用性，p99 延迟低于 800 毫秒）。配置消耗率告警（1 小时内消耗 2% 和 6 小时内消耗 1%），并附上运行手册链接和 PagerDuty 渠道；构建展示黄金信号和错误预算趋势的仪表盘。
• 理由：基于错误预算的告警与客户影响挂钩，可减少噪声；仪表盘提供运营态势感知。

5. 添加外部和内部健康检查

• 为结账端点配置带内容验证的多区域正常运行时间检查；为购物车到支付流程添加综合交易检查。集成 GCLB 和 GKE 的就绪探针 (readiness probes)。
• 理由：正常运行时间检查验证面向客户的可用性；综合流程检测依赖项中断。

6. 自动化清单、策略监控和漂移检测

• 创建一个安全项目，用于接收 Cloud Asset Inventory 到 GCS 和 BigQuery 的导出；为 IAM 和组织策略变更启用实时 Pub/Sub Feed。每晚运行 Workflows，将期望状态清单与当前资产进行比较；对低风险漂移创建工单或自动协调。
• 理由：集中式清单支持审计；持续的策略评估防止权限蔓延；自动化抑制漂移。

7. 管控配额和容量

• 监控计算、负载均衡器和 API 配额，在用量达到 70% 和 85% 时发出告警。为目标负载预先申请更高的配额；使 GKE 集群自动扩缩器和 HPA 的限制与配额保持一致。对于启动较慢的、基于 MIG 的服务，启用预测性自动扩缩。
• 理由：配额上限可能伪装成服务中断；主动调整和对齐的自动扩缩可防止峰值下的节流。

8. 优化可观测性成本

• 按存储桶限制日志保留时间，通过 Log Router 过滤器在生产环境中排除详细的调试日志，并仅将必要字段导出到 BigQuery 并设置分区过期。限制指标标签的基数；利用 Profiler 的发现来缩减热点服务的规模。
• 理由：可观测性应具成本效益；有针对性的保留和导出可防止开销失控。

9. 准备运行手册和事件演练

• 为每个告警策略编写版本化的运行手册，包括诊断查询、跟踪过滤器、回滚命令和沟通方案。运行攻防演练日 (Game Day) 来验证上报流程和自动化。
• 理由：确定性的、经过演练的响应可降低 MTTR 并提高可靠性。

10. 验证和迭代

• 根据真实流量持续审查告警噪声、调整阈值并优化 SLO。跟踪事后复盘的行动项，明确负责人和截止日期，直至完成。
• 理由：通过可衡量的反馈来改进可观测性和运营，从而减少重复性的人工操作并随着时间的推移提高服务质量。

← 迁移、现代化与混合云策略 · 所有领域 · DevOps、交付工程与基础设施即代码 →

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

浏览 Google →