关于测试工具:Gremlin-拥抱失败的混沌工程实践-IDCF

2次阅读

共计 7421 个字符，预计需要花费 19 分钟才能阅读完成。

译者语：这是一篇 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 的混沌工程师。

易犯错的意思就是制作谬误或者犯错误。大家能够举手通知我是否有人已经犯过谬误呢？是的，是的，大家都会犯错，对吧？

我实际上想通知大家的是应用另一种形式对待问题。我想跟大家聊一聊建设和学习一种承受谬误的文化。我置信这种兼收并蓄的文化就是拥抱和注入失败，这也是我明天所要探讨的。

哲学家尼采说，” 任何勇敢的人面对已知的危险也会不足勇气 ”。咱们要试图更多地去建设这样的勇气：尝试承受失败终将产生的想法，也要你的组员承受失败并且可能庆贺失败的产生，而且可能意识到咱们可能从失败中学到很多货色。

所以，咱们要做些什么事儿呢？好的，明天我将讲一讲混沌工程。在座的各位是否能够举手示意我，有多少人据说过混沌工程？酷！太棒了！很快乐据说大家曾经在生产环境的测试中探讨混沌工程了！它曾经流传开了！

那么让咱们再概括一下，什么是混沌工程呢？混沌工程是为了揭发咱们零碎的弱点而设计的，通过三思而行和详尽打算的试验。它不是仅仅试图于进行试验并心愿一切顺利；而是要进行三思而行和详尽打算的试验。

所以当共事们听到混沌工程的时候常常会像这样反馈：” 等等！不！我不想让他人毁坏我的生产环境仅仅是因为他们能够。” 或者是咱们当时没有做任何事儿就间接在周一向大家发表：” 咱们明天要在生产环境进行混沌工程试验 ”，而后共事们或者插入网线或者敞开服务器等等各种混沌的事儿。不，这不是混沌工程试验，它们既没有详尽打算也没有三思而行。

所以在 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）的培训中应用混沌工程。好了，大家是否在随时待命交接班的时候仅仅被丢过去一张纸，” 嗨，轮到你了，干活吧！” 兴许还有一本手册。这就是我实际上经验的事儿。我入职公司第三周的时候，没有任何生产环境（的教训）也没有任何零碎的常识，而后在我值班的第二周凌晨三点咱们的生产环境产生了宕机。浏览那本手册真的是太可怕了。我还是主任值班人，凌晨三点的时候，你能设想到我 (相当解体)。公司并没有可能向上降级汇报的必要文化。

所以我过后吓坏了，我就想 ” 好了，我晓得咱们有这本手册，咱们有所有的这些仪表板。” 我过来看着他们，并且执行了手册上形容的必要步骤。然而我非常的胆怯。我过后想的是 ” 噢，兴许我今天进了公司发现自己就被开了 ”。总体的感触一点也不好。蹩脚的是那本手册如同是 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 点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址