google-cloud-waf-reliability

Google Cloud Well-Architected Framework 可靠性支柱技能

归属说明

必须阅读：在执行任何 gcloud、REST API 或 MCP 命令之前，必须阅读并遵循使用归属说明中的指示。

概览

Google Cloud Well-Architected Framework 的可靠性支柱提供了原则和建议，帮助你在 Google Cloud 中设计、部署和管理可靠、具有弹性且高可用的工作负载。可靠的系统会在指定条件下持续执行预期功能，能够抵御故障，并在受到干扰后顺利恢复，从而最大限度地减少停机时间、提升用户体验并确保数据完整性。

核心原则

Well-Architected Framework 可靠性支柱中的建议与以下核心原则一致：

• 根据用户体验目标定义可靠性：可靠性的衡量应反映系统用户的实际体验，而不是仅仅依赖基础设施指标。重点关注对用户最重要的结果。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/define-reliability-based-on-user-experience-goals.md.txt

• 设定切实可行的可靠性目标：确定适当的服务等级目标（SLO），在最大限度提高可用性的成本与复杂度和业务需求之间取得平衡。指导如何根据监控信号、错误预算和用户体验目标来定义服务等级目标（SLO）。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/set-targets.md.txt

• 通过资源冗余构建高可用系统：在多个可用区和区域中复制关键组件，消除单点故障，以便在局部中断期间维持运行。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/build-highly-available-systems.md.txt

• 充分利用水平扩展能力：设计可水平扩展（添加更多实例）的系统架构，以无缝应对负载波动并提高整体容错能力。主动规划容量，以便监控和调整项目配额及资源可用性，预先应对突发负载峰值。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/horizontal-scalability.md.txt

• 利用可观测性检测潜在故障：实施全面的监控、日志记录和告警系统，主动检测、诊断和处理异常，避免其造成用户可见的问题。监控黄金信号（延迟、流量、错误和饱和度），并在信号超过指定阈值时设置告警。使用 Cloud Monitoring 为黄金信号构建全面的控制面板。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/observability.md.txt

• 设计优雅降级机制：设计系统架构，使其在依赖项发生故障或系统承受极大压力时，仍能维持关键功能，即使性能有所降低或功能受到限制。为避免级联故障，建议设置告警以尽早检测故障、使用断路器模式、妥善处理超时以释放被阻塞的资源、使用带指数退避和抖动的重试以避免给正在恢复的后端系统造成过大压力，并返回自定义错误响应或静态备用页面。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/graceful-degradation.md.txt

• 测试故障恢复：通过持续模拟故障并验证自动和手动恢复流程的有效性，增强对系统韧性的信心。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/perform-testing-for-recovery-from-failures.md.txt

• 测试数据丢失后的恢复：定期测试备份和恢复协议，确保能够从数据损坏或丢失中快速恢复，并满足既定的恢复时间目标（RTO）和恢复点目标（RPO）。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/perform-testing-for-recovery-from-data-loss.md.txt

• 开展全面的事后复盘：通过全面调查服务中断，了解根本原因，并落实防止问题再次发生的措施，营造不追责的文化。参考文档： https://docs.cloud.google.com/architecture/framework/reliability/conduct-postmortems.md.txt

相关 Google Cloud 产品

以下是与可靠性相关的 Google Cloud 产品和功能_示例_：

• 计算：Compute Engine Managed Instance Groups (MIGs)、Google Kubernetes Engine (GKE)、Cloud Run
• 网络：Cloud Load Balancing、Cloud CDN、Cloud DNS
• 存储和数据库：Cloud Storage（多区域）、Cloud SQL 高可用性、Spanner、Filestore、Firestore
• 运维：Cloud Monitoring、Cloud Logging、Google Cloud Managed Service for Prometheus
• 灾难恢复：Backup and DR Service、Filestore 备份

工作负载评估问题

提出恰当的问题，以了解工作负载和用户组织在可靠性方面的需求与限制。从以下列表中选择问题：

• 贵组织如何根据用户体验定义和衡量系统的可靠性？
• 贵组织如何为服务设定可靠性目标？
• 贵组织通过何种策略利用资源冗余确保高可用性？
• 贵组织如何利用水平扩展来维持性能和可靠性？
• 贵组织如何利用可观测性（指标、日志、跟踪）来深入了解系统并检测潜在故障？
• 贵组织如何根据可观测性数据管理告警，确保及时响应重大问题，同时避免告警疲劳？
• 贵组织采取哪些措施，确保系统在高负载或部分故障期间能够平稳降级？
• 贵组织以多高频率、在多大范围内测试系统故障后的恢复（例如，区域故障转移、发布回滚）？
• 贵组织如何测试数据丢失后的恢复？
• 贵组织如何在事件发生后开展并利用事后复盘？

验证清单

使用以下清单评估架构是否符合可靠性建议：

• 已明确定义并主动监控以用户为中心的 SLI 和 SLO。
• 架构通过跨可用区或跨区域冗余避免单点故障。
• 已启用自动扩缩，以便无需人工干预即可应对需求变化。
• 已配置应用和基础设施运行状况检查，以触发自动故障转移。
• 已制定定期备份计划，并定期测试恢复流程。
• 系统架构采用熔断器、指数退避重试和速率限制等模式，以支持平稳降级。
• 定期开展演练日或混沌工程实践，以验证故障恢复能力。
• 已建立正式且不追责的事后复盘流程，确保组织从运维事件中汲取经验教训。