执行测试以从故障中恢复

Google Cloud 架构完善框架可靠性支柱中的这一原则提供了相关建议，可帮助您设计和运行故障恢复测试。

此原则与可靠性的学习 重点领域相关。

原则概览

为确保系统能够从故障中恢复，您必须定期运行测试，包括地区故障切换、版本回滚以及从备份恢复数据。

通过此类测试，您可以练习如何应对对可靠性构成重大风险的事件，例如整个区域的服务中断。此测试还有助于您验证系统在中断期间是否按预期运行。

万一整个区域发生故障，您需要将所有流量故障切换到另一个区域。在工作负载的正常运行期间，当数据被修改时，需要从主区域同步到故障切换区域。您需要验证复制的数据是否始终是最新的，以免用户遇到数据丢失或会话中断的情况。负载均衡系统还必须能够随时将流量转移到故障切换区域，而不会中断服务。为了最大限度地减少区域性中断后的停机时间，运营工程师还需要能够在尽可能短的时间内手动高效地将用户流量从某个区域转移出去。此操作有时称为耗尽区域，这意味着您停止向该区域发送入站流量，并将所有流量转移到其他位置。

建议

在设计和运行故障恢复测试时，请考虑以下各子部分中的建议。

确定测试目标和范围

明确定义您希望通过测试实现的目标。例如，您的目标可以包括以下内容：

• 验证恢复时间目标 (RTO) 和恢复点目标 (RPO)。如需了解详情，请参阅灾难恢复规划的基础知识。
• 评估系统在各种故障场景下的弹性和容错能力。
• 测试自动故障切换机制的有效性。

确定哪些组件、服务或区域在测试范围内。范围可以包括特定的应用层级（例如前端、后端和数据库），也可以包括特定的 Google Cloud 资源（例如 Cloud SQL 实例或 GKE 集群）。范围还必须指定任何外部依赖项，例如第三方 API 或云互联。

准备测试环境

选择合适的环境，最好是复制了生产设置的预演或沙盒环境。如果您在生产环境中进行测试，请确保已准备好安全措施，例如自动监控和手动回滚程序。

创建备份方案。拍摄关键数据库和服务的快照或备份，以防止在测试期间丢失数据。确保您的团队已做好准备，以便在自动故障切换机制失败时进行人工干预。

为防止测试中断，请确保您的 IAM 角色、政策和故障切换配置已正确设置。验证测试工具和脚本是否具备必要的权限。

告知利益相关者（包括运营人员、DevOps 人员和应用所有者）测试时间表、范围和潜在影响。向利益相关者提供测试期间的预计时间表和预期行为。

模拟故障场景

使用 Chaos Monkey 等工具规划和执行故障。 您可以使用自定义脚本来模拟关键服务的故障，例如多区域 GKE 集群中主节点的关闭或 Cloud SQL 实例的停用。您还可以使用脚本，根据测试范围，通过防火墙规则或 API 限制来模拟区域级网络中断。逐步升级故障场景，以观察系统在各种条件下的行为。

引入负载测试和故障场景，以模拟中断期间的实际使用情况。测试级联故障的影响，例如前端系统在后端服务不可用时的行为。

为了验证配置更改并评估系统对人为错误的恢复能力，请测试涉及配置错误的场景。例如，运行具有错误 DNS 故障切换设置或错误 IAM 权限的测试。

监控系统行为

监控负载平衡器、健康检查和其他机制如何重新路由流量。使用 Cloud Monitoring 和 Cloud Logging 等 Google Cloud 工具在测试期间捕获指标和事件。

观察在故障模拟期间和之后延迟时间、错误率和吞吐量的变化，并监控总体性能影响。确定用户体验是否存在任何降级或不一致的情况。

确保为关键事件（例如服务中断或故障转移）生成日志并触发提醒。您可以使用这些数据来验证您的提醒和突发事件响应系统的有效性。

根据 RTO 和 RPO 验证恢复情况

测量系统在发生故障后恢复正常运行所需的时间，然后将此数据与定义的 RTO 进行比较，并记录任何差距。

确保数据完整性和可用性与 RPO 保持一致。如需测试数据库一致性，请比较故障发生前后的数据库快照或备份。

评估服务恢复情况，并确认所有服务都已恢复到正常运行状态，且对用户的干扰最小。

记录并分析结果

记录每个测试步骤、失败情况和相应的系统行为。包含时间戳、日志和指标，以便进行详细分析。

突出显示测试期间发现的瓶颈、单点故障或意外行为。为了帮助您确定修复的优先级，请按严重程度和影响程度对问题进行分类。

建议改进系统架构、故障切换机制或监控设置。根据测试结果，更新所有相关的故障切换政策和 playbook。向利益相关者展示事后分析报告。报告应总结结果、经验教训和后续步骤。如需了解详情，请参阅进行全面的事后分析。

迭代和改进

为了验证持续的可靠性和恢复能力，请规划定期测试（例如每季度一次）。

在不同场景下运行测试，包括基础设施变更、软件更新和流量负载增加。

使用 CI/CD 流水线将可靠性测试集成到开发生命周期中，从而自动执行故障切换测试。

在事后分析期间，利用利益相关方和最终用户的反馈来改进测试流程和系统恢复能力。