"当我在去年7月的文章中第一次开始这个推进可靠性的博客系列时，我强调了一些正在进行的旨在不断提高平台可用性的计划，作为我们提供一套可信的云服务的承诺的一部分。我提到的一个领域是故障注入，通过它，我们越来越多地验证系统在面对故障时的性能是否符合设计。今天，我请我们在这一领域的首席项目经理克里斯·阿什顿（Chris Ashton）对这些更广泛的"混沌工程"概念进行了一些阐释，并概述了我们如何应用这些概念，以及压力测试和合成工作负载，来提高应用程序和服务的弹性。"—Mark Russinovich，Azure首席技术官 开发大规模的、分布式的应用程序从来没有这么容易过，但是有一个问题。是的，由于您的公共云，基础设施可以在几分钟内提供，有许多语言选项可供选择，大量的开源代码可供利用，以及市场上丰富的组件和服务可供构建。是的，有一些很好的参考指南可以帮助你对你的解决方案架构和设计有所帮助，比如Azure架构良好的框架和Azure架构中心的其他资源。但是，虽然应用程序开发更容易，但依赖关系中断带来的影响风险也会增加。无论多么罕见，您无法控制的中断随时都可能发生，您的依赖关系可能会发生事故，或者您的关键服务/系统可能会响应缓慢。一个地区的小干扰可能会被放大或在另一个地区产生长期的副作用。这些服务中断会剥夺开发人员的生产效率，对客户的信任产生负面影响，造成业务损失，甚至影响组织的利润。现代应用程序，以及构建它们的云平台，都需要进行设计，并不断验证其是否存在故障。开发人员需要考虑已知和未知的故障情况，应用程序和服务必须设计为冗余，算法需要重试和退避机制。系统需要对偶尔发生但不可避免的生产中断和中断造成的场景和条件具有弹性。本文旨在让您思考如何最好地验证典型的故障情况，包括我们在Microsoft如何验证我们自己的系统的示例。恢复力弹性是系统在面对破坏性事件时优雅地失败并最终从中恢复的能力。验证一个应用程序、服务或平台是否具有弹性与构建失败同样重要。孤立地验证单个组件的可靠性并推断整个系统也同样可靠，这很容易也很诱人，但这可能是一个错误。弹性是整个系统的特性，而不仅仅是其组成部分。要了解一个系统是否真正具有弹性，最好是测量和了解整个系统在其运行环境中的弹性。但是你是怎么做的，从哪里开始呢？混沌工程与故障注入混沌工程是将一个系统置于生产中所面临的现实世界的失败和依赖性中断的实践。故障注入是故意将故障引入系统，以验证其鲁棒性和错误处理。通过使用错误注入和混沌工程实践的应用，架构师可以建立对他们的设计的信心-开发人员可以衡量，理解，并提高他们的应用程序的弹性。类似地，站点可靠性工程师（SRE）和实际上任何让其更广泛的团队负责的人都可以确保他们的服务级别目标在目标范围内，并在生产过程中监控系统运行状况。同样，运营团队可以在推出供客户使用的新硬件和数据中心之前对其进行验证。在发布验证中加入混沌技术可以让每个人（包括管理层）对他们的组织正在构建的系统充满信心。在整个开发过程中，正如您希望已经做的那样，尽早测试并经常测试。当您准备将应用程序或服务投入生产时，请遵循常规的测试实践，添加并运行单元测试、功能测试、压力测试和集成测试。在有意义的地方，为失败案例添加测试覆盖率，并使用故障注入来确认错误处理和算法行为。为了获得更大的影响，而这正是混沌工程真正发挥作用的地方，通过故障注入来增强端到端的工作负载（例如压力测试、性能基准测试或合成工作负载）。在进行生产试验之前，先从生产前的测试环境开始，然后了解解决方案在安全环境中的行为，以及在对实际客户流量造成潜在影响之前，如何在合成工作负载下运行。在验证过程中正确使用故障注入可能包括以下一项或多项：在测试环境中特别验证新功能：开发人员可以建立一个测试虚拟机（VM）并独立运行新代码。在执行现有的功能测试或压力测试时，可以注入错误来阻止对远程依赖项（如sqlserver）的网络访问，以证明新代码正确地处理了场景。CI/CD管道中的自动故障注入覆盖范围，包括部署或恢复门：现有的端到端场景测试（如集成或压力测试）可以通过故障注入进行扩展。只需在正常执行之后插入一个新的步骤，以继续运行或在应用某些错误的情况下再次运行。添加故障可以发现测试通常不会发现的问题，或者加速发现最终可能发现的问题。事件修复验证和事件回归测试：故障注入可以与工作负载或手动执行结合使用，以诱导导致事件的相同条件，从而能够验证特定的事件修复或事件场景的回归测试。在预生产环境中进行BCDR演练：导致数据库故障转移或使存储脱机的故障可在BCDR演练中使用，以验证系统在这些故障面前的行为是否正确，以及在任何故障转移测试期间数据不会丢失。生产中的游戏天数："游戏日"是对中断或事件的协调模拟，以验证系统正确处理事件。这通常包括对监控系统以及在事故中起作用的人工过程的验证。执行游戏日的团队可以利用故障注入工具，以可控的方式编排表示假设场景的故障。典型排放管道此图显示了一个典型的发布管道，以及包含故障注入的机会： 如果故障注入的投资建立在几个基础组件上，那么它将更加成功：协调部署管道。自动化ARM部署。合成跑步者和合成的端到端工作负载。监视、警报和livesite仪表板。有了这些东西，故障注入就可以集成到部署过程中，几乎没有额外的开销，并且可以用来在代码流进入生产的过程中把关。在过去事件的根本原因分析中，发现局部机架停电和设备故障是单点故障。对于随叫随到的工程师来说，了解到服务受到生产中的这些事件之一的影响而不是弹性的，是一个有时间限制、痛苦且昂贵的过程。在一个受控的环境和时间范围内，可以使用故障注入来验证整个发布管道对这些故障的恢复能力，这也为代码作者提供了更多机会来领导对未发现问题的调查。有代码更改或新代码的开发人员可以创建一个测试环境，部署代码，并使用功能测试和具有错误的工具执行临时实验，这些工具模拟将依赖关系脱机，例如关闭vm、阻止对服务的访问或简单地更改权限。在登台环境中，可以将类似故障的注入添加到自动化的端到端和集成测试或其他合成工作负载中。然后，可以使用测试结果和遥测来确定故障的影响，并将其和基线性能进行比较，以便在必要时阻塞代码流。在预生产或"金丝雀"环境中，自动运行器可以用于再次阻止对依赖项的访问或使其脱机的故障。然后，可以使用监视、警报和livesite仪表板来验证是否观察到了中断，以及系统是否对其显示的恢复能力问题作出了响应和补偿。在同一环境中，SRE或运营团队还可以执行业务连续性/灾难恢复（BCDR）演练，使用故障注入使存储或数据库离线，并再次监控系统指标以验证恢复能力和数据完整性。这些相同的金丝雀活动也可以在有实际客户流量的生产中执行，但这样做会给客户带来更大的影响，因此建议仅在管道早期利用故障注入后再执行此操作。建立这些实践并将故障注入到部署管道中，可以进行系统的、可控的弹性验证，从而使团队能够在不影响最终客户的情况下减轻问题，提高应用程序的可靠性。微软的故障注入在微软，一些团队在验证管道和自动化测试通过的早期就加入了故障注入。不同的团队在其自动验证关卡中正常运行压力测试、性能基准测试或合成工作负载，并建立基线。然后，再次运行工作负载，这一次应用错误–例如CPU压力、磁盘IO抖动或网络延迟。工作OA