\

本文要点

\\

• 现代体系结构和基础设施是短暂的、动态的，不可预测的用户行为与不可预见的事件交织在一起。我们的系统开始不再像可预测的金属机器那样工作，而更像具有突发行为的生物机器。\\t
• 灾难恢复已经存在多年了，但是它很昂贵、很传统，而且很脆弱，所以它只会部署在必要的地方，而且极少会用得到。混沌工程利用了云本地体系结构中现有的api和自动化。\\t
• IT团队中的每个人都应该关注于混沌工程，但是关注的领域可能有所不同。例如，在操作系统层(CPU、内存)、网络层和应用层都存在混乱。即使是专注于用户体验的产品经理也应该将混沌练习作为他们特性展示的一部分，予以规划和执行。\\t
• 混沌工程是一种在目标时间框架内引发未知和意外故障的好方法，有助于提高系统的弹性。混沌工程应持续不断地运行。\\t
• 对于混沌工程来说，有几个重要的先决条件。首先，你需要确保有适当的监控。然后，你需要能够确定五大关键服务是什么。接下来，选择一个服务，并确定一个你想在其上执行的假设和混沌实验。\

\\

9月28日，InfoQ在美国旧金山举办了的，为了准备这次会议，InfoQ采访了多位演讲者，并讨论了混沌工程的好处、挑战和实践。

\\

首届Chaos Conf将由 团队组织，旨在为专家、实践者和混沌工程领域的新手提供一个分享经验和学习新出现的良好实践的论坛。演讲内容包括向非技术涉众介绍运行混沌实验的想法、混沌工程的历史、实现故障注入、故障管理模式、“破坏容器”和使用Kubernetes运行混沌实验等。

\\

InfoQ最近与诸位Chaos Conf演讲者坐谈，讨论了混沌工程的方方面面，他们是：OUI.Sncf卓越运营总监 、亚马逊云架构副总裁 、Honeycomb首席执行官 、Turbine 实验室首席执行官和创始人、沃尔玛实验室工程总监 、推特工程经理、彭博社软件工程师，以及Gremlin的混沌皇后 和。

\\

InfoQ：欢迎大家的到来，非常感谢你们参加了Chaos Conf会前问答环节。你们可以简单介绍一下你们自己吗?

\\

\

Kriss Rochefolle：你好，我是来自法国南特理工学院的质量和安全工程师(现在叫IMT Atlantique)，我在软件公司和初创企业中建立软件质量团队的经历积累一定经验，特别是在多站点环境和离岸环境中受益匪浅。

\\

在领导了第一个法国flash销售网站的敏捷 \u0026amp; DevOps方法之后，我加入了OUI。sncf集团在两年前以卓越运营方法和少量的混沌工程继续DevOps转型。

\

\\

\

Adrian Cockcroft：你好，我是亚马逊云架构战略副总裁，我的部分工作是为亚马逊运营开源社区团队。我剩下的工作就是和客户交流，在会议上发言。

\

\\

\

Charity Majors：嘿，我是 的联合创始人兼首席执行官，那是一家为软件工程师建立可观察性的公司。我还曾任职于Parse/Facebook, 是O'Reilly著作《》的合著者，长期作为运营工程师和体系破坏者。

\

\\

\

Mark McBride：大家好，我是Turbine 实验室的创始人和首席执行官。我们创造了Houston，它是一个专注于微服务自助服务的服务网络。在Turbine 实验室之前，我在Nest负责服务器端工程，更早的时候，我在推特工作。在这两个地方，我都领导了向微服务的转型。

\

\\

\

Vilas Veeraraghavan：你好，我在沃尔玛运营云应用程序测试和部署管道。我们拥有用于混合云部署和混沌工程的测试、分析、集群规模估算。

\

\\

\

Ronnie Chen：嗨，我现在是Twitter的工程经理。我从科技行业的后端工程师做起，然后进入数据工程领域。然而，对于混沌大会，我主要是以我作为技术潜水员(自给式水下呼吸器和换气器)的身份发言。

\

\\

\

Mikolaj Pawlikowski：我是彭博社的一名软件工程师，我在那里的工作主要是围绕一个运行在Kubernetes之上的微服务平台。这是一个大型的分布式系统，它把我引向了混沌工程范式。

\

\\

\

