Gremlin: 拥抱失败的混沌工程实践 | IDCF

译者语：这是一篇Kim Harrison现场转播记录关于混沌工程与失败的主题演讲。该演讲是LaunchDarkly在旧金山组织的关于“失败”主题线下活动的一部分。演讲者Ana Medina[2]是供职于Gremlin公司的混沌工程师。
其实中国古人早就参透了其中道理：失败乃成功之母。
我试图从Ana的演讲中分出了四个部分，她分别详尽讨论了爆炸半径，游戏日活动，星期四下线实践和on-call与培训四个部分。Gemlin在文化层面对于失败和混沌工程的思考是最近几年业界先进实践值得我们仔细学习。对比Netflix的ChAP博客文章，Ana的故事更贴近于我们日常的工作，为我们从各个角度实践混沌工程提供了参考。可谓是干货满满，请大家欣赏。

在生产环境进行测试又来了！五月份我们在旧金山Microsoft Reactor举行了线下的聚会。这次活动主要聚焦于关于失败"的文化。特别地，我们想聆听和学习"失败"文化（避免失败，从失败中恢复，从失败中学习）是如何影响在生产环境中进行测试的。

Ana Medina, 本次的演讲嘉宾，现任Gremlin的混沌工程师。她讲述了如何实施混沌工程实验并且赞美了"失败"文化是如何帮助工程师形成肌肉记忆，投入更多时间开发功能和建立更具韧性的复杂系统的实践中起到的作用。

"我们要试图更多地去建立这样的勇气：尝试接受失败终将发生的想法，也要你的组员接受失败并且能够庆祝失败的发生，并且能够意识到我们能够从失败中学到很多东西"

——Ana Medina，Gremlin混沌工程师

主持人：好了，大家准备好来点儿混沌了么？对此我非常兴奋。我很喜欢这个主题，混沌工程中的失败和混沌工程如何成为你成功的关键。有请下一位演讲者，现任Gremlin的混沌工程师。Gremlin帮助企业用户实施混沌工程从而避免了服务的失效和停止。Ana Medina曾供职于Uber，作为基础设施团队的SRE聚焦于混沌工程与计算，现供职于Gremlin。让我们有请Ana。

Ana Medina：嗨！大家好！谢谢大家今天来捧场，也谢谢大家坚持到最后一个演讲。非常激动能够和大家分享一些关于失败和混沌工程的故事。

我是Ana Medina，我是来自Gremlin的混沌工程师。

Human are fallible "人类是易犯错的"

易犯错的意思就是制造错误或者犯错误。大家可以举手告诉我是否有人曾经犯过错误呢？是的，是的，大家都会犯错，对吧？

我实际上想告诉大家的是使用另一种方式看待问题。我想跟大家聊一聊建立和学习一种接受错误的文化。我相信这种兼收并蓄的文化就是拥抱和注入失败，这也是我今天所要讨论的。

哲学家尼采说，"任何勇敢的人面对已知的危险也会缺乏勇气"。我们要试图更多地去建立这样的勇气：尝试接受失败终将发生的想法，也要你的组员接受失败并且能够庆祝失败的发生，而且能够意识到我们能够从失败中学到很多东西。

所以，我们要做些什么事儿呢？好的，今天我将讲一讲混沌工程。在座的各位是否可以举手示意我，有多少人听说过混沌工程？酷！太棒了！很高兴听说大家已经在生产环境的测试中讨论混沌工程了！它已经传播开了！

那么让我们再概括一下，什么是混沌工程呢？混沌工程是为了揭露我们系统的弱点而设计的，经过深思熟虑和详尽计划的实验。它不是仅仅试图于进行实验并希望一切顺利；而是要进行深思熟虑和详尽计划的实验。

所以当同事们听到混沌工程的时候经常会像这样反应："等等！不！我不想让别人破坏我的生产环境仅仅是因为他们可以。"或者是我们事先没有做任何事儿就直接在周一向大家宣布："我们今天要在生产环境进行混沌工程实验"，然后同事们或者拔出网线或者关闭服务器等等各种混沌的事儿。不，这不是混沌工程实验，它们既没有详尽计划也没有深思熟虑。

所以在Gremlin我们把混沌工程类比于向你的系统中注入疫苗使得其从有害入侵中获得免疫。也就是说这实际上要让你的工程师们事先就准备好应对这些失败的场景。

爆炸半径

什么是混沌工程的法则呢？首先从一个实验出发。然后考虑它的爆炸半径并且进行下面的抉择，要么扩大实验爆炸半径并划定范围，要么打断实验并且修复未被揭露的问题，并且再次进行重复实验。

