内容
资料来源：pressureUA / iStockphoto
带走：
现代系统必须能够处理混乱，以避免停机。因此，全面测试系统并确保其弹性比以往任何时候都更为重要。
尽管我们尽了最大的努力来避免这种情况，但IT事故是工作中不可避免的一部分-试图保持领先于业务的停机时间只会变得越来越棘手。当今的系统紧密耦合，并且变得越来越复杂，随着运动部件的增多，出现错误的机会也越来越多。
这就是为什么越来越多的组织转向微服务以提高服务可用性和更好的故障恢复能力的原因之一。但是，尽管这些是打破单片应用程序的前提，但它们也有可能增加失败的风险-除非明确设计时要牢记弹性。
为失败做准备
考虑到分布式系统固有的混乱性质，应该开发服务，不仅可以预期故障，还可以在发生故障时自动恢复。这意味着要定期减少故障，以确保您的系统可以处理混乱情况，而不会中断对最终客户的服务。为了做到这一点，您需要能够在测试环境中模拟类似于生产的流量。
当然，在变更生产之前测试弹性是一个好主意。如果您不这样做，将无法验证您的服务可以同时支持平均负载和峰值负载。实际上，最安全的选择是确保您的产品无需扩大规模即可处理最高两倍的峰值量。
在弹性测试中，正确的工具不应太在乎请求的处理方式，而只是最终会产生正确的影响。请记住，在某些情况下，输入服务可能无法将请求移交给系统的其余部分，但不会报告失败。确保确实发生了端到端验证，不要冒险在监控范围内飞扬的问题。 （有关更多信息，请参阅技术失败：我们可以忍受它们吗？）
后续步骤
了解服务在负载下的行为之后，该开始介绍故障事件了。与所有软件测试一样，最好拥有自动化工具，使您能够轻松快速地重现场景，以便您协调影响不同基础架构技术的复杂事件。除了验证服务的修复和更改的能力之外，这还使您可以在任何环境中按计划运行随机故障方案。
有意义的故障事件在很大程度上取决于服务的布局，您可以通过提出与您相关的特定问题来制定它们。例如，当数据库在一段时间内无法访问时，对使用前端的人员有什么影响？这些用户是否仍可以浏览Web UI？他们是否仍可以发布其信息的更新，并且当数据库再次变得可访问时，这些更新是否将得到正确处理？
如果您运行多个微服务，则可以询问是否有任何单个服务崩溃而导致全局中断。或者，如果您有一个排队机制来缓冲服务之间的通信，那么当消费者服务（或多个服务）停止工作时会发生什么？用户仍然可以使用您的应用程序吗？给定一个平均负载，在队列溢出并开始丢失s之前需要多长时间？
没有错误，没有压力-在不破坏生活的情况下创建可改变生活的软件的分步指南
当没有人关心软件质量时，您就无法提高编程技能。
定义完有关基础架构的几个关键问题后，便可以开始列出模拟这些故障的不同方法。停止特定服务或数据库服务器可能就足够了。您可能希望阻塞服务的主线程以模拟死锁，而其容器仍在响应并正在运行。您可能决定在网络中引入规则以阻止特定服务之间的流量。在Linux环境中，您可以使用“ tc”之类的工具来模拟网络情况，例如高延迟，丢包，损坏或重复的数据包。 （让用户参与测试可能很重要。了解4个为什么最终用户需要在UAT之前参与测试的原因。）
通过演习学习和改进
创建故障方案的最有价值的方面之一是，它们可以揭示系统可能发生故障的所有可能方式，从而为实现自我修复逻辑开辟道路。您的团队将逐步完成手动恢复服务的步骤-顺便说一句，这是一次很棒的练习，以确认他们能够在SLA中完成此任务。可以进行此恢复过程的自动化，但是与此同时，您可以放心，您的团队已经完成了使服务重回正轨的过程。通过使故障场景随机且定期且不公开运行的全部细节，您还可以将演练的发现和诊断包括在内，这毕竟是SLA的关键部分。
混沌工程的核心是将系统的复杂性作为给定条件，通过模拟新的和古怪的条件对其进行测试，并观察系统的响应方式。这是数据工程团队需要重新设计和重新配置系统以实现更高的弹性。有太多的机会学习新颖有用的东西。例如，您可能会发现在下游服务发生变化时服务没有得到更新的实例，或者完全缺少监控的区域。可以通过各种令人兴奋的方法来提高产品的韧性和强度！