在最近于阿姆斯特丹举行的事件驱动微服务大会上，Russ Miles声称，架构师面临的最大挑战是自身被忽视。你有很多很好的想法，比如事件驱动的微服务，但通常的反应是，这些主意听起来不错，但是对于手头要解决的问题来说过于复杂。当Miles建议公司应该考虑将异步事件驱动系统作为实现伸缩、冗余和容错的一种方式时，通常会收到这种反应。这些术语听起来通常对公司来说是有意义的，但同样经常被忽略。
Miles的主要工作目标是构建可靠的系统。对于他而言，可靠性是客户需求的一种考量，客户需要的是一个功能丰富且始终能正常运行的系统。这意味着我们有两股不容易共存的对立力量，特别是在复杂的系统中——一方面是持续的创新和变化，一方面是能够一直正常运行的系统。
根据Miles的说法，对于架构师来说最困难的事情就是让每个人都明白你正在构建一个具备弹性的系统。Miles强调，他不仅仅是在谈论技术，而是指整个系统，包括人员、实践和流程。基于这些原因，他认为一个生产系统能够正常运作简直就是一个小小的奇迹。
Miles引用了John Allspaw对弹性的定义。如果你构建的系统具备冗余、复制和分布式等特点，那么你可能正在构建一个健壮的系统。Allspaw认为，当涉及人员时才能叫弹性。同样，混沌工程也超出了工具的范畴——它是关于人们如何思考和实现系统。
在Miles看来，混沌工程是一种在故障发生之前发现故障的技术，但也是一种心态：
- 永远不要忽略故障能够为我们带来的启示，要从故障中吸取教训。
- 要具备事前分析的态度。你可以从故障中吸取教训，但如果能在故障发生之前就分析它们会更好。
- 这需要协作的，每个人都应该事先知道并同意你想要做的事情。
- 从小实验开始。如果系统能够存活下来，可以逐渐加大范围。
- 刚开始时开动你的大脑，通过手动来完成。之后，可以考虑使用工具进行自动化。
Miles认为，混沌工程最重要的一点是你必须成为系统团队的一员。你不能成为破坏系统然后等待别人去解决问题的人。你必须参与你所做的一切，并与其他人一起修复问题。Miles已经看到一些公司专门成立团队对系统实施破坏，但根据他的经验，这样是起不到混沌工程的作用的。
Miles指出，在他看来，混沌工程很简单，因为只有两个主要的关键实践需要学习。他认为这不需要任何认证计划：
- 游戏日，你聚集所有团队，经过讨论后对生产环境的某些条件进行修改，然后看看你们将如何处理故障。他指出，游戏日可能代价高昂，因为它们占用了团队很多的时间。
- 自动化混沌实验是指能够持续探索和寻找系统弱点的自动实验。
如果你准备好开始在公司里实践混沌工程，Miles的第一个建议就是不要使用这个术语本身。不要谈论破坏系统，而是谈论已经发生的事故以及你可以从中学到什么并加以改进。他指出，你正处于一个学习循环中，试图让系统逐步变得越来越有弹性。
Miles总结了一些必须遵循的“混沌俱乐部”规则：
- 不要谈论混沌。这些概念正在变得越来越主流，但这个术语可能仍然会让人们感到失望。当人们感到能够适应时才开始使用它。
- 在不破坏系统的情况下总结经验。你试图赶在用户之前找到并处理系统弱点，从而改善整个系统。
- 混沌不应该是一个惊喜。
- 如果你知道系统会中断，请不要进行实验。在尝试寻找新的系统弱点之前，先尝试解决你已经知道的系统弱点。
在开发基于事件驱动的微服务系统时，最难的一件事情就是让开发人员了解如何让微服务在生产环境中有良好的表现。这包括使用正确的端点来声明服务的健康状况，并使用正确的接触点来说明服务是否运行正常。良好的日志记录是一个重要的方面，改进这一点的方法是让开发人员阅读他们自己的日志，例如，在游戏日，他们必须通过他们自己的日志了解系统都发生了什么。
在进行混沌工程时，使用事件溯源系统可以带来可观察性。在Miles看来，可观察性意味着能够在不改变生产系统的情况下对其进行调试。如果你正在进行某种形式的混沌实验，那么你要做的第一件事就是调试系统以便找出问题所在，并使用事件源系统，这样你就可以确切知道发生了什么以及何时发生的。
Miles最后说，这是他职业生涯中第一次遇到了最佳实践。对于我们今天构建的复杂系统，混沌工程是一种可行的技术。通过手动的方式做少量的操作，可以采取游戏日或任何适合你的方式。如果你关心系统的可靠性或弹性，它应该是一个比较适合你的工具。