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实践之持续测试》