本文要点

软件应用变得越来越复杂，停机的成本愈加昂贵，消费者对停机的容忍度也越来越低。
混沌工程还不是很主流，但本次问答的受访者大都认为它已经走出了创新阶段，进入了应用曲线的早期使用阶段。在组织内部，事件响应和缓解措施变得越来越重要，优先级不断上升。
混沌工程的核心理念已经很完善了，在过去的几年中社区对它的理解更为广泛和深刻。工程师开始理解它是实验和信息共享的有原则实践，并不是什么完全随机攻击的神话。
软件工程师一直在生产中做测试（即使他们没有意识到这一点）。混沌工程可以提供更正式的方法。
通过事件响应策略和管理演练游戏日之类的形式关注人员和流程可以显著提升价值。与大多数技术变革一样，新理念普及的最大障碍往往是人们自身。关键在于找出实践的合理性，设定期望并在整个组织中建立信任。
太多的人认为构建和运行系统的目的是不要犯错误。当他们意识到出色的系统并不完美，而是有弹性的，那么组织自然就能开始理解混沌工程及其实践的优势。
混沌工程的一个好处是你不需要很多工具就能启动。例如，你可以使用Linux的本地kill命令来停止进程和iptables来造成网络连接问题。
谷歌的团队会做DiRT（灾难和恢复测试），他们走进数据中心对服务谷歌内部系统的机器“造成可怕的后果”，例如拔掉硬件等。组织的规模没有那么大的话，也有侵入性较小的开源和商业工具可用。
为了从混沌工程的投资中获益，组织首先需要建立一种从事件中学习的文化。没有这种学习过程，投资可能就无法创造价值，并令人感到沮丧。观察系统并了解停机时间的影响也是关键所在。

第二届混沌大会活动于9月25日至26日在旧金山举行，InfoQ也将报道活动概况。在为大会做准备时，InfoQ与许多演讲者坐下来讨论了众多话题，诸如混沌工程的演变和应用、进行混沌实验时相关人员和流程的学习重点以及主流应用的最大障碍等。

希望深入学习混沌工程的读者可以参阅最新版的混沌社区日v4.0的摘要、混沌工程电子杂志以及有关弹性系统的多份QCon演讲的摘要。

InfoQ：非常感谢几位参加2019混沌论坛的会前问答。请各位简单介绍一下自己。

Jason Yee：我是Datadog的高级技术传播者。Datadog是基于SaaS的可观察性平台，使开发人员、运营和业务团队可以更好地了解用户体验和应用性能。

Caroline Dickey：我是Mailchimp的网站可靠性工程师，这是一个针对小型企业的多合一营销平台。我构建工具和配置以支持工程运作，并发展监视和服务级别的目标以改善我们应用程序的健康水平；我领导了Mailchimp的混沌工程计划。

Joyce Lin：我是Postman的开发者支持——这是一种在开发社区中广泛应用的API开发平台。我还与致力于更好的软件开发实践的组织合作。

Robert（Bobby）Ross：我叫Robert Ross，但人们喜欢用流行的XKCD漫画来称呼我Bobby。我是尖端技术爱好者，所以我喜欢尝试新事物并愿意承受尝新的代价。我是事件响应工具FireHydrant的CEO。

Kolton Andrus：我是Gremlin的CEO兼联合创始人。我曾全力在Amazon建立可靠的系统，当时我的团队负责零售网站的可用性。我建立了他们的第一个“混沌工程”平台（彼时还没有这种概念），并帮助其他团队做了他们的第一个实验。然后我加入了Netflix，那时他们刚刚开始撰写有关这个话题的博客。我建立了他们的下一代故障注入测试（FIT），并与所有关键的流媒体团队一起将正常运行时间的可靠水平从三个九提高到了四个九（99.99％）。看到了Amazon和Netflix获得的价值后，我强烈感受到所有人都需要这种方法，需要强大的工具来支持它——因此我创立了Gremlin。