Tammy Butow和Ana Medina：我们都实践了混沌工程。我们正踏在了失败的边缘上，并不断探索如何利用混沌工程使系统更具弹性。我们也花时间帮助更大的社区了解更多关于混沌工程的知识。我们曾在Gremlin、Dropbox、Uber、DigitalOcean和澳大利亚国家银行(National Australia Bank)实践过CE。这些年来，我们学到了很多东西，能够回馈社会是一件很棒的事情。

\

\\

InfoQ：是什么让混沌工程如此重要?是什么原因让你认为这个话题现在受到了更多的关注?

\\

\

Rochefolle：对于IT主管来说，服务的可用性与安全性同等重要，我们必须减轻重大事故和停机的影响：

\\

• 每个欧洲组织每月重大IT事故(CIEs)的平均数量为3起\\t
• 65%的欧洲组织报告称，过去的重大IT事故已导致声誉受损和相关的财务损失\

\\

最近一个例子是

\

\\

\

Cockcroft：灾难恢复已经存在了很多年了，但是它很昂贵，很传统，而且很脆弱，所以它只部署在必要的地方，而且很少会用到。混沌工程利用了云原生架构中现有的api和自动化(无论是在使用Kubernetes的前提下，还是在AWS上)，使灾难恢复成本低、产品化且足够健壮，可以持续运行，以证明存在安全边际量。

\

\\

\

Majors：因为现代系统需要它。就在过去几年里，基础设施领域的复杂性激增。现代基础设施由分布广泛的分布式系统组成，再加上容器和调度程序，另外还有虚拟化，它与第三方供应商、SaaS或IaaS的耦合已经极为松散，具有区域之间的冗余和亚秒延迟保证，支持越来越多的语言、环境和编配层，以及“许多”存储系统。

\\

哦，别忘了微服务！现代的infra是短暂的和动态的，不可预测的用户行为与不可预见的事件交织在一起，对可靠性和丰富的新特性集的渴望与日俱增。我们的系统开始不像可预测的金属机器那样工作，而更像具有突发行为的生物机器。

\\

然而，我们用于与这些系统交互的大多数工具和实践都是LAMP-stack时代的遗留产物，那时你可以查看仪表板，了解系统的健康程度。你可以预测这些系统将如何失效，并监控这些东西。现在你不能再做这些事情了，这就是为什么混沌工程开始出现，为什么可观察性和其他学科开始出现。

\\

它们基于的是这样的一个假设：失败是不可避免的，同时又是不可预知的；理解你的系统并与之交互的最佳方法是接受这种不可能，并为此进行构建。你的目标不是让每个人都预测未来，建立完美的系统，而是要不断地管理失败，迅速地发现并纠正它们，有时还会在某种可控的情况下注入它们，从而加速学习和应对。因此就有了混沌工程学。

\\

世界正从一个已知的未知世界迅速转变为一个未知的未知世界，从“预测失败并监控它们”到“仪器和探索”。我们用来处理这些问题的工具和技术是完全不同的。

\

\\

\

McBride：在推特和Nest，向微服务的转变将一条不断增长的鸿沟带到了我们的面前，我们当前认为应用程序将如何失败和应用程序实际上是如何失败的之间存在着巨大的差异。在所有团队中，我看到了明显不同的方法，从创建昂贵的准生产模拟到允许开发人员安全直接地管理生产。工具化和直接与生产交互更加有效。

\\

今天，关键的高规模服务都由小团队管理，这种情况无非过去可比。混沌工程闭合这个循环，为他们提供实际信息，让之了解他们的服务在生产中的实际行为。否则，球队只是在猜测什么会被破坏，赌注高到无法猜测。

\

\\

\

Veeraraghavan：在云工程生态系统中，特别是基于微服务的体系结构中，存在一些传统的devops和/或质量工程无法发现或发现成本极其昂贵的漏洞。混沌工程可以使我们更加简单地找到这些以前难以发现的问题。随着私有云部署成为所有公司的标准，这个话题将继续变得越来越主流。

\

\\

\

Chen：普通系统复杂性的增加肯定会引起人们对这场运动的关注，但是以训练为目的而进行灾难演习的做法，在其他行业已经存在多年了。

\

\\

\

Pawlikowski： 混沌工程帮助填补了其他更传统的软件测试方法留下的空白。特别是，它解决了分布式系统中各个组件交互所产生的问题，虽然每个组件都经过了测试，并显示可正常工作，但集成在一起交互却未必没有问题。

\\

