Best practices for handling cloud reliability incidents

云可靠性事件处理最佳实践 | Google Cloud 博客

开发者 & 实践者

处理云可靠性事件的最佳实践

2026年9月16日

##### Flemming Christensen

产品经理 & 技术解决方案工程师，Google Cloud

##### 立即体验 Gemini Enterprise

职场人工智能的入口

立即体验

云服务中断可能从全球性服务中断到仅限特定区域、可用区甚至仅限您的项目、工作负载或应用程序的问题。如果您怀疑Google Cloud Platform出现影响服务的故障，建议您遵循“验证→调查→报告→解决→复盘”的结构化工作流程进行处理。在故障发生之前，您还应通过设计容错方案并主动演练恢复服务所需步骤，提前为潜在中断做好环境准备。

在本文中，我们总结了关键的可靠性事件处理最佳实践，帮助您设计并演练可靠性事件响应能力，最大限度降低影响。这并非详尽指南，而是仅针对咨询目的列出最重要的实践要点。请注意，本文不涵盖针对安全事件的其他特定实践。

除了本文涵盖的基础步骤，您可能还希望了解AI代理和工具如何开始改变事件处理方式。在Prodcast播客的这一期中，Google工程师探讨了在站点可靠性工程（SRE）中利用代理式AI的最新趋势，以实现早期问题检测和预防中断。您可以尝试Cloud Assist调查功能，或探索Agent Skills和远程托管MCP服务器，这些工具能帮助您更快定位问题。在深入这些高级技术之前，我们首先聚焦于良好事件处理的基础步骤。

1. 准备

在事情出现异常之前，您应在至少四个维度上投入大量时间进行准备：设计、数据、应对方案和培训。

• 设计：提前规划，通过设计自动化响应措施（如负载均衡器将流量从响应缓慢或无响应的实例转移）来预防未来事件，尽可能自动化事件响应方案中的所有步骤。审查所有关键应用程序的设计，尽可能自动化操作以加速响应和恢复。

• 数据：当发生中断时，拥有即时可用的关键数据可显著提升响应能力。使用Cloud Logging、Cloud Trace和Cloud Monitoring等工具，或第三方可观测性工具，并将这些数据复制到与被监控系统位于不同位置的冗余架构中。在任何事件发生前，确保所有可观测性数据流的时间戳同步以便于关联，或在发生中断时（此时时间至关重要）掌握如何按需实现同步。

• 应对方案：一份经过精心设计的应对方案，详细记录您的事件响应流程，包括为所有角色明确界定职责和任务，是实现高效事件响应的关键。谁负责执行什么任务？对于每种类型的中断，需要通知或调动哪些人员？如何联系他们？有哪些可用的工具和数据？如何传递结果？在长时间事件中，团队如何交接给下一班次？等等。通过进行模拟事件响应演练，并对每个步骤进行批判性审查，找出应对方案中需要澄清的地方。缺乏明确职责会导致缓解措施不可避免地耗时更久。

• 培训：希望服务中断是罕见事件。为了确保员工熟悉并记住应对方法，需每年多次通过跨团队模拟事件响应演练进行复训。对模拟演练的回顾有助于识别需要改进的方面。

2. 验证

尽管您已尽最大努力，但迟早会发生服务中断，您可以通过以下多种机制检测到：

• 可观测性工具（Google 工具或第三方工具）

• 统一维护管理通知（用于计划维护）

• 通过警报策略管理的个性化服务健康通知

• Google 的主动客户监控

现在，您需要确定问题根源以及最终应负责修复问题的主体：

• Google，例如：代码错误、代码部署、硬件故障等

• 您自己，例如：配置更改、负载激增、配额上限等

• 第三方，例如：由其他云提供商托管的目录

如果 Google 已声明事件并开始修复问题，请评估是否有可能通过切换到备用架构（见下表“常见原因”）更快恢复服务。您可以通过以下方式确认 Google 是否已声明事件并提供修复方案：

• 个性化服务健康状态：这是首要检查项。个性化服务健康状态会显示与您的项目和区域特别相关的事件，并区分事件类型：
• 新发事件：Google 收到警报，值班人员正在调查，影响尚不明确
• 确认事件：Google 已调查并确认客户受到影响