所以如图所示，这就是我们所说的爆炸半径。首先从一个非常非常小的初始测试开始，然后你可以看到混沌工程实验在扩大，再之后你也许会看到混沌工程实验成功了，正如我们上文所描述的一样。这样的做法就好比，实际上你并不知道一个混沌工程实验会给你两个服务器带来什么样的影响，为什么你要在100%的资源上进行实验？所以你实际上需要从一个深思熟虑的方向出发，"我要从一个服务器开始，一个容器，就从一个服务开始。然后逐渐地持续地扩大爆炸半径"。

这也意味着，也许我还没有信心在我们的生产环境上进行混沌工程实验。没问题，我们可以从测试环境开始，从QA环境开始，在混沌工程实验成长到足够成熟之后，再于生产环境进行实验。

在我们讨论爆炸半径时，另外一件需要我们思考的事情是终止条件。是什么可以使得混沌工程实验停止下来呢？有一些实践包括了我们的错误率升高，比如当我看到用户的错误率升高或者API调用的错误频率增高，那么我们就触发使得实验停止。或者当我的用户出现了很多延迟，比如我们在一个iOS生产环境上运行关闭容器的混沌工程实验，当你看到先前只需几毫秒加载的图片需要五秒以上的时间才能在用户的屏幕上出现的时候，你可能实际上需要下一步的操作来停止这个实验了。

但是在讨论混沌工程的时候你还有一个事情需要考虑，就是你的混沌工程平台本身需要一个大红按钮（a big red button）！这个功能意味着当你从监视器或观测系统发现你的用户端受到了失败的混沌工程实验的影响，你有能力通过按下大红按钮来停止和恢复一切。

可见正如我所说，当我们实施混沌工程的时候，要深思熟虑和精心计划。我们使用科学的方式来达到这个目标。一切从一个假说（hypothesis）开始。比如我们说："如果我停止我的容器和Redis，我相信我的备用（Replica）Redis将会变成主要的（Primary）Redis。我不会遭受数据丢失的影响，我会继续享受良好的用户体验，一切都会平稳的运行，因为我有良好的Redis配置。"

让我们继续，你继续上述假说实施了混沌工程实验（我在去年11月的AWS re:Invent上也讨论了这个例子）。我们关闭了我的主要Redis容器，然后这下好了，我玩儿完了。因为我意识到我的开箱即用的Redis基本配置使得备份容器会观测主要Redis容器（以保持同步）。当主要Redis被关闭而备用Redis容器看到一个空的主要Redis容器时候，备用Redis容器也清空了自己本身，并且被提升为主要Redis容器。我们丢失了所有Redis中的数据！

当然了，如果你在生产环境实施了这个实验，那么数据的丢失会给你的公司带来很大的经济损失，你的用户也会怨声载道。所以你不必要做这么极端的实验。那么你要思考的是首先在一个相对安全的空间内实施混沌工程实验，这样实际上你可以验证配置的正确性，并且能够保证并通过监视工具和观测工具验证没有数据的丢失，这也是工程师需要付出行动的地方。因此，当客户再也无法访问应用程序上的任何数据时，你实际上并不会发现他们真的不满意。

下一步，当你看到混沌工程实验成功或者失败之后，你需要分享这些结果。你需要分享这些"失败"。你想告诉你的同事们："嗨，话说我们上个月实施了一些混沌工程实验，然后我们探测到应用程序没有正确的的配置，我们要做下面这些步骤可以让我们的应用程序更加有韧性，更加可靠。" 这样来分享实验结果是非常关键的一个部分。

（Ana再次展示了上图）这还是爆炸半径的图，我们把所有的东西都放在一起。首先我们实施第一个初始的混沌工程实验。我们分析这些结果，我们看到一切都很成功，因此我们拓展爆炸半径然后持续进行混沌工程实验。

游戏日

现在我想聊一点儿关于"失败"的文化，聊一点儿我看待失败发生的看法，以及我三年来实践混沌工程的更多感受。我之前加入Uber的混沌工程小组并且学习了如何搭建内部的工具，还为它的运行值守。它给我了很多乐趣，我也从中学习到了很多。但是这个经历也使我意识到我想要加入一个帮助其他企业进行混沌工程的公司。

接下来我要开始讲讲"游戏日"（Game Day）。在Gremlin，我们主动的拥抱失败并且不断地告诉我们的用户也要如此。当然我们告诉用户要用Gremlin来做这件事。但是还有一件事儿，嗯，就是我们做一个叫做"游戏日"的实践。简单来说我们把一个团队叫到一起，讨论他们的架构图并且思考什么样的错误和失败会发生。Gremlin实际上有一整捆如何进行游戏日的资源，他们放在一起包括了目录模板，可用的混堵工程实验模板，邮件模板等等。但是这个点子实际上是要大家在一起思考架构图，并且思考什么样的失败在什么地方会实际上发生。