我认为Netflix公司出版的《》发挥了很大的作用，使混沌工程获得了更多的关注。其他因素还包括云、微服务和大型分布式系统的日益普及，在这些系统中，各种子组件出现故障是一种常态。

\

\\

\

Butow \u0026amp; Medina：任何公司都不希望自己的系统出现停机或故障。多天停机是不可接受的。随着分布式系统、云基础设施、无服务器、微服务等的复杂性，作为工程师，我们甚至更难知道稳定状态是什么样子。我们需要为失败做好准备，而混沌工程可以做到这一点。

\

\\

InfoQ：每个人都应该关注混沌工程，还是仅仅应该由运维团队关注?

\\

\

Rochefolle：拥有最好的客户体验是每个人的目标，而不仅仅是运维团队。

\\

混沌工程实践是通过在事故发生时限制影响来改善混沌工程的一种方法：

\\

• 开发团队在他们的应用程序中使用弹性模式，\\t
• 运维团队提供和运营弹性平台，以及\\t
• UX/UI团队设计客户体验以吸收事件的影响。\

\\

\

Cockcroft：可用性是开发人员关心的问题，混沌工程确保开发人员构建有弹性的系统并学习如何使其更强大。混沌工程甚至不需要运维团队插手都行。

\

\\

\

Majors：甚至运维团队什么都不是了?在现代组织中，所有的工程团队都交付软件，每个人都掌握自己服务的健康状况。这些项目过去被称为“开发”和“运维”，但这已逐渐成为一种老古董喽。

\\

如果你问是否只有基础设施团队应该关心混沌，我会反问“只有基础设施工程师有服务等级协议或者关心质量?”但愿不是。每个工程团队都应该热心地关心(并负责)他们的服务的健康。混沌工程可以通过加速发现失败场景并提升解决它们的速度来帮助你。

\

\\

\

McBride：每个人都应该关注混沌工程。运维团队需要成为冠军，因为成功工作的关键是一个能让团队安全地执行混沌实验的平台。然而，一旦这一切就绪，服务团队就真正找到了边缘情况和粗糙边缘，并且处于修复它们的最佳位置。

\

\\

\

Veeraraghavan：每个人都应该关注混沌工程——关注的领域可能不同。例如，在操作系统层(CPU、内存)、网络层和应用层都存在混沌。即使是专注于用户体验的产品经理也应该计划并执行混乱练习，作为他们特性展示的一部分。

\

\\

\

Chen：每个在复杂系统中进行开发的人都应该认识到系统是如何失效的，并考虑失效模式。

\

\\

\

Pawlikowski：好的工具化，可以自动完成任务，并且可以持续报告检测到的问题，这对实现这一点非常有帮助。

\

\\

\

Butow \u0026amp; Medina：我们坚信每个人都应该关注它。混沌工程可以在整个软件栈中使用，我们认为所有开发人员都应该为自己的代码随时待命，我们认为所有开发人员都应该针对失败进行构建，并通过混沌工程实验对其进行测试。混沌工程不仅仅是关于后端或基础设施，这是所有工程师的事情。

\

\\

InfoQ：混沌工程和弹性工程有什么区别?

\\

\

Rochefolle：弹性工程旨在通过构建具有弹性的应用和平台来防止事故的影响。然而，我们的系统变得越来越复杂了，很难预测到所有的事情。

\\

混沌工程是一种在目标时间框架内引发未知和意外故障(暗弱点)的好方法，从而帮助提高系统的弹性。通过不断地运行混沌工程，它也帮助我们有信心恢复能力不会退化。总之，弹性工程是确定性的，而混沌工程是非确定性的。我们两者都需要，以拥有最好的客户体验。

\

\\

\

Cockcroft：如果你的团队是这样叫它们的，那就没什么明显区别了。塔勒布认为，与弹性不同，是因为抗脆弱系统在承受压力时变得更强，而弹性系统具有固定的特性。混沌工程具有更强的抗脆弱性，因为系统需要寻找薄弱环节。

\

\\

\

Majors：要是我知道就好了。是黑帽子和白帽子吗?渗透性测试和…仅仅是破坏性测试?

\

\\

\

McBride：他们很相似，因为他们都鼓励开发人员，接受失败是不可避免的这一事实。弹性工程只鼓励团队为失败而设计。混沌工程更进一步，要求团队测试他们的理论，最终产生更强大的系统。

\

\\

\

Veeraraghavan：我觉得它们可以互换。然而，我发现弹性工程在高层领导中似乎更能获得青睐，而混沌工程却让他们感到害怕：)

