总结： Azure Chaos Studio通过在影响生产之前模拟中断、故障转移、网络中断和基础架构故障，帮助组织验证应用程序弹性。在测试弹性之前，您无法确定您的应用程序是否具有弹性。学习它不是通过在测试环境中故意破坏它并观察它的反应，而是通过生产中的失败。
Azure Chaos Studio是我们的托管服务，可以安全、有目的地做到这一点。如今， Azure Chaos Studio Workspaces处于公开预览状态：一种以场景为中心的方法，可让您测试Azure客户在生产中实际看到的故障模式。我们一直在努力使工作区易于使用，并提供广泛的故障支持和反映真实中断的命名方案，而不是孤立的故障。
探索Azure Chaos Studio工作区为什么设计弹性还不够Azure客户投资弹性设计：多区域部署、地理冗余存储、自动数据库故障转移、重试逻辑、负载平衡前端。然而，真正的问题是事件何时开始：当故障到达时，这些机制是否在您假设的时间内恢复您的应用程序？
真正的停电不会读取架构图。区域冗余部署可能会失败，因为运行状况探测器在几年前配置错误。具有自动故障转移的数据库可能会使应用程序停止运行，因为连接字符串被硬编码到单个区域。地域冗余存储可能会短暂产生意想不到的陈旧读取应用程序代码。这些错误很常见，只有在发生故障时才会出现。
Azure上的可靠性和弹性是共同的责任。Microsoft负责Azure服务中内置的平台和弹性。客户有责任配置这种弹性以及使用它的代码。没有层可以弥补另一层的缺口。