Google PCD: 可观测性、调试和网站可靠性运维 — 学习指南

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

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

追踪、错误和深度诊断

分布式追踪

• 追踪上下文 (Trace context)。优先使用 W3C trace-context (traceparent, tracestate)。为了与 Cloud Trace 互操作，请继续支持 x-cloud-trace-context： x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
• 传播 (Propagation)。在服务、消息队列和异步边界之间转发追踪头；在进行 RPC 或 SQL 调用时捕获新的子 span。上下文丢失会破坏服务地图并增加“未知服务”节点。
• 采样 (Sampling)。平衡成本和保真度；在入口处进行动态的基于头部的采样，并对罕见的慢速请求进行基于尾部的采样，可以提高实用性。

Cloud Trace

• 提供延迟直方图、span 瀑布图和服务地图。对关键子操作（RPC、数据库查询）使用注解 (annotations)。
• 使用 p95/p99 追踪来诊断异常值；注意扇出 (fan-out)、N+1 查询或锁竞争。
• 启用追踪-日志关联，以便点击追踪即可查看其日志。

Error Reporting

• 按堆栈签名自动聚合每个服务/版本的异常。配置服务上下文以避免跨服务混淆。抑制已知的嘈杂错误或将其引导至较低优先级的通知。
• 从异常消息中隐去 PII（个人身份信息）；应记录稳定的错误代码和关联 ID。

Cloud Profiler

• 为支持的运行时提供低开销的持续 CPU/堆分析。比较不同版本和流量水平下的性能剖析，以捕获性能退化。避免将采样伪像解释为精确计数。

Cloud Debugger

• 快照 (Snapshots) 可以在不暂停进程的情况下捕获代码位置的变量。日志点 (Logpoints) 可注入临时日志记录语句。限制访问权限，隐去敏感变量，并将范围限定在非 PII 表达式内。

简短示例：添加 W3C traceparent 并关联日志

• HTTP 传播： traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
• 用于链接到 Cloud Trace 的日志字段： “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

可靠性工程、告警和健康信号

SLI、SLO、SLA 和错误预算

• SLI 衡量用户满意度：可用性、延迟、正确性。为每个关键端点和用户旅程定义 SLI。
• SLO 设定目标，例如，在 30 天内 99.9% 的请求延迟低于 300 毫秒。
• 错误预算量化了允许的不可靠性。将预算用于发布、实验或迁移；如果消耗速率过快，则冻结变更。
• SLA 是对外的承诺；保持 SLO 比 SLA 更严格，以保留余量。

高质量告警设计

• 在可能的情况下，优先选择基于 SLO 和症状的告警，而不是基于原因的告警。
• 使用多窗口、多消耗率告警（例如，5 分钟内消耗 14 倍和 1 小时内消耗 2 倍）来捕获快速和慢速的预算消耗，同时减少噪音。
• 为看门狗 (watchdogs) 添加指标缺失告警（例如，长时间运行作业的心跳）。
• 按严重性路由；对通知进行速率限制；提供指向应急手册 (runbooks) 和仪表板的链接。

健康检查和探针

• 就绪探针 (Readiness checks) 在依赖项就绪前阻止流量；存活探针 (liveness checks) 在进程卡死时触发重启；启动探针 (startup probes) 保护启动缓慢的应用免于过早重启。
• 对于负载均衡的虚拟机，允许来自健康检查器的源 IP 范围，否则流量永远无法到达后端： gcloud compute firewall-rules create allow-lb
  –network prod –allow tcp
  –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
• Kubernetes 示例： readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
• 综合测试 (Synthetic testing)。使用正常运行时间检查和通过 Cloud Scheduler + Cloud Run/Functions 实现的定制化端到端流程，来验证登录、支付或其他关键路径。
• 依赖项监控。跟踪数据库连接饱和度、RPC 错误率、队列积压、出口错误和第三方 SLI。为瞬时的 429/5xx 错误设置带有截断指数退避的重试，并使用幂等性密钥以确保安全。

事件响应、安全意识调试与根本原因分析

事件响应生命周期

• 分类：划分严重等级，指派事件指挥官，并通过预定渠道呼叫待命人员。
• 遏制：应用已知的缓解措施和流量控制（回滚、金丝雀发布、熔断器、速率限制器）。
• 沟通：维护内部作战室，定期更新干系人信息，并在必要时发布面向用户的状态更新。
• 解决与恢复：通过 SLI 验证健康状况；避免过早宣布“警报解除”。
• 事后复盘：无指责地分析时间线、检测差距、促成因素以及包含负责人和截止日期的行动项。跟踪直至关闭。

运行手册

• 包括触发条件、所需上下文、诊断命令、安全缓解措施、回滚步骤和上报路径。链接到仪表盘、日志以及针对特定故障模式的剧本。

配额与容量监控

• 通过 Cloud Monitoring 指标监控服务配额。在利用率达到 70-80% 时自动发出警报，并为计划中的负载测试或产品发布预先申请提升配额。
• 需要跟踪的容量信号：CPU、内存、文件描述符、线程池、数据库连接、自动扩缩容限制和请求队列深度。

在不暴露敏感信息的情况下进行调试