\

\\

\

Chen：如果要仲裁这种区别，我或许不是个合适的人选。我的理解是，混沌工程侧重于以故障注入为中心的方法，而弹性工程则是构建更多容错系统的复杂学科。

\

\\

\

Pawlikowski：另一方面，混沌工程更多的目的是为了观察系统作为一个整体是否能够继续按照预期工作。这也使开发人员能够检测出他们没有考虑过测试的缺陷。

\

\\

\

Butow \u0026amp; Medina：混沌工程是一种实现弹性工程的方法。我们更倾向于关注抗脆弱性系统，这些系统不仅优雅地失败，而且在你注入混乱和失败时变得更加强大。一个系统应该不断改进。

\

\\

编者按：  在这个领域做了很多有趣的研究和思考。有关更多信息和其他参考资料，请参阅这个比。

\\

InfoQ：你能推荐一下你最喜欢的混沌工程领域的工具吗?

\\

\

Rochefolle：我们开发了自己的工具，因为我们不在亚马逊AWS上，而目前大多数工具都是针对这个平台的。

\

\\

\

Cockcroft：我认为Gremlin 很好地引领了这一领域，我加入AWS之前是他们的顾问。有很好的文档记录，是每个人在进一步开发该领域进行协作的好地方。也是一个很好的起点。

\

\\

\

Majors：这听起来有点偏私，但却是大实话，那就是你的可观察性工具先于honeycomb。如果你没有能力观察每一个失败的请求，并深入分析其原因，然后返回查看其他影响因素，那么你就不是在做工程，而只是在猜测。我非常喜欢在生产环境中进行测试，也非常喜欢在受控环境下注入混乱。但是，如果你不能精确地观察结果，如果你所拥有的只是仪表板和聚合，没有唯一的请求标识符，没有能力通过高基数维度分解，那么你就不是在做“混沌工程”，你只是在破坏一些东西。可见性是大多数现代化系统中缺失的一环。

\

\\

\

McBride：最好的公司在故障和修复之间有一个紧密的反馈环。为了将失败注入到系统带有（来自CNCF的）中，我个人最喜欢将chaos setup和Gremlin结合来用。

\\

就服务是如何执行的，Envoy 提供了一个一贯的主张，Gremlin来搞破坏，特使提供工具来减轻所有类型的失败。这是一个功能强大得惊人的系统，它不需要在不同的语言或多个服务之间以定制的方式重新实现修复。

\

\\

\

Veeraraghavan：我们正在内部编写许多工具(最终将发布开源)。有很多工具可以满足很多弹性需求。但是，大多数工具仍处于发展阶段。随着更多的公司(Netflix除外)开始执行混沌练习，这些工具将会越来越成熟。

\

\\

\

Chen：拥有足够访问权限的初级工程师会是个危险源。

\

\\

\

Pawlikowski：我推荐的一个很好的资源，是，它列出了许多相关的资源和工具，没有特定的顺序。我最偏爱的是PowerfulSeal，这是我们公司针对Kubernetes集群的编写的一款混沌测试工具，并在公司中进行了广泛地使用。去年，我们在位于奥斯丁的KubeCon + CloudNativeCon北美2017大会上将其。

\

\\

\

Butow \u0026amp; Medina：空间仍然很小，在未来还会有更多的工具被开发出来，但是在使用Uber自己的混沌猴子工具后，我(Ana)学会了欣赏Gremlin提供的自动化混沌工程软件。我(Tammy)过去在Dropbox对数据库基础设施进行混沌工程实验时，就已经开发了自己的工具。在看到Gremlin的产品后，我觉得它比我梦想的任何东西都更棒，然后我问我是否可以加入团队：)现在我在Gremlin工作，我已经在这里工作了10个月了，我爱它！

\

\\

InfoQ：如果一个团队想要开始使用混沌工程，他们应该采取的第一步是什么?

\\

\

Rochefolle：通过组织一个来准备文化变化

\

\\

\

Cockcroft：在部署任何应用程序之前，先在新环境中安装混沌工具和进程，并在应用程序进入生产环境之前创建一个测试环境来折磨它们。

\

\\

\

Majors：确保他们的仪器足够成熟，这样他们就可以解释系统中发生的未知事件。没有装备，战争还没开始就输了。

\

\\

\

McBride：第一步就是开始做。最好是在每个人都注意的情况下故意中断服务，而不是等到凌晨2点只有一个昏昏欲睡的开发人员醒来。混沌工程就是测试你对系统的了解。