YuryNiño：我来自哥伦比亚国立大学，目前是Aval Digital Labs的DevOps工程师，我们这家创业企业领导着我国一批银行的数字化转型。

我也是混沌工程的拥护者。我喜欢破坏软件应用、设计弹性策略、在生产中实验并解决棘手的性能问题。我正在研究软件系统的安全性与人为错误和缺乏可观察性之间的关系。目前我正在领导一家创业公司创建哥伦比亚的第一个混沌社区。我们正在构建Gaveta，这是一款用来支持混沌游戏日执行的应用。

Jose Esquivel：我是Backcountry.com的一名工程经理，在供应链管理中负责实现、市场营销和内容团队的工作。他们运行着大约65种API，这些API在我们的网络内与第三方系统及公共API交互。从技术角度来看，我的责任是确保这些API保持稳定并及时添加新功能。

Subbu Allamaraju：我是Expedia Group的VP。我刚加入Expedia时负责了我们的旅行平台向云的战略迁移。这些年我花了大量时间继续推动这一转型，更重要的是让我们为卓越运营做好了准备。我认为大家之间有很多东西可以学习交流，因此我在自己的博客上撰文并在许多会议上发表演讲。

Dave Rensin：我是谷歌的高级工程总监，目前正在为我们的CFO从事战略项目。在谷歌，我负责客户支持、一部分SRE以及全球网络容量规划。

Paul Osman：我负责Under Armour Connected Fitness的现场可靠性工程团队。我的团队负责MyFitnessPal、MapMyFitness和Endomondo等产品。加入Under Armour之前，我曾在Pagerduty、SoundCloud、500px和Mozilla工作。我的大部分职业生涯都横跨运维和软件开发领域，因此自然而然地走近了SRE工作。这些年来我已经在多家公司实践过混沌工程。

InfoQ：在过去的一年中混沌工程发生了什么变化？应用情况如何？混沌工程已成为主流了吗？

Yee：我认为混沌工程本身并没有什么变化，理念还是一样的，但是我们对它的理解更深了。工程师开始明白这是有原则支撑的实验和信息共享的实践，并不是完全随机攻击的神话。神话的破灭和最佳实践的出现都推动了混沌工程的应用。它还不是很主流，但我们肯定已经走过了“创新者”阶段，进入了应用曲线的“早期使用者”部分。

Dickey：在组织中，事件响应和缓解措施愈加重要，优先级不断提升。应用程序变得越来越复杂，停机成本愈加高昂，消费者对停机的容忍度也越来越低。令人欣喜的是，过去一两年来人们对待突发事件的态度已经不再只是分析其成因或推卸责任，而是开始将事件视为一场完美的风暴。混沌工程是这种行业范式转变的理想选择，因为它让工程师能够识别并解决可能导致连锁故障的问题。

混沌工程在大型科技公司和早期使用者当中已经成为了主流，而在中小型公司中仍在寻找自己的立足之地。但这种趋势是不变的，因为软件的分工越来越细，人们犯错的几率也不会减少！我很期待看到几年后混沌工程的应用和相关实践会是怎样的情况——投身于这一行业是很有趣的。

Lin：我相信混沌工程对于大多数团队来说仍然是一种可能考虑在未来实施的新事物。如果团队做好了发布前测试的所有基础工作，那么他们就更容易开始混沌实验。

Ross：混沌工程运动的一大影响在我看来就是游戏日的流行。它们并不是一个全新的概念，但我注意到已经有越来越多的公司采用它们。人们意识到，既然发布前测试软件的舞台已经搭建好了，为什么不一起测试一下事件响应流程呢？大型企业这样做已经有很多年了，越来越多的小公司也加入了进来。

Andrus：不过几年前，我还得经常向人解释为什么需要混沌工程。现在大多数认真运营的团队都理解了它的价值，只需要一些帮助即可入门。拥有两年经验的早期使用者现在已经取得了很大的成功，并且正在设法将其扩展到整个组织中。主流群体仍在与项目和团队一起展开测试，然后才能更全面地应用混沌工程。

