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