Google Cloud 架构框架可靠性支柱中的这一原则提供了一些建议，可帮助您设计和运行测试，以便在发生故障时进行恢复。
此原则与可靠性的学习 重点领域相关。
原则概览
为确保您的系统能够从故障中恢复，您必须定期运行测试，包括区域故障转移、版本回滚和从备份恢复数据。
此类测试有助于您练习应对对可靠性构成重大风险的事件（例如整个区域停电）的响应。此类测试还有助于您验证系统在发生中断期间是否会按预期运行。
在极少数情况下，整个区域都可能会宕机，因此您需要将所有流量故障切换到另一个区域。在工作负载正常运行期间，修改数据时，需要将数据从主区域同步到故障切换区域。您需要验证复制的数据始终是最新的，以免用户遇到数据丢失或会话中断的情况。负载均衡系统还必须能够随时将流量转移到故障切换区域，而不会中断服务。为了尽可能缩短区域性服务中断后的停机时间，运营工程师还需要能够在最短的时间内手动高效地将用户流量从某个区域转移出去。此操作有时称为清空区域，这意味着您会停止向该区域发送入站流量，并将所有流量移至其他位置。
建议
在设计和运行失败恢复测试时，请考虑以下子部分中的建议。
定义测试目标和范围
明确定义您希望通过测试实现的目标。例如，您的目标可以包括：
- 验证恢复时间目标 (RTO) 和恢复点目标 (RPO)。如需了解详情，请参阅DR 规划的基础知识。
- 评估系统在各种故障场景下的弹性和容错性。
- 测试自动故障切换机制的有效性。
确定测试范围涵盖哪些组件、服务或区域。范围可以包括特定的应用层（例如前端、后端和数据库），也可以包括特定的 Google Cloud 资源，例如 Cloud SQL 实例或 GKE 集群。该范围还必须指定所有外部依赖项，例如第三方 API 或云互连。
准备测试环境
选择合适的环境，最好是复制生产环境设置的预演环境或沙盒环境。如果您在生产环境中进行测试，请确保已准备好安全措施，例如自动监控和手动回滚流程。
创建备份方案。请为关键数据库和服务创建快照或备份，以防止测试期间数据丢失。确保您的团队准备好在自动故障切换机制失败时进行手动干预。
为防止测试中断，请确保正确设置 IAM 角色、政策和故障切换配置。验证测试工具和脚本是否已获得必要的权限。
告知运营、DevOps 和应用所有者等利益相关方测试时间表、范围和潜在影响。向利益相关方提供预计时间表和测试期间的预期行为。
模拟故障场景
使用 Chaos Monkey 等工具规划和执行故障。您可以使用自定义脚本来模拟关键服务故障，例如多区域 GKE 集群中的主节点关闭或 Cloud SQL 实例处于停用状态。您还可以根据测试范围，使用防火墙规则或 API 限制来使用脚本模拟整个区域的网络中断。逐步升级失败场景，以观察各种条件下的系统行为。
引入负载测试和故障场景，以重现停机期间的实际使用情况。测试级联故障的影响，例如当后端服务不可用时前端系统的行为方式。
如需验证配置更改并评估系统对人为错误的弹性，请测试涉及错误配置的场景。例如，使用不正确的 DNS 故障切换设置或不正确的 IAM 权限运行测试。
监控系统行为
监控负载平衡器、健康检查和其他机制如何重新路由流量。使用 Google Cloud 工具（例如 Cloud Monitoring 和 Cloud Logging）在测试期间捕获指标和事件。
观察故障模拟期间和之后的延迟时间、错误率和吞吐量变化，并监控整体性能影响。找出用户体验中的任何降级或不一致之处。
确保为关键事件（例如服务中断或故障转移）生成日志并触发提醒。您可以使用这些数据来验证提醒和突发事件响应系统的有效性。
针对 RTO 和 RPO 验证恢复情况
衡量系统在发生故障后恢复正常运行所需的时间，然后将此数据与定义的 RTO 进行比较，并记录任何差距。
确保数据完整性和可用性符合 RPO 要求。如需测试数据库一致性，请比较数据库在失败前后快照或备份。
评估服务恢复情况，并确认所有服务都已恢复为正常运行状态，尽可能减少对用户的影响。
记录和分析结果
记录每个测试步骤、失败场景和相应的系统行为。请添加时间戳、日志和指标，以便进行详细分析。
突出显示测试期间观察到的瓶颈、单点故障或意外行为。为帮助确定修复优先级，请按严重程度和影响对问题进行分类。
建议改进系统架构、故障切换机制或监控设置。根据测试结果，更新所有相关的故障切换政策和策略方案。向利益相关方提交问题排查报告。该报告应总结成效、经验教训和后续步骤。如需了解详情，请参阅进行全面的事故分析。
迭代和改进
为了验证持续的可靠性和弹性，请规划定期测试（例如，每季度进行一次）。
在不同的场景（包括基础架构更改、软件更新和增加的流量负载）下运行测试。
使用 CI/CD 流水线将可靠性测试集成到开发生命周期中，从而自动执行故障切换测试。
在问题排查期间，利用利益相关方和最终用户的反馈来改进测试流程和系统弹性。