https://thedotnetblog.com/zh/tags/sre/Articles, tutorials and insights from the .NET community.Hugozh@thedotnetblog (The .NET Blog)@thedotnetblogTue, 21 Jul 2026 00:00:00 +0000https://thedotnetblog.com/zh/news/emiliano-montesdeoca/proving-resilience-chaos-studio-workspaces/Tue, 21 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/zh/news/emiliano-montesdeoca/proving-resilience-chaos-studio-workspaces/Azure Chaos Studio Workspaces 将弹性从架构意图转化为可衡量的证据，这一转变应该改变团队在 Azure 上发布软件的方式。<p>大多数团队仍然将弹性视为设计时的检查清单：多可用区、故障转移已启用、重试已到位、完成。这种心态已经过时了。生产事故很少像架构图预测的那样发生，而 Azure 新的 Chaos Studio Workspaces 正是对这一现实的直接回应。</p> <p>原文来源：https://azure.microsoft.com/en-us/blog/proving-application-resilience-on-azure-with-chaos-studio/</p> <p>最重要的转变不是&quot;更多的故障注入&quot;，而是<strong>场景优先的验证</strong>。Workspaces 不是手动组合随机故障，而是从团队实际看到的中断模式开始：可用区丢失、DNS 中断、数据库故障转移、身份服务中断、缓存雪崩和消息传递中断。这是一个更好的模型，因为运维风险存在于组合中，而非孤立的故障。</p> <p>我的观点很简单：没有定期演练的弹性是弹性剧场。如果你的服务从未经历过一个真实的、跨层的故障序列，你并不了解你的恢复行为——你只是假设。Workspaces 通过自动发现范围并针对真实资源推荐场景来降低这个门槛，消除了&quot;我们不知道从哪里开始&quot;的常见借口。</p> <h3 id="开发者和平台团队现在应该做什么">开发者和平台团队现在应该做什么</h3> <ul> <li><strong>定义最小的弹性管道</strong>。每个关键工作负载至少一个场景，按发布节奏执行，并带有通过/失败门控与恢复目标绑定。</li> <li><strong>将场景报告视为变更管理中的一等制品</strong>。它们应该像安全扫描一样附加到发布审批和事后审查中。</li> <li><strong>包含应用级别的断言</strong>，而不仅仅是基础设施的成功。数据库可以正确故障转移，而你的应用仍然提供过期的读取或发生死锁。</li> </ul> <p>微软的另一个好举措是通过 Copilot 技能和 MCP 工具暴露此功能。这是战略上的明智之举。工程师越来越多地通过助手工作流进行操作，弹性测试应该成为日常循环的一部分，而不是由一个可靠性专家每季度执行一次的仪式。</p> <p>如果你在 Azure 上运行 AI 工作负载，这一点甚至更重要。智能体和检索管道仍然依赖普通的云原语：网络、缓存、身份、存储、数据库。如果这些基础组件没有经过压力测试，平台就谈不上可靠性。</p> <p><strong>核心观点：</strong> Chaos Studio Workspaces 使&quot;证明它&quot;成为可靠性的新默认。早期采纳的团队将自信地交付。推迟的团队将继续在生产中发现弹性缺陷——在那里每个测试都是昂贵且公开的。</p>