Niño：我认为混沌工程在很短的时间内就达到了惊人的发展速度。经典文章“混沌工程”的作者在2016年提问，是否有可能构建一套可在组织间重复使用的自动化故障注入工具。仅仅三年后的今天，我们已经拥有20多种工具来实施混沌工程，一些组织正在使用它们来在生产中构建更可靠的系统。

根据Thoughtworks发布的最新版《技术雷达》，混沌工程已经从一个广为人知的理念转变为一种公认的主流方法，可用来改善和确保分布式系统的弹性。

Esquivel：在线业务的负载一直在增长，而对于电子商务来说大部分流量集中在一年中的某几个星期。这意味着在人流量大的时期，公司的收入直接与系统稳定水平成正比。采用诸如单元测试、集成测试、安全测试、负载测试及最终混沌测试等工具已成为关键任务。混沌工程的使用率一直在上升，我们都知道自己确实需要它。现在我们需要的是花费时间来等待它成熟。

Allamaraju：还没有。

尽管这个话题已经有约十年的历史，但业界对混沌工程这种理念的理解仍处于萌芽状态。

我的理由如下。在这个行业中很少有人将生产环境中运行的软件视为随机和非线性的系统，而且我们每次做出更改时都会在系统中引入许多假设。因此当团队设计混沌工程时，他们会通过各种混沌工程工具测试操作系统以及网络和应用级别的故障，但远不足以了解系统的安全性。

即使我们对生产系统所做的大部分工作看起来都是良性的，但这些工作有时仍会将系统推向不安全的区域，阻止我们交付客户所需和想要的价值。因此在深入研究混沌工程技术之前，从事件中学习和反思是非常重要的。

Rensin：我认为混沌工程一直都是主流方法，只不过以前我们叫的名字不一样。如果你的客户先碰上了混沌，我们称之为“客户支持”。如果你的电信公司（或提供商）先你一步，我们称之为“厄运”。我认为这是去年发生的最大变化。当越来越多的人发现混沌工程的本质时，他们也更深刻地意识到自己的组织已经身处其中（或需要这样做）了。

Osman：人们的兴趣越来越浓，但许多公司仍在努力入门。我觉得这是因为混沌工程并非灵丹妙药——混沌工程处于一个能力矩阵中，这个矩阵整体的确可以产生效果，但是如果没有可观察性、良好的事件响应流程和无过错反思等事物的配合，单单是混沌工程自己不太可能带来什么惊喜。

基本上来说，如果你们不是学习型组织，那么开展实验是没有意义的，混沌工程技术也会无济于事。从好的一面来看，越来越多的人意识到现代系统是复杂的，明白故障无法全部预测。仅仅让质量检查团队在过渡环境中测试并不会消灭故障，因此人们对混沌工程的兴趣越来越大。我认为所有这些都可能意味着它现在已经成为了主流。:)

InfoQ：采用混沌工程实践的最大障碍是什么？

Yee：与大多数技术变革一样，最大的障碍在于人本身。想要获得领导者的批准来故意破坏你的生产系统是很困难的，尤其是无法准确判断业务风险和收益的情况下更是如此。想要赢得支持，关键在于创建一个可靠的策略来管理混沌测试的破坏半径、确保发现的薄弱环节得到改善并传达业务价值等等。

Dickey：文化上的转变——在堆积的工作计划中让工程师优先考虑并重视破坏性测试——这一直是推动Mailchimp采用混沌工程技术的最具挑战性的部分。策划游戏日或实施混沌工程自动化至少需要几个小时的准备工作，而且如果没有专门的混沌工程团队，做计划和确定场景的耗时可能会影响进度。

因此，重要的是要记住所有工程规范都需要文化上的转变——无论是引入单元测试、代码审查还是日常站会或在家工作都是如此。由于Mailchimp的混沌工程计划很大程度上是由SRE团队引导的，因此我们不得不依靠技术讲座和内部新闻通讯直接与团队联系，并设法让游戏日更加有趣（我们建议使用混沌纸杯蛋糕），从而推动整个工程部门的参与度。