\\

作为第一步，选择一些你认为应该有弹性的东西，并以你认为系统会优雅地恢复的方式破坏它。如果成功了，太好了。如果没有，你已经学到了一些有价值的东西！

\

\\

\

Veeraraghavan：坦率地说出你的期望，并意识到这应该是一个科学实验。仅仅因为名字里有“混沌”这个词，并不意味着你放弃了作为工程师的责任。Gremlin有一些，我们可以参考它们来计划和执行实验。

\

\\

\

Chen：大多数团队在开始实际的故障注入之前，应该先检查他们的运行表和标准恢复程序偏离了实际系统状态的程度。让没有运维背景的人按照你的文档来做，并在你开始将更多的混乱添加到整体之前进行验证。

\

\\

\

Pawlikowski：我会从令人敬畏的混沌工程开始，阅读，然后尝试使用各种可用的工具来破坏你的系统。破坏你精心设计的系统是很有趣的！

\

\\

\

Butow \u0026amp; Medina：我们相信混沌工程有几个。首先，你需要确保有适当的监控。然后，你需要能够确定五大关键服务是什么。接下来，选择一个服务，并确定要对其执行的混乱实验。

\\

我们的目标是以一种不会对顾客造成伤害的方式进行实验。你的系统应该优雅地失败。我们的目标是使用混沌工程实验来确认你对于失败场景的假设。接下来观察/分析结果，然后增加爆炸半径。

\

\\

关于小组成员

\\

Kriss Rochefolle 是OUI.Sncf卓越运营总监。为提高系统和团队的质量和敏捷性提供组织、方法和工具的人，在混沌工程的探索和实验过程中，充满激情和快乐！                                                                       

\\\\

Adrian Cockcroft 是AWS. Adrian云架构的副总裁。Adrian曾在Netflix担任云架构师，后来又在Battery Ventures担任技术研究员，在开发云生态系统方面发挥了关键作用。在此之前，他曾在eBay和Sun Microsystems担任杰出工程师。

\\\\

Charity Majors 是Honeycomb首席执行官。Charity曾是Facebook、Parse和Linden实验室的系统工程师和经理，也是《数据库可靠性工程》的合著者。对于分布式系统，你不必关心系统的健康状况，你关心的是事件或部分的健康状况。

\\\\

Mark McBride 是Turbine 实验室的创始人兼首席执行官，Houston的制造者，它是一个现代交通管理平面。在建立Turbine 实验室之前，他在Nest从事服务器端工程。在此之前，他在推特工作，致力于将他们的rails代码库迁移到基于jvm的对等端。

\\\\

Vilas Veeraraghavan 是沃尔玛实验室主任。Vilas于2017年加入沃尔玛实验室(Walmart labs)，带领团队负责电子商务和商店的测试和部署。在加入沃尔玛实验室之前，他曾长期任职于康卡斯特(Comcast)和Netflix，在这两家公司担任自动化、性能和故障测试负责人。他喜欢打破常规，认为混沌工程是测试复杂应用生态系统的新常态。

\\

Ronnie Chen 在推特时是一个工程经理。之前，她是Slack和Braintree的数据工程师，贝宝的后台工程师。她是一名深海技术潜水员，还曾经是一家米其林星级餐厅的副主厨。

\\\\

Mikolaj Pawlikowski 彭博社的一名软件工程师，正在构建一个基于Kubernetes 微服务的平台,传播推广云本地工程和混沌工程。他曾创办过两家初创公司，担任过自由顾问，并与等开源项目合作过。在空闲时间，他是一个运动狂，也研究生产力和幸福感。

\\

Tammy Butow 是Gremlin的主要网站可靠性工程师。她曾领导过Dropbox的网站可靠性工程团队，负责管理超过5亿客户使用的数据库和存储系统。在此之前，Tammy在DigitalOcean工作过，那是家澳大利亚最大的银行之一，从事安全工程、产品工程和基础设施工程等工作。

\\

Ana Medina 目前正在Gremlin作为一名混沌工程师,通过运行主动混乱工程实验帮助公司避免运行中断。她最后一次在优步工作是在网站可靠性工程和基础设施团队担任工程师，专门从事混沌工程和云计算。可以在推特@Ana_M_Medina找到她，她发的微博主要是关于旅行、科技多样性和心理健康。

\\

查看英文原文：