注意事项 佩雷夫 ：我们很高兴分享来自AWS高级技术推广人员Adrian Hornsby的精彩材料的翻译。 简而言之，他解释了旨在减轻IT系统故障后果的实验的重要性。 您可能已经听说过Chaos Monkey（甚至使用过类似的解决方案）？ 今天，作为一种称为“混沌工程”的活动的一部分，采用了这种工具的创建方法及其在更广泛的范围内的实现。 在本文中阅读有关它的更多信息。
“但是所有这些美丽的背后都是混乱和疯狂。” -制革墙
消防员 。 这些高素质的专家每天冒着生命危险，着火。 您知道在成为一名消防员之前，您需要花费至少600个小时进行培训吗？ 这仅仅是开始。 据报道，消防员最多训练80％的工作时间。
怎么了
当消防员用真火挣扎时，他需要适当的
直觉 。 为了开发它，您必须日复一日，日复一日地训练。 正如他们所说，实践可以创造奇迹。
“似乎它们渗透了火的本质； 菲尔博士的类似物就是火焰。” - 用计算机和直觉来扑灭野火
注意事项 佩雷夫 ：Phillip Calvin“ Phil” McGraw是一位美国心理学家，作家，受欢迎的电视节目“ Phil医生”的节目主持人，节目主持人为参与者提供解决问题的方案。从前在西雅图
在2000年代初期，
杰西·罗宾斯 （
Jesse Robbins）创立并领导了GameDay计划，他曾在亚马逊担任正式职务，名字
为Disaster 。 这是基于他作为消防员的经验。 GameDay旨在测试，教育和准备各种Amazon系统，软件和人员以应对潜在的危机情况。
就像消防员发展直觉来灭火一样，杰西（Jesse）即将帮助其直觉发展以应对大规模灾难性事件。
“ GameDay：通过破坏创造弹性”-Jesse RobbinsGameDay旨在通过将错误引入关键任务系统来提高亚马逊零售网站的弹性。
GameDay首先为整个公司发布了一系列计划中的培训警报的公告，例如，有时规模非常大，例如，禁用整个数据中心。 有关计划关闭的详细信息很少，并且给了小组几个月的准备时间。 演习的主要目的是检查工作人员是否可以应对当地危机并迅速消除其后果。
在这些练习中，使用了特殊的工具和流程（例如监视，警报和紧急呼叫）来分析和识别事件响应程序中的错误。 事实证明，GameDay完美地揭示了经典的建筑问题。 有时也有可能检测到所谓的“隐藏缺陷”-由于事件的具体细节而出现的问题。 例如，由于人为问题引起的意外副作用，对恢复过程至关重要的事件管理系统失败了。
随着公司的发展，GameDay失败的理论范围不断扩大。 最后，这些练习停止了：如果出现问题，对公司的潜在损害变得太大。 从那时起，该程序已退化为一系列不同的，不影响业务的实验，用于培训处于危机情况下的人员。 我不会在本文中详细介绍实验，但是将来会做。 这次，我想讨论GameDay背后的重要思想：
弹性工程 ，也称为
混沌工程 。
猴子崛起
您可能听说过在线视频内容提供商Netflix。 Netflix于2008年8月开始从自己的数据中心迁移到AWS Cloud。 此步骤是由于数据库严重损坏而导致的，由于DVD的交付延迟了三天（是的，Netflix开始通过普通邮件发送电影）。 向云的迁移与承受更高的流负载的需求以及放弃单片架构并转向易于根据用户数量和工程团队规模扩展的微服务的需求相关。 流服务的用户部分首先在2010年至2011年之间转移到AWS，然后是公司IT和所有其他结构。 Netflix自己的数据中心于2016年关闭。 该公司将可访问性衡量为成功上映影片的次数与总数的比率，而不是对正常运行时间和停机时间的简单比较，并尝试每季度在每个区域获得0.9999的数字（通常会成功）。 Netflix的全球架构跨越三个AWS区域。 因此，在其中一个地区出现问题的情况下，公司可以将用户重定向到其他地区。
我重复我最喜欢的一句话：
“失败是不可避免的； 最终，任何系统都会随着时间崩溃。” -Werner Vogels
实际上，即使在云中，分布式系统（尤其是大规模系统）的故障也是不可避免的。 但是，AWS云及其冗余原语-尤其是基于其构建
的多个访问区的
原理 -允许任何人设计高度可靠的服务。
借助冗余和
正常降级的原理，Netflix
设法在不影响最终用户的
情况下
幸免于难 。
从一开始，Netflix就一直遵循最严格的架构原则。 他们部署到AWS的首批应用程序之一是他们的
Chaos Monkey-支持自动缩放无状态微服务。 换句话说，任何实例都可以停止并自动替换，而不会丢失任何状态。 混沌猴子确保没有人违反这一原则。
注意事项 佩雷夫 ：顺便说一下，对于Kubernetes，有一个名为kube-monkey的类似物，其开发似乎已在今年3月停止。Netflix还有一条规则，该规则规定了在三个可用性区域中分配每种服务。 如果只有两个可用，它将继续工作。 为了确保符合此规则，
Chaos Gorilla禁用可用性区域。 在全球范围内，
Chaos Kong可以禁用整个AWS区域，以确认可以从这三个区域中的任何一个服务所有Netflix用户。 他们在生产中每隔几周进行一次大型测试，以确保没有任何东西引起关注。
最后，Netflix还开发了更具针对性的
混沌测试工具，以帮助检测微服务和存储体系结构的问题。 您可以从《混沌工程》一书中了解有关这些技术的更多信息，我推荐给对此主题感兴趣的任何人。
“通过定期进行模拟区域故障的实验，我们能够发现各种系统缺陷并在早期阶段消除它们。” -Netflix博客
今天，混沌工程学的原理已经
正式化 。 它们具有以下定义：
“混沌工程是一种涉及在生产系统上进行实验以确保其能够承受运行期间发生的各种干扰的能力的方法。” -Principlesofchaos.org
然而，在Netflix云架构的前创建者
Adrian Cockcroft 在AWS re：Invent 2018关于混沌工程的
演讲中 ，帮助公司完全转向云基础架构的前创建者
Adrian Cockcroft介绍了混沌工程的另一种定义。 在我看来，它更准确，更完善：
“混沌工程是旨在减轻故障后果的实验。”
实际上，我们知道崩溃一直在发生。 有了正确的响应，它们就不会影响最终用户。 混沌工程的主要目标是发现无法正确解决的问题。
造成混乱的前提
在着手进行混乱工程之前，请确保做所有必要的工作以确保组织各个层面的可持续性。 创建容错系统不仅仅是软件。 它从
基础架构级别开始，扩展到
网络和数据 ，影响
应用程序的结构，并最终包含
人员和文化 。 过去，我写了很多关于稳定性模型和失败的文章（
这里 ，
这里 ，
这里和
这里 ），现在我将不再专注于此，但是我不得不提醒一下。
将混乱引入系统之前的一些强制性元素（列表并不详尽）混沌工程的各个阶段
重要的是要理解，混沌工程的本质
不是让猴子松散，让它们无目的连续破坏一切。 该学科的重点是通过精心计划的实验来检查可控环境中系统的某些元素，以检查您的应用程序是否可以承受湍流条件。
为此，必须遵循下图所示的明确定义的正式流程。 有了它，您就可以从了解系统的稳定状态转变为提出假设，进行测试，最后分析实验中获得的经验并提高系统本身的稳定性。
混沌工程的各个阶段1.状况稳定
混沌工程最重要的元素之一是了解正常条件下系统的行为。
怎么了 这很简单：引入人为故障后，必须确保系统已返回经过充分研究的稳定状态，并且实验不再干扰其正常行为。
这里的关键点是，您不必关注系统的内部属性（处理器，内存等），而是监视可衡量的输出信号，这些信号将性能与用户体验联系起来。 为了使这些输出信号处于稳定状态，观察到的系统行为必须具有可预测的模式，但是当系统中发生故障时会发生显着变化。
牢记上面由Adrian Cockcroft提出
的混沌工程的
定义，当失控故障导致意外问题并发出应中断混沌实验的信号时，这种稳定状态就会改变。
作为稳定条件的一个例子，让我们引用亚马逊的经验。 该公司将订单数量用作稳定条件的指标之一，这是有充分理由的。 2007年，曾在亚马逊工作过的格雷格·林登（Greg Linden）谈到了作为使用
A / B测试方法的实验的一部分
，他如何尝试以100毫秒为增量来减慢网站页面的加载时间，并发现甚至造成了轻微的延迟导致收入严重下降。 随着100 ms的加载时间的增加，订单数量（因此销量）下降了1％。 这就是为什么订单数量是稳定指标的最佳选择的原因。
Netflix使用与播放开始相关的服务器端指标-播放按钮的点击次数。 他们注意到SPS指示器（每秒启动）的行为具有规律性，并且在发生系统故障时其波动很大。 该度量标准称为“ Netflix的
脉冲 ”（
Netflix的脉冲 ）。
就Amazon和Netflix Pulse而言，订单数量是出色的稳定性指标，因为它们将用户体验和运营指标结合为一个可衡量且高度可预测的指标。
再次测量，再测量
不用说，如果您无法正确记录系统的性能，那么您将无法监视稳定状态下的更改（甚至无法检测到它们）。 特别要注意从网络，硬件中删除所有参数/指示器，并以应用程序和人员结尾。 绘制这些测量的图表，即使它们不会随时间变化。 您会惊讶地发现自己不知道的相关性。
“使工程师尽可能容易地访问他们可以计算或转换为图形形式的数据。” - 伊恩·马尔帕斯 （ Ian Malpass）
2.假设
处理了稳定状态后，我们可以继续提出假设。
- 如果推荐机制停止，该怎么办？
- 如果负载均衡器掉了怎么办？
- 如果缓存消失了怎么办？
- 如果延迟增加300毫秒怎么办？
- 如果主库崩溃了怎么办？
当然，仅应选择一种假设，而不必不必要地使其复杂化。 从小开始。 我喜欢从员工假说开始。 您听说过
公交车因素吗？ 总线因素是一种风险度量，与知识在团队成员之间分布不均有关。 它使您可以计算出最少的参与者人数，然后由于缺乏知识或经验而导致项目突然中断，从而使参与者人数最少。
许多公司都有技术专家，他们的突然失踪（“被公共汽车撞中”）将对项目和团队造成破坏性影响。 确定这些人并在他们的参与下进行混乱的实验：例如，从他们那里拿走计算机并将其送回家一天，然后观察（通常是混乱的）结果。
使这个问题对所有人都有！
让
整个团队参与制定假设。 让所有人参与头脑风暴：产品所有者，技术经理，后端和前端开发人员，设计师，架构师等。 以某种方式与产品建立联系的每个人。
首先，请每个人对“如果……怎么办？”这个问题写下自己的答案。 在一张纸上。 您将看到，在大多数情况下，每个人都会有自己的答案，并且您将了解，团队中的某些部分仍然根本没有考虑过这样的问题。
到此为止，讨论在“如果...怎么办？”的情况下，为什么团队成员对产品行为有不同的看法。 返回其规范，并确保每个人都正确理解事件的可能发展。
以提到的亚马逊零售网站为例。 如果按类别购物服务停止在主页上加载怎么办？
我应该返回404错误吗？ 加载页面是否值得，在下面的屏幕截图中留出空白？
是否值得牺牲部分功能，例如让页面扩展并隐藏错误？
而且这仅在用户界面方面。 后端应该发生什么？ 是否应该发送警报？ 失败的服务应该在用户每次加载主页时继续接收请求，还是后端必须将其完全切断？
还有最后一个。 请不要提出一个假设，该假设事先已知会破坏柴火！ 用您认为稳定的系统部分进行实验-最终，这是整个实验的重点。3.设计并进行实验
- 选择一个假设；
- 定义实验范围；
- 定义要测量的相关指标；
- 通知组织。
如今，许多人以及
Principlesofchaos网站都在推广生产中的混沌工程学思想。 尽管这应该是最终目标，但是大多数组织都害怕这种方法，因此您不应该从此开始。
对我来说，混乱的工程不仅破坏了生产系统的各种要素。 这是一个旅程。 进入知识世界的旅程，与诸如在受控环境中破坏系统之类的活动密不可分-在任何环境中，无论是本地开发环境，测试版，暂存版还是产品。 通过精心设计的实验进行销毁，以增强您对应用程序耐受湍流条件的能力的信心。 在这种情况下，“
建立信心 ”是关键点，因为它是成功实施混沌工程和提高公司可靠性的实践所必需的文化变革的先驱。
老实说，即使在非生产环境中，大多数团队也会通过打破常规来学习很多东西。 只需尝试使
docker stop database在本地环境中
docker stop database ，然后查看是否可以处理此问题而不会产生任何后果。 没有的可能性很高。
数据库停止-示例从小处着手，逐步建立团队和组织内的信心。 您将被告知“实际的生产流量是可靠地捕获系统行为的唯一方法。” 倾听，微笑并继续慢慢做您正在做的事情。 您能做的最坏的事情是将混乱的工程应用到生产中，并且惨遭失败。 在那之后，没有人会相信您，您将被迫永远忘记“混乱的猴子”。
首先获得信誉。 向组织和同事表明您知道自己在做什么。 成为消防员，并在继续进行实弹训练之前，尽可能多地了解火焰。 赢得信誉。 还记得
乌龟和野兔的
故事吗？ 这场比赛总是由缓慢而耐心的人赢得。
实验过程中最重要的要点之一就是了解所引入故障的潜在
损坏半径并将其最小化。 问自己以下问题：
- 该实验将影响多少客户？
- 什么功能会受到影响？
- 哪些地方会受到影响？
考虑一下“紧急停止按钮”或立即终止实验并尽快返回稳定状态的方法。 我喜欢使用所谓的进行实验。 “金丝雀”推广。 通过逐步将更改逐步推广到一小部分用户，然后将其缓慢散布到整个基础架构和所有用户中，此技术可降低在生产环境中启动应用程序的新版本时出现故障的风险。 我之所以喜欢“金丝雀”推广，仅仅是因为它们满足
固定基础结构的原则，而且实验本身非常容易停止。
用于混乱实验的基于DNS的金丝雀推出示例小心更改应用程序状态（缓存或数据库）或无法回滚的实验（轻松或原则上）。
奇怪的是Adrian Cockcroft告诉我，Netflix开始使用NoSQL数据库的原因之一是缺乏对数据库进行更改或回滚的方案，因此用数据逐步更新或纠正单个记录要容易得多（即它们更容易对混乱的工程友好）。
4.观察和学习
为了学习新知识并监视实验进度，您必须能够跟踪系统性能。 如前所述，请充分注意各种指标和参数！ 然后始终量化结果-永远！ -注意直到出现问题的最初迹象为止的时间。 在我的历史中，屡屡发生警告系统被拒绝，并且第一个在Twitter上向客户报告问题的方法...相信我，您不希望遇到这种情况，因此请使用混乱的实验来检查您的监视和警告系统。
- 是时候发现了？
- 是时候提醒并开始积极行动了吗？
- 是时候发布公告了？
- 是时候部分失去功能了吗？
- 自愈期长短？
- 是时候完全恢复还是部分恢复？
- 是时候结束危机并回到稳定状态了吗？
请记住，没有单独的故障原因。 重大事故始终是几次小故障的累积，并导致大规模危机。
对每个实验进行详细的验尸分析！在AWS上，我们非常重视分析检测到的故障并了解导致它们将来防止类似问题的原因。 实验的所有结论和结果都汇总在一个称为“校正错误”（COE）的文档中。 COE使我们可以从错误中学习，无论是技术，流程还是组织方面的缺陷。 我们使用这种机制来消除故障和持续发展的根本原因。
在此过程中成功的关键是对问题出处保持公开和透明。 撰写好的COE时最重要的原则之一就是保持公正，避免提及特定的人。 在不鼓励这种行为并且不允许失败的环境中，这通常很困难。 亚马逊使用一系列
领导原则来促进这种行为-例如，
自我批评，分析方法，对最高标准的承诺和责任感是COE流程和总体上卓越运营的关键组成部分。
COE报告包含五个主要部分：
- 发生了什么（按时间顺序）？
- 对客户有什么影响？
- 为什么会发生错误？ （ 五个“为什么？” ）
- 我们学到了什么？
- 将来如何预防？
回答这些问题比乍看起来要困难得多，因为您需要确保仔细研究每个难以理解/未知的时刻。
为了使COE机制变成一个完整的过程，我们不断以每周会议的形式进行检查，并对运营指标进行强制性分析。 此外，领先的技术专家每周都会与所有AWS员工进行指标评估。
5.纠正和改善！
首先，这里的主要课程是
消除混乱实验中发现的问题，并为它们分配比开发新功能更高的优先级 。 让高层管理人员参与此过程，并向他介绍解决当前问题比开发新功能重要得多的想法。
一次，在一个混乱的实验的帮助下，我帮助客户确定了关键的稳定性问题，但是由于来自销售部门的压力，修复的优先级降低了，所有工作都致力于推出对客户“极其重要”的新事物。 两个星期后，一个16小时的停机时间迫使该公司解决了我们在混乱实验中发现的相同问题。 只有损失要高得多。
混沌工程的好处
有很多优点。 我认为，最重要的是两个：
首先，混乱的工程有助于解决系统中的未知问题，并在导致生产失败之前修复它们，例如在周日凌晨3点。 也就是说，它
提高了抗撞击性，实际上提高了睡眠质量 。
其次，有效进行的混乱实验总是会引起比预期更广泛的变化（主要是文化方面的变化）。 其中最重要的也许是当“为什么要这样做吗？”这个问题向
“ 非责备”文化的自然演变。 变成“将来如何避免这种情况？”。 结果，团队变得更快乐，更有效率，更有兴趣和成功。
这太好了！至此，第一部分结束。 希望您喜欢。 请发表评论，分享意见，或者只是在
Medium中鼓掌。 在下一部分中，我将介绍引入系统故障的工具和技术。 直到-再见！
对于那些渴望了解第二部分的人，我在奥斯陆的NDC上介绍了有关混沌工程的主题。 在其中，我谈论了许多我最喜欢的工具：
译者的PS
该文章的第二部分已经用英文发表 ，如果我们看到哈勃（Habré）的读者对此材料有足够的兴趣，我们还将对其进行翻译-欢迎对该文章发表相关评论！ 更新 （9月3日）：也
发布了第二部分的
翻译 。
更新 （12月19日）：
第三部分的
翻译已可用。
另请参阅我们的博客：