• 在源头对密钥和个人身份信息 (PII) 进行脱敏处理；将密钥集中存储在 Secret Manager 中。对用户标识符使用哈希或令牌化处理。在日志中间件中启用字段级脱敏。
• 通过 IAM 限制对日志、跟踪和调试工具的访问；在适用情况下使用 CMEK 和 VPC Service Controls。
• 在 Debugger 中，禁用大型对象图的收集，并添加条件以避免捕获敏感帧。

跨层根本原因分析

• 运行时：通过 Profiler 将 GC、线程池或 CPU 的峰值与 Trace 中的 p99 延迟关联起来。
• 网络：检查负载均衡器日志、VPC Flow Logs、防火墙日志和 Connectivity Tests 以验证路径。健康检查失败通常是由于缺少防火墙规则或端口错误造成的。
• IAM：审查 Cloud Audit Logs 中的权限拒绝或策略变更；确认服务账号角色和令牌范围。
• 数据：使用 Cloud SQL Insights、Spanner 查询统计信息、Bigtable CPU 和热点 tablet 以及 Storage 错误率来查找热点。对瞬时故障应用带退避的重试，并减少会放大尾部延迟的扇出。
• 使用关联的跟踪 ID 和基于日志的指标将所有信息联系起来；导出到 BigQuery 以在事后分析期间执行多源连接查询。

实践问题场景

Fjord Retail 将一个多服务结账系统迁移到 Google Cloud，使用了 Cloud Run、Cloud SQL、Pub/Sub 和一个外部税务 API。用户报告在闪购期间出现间歇性超时和突发性错误率，待命人员收到大量低信号价值的嘈杂警报。

解决方法：

1. 使用跟踪关联来实施结构化日志记录

• 在所有服务间添加 W3C traceparent 传播，并在所有日志中包含 logging.googleapis.com/trace。理由：端到端的关联使工程师能够从一个缓慢的用户请求迅速定位到具体缓慢的 RPC 或查询及其日志。

2. 创建 Logging 存储桶、设置保留期和导出

• 将 _Default 保留期增加到 90 天，并为欧盟 (EU) 工作负载创建一个区域性存储桶。为 ERROR 和 WARNING 级别的日志添加一个到 BigQuery 的聚合接收器： gcloud logging sinks create bq-prod
  bigquery.googleapis.com/projects/fjord/datasets/ops_logs
  –log-filter=‘severity>=WARNING’ –include-children 理由：充足的热存储保留期有助于调试；BigQuery 可以在不增加热存储成本的情况下实现快速的事件分析。

3. 定义 SLI/SLO 和基于 SLO 的警报

• 可用性 SLI：成功请求数 / 总请求数。延迟 SLI：POST /checkout 的 p95 持续时间。
• SLO：月度可用性 99.9%；95% 的结账操作在 300 毫秒内完成。
• 为结账心跳配置多窗口消耗率警报和指标缺失警报。理由：基于症状的警报可以减少噪音，仅在对用户产生影响时才呼叫待命人员。

4. 设置健康探针和综合检查

• Cloud Run 服务暴露 /ready 和 /healthz 接口。为 /checkout 添加一个全局正常运行时间检查，并在 VPC 中添加一个私有综合作业，使用测试凭据执行完整的结账流程。理由：就绪探针可以防止冷启动的后端接收流量；综合检查可以捕获端到端问题和第三方服务的回归。

5. 启用 Cloud Trace 和 Profiler，并采用带退避的重试机制

• 在适用处安装 Trace/Profiler 代理；启用自动 HTTP 客户端检测和 SQL Span 注释。为税务 API 调用实现带幂等性密钥的截断指数退避。理由：跟踪可以隔离延迟的来源；退避可以减少 429/5xx 错误的放大效应并保护错误预算。

6. 监控容量和配额

• 为 Cloud SQL 连接数、CPU、InnoDB 缓冲池、Pub/Sub 未确认消息数、Cloud Run 并发数和服务配额使用情况添加仪表盘和警报。理由：容量饱和是尾部延迟的一个常见隐藏原因；早期警报可以预防服务中断。

7. 为保护隐私而强化调试过程

• 使用哈希处理的用户 ID，并从错误消息中排除 PII。将 Debugger 的使用限制在生产环境中，并仅使用带脱敏规则的日志点。理由：在遵守数据最小化原则的同时保持可观测性。

8. 构建依赖项监控和熔断器

• 通过自定义指标跟踪外部税务 API 的成功率和延迟；当失败率超过阈值时，触发熔断器切换到缓存的税率。理由：隔离第三方依赖项的故障，并保持核心结账功能的可用性。

9. 准备运行手册和上报路径

• 记录步骤：验证 SLO 仪表盘，检查 Trace 服务地图中的热点链路，审查 Cloud SQL Insights 中的慢查询，验证防火墙和健康检查，并评估配额余量。包括回滚和金丝雀发布程序。理由：一致、快速的响应可以降低 MTTR，并避免临时的、有风险的变更。

10. 事后分析流水线

• 使用 BigQuery 导出的数据来计算每个租户的错误率，并通过跟踪 ID 将日志与跟踪和 Cloud SQL Insights 的数据关联起来。理由：持久化、可查询的历史记录有助于进行准确的 RCA 和制定预防措施。

这个计划提升了信号质量，缩短了检测和解决问题的时间，在流量高峰期间保护了用户体验，并在生产环境中进行调试时强制执行了隐私保护。

← 持续交付、配置和基础设施自动化 · 所有领域 · 性能、可扩展性和弹性工程 →

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

浏览 Google →