Lin：仅仅靠解决一个常见的障碍并不足以证明采用混沌工程实践的合理性。当组织的其他成员还不了解它或不相信其收益时，他们会感到恐惧和困惑。更糟糕的是人们通常会认为你只是在随机搞破坏，并没有合理的假设和前提。

Ross：你需要一位流程推动人。人们总是习惯继续做自己熟悉的事情。需要有人力挺才好尝试混沌工程。我认为有时“混沌工程”这个词可能会让某些人害怕，因此你需要有人真正向团队成员解释其价值所在，并让所有人参与其中。入门往往是很难的。

Andrus：我认为许多人都理解基础的理念，但是低估了它为业务提供价值的潜力。他们只把它当作一个任务，而不是用它节省手头项目的时间——简化诸如迁移到云或采用Kubernetes之类新服务的工作。可靠性往往是事后才想到的，因此我们正在投入大量工作来教育市场并展示投入前期努力会产生的价值。

Niño：我遇到的障碍很多，比如设法理解为什么构建弹性系统与软件、基础架构、网络、数据甚至是制作项目列表都有关系。但我认为最大的挑战是文化变革。

根据我的经验，很难让客户同意拿他们的系统来做实验。刚谈起混沌工程时客户很兴奋，比如会说：“如果巨头都在这样做，我们也应该考虑混沌工程。” 但等他们了解了基本概念后就会说：“我们不会在生产中注入失败”之类的话。

另一方面，我认为也必须提到这些局限，告诉大家混沌工程技术本身不会使系统更强大，增强系统是系统设计者的使命。混沌工程使我们了解系统如何应对生产中的动荡条件，并建立起对其可靠性水平的信心，但设计策略是我们的责任。技术不是弥补我们弱点的灵丹妙药。

David Woods在这方面有一个很好的观点：“扩展系统能力以处理某些额外扰动会以其他方式增加系统对其他类型事件的脆弱程度。这是复杂的自适应系统的基本取舍”。

Esquivel：企业必须精通IT才能克服应用混沌工程的最大障碍——欠缺将稳定性放在首位的文化。高层管理人员必须了解技术，并知道对质量的投资可以转化为有效的长期解决方案。只交付功能是不够的，构建功能的同时必须确保解决方案中包含以下非功能要素：通过单元和集成测试保证的可维护性和一致性、通过负载测试保证的性能水平，以及通过注入混沌测试等保证的稳定性。

Allamaraju：在我看来，最大的门槛是理解混沌工程实践背后的基本原理，同时发展一种安全运行我们系统的文化，并阐明这种实践相对其他工作的价值所在。如果你无法阐述清楚并创建出假设以证明其可以带来价值，那么你就无法通过混沌工程获得成功。

一旦克服了这些障碍，混沌工程的实际实践就会自然而然地到位。

Rensin：不要再追求完美。太多的人认为系统的目的是不要犯错误。一旦他们意识到一个好的系统不是完美的，而是有弹性的，那么混沌工程就自然而然地到来了。

Osman：我认为信任是最常见的障碍。你必须有一种信任文化，其中团队相互信任，非技术的利益相关者则相信工程团队会考虑客户的最大利益。这种信任非常重要——如果团队担心混沌实验可能发生什么情况并且进展不顺利，他们当然就会犹豫不决。

混沌工程揭示了复杂系统的一项缺陷：我们无法完全控制，也无法预测生产中会发生什么。不幸的是一些组织不愿面对这一现实。这就是为什么在介绍混沌工程之前，更重要的是先引入无过错反思和良好的事件响应机制之类的实践。这些实践会影响组织的文化，为讨论混沌工程打下基础。

InfoQ：混沌工程中人的因素有多重要？你能为希望提高组织应变能力的领导者提供一些参考意见吗？