个性化服务健康状态位于 Google Cloud 控制台内，通常会显示在公共仪表板上未呈现的有限影响事件。个性化服务健康状态还提供 Android 和 iOS 手机的移动客户端（前提是您能在手机上使用工作 ID 和凭证登录）。

• Gemini Cloud Assist：该工具与个性化服务健康状态集成，因此您可以使用自然语言查询相关信息。

• Cloud Service Health 仪表板：这是面向公众的非认证网页，用于通报影响大量客户的重大严重事件。有限影响范围的中断不会对外公开。其所有内容也可在个性化服务健康状态中找到。如果个性化服务健康状态出现故障，Cloud Service Health 将作为基于独立基础设施的替代渠道提供服务。

• 已知问题：在控制台中，导航至支持 > 问题，查看某个问题，然后使用控制台工具栏上的资源选择器查找您感兴趣的特定云资源。接着点击“已知问题”。如果您的问题与此处列出的某个问题匹配，可以将支持案例链接到该问题，这样您将在案例记录中收到自动更新。如果没有找到匹配项，请创建一个新的支持案例。Google 将在相关事件被声明后，自动将案例匹配到相关事件。

• Google 声明的事件会随着新信息的出现而更新，因此请定期查看，或设置个性化服务健康警报策略，以便每次有新信息时收到通知。

如果您在多个云中托管云资源，一个良好的实践是尽早检查问题是否影响多个云提供商。如果是，问题很可能与提供商无关，而是由您或与您的应用程序交互的第三方服务引起。

3. 调查

要确定 Google 声明的可靠性事件对您云足迹的冲击范围，首先检查个性化服务健康更新，以了解技术问题的描述。知道需要查找的内容将帮助您绘制冲击范围，并更快地决定合适的应急措施。

如果 Google 未声明事件，请通过以下方式排除配置错误或环境内问题：

• 云监控：在仪表板中查找错误率激增（例如 5xx 错误）、延迟增加或流量下降。

• 云日志：使用日志分析器查找特定错误信息，如 DEADLINE_EXCEEDED、SERVICE_UNAVAILABLE 或特定的 API 错误。

• 配额：确保您没有达到项目配额（例如 CPU、API 速率限制），这通常会模仿中断行为。

• 变更历史：检查最近应用的更改日志。并非所有问题都会立即显现，但时间线上的接近性可以成为因果关系的有力指标，即使不是确凿证据。同时检查 Google 是否在症状开始前刚刚发布了更新。请参阅 Cloud Hub 中的统一维护管理界面。

如果没有明确的诱因，例如流量激增或 DDoS 攻击，且症状在部署更改后立即出现，一个好的策略是回滚该更改，并尝试恢复到已知的稳定配置。

4. 报告

如果云服务健康和个性化服务健康仪表板显示绿色，但您的指标显示故障，您必须向 Google 报告。

• 确定优先级：

• P1（关键）：您的生产服务无法使用或受到严重影响，且没有变通方法。

• P2（高）：有显著影响或性能下降，但可能存在变通方法。

• 有关设置优先级和描述问题的指导，请参阅相关指南。

• 创建案例：在控制台中导航至支持 > 问题 > 创建案例。

• 解释可量化的业务影响，以合理说明提交的优先级，并防止在云支持对案例进行优先级排序时被重置。清晰准确的理由非常重要！

• 需要包含的关键信息：

• 项目 ID 和受影响的区域/可用区

• 时间戳（开始时间及是否持续进行）并标明时区

• 具体错误信息或日志片段

• 范围：是否影响所有用户/系统，还是特定子集/位置？

如果您的支持计划是高级版或增强版，且P1案例未获得应有的关注，请在控制台的支持案例中点击“升级”按钮。这将通知支持经理进行调查并解决问题。

5. 解决

通过采取这些步骤，您已经走在解决停机问题的正确道路上。在此期间，以下方法可帮助您减轻停机影响并与受影响的利益相关者沟通：

等待解决方案期间：

• 沟通：通知您的利益相关者和客户。透明度有助于管理预期并减少重复的内部报告。
• 故障转移：如果您采用多区域架构，可考虑将流量切换到健康区域。最佳实践是首先确认中断发生在基础设施层级而非工作负载层级。
• 检查变通方法：在永久修复方案实施期间，Google通常会在服务健康仪表板更新或个性化服务健康更新中发布临时变通方法。
• 考虑监管报告要求：了解您的组织是否受监管报告要求约束，以及初始报告和后续报告的截止时间要求。Google Cloud会为符合特定标准的事件准备事件报告——详见此处如何获取这些报告。高级支持客户还可申请事件摘要，这是根据您账户的具体托管位置、时间戳等信息定制的事件报告。