这也是一个绝佳的时机回头来看事故发生后的回顾和思考，"嗨，我们实际上在几个月前发生过一个事故，现在我们想确定我们已经正确执行了应对措施。" 那么你就可以按照相同的条件来实施混沌工程实验，从而满足你的事故发生后的回顾需求。

所以在Gremlin我们实际上也是在这么做的。我们在Gremlin上使用Gremlin。我们明确的使用软件服务自我试用原则，我们也想确定它真的是具有韧性的并且能够为我们的员工展示其韧性。在两个月之前，我们把游戏日的线路图放在一起，并且收集同事们的想法。"嗨，你想做混沌工程实验，但是并不需要知道从哪里开始？" 这样我们就写出了像SRE手册一样的游戏日线路图，并且也思考了用SRE心态构建事物的方式的层次结构。

第一个基础层面就是要确定你的监测和告警要正确的配置和建立。我们现在已经发表了博客，介绍了Gremlin实施游戏日来验证我们的告警和监测系统。我们是上个月发表的，揭示了一大堆干货。我们已经能够从我们的监测工具Datadog中学到很多东西了。上周五我们刚刚在生产环境进行了游戏日。我们试图去验证生产环境的监测系统正确的运行。并且试图去回答同事们是从手册中寻找解决步骤还是真的从实验中得到启示而去解决问题。我们很高兴有这样的互动。
游戏日给我们带来的体验是能够把任何人聚集在一起。所以当我告诉别人他们想要把混沌工程带到他们的公司，实际上是在告诉他们："嗨，带上一些实习生，中等水平的工程师和你的架构师们，这样你可以分享知识，并且能够一起学习，检查最终的决定，最后我们就能为公司带来成功。"

星期四下架

另外一个我们不断拥抱失败并且能够实施一些混沌工程实验的事情叫做"星期四下架"（Takedown Thursdays）。有趣的是，我们之前把它叫做"星期五宕机"（Failure Fridays），但是随着公司的发展壮大，我们意识到在周五晚上进行混沌工程实验真的变得越来越困难了。我们有默认的远程工作模式，于是在东海岸的员工在周五就需要加班，于是为了他们我们就变成了"星期四下架"。我们在这天实际上会做一些新功能的发布，或者各种新的尝试。于是大家就聚到一起，主要是产品的工程师，他们会思考各种不同的毁坏产品的方法。所以你不仅仅是在使用这个产品应用，我们还在后端进行混沌工程实验，包括了底层的测试或者广泛意义上的应对高负载的事件。

我还要讨论一个的话题，使用混沌工程进行断路失败事后的重现能促进和提高"失败"文化。这也正是我们说的关注事故后的回顾并且再次思考。"嗨，我想确定工程师们介入并且修复了那些被标记和未被标记的根本问题。" 那些条件最终形成了混沌工程实验，这样你就能够使用这些行为再次进行验证。

在这部分"失败"的文化中，我们有好多人已经把系统事故的事后回顾和检查分享出去，分享给更大的平台，我们也从中学习到了很多东西。你可以去GitHub中搜索，那里已经有一大堆公开的事故的回顾和讨论。你更可以从中发现有趣的行为，也许有些正是你想在你的基础设施中，你的应用程序中，你的服务中实施的，通过这些条件你就可以形成混沌工程实验的配置。通过这样的方式你就可以思考，"嘿，大家在分享他们关于失败的想法，让我们看看他们实际上是否可以应用在我的场景中"。

On-Call和培训

下一个实践，在随时待命值班（On-call）的培训中使用混沌工程。好了，大家是否在随时待命交接班的时候仅仅被丢过来一张纸，"嗨，轮到你了，干活吧！" 也许还有一本手册。这就是我实际上经历的事儿。我入职公司第三周的时候，没有任何生产环境（的经验）也没有任何系统的知识，然后在我值班的第二周凌晨三点我们的生产环境发生了宕机。阅读那本手册真的是太可怕了。我还是主任值班人，凌晨三点的时候，你能想象到我(相当崩溃)。公司并没有能够向上升级汇报的必要文化。

所以我当时吓坏了，我就想"好了，我知道我们有这本手册，我们有所有的这些仪表板。" 我过去看着他们，并且执行了手册上描述的必要步骤。但是我十分的害怕。我当时想的是"噢，也许我明天进了公司发现自己就被开了"。总体的感受一点也不好。糟糕的是那本手册好像是180年前的一样，所以在值班时候有一本陈旧的手册事情就变得更糟糕了。现在回想起来我更希望我值班时候会有一些关于怎么在心理上如何处理焦虑的培训，让我能够注视着我们的仪表板的同时更快节奏地输入命令，能够告诉同事我正在服务器上执行什么。