Dickey：混沌工程的推广既是营销工作也是技术工作。领导力支持对于混沌工程计划能否取得长期成功是至关重要的。我推荐出色的混沌工程技术这份全面的资源清单，可以成为一个很好的起点。

Lin：大多数组织都害怕更快交付软件背后的风险，并通过越来越多的预发布测试来减轻这种担忧。当组织对他们的平均恢复时间心里有数时，就会愿意开展深入的混沌实验来学习更多内容。

Ross：当你对某些东西进行混沌测试时，你可能会发现一些有严重缺陷的代码/基础结构设计，然后可能就会想“怎么会出这种问题？” 请务必记住，会引入问题的是组织而非个人。你可能会发现某些代码引起某个问题，就算你不说，编写代码的人也知道那是自己写的。有的人可能会很难受，甚至可能因此感到不适。你要让他感受到支持和鼓励，因为我们所有人都会犯错（实际上如果你编写的是生产代码，那么你已经在犯错了）。不要到处怪这怪那，你做不到的话就还没有为混沌工程做好准备。

Andrus：在我们这个行业中，我最讨厌的事情之一是还没投入资源训练好团队就让他们待命。我们进行消防演习是有原因的：这样我们就有机会提前练习并建立肌肉记忆，以免出事以后火烧眉毛四处乱窜。同样，事件管理的一大要素就是团队之间的协调——通常指的是以前没有互动的各个团队。在紧急情况出现之前建立互动空间就能准备得更加充分，取得更好的成绩。

Niño：我认为混沌工程是人们为自己创造的学科。我们人类、我们的态度以及我们在压力下所做出的权衡都体现在系统运行和表现的方式中。在混沌工程中，我们设计故障，在生产中进行实验，分析结果并生成弹性策略。

谈到参考资料，我认为一些出色的人员和组织已经利用混沌工程提升了他们的弹性。Gremlin团队在这个方面做得很出色；他们的工具和文档为那些想要提升弹性的领导者提供了很好的参考。

Esquivel：一旦人们明白自己努力的成果是自己拥有的——这里我指的是公司所有权——那么你就很容易获得支持，人们也很容易参与。在Backcountry，产品VP、工程总监和几名工程经理都提倡提高弹性。在这种情况下，自上而下的支持是取得进展的关键所在。

Allamaraju：人是这门学科的核心。毕竟是人在构建和运行我们的系统。人们可以通过运营指标来聆听那些系统的反馈。人们可以从事件中学习，以了解系统什么时候可以工作，什么时候不行。

不幸的是我们仍在通过经验来学习这些知识，这需要花费很多时间。

Rensin：人是所有系统中最重要的部分。我们为他人构建和运营这些事物。人也是最大的障碍（或动力源泉）。我认为建立组织弹性的最好方法是定期“关闭”关键人员。比如说“今天，Sally不会回复任何工作邮件或消息。生活交流没问题，但工作的事情一概免谈。” 我们为什么要这样做？是要找出只有Sally才拥有的部落知识，然后全记下来——或至少传播开来。这样随机测试过足够多的成员后，突然间你就会拥有一支更具韧性的团队。

Osman：像我前面提到的那样，人是非常重要的！工具和流程再怎么好，没人信任和使用也毫无意义。谈到参考资料，混沌工程已有七年历史了，但我还是推荐John Allspaw在ACM Queue中发表的文章“生产中的故障注入”。这是对这个概念很好的介绍。他在同年写的“无过错反思和公正的文化”博文也很棒。我多次提到良好的事件响应流程的重要性；如果组织没有自己满意的流程，我都推荐他们参考PagerDuty的事件响应文档，写得很好。要是你不知道该怎么起步，看这些就行。

InfoQ：能否推荐一些自己喜欢的混沌领域的工具和实践/游戏？

Yee：混沌工程有一点好处是你不需要很多额外的工具。比如说你可以使用Linux的原生kill命令来停止进程和iptables来造成网络连接问题。我们在Datadog使用的一些工具包括可模拟恶劣网络条件的Comcast，和HTTP负载测试工具Vegeta。

