云服务中断的影响范围可能从全球性服务故障到局限于特定区域、可用区甚至单一项目或应用。据 Google Cloud 介绍，当怀疑平台故障影响自身服务时，建议遵循“验证→调查→报告→解决→回顾”的结构化工作流。在此之前，团队还需要为环境做好应对准备。
事前准备的四个维度
在故障发生前，可从设计、数据、手册和培训四个方面进行准备：
- 设计：提前规划自动化响应动作，例如负载均衡器将流量从响应缓慢的实例移走，并尽可能将事件响应手册中的步骤自动化。
- 数据：使用 Cloud Logging、Cloud Trace、Cloud Monitoring 或第三方可观测性工具，并将这些数据复制到与被观测系统物理隔离的冗余栈中。确保各可观测性数据流的时间戳已同步，以便快速关联。
- 手册：记录清晰的事件响应流程，明确所有角色的职责、通知与动员方式、可用工具以及长时间运行事件的交接班机制，并通过模拟演练检验每一步骤。
- 培训：每年多次组织跨团队模拟事件响应演练，帮助人员熟悉流程，并通过复盘识别改进点。
验证：确认问题来源
检测到服务中断后，首先需要判断责任方是平台（如代码推送、硬件故障）、自身（如配置变更、负载激增、配额耗尽）还是第三方服务。
如果平台已宣布事件并开始修复，可评估是否能通过切换至备用栈更快恢复服务。确认平台状态可通过以下渠道：
- Personalized Service Health：优先查看。它显示与具体项目和区域相关的事件，区分“新兴事件”（值班人员正在调查，影响未知）和“已确认事件”（已确认客户受影响）。该面板位于控制台中，通常能展示公共仪表板未覆盖的有限范围事件，并提供 Android 和 iOS 移动端。
- Gemini Cloud Assist：与 Personalized Service Health 集成，支持自然语言查询事件信息。
- Cloud Service Health 仪表板：面向公众的非认证页面，仅展示影响广泛且严重的重大事件。若 Personalized Service Health 不可用，可作为基于独立基础设施的替代渠道。
- 已知问题（Known Issues）：在控制台的支持工单中使用资源选择器定位特定云资源，若匹配已知问题可关联工单以接收自动更新；若不匹配则提交新工单，平台会在宣布相关事件时自动匹配。
如果在多个云平台托管资源，应尽早检查问题是否同时出现在多个提供商处。若是，问题很可能出在自身或交互的第三方服务上。
调查：确定影响范围
对于平台已宣布的可靠性事件，先查阅 Personalized Service Health 更新中的技术问题描述，据此映射影响范围并决定应急措施。
若平台未宣布事件，需排查自身环境：
- Cloud Monitoring：检查仪表板中错误率（如 5xx 错误）飙升、延迟增加或流量下降的情况。
- Cloud Logs：使用 Log Explorer 查找
DEADLINE_EXCEEDED、SERVICE_UNAVAILABLE等特定错误信息。 - 配额：确认是否触及项目配额上限（如 CPU、API 速率限制），这类情况常表现出类似故障的症状。
- 变更历史：检查近期应用的变更记录及平台更新日志。时间线上的接近性是因果关系的有力指标。如果没有明确的攻击或流量激增原因，且症状在变更后立即出现，可考虑回滚该变更并恢复到上一个已知良好的配置。
报告：提交支持工单
当健康状态仪表板显示正常但自身指标表明存在故障时，需要向平台报告。首先确定优先级：P1（严重）表示生产服务不可用或受严重影响且无变通方案；P2（高）表示有显著影响或降级，但可能存在变通方案。
在控制台创建工单时，需说明可量化的业务影响以支撑所提交的优先级，防止被重置。工单应包含项目 ID 及受影响区域、带明确时区的起止时间戳、具体错误信息或日志片段，以及影响范围（全部用户还是特定子集）。
拥有 Premium 或 Enhanced 支持计划的客户，如果 P1 工单未获得足够关注，可使用工单内的 Escalate 按钮提醒支持经理介入。
解决与回顾
在等待问题解决期间，应通知利益相关者和客户以保持透明，若有跨区域架构可考虑将流量转移至健康区域（前提是确认中断发生在基础设施层面而非工作负载层面）。同时关注平台在服务健康仪表板中发布的临时变通方案，并确认组织是否需要满足监管报告的时限要求。Premium Support 客户还可请求针对自身账户定制的 Incident Summary。
当系统稳定后，平台会降级严重程度并停用值班升级链。只有在采取覆盖所有受影响客户的缓解措施后，事件才会在 Personalized Service Health 中关闭；公共仪表板则在系统稳定运行指定时长后正式关闭事件。此时需再次验证自身服务是否正常运行。
运营恢复正常后，应进行“无指责”的事后分析，探讨哪些环节表现良好、哪些可以改进、哪些依赖了运气，并据此调整手册、工具和培训计划。平台通常会为重大故障发布事后分析报告或 Incident Report，可用于了解根本原因并优化自身的灾难恢复计划。