#### 降级与关闭

当系统恢复稳定后，Google会降低严重性等级并停用主动升级链。Google仅在个性化服务健康中关闭事件，当已采取涵盖所有受影响客户的缓解措施后。如果其他客户的恢复时间晚于您，您的特定服务可能在事件关闭时间前就已恢复。事件在Google Cloud状态仪表板上被正式关闭时，系统已稳定运行预设的自动关闭时长。请在此时确认您的服务是否正常运行。如果您的事件响应人员未因额外时间投入获得补偿，请寻找方式感谢他们。

6. 回顾

在问题解决且运营恢复到正常稳定状态后，是时候进行事后分析，以识别团队未来如何更好地应对服务中断。采用“无责”方法对于发现有意义且有影响力的改进措施至关重要。提出以下问题：

• 哪些方面做得好？
• 我们哪些地方可以做得更好？
• 我们在哪些地方运气不错？
• 我们在哪些地方运气不佳？

然后决定可以对操作手册、工具和培训做出哪些改进。

在Google，我们通常会为重大停机事件发布事后分析或事件报告，可通过个性化服务健康访问。请查阅这些内容以了解根本原因，并调整自己的灾难恢复计划以预防或减少未来影响。拥有高级支持计划的客户可以申请事件摘要，该摘要针对Google引起的事件（您因此事件提交了P1案例）进行定制，包含您的环境信息（例如影响的开始和结束时间）。

典型原因、沟通及预防策略

为帮助您提前准备和规划，以下是一些典型事件的概述，这些事件基于Cloud Service Health和Personalized Service Health中报告的症状，同时提供有关预期Google沟通内容的指导，以及您可以纳入操作手册的通用缓解或预防策略。

影响范围 典型原因 沟通方式 策略

单区域或区域。部分产品。 典型由发布引发的软件问题。学习要点：

• 了解工作负载的位置范围（区域和区域）
• 产品可能依赖于其他产品

重大事件通过Cloud Service Health进行沟通。重大和次要事件（按客户数量，而非严重性）通过Personalized Service Health进行沟通。 高度本地化事件不会通过Cloud Service Health或Personalized Service Health进行沟通。 如果配置了故障转移，请先验证次级堆栈的健康状况。

单区域。大部分或所有产品。 典型为电源或冷却问题。 检查Cloud Service Health和Personalized Service Health。 如果配置了故障转移，请切换到不同区域。

单区域。大部分或所有产品。 典型为骨干网络基础设施问题 如果配置了故障转移，请切换到不同区域。

产品控制平面问题 典型为晚期检测到的问题 如果确认对客户有重大影响，通过Personalized Service Health进行沟通。 寻找变通方法。等待Google修复。如果配置了故障转移，请切换。

具有全球产品的多区域问题 罕见但可能，通常能快速检测到。学习要点：缓解选项可能有限。尝试区域变体，或使用功能相似的替代产品。 等待Google修复。在此期间，通过Google沟通和您自己的调查确认这确实是Google需要修复的问题。

容量/缺货问题 产品/位置/型号的系统级需求超过容量。（云设计用于扩展，但始终存在限制，因此建议做好规划） 错误信息。不会声明事件。 为预测的容量需求预订资源（如果成本可接受）。区域放置的灵活性也有助于缓解。

配额耗尽 流量预测困难或不准确 定期审查消耗趋势与上限的对比。

深入了解

本文仅提供关键点的简明摘要。如果您与Google Cloud有活跃的高级支持合同，请联系您的账户团队，以深入审查您的响应计划。如需全面了解如何构建可靠服务以及如何应对事件，我们强烈推荐Google的SRE书籍，该书可免费下载。SRE书籍的新版本将于2026年10月左右发布，并将在O’Reilly Media上提供购买。我们还在筹备一本未来指南，深入探讨AI支持的事件处理——敬请期待！

发布于

• 开发者与从业者
• DevOps与SRE
• 管理工具
• Google Cloud咨询