Dickey：Mailchimp已成为Gremlin的客户大约一年了，我们很满意他们的工具所提供的灵活性和功能。我们选择使用他们的工具而不是构建自己的，因为我们认为开发人员可以花更多的时间为客户创造出色的产品。我们还有一些独特的技术限制（我在大会上的演讲会提到），这所以很多开源工具都用不了。

SRE团队每月组织一次游戏日，其他团队需要时加大频率。事件模拟游戏日（有时称为战争游戏或消防演习）已经帮助我们的工程师可以更轻松地响应事件了。

Ross：我很喜欢尝试不用任何工具的混沌工程。基本上来说，游戏日中有一个工程师团队负责破坏网站，不告诉另一个团队他们要做什么，什么时候会做（很有意思）。这样我们就能知道哪里是领域知识所在地、人们在发生状况时是否了解流程、你是否为此设置了警报，以及他们是否有合适的调查工具等等。

Andrus：我推荐的一些最佳工具实际是命令行和观察工具。可以grep/sort/cut/uniq一组日志来缩小调查范围。可以用TCPDump或网络分析工具来真正了解幕后情况。了解延迟分布、聚合和百分比以及你要测量的内容都是理解系统行为的关键所在。

还有一个叫做Gremlin的工具。;）我们最近为刚入门的用户推出了一个免费版本，你可以用它运行停机和CPU实验。

Niño：有些行业要部署到云端还有很多限制，我推荐用Chaos Monkey之类的工具进行Spring Boot。这个工具非常适合用于做一些涉及延迟、受控异常以及在本地架构中终止活动应用之类的实验。

我还一直在探索ChaoSlingr，一种用于安全混沌工程的新工具。它是为AWS构建的，你可以用它将故障推送到系统中，同时识别出安全问题并更好地了解基础架构。

Esquivel：我们已经从内置工具转向了商业软件，除非你愿意花费大量时间和金钱，否则我们建议你还是选择商业方案。我们选择的解决大规模稳定问题的武器是Jenkins，它使用Gatling和Gremlin进行负载测试，在预设的冲击半径下释放混沌；我们用它可以很轻松地在生产和开发环境中进行混沌实验。

Allamaraju：我没有最喜欢的哪种工具或实践。相反，我将研究系统的架构、我们所做的假设和通过事件观察到的弱点，然后发展假设以测试故障，并找出哪些工具或实践可以用来测试假设。

Rensin：在谷歌我们使用DiRT（灾难和恢复测试），我们会走进数据中心，对服务谷歌内部系统的机器做一些可怕的事情——例如拔下硬件。有一个小型团队来计划和执行这项工作，避免对客户造成伤害；但大多数情况下我们的工程师会将其视为真正的中断。我们通过这种方式发现了很多东西，而DiRT事后反思是谷歌上最好的资料之一。

Osman：实践而言，我真的很喜欢在事件的事后反思过程中策划混沌实验。当你查看事件的前后过程时请注意意外情况——也许数据库失败了却没人真正知道原因，或者服务A的延迟增加导致了意料之外的错误——这些都是混沌实验很好的对象，帮助团队在某些压力下了解有关系统行为的更多信息。Richard Cook谈到了“想象中的系统”与“现实系统”之间的区别，而事后反思是弥补它们一些差异的绝佳机会。这些差异是高价值混沌实验的理想材料。

InfoQ：能否用两句话介绍你的混沌大会演讲？你的演讲为什么不容错过？

Yee：如果弹性是现代应用的必要需求，那么我们需要改变软件的构建方式。我将谈论弹性驱动的软件开发，这是在早期开发流程中应用混沌原理以确保应用更具弹性的一种方法。

Dickey：对于许多公司而言，混沌工程意味着测试服务之间的依赖关系或杀死容器实例。我的演讲谈论了何时不能采用这些方法，以及这种情况下如何实践混沌工程，比如说你的主要应用是在裸机上运行的单体架构的情况。

