尽管我们尽了最大努力来避免IT事故，但IT事故是这项工作不可避免的一部分——试图提前应对业务影响停机只会变得更加棘手。今天的系统紧密耦合，越来越复杂，更多的移动部件带来了更多的出错机会。
这就是为什么越来越多的组织转向微服务来提高服务可用性和更好地从故障中恢复的原因之一。尽管这些是打破单一应用程序的重要先决条件，但它们也可能增加失败的风险——除非明确考虑弹性设计。
准备失败。
鉴于分布式系统固有的混沌特性，服务的开发不仅要预测故障，而且要在故障发生时自动恢复。这意味着定期故障，以确保您的系统可以处理混乱，而不会中断对最终客户的服务。为了实现这一目标，您需要能够在测试环境中模拟类似产品的流量。
当然，在改变生产之前测试一下弹性是个好主意。否则，您将无法验证您的服务是否支持平均负载和峰值负载。事实上，最安全的选择是在不扩大规模的情况下，确保您的产品能够处理两倍的峰值流量。
在弹性测试方面，合适的工具不应该过多关注请求的处理方式，只要它们最终能够产生合适的影响。请记住，在某些情况下，输入服务可能无法将请求传递给系统的其余部分，但不会报告失败。确保端到端验证确实在进行，不要冒在监视雷达下飞行的问题。
下一步
在了解了服务如何在负载下运行之后，是时候开始引入故障事件了。与所有软件测试一样，最好使用自动化工具，这样您就可以轻松快速地重现场景，从而协调影响不同基础设施技术的复杂事件。除了验证修复和服务更改的能力之外，这还允许您在任何环境和计划中运行随机故障场景。
有意义的失败事件很大程度上取决于您的服务布局，您可以通过询问与您相关的特定问题来表述它们。比如数据库一段时间不能访问，使用前端的人会怎么样？这些用户还能在Web UI中导航吗？他们还能更新他们的信息吗？当数据库再次可访问时，他们能正确处理这些更新吗？
如果您运行多个微服务，您可以询问是否存在全局中断，是否有任何单个服务崩溃。或者，如果您有一个缓冲服务间通信的排队机制，当消费者服务(或服务)停止工作时会发生什么？用户还能用你的应用吗？考虑到平均负载，在队列溢出并开始丢失消息之前，您还有多长时间？
一旦定义了关于基础设施的几个关键问题，就可以开始列出模拟这些故障的不同方法。停止特定的服务或数据库服务器可能就足够了。您可能希望阻塞服务的主线程来模拟死锁，而其容器仍然响应和运行。您可以决定在网络中引入规则来阻止特定服务之间的流量。在Linux环境下，可以使用“tc”之类的工具来模拟网络状况，比如高延迟、数据包丢失、损坏或重复。
通过演练学习提高。
创建故障场景的最有价值的方面之一是，它们可以暴露系统可能发生故障的所有潜在方式，从而为自我修复逻辑奠定基础。您的团队将完成手动恢复服务的步骤——顺便说一下，确保他们可以在SLA中完成这项工作。您可以使用这个恢复过程的自动化，但同时，您可以很容易地知道您的团队已经完成了让服务回到正轨的过程。通过使故障场景随机且有规律，并且不披露操作的完整细节，您还可以包括演练的发现和诊断——毕竟，这是SLA的关键部分。
混沌工程的核心是把系统的复杂程度作为一个给定，通过模拟新的、奇奇怪怪的情况进行测试，观察系统如何反应。数据工程团队需要重新设计和重新配置系统，以实现更高的灵活性。有很多机会学习新的有用的东西。例如，您可能会发现下游服务在更改时没有更新的情况，或者完全缺乏监控的区域。有一些令人兴奋的方法可以让你的产品更有弹性，更结实！
标签：
免责声明：本文由用户上传，如有侵权请联系删除！