所以想象一下，无论是你的轮岗实习生，你将要发布新功能到生产环境的新入职的工程师，我们要把他们叫到一起来通过实施混沌工程实验的方式来进行培训。这是一个绝好的方式让大家一起学习过往的失败经验或者让大家思考新的可能发生的失败场景。

让我们概括一下，失败是可以接受的事情。我想让大家一起体验失败并从中一起学习。当我们理解了人类必然犯错便会拥抱错误，这样兼容并包的文化就能创造出一个环境。

Gremlin几个月前发布了免费产品。大家可以访问Gremlin.com注册并且体验混沌工程实验，只需要五分钟。我们有两个混沌工程实验可以实施在你的基础设施上，关闭系统，关闭容器和占满CPU使用率。这是一个很好的能够实际验证你的K8S环境是否真正可靠的方法，看他是否真实反应容器的空间，或者你的监视和告警正确配置，或者在CPU负载增高时弹性扩容是否能正确工作。

问答环节

观众1：大部分运维人员都知道系统哪里哪些部分是严重损坏的，他们也已经给出了很多优先级，比如"这里需要修复"。那么你是怎么从把系统毁坏的更严重和治疗这个系统中分配和安排时间的呢？你是怎么能够花时间去毁坏他们，与此同时你还已经知道有些毁坏的地方已经开始被修复了？

Ana：是的，我觉得这个例子更像这样。"我们已经足够混乱了，我们不想要系统里面更多的混乱了。我们为什么还要故意地做这个事情呢？" 所以项目经理是如何理解韧性的重要程度有时候十分关键。我们的做法之一就是实践游戏日。我们有时候会有公司的销售人员安排三个小时后的时间来一起体验破坏。这个既可以在开发环境也可以在生产环境。但是这个最重要的是始终拥抱失败去揭露失败并且讨论"这些P0的Jira任务到底是什么？"

Gremlin应对这个的做法是这样的。我们的工程师值班轮岗时候，并不会负责为他本周的当前项目值班。你会在另一个项目的Jira中工作，处理一些值班时候的事件，某些会变成影响韧性的事件，或者某些高优先级真正影响客户的事件。

所以，我们是通过试图把韧性当作产品的一部分来处理这个事情的，我们也试图制造这些P0的事件。

观众2：我们有一些共同的历史，我现在是来自Uber的SRE。我的问题是，混沌工程到底在测试什么（对象）呢？它是在测试基础设施？测试服务还是测试产品？

Ana：正如我们在Uber做的，我们有uDestory，它仅在基础设施层面工作。但是我们还可以向上层移动。我们可以把它上移到应用程序层面。所以在Gremlin，我们实际上不需要仅仅在基础设施层面进行混沌工程。我们有应用层面的混沌工程，现在我们有Java的库可以写入你的应用程序本身。它可以让你在程序内封装和调用来满足你自己的一些目标。这能让你更加的深思熟虑和计划你的实验。

我们把这个应用叫做ALFI（application level fault injection），即应用层面故障注入，这是我们来自Netflix的CEO提出的点子。他的想法是这样的，"我想实施混沌工程实验，但是我想在我房间中的PS主机上运行"。所以你要如何让你的混沌工程实验变得更加具体呢？使用ALFI你就可以不必要具体到EC2主机或者Lambda函数。同样的用这种方式你可以仅在你的安卓系统上制造事故而非iOS设备。

观众3：谢谢！这真是太有趣了！我好奇的是你是否发觉通过混沌工程拥抱失败，拥抱学习，拥抱持续学习的态度已经超越了工程本身？

Ana：是的，没错！我们在公司做游戏日的时候邀请了55人。我们有从销售，从市场部门来参与的同事，他们也在学习。在上周在生产环境进行的游戏日实践上，我们有销售的同事坐在一起观测仪表板，做笔记。工程师在指导他们如何使用仪表板，如何解读峰值数据。而他们也沉迷于这个工程的世界之中了。这个在我们的生活中是完全可行的，我们从自我的失败中学习，无论从事业，到学业，还是到我们的心里健康，我是深信不疑的。这在很大程度上告诉人们失败是可以的，分享你的失败，走到一起，从中吸取教训。

引用链接

[1] A Key to Success: Failure with Chaos Engineering: https://launchdarkly.com/blog...
[2] Ana Medina: https://twitter.com/Ana_M_Medina

来源：DevOpsXP
原文发表于LaunchDarkly博客，A Key to Success: Failure with Chaos Engineering[1]，- Kim Harrison, June 25, 2019
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

5月每周四晚8点，【冬哥有话说】质量与测试专场。公众号留言“质量”可获取地址

• 0506 朱少民 《如何最大化软件测试效能》
• 0513 陈琦 《数据驱动测试》
• 0520 陈霁 《没错，去QA是提高质量最有效的方法！》
• 0527 施慧斌 《DevOps实践之持续测试》