Lin：在组织中推行混沌工程是谁的责任？在非常大型且成熟的公司中，可能由SRE或DevOps团队来处理，但如果你没有定义清晰的功能怎么办？还有谁能开展混沌实验？我的演讲将研究这个主题。

Ross：我们将向你展示如何将先前发生的严重事件的影响因素整合到一个混沌实验中。然后我们从上一个事件的反馈中学习经验，再来测试事件是否会再次发生。

Andrus：今年这个领域有了很多发展。我们看到面向公众的停机次数有所增加，但这种趋势带来好处之前我们都害怕它产生的负面影响。我的演讲将介绍公司如何为常见的、影响广泛的停机事件做准备，帮助听众了解如何建立更可靠的网络。

Niño：如今有很多关于混沌工程的书籍、工具、卡片和论文。对于刚开始探索该学科的人来说这可能是很大的负担。我的演讲“入门混沌工程的流行菜谱”提供了指导和实验，帮助混沌工程师新手入门

Esquivel：在进行混沌实验时我想解决一个常见的问题：混沌工程有没有很好的路线图？为此我想展示八种稳定性模式、讨论实现可观察性的三种方法，并用实时混沌测试来做总结。

Allamaraju：我准备探讨如何形成失败假设。根据我在Expedia Group的经验，我会分享我们用来驱动安全性的防护体系，以及如何制定基于价值的假设来促进安全性。

Rensin：我认为我们可以（并且应该）将混沌工程原理应用到团队开发和培训中。没有理由将这些想法局限在于软件或硬件上。我想我可以说服听众为什么它可以让团队和公司变得更好。

Osman：Ana Medina和我将讨论将混沌工程引入组织的方法。我们将从工作过的公司的实际案例中汲取经验。我们还将介绍引入这些实践的多种途径。如果你在公司中一直很难就这一理念获得支持，或者你对混沌工程技术感兴趣但不知道如何入门，那么你绝对应该观看我们的演讲。

最后，InfoQ联系到了Gremlin的传播总监Adam LaGreca，了解了他对大会目标的看法。他表示，2018年混沌大会主要讨论什么是混沌工程，以及为什么团队应该这样做。今年的主题是“突破”，演讲者主要是这一领域的先驱，他们会分享他们的专业知识和来之不易的经验。

受访者介绍

Jason Yee是Datadog的技术布道者，他致力于利用测试和监视功能来激励开发人员和操作工程师。他曾是O’Reilly Media的DevOps＆Performance社区经理和MongoDB的软件工程师。

Caroline Dickey是亚特兰大Mailchimp的站点可靠性工程师。她负责建立内部工具，与开发团队合作开发SLI和SLO，并领导混沌工程计划——包括协调每月的游戏日。

Joyce Lin是Postman的首席开发倡导者。每月有700万开发人员和超过300,000家公司使用Postman来访问1.3亿个API。她经常与API优先组织合作，并且在现代软件实践方面对该做和不该做的事情有突出的观点。

Robert Ross（Bobby Tables）是FireHydrant的创始人兼CEO。

Kolton Andrus是Gremlin的CEO兼联合创始人。此前，他负责解决亚马逊和Netflix中企业范围内的事件。

Yury Niño是一名软件和DevOps工程师，也是一名混沌工程师。Niño喜欢软件应用、自动化、阅读、写作和教学。

Jose Esquivel是Backcountry.com的首席软件工程师。

Subbu Allamaraju是Expedia Group的副总裁。

Dave Rensin在谷歌的工程领导团队中工作。他帮助谷歌将资金投入到正确的地理位置、技术和战略投资中。

Paul Osman是Under Armour的高级工程经理。他是一位经验丰富的软件工程领导者，对运营和可靠性工程充满热情。

原文链接：

Designing Chaos Experiments, Running Game Days, and Building a Learning Organization: Chaos Conf Q&A

创作场景

混沌大会 Q&A：设计混沌实验、组织游戏日活动并建设学习型组织