混沌实验

混沌实验

AWS 云上混沌工程实践之可行性评估篇

henrysher 发表了文章 • 0 个评论 • 420 次浏览 • 2019-04-27 10:19 • 来自相关话题

【编者的话】本文是亚马逊 AWS 博客混沌工程专栏的第二篇,该文厘清了混沌工程实验的目标,利用实验提前探知系统风险,采用架构和运维体系优化的方式来解决系统弱点,真正实现韧性架构,降低企业损失,提高故障免疫力。并通过对混沌工程实验的成熟度等级和接纳指数的深入描述 ...查看全部
【编者的话】本文是亚马逊 AWS 博客混沌工程专栏的第二篇,该文厘清了混沌工程实验的目标,利用实验提前探知系统风险,采用架构和运维体系优化的方式来解决系统弱点,真正实现韧性架构,降低企业损失,提高故障免疫力。并通过对混沌工程实验的成熟度等级和接纳指数的深入描述,探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性,以及未来的路线图计划。

自首篇《AWS云上混沌工程实践之启动篇》发表之后,引起了大家的兴趣,不少读者发信讨论。为了更好地围绕混沌工程实践分享我们的知识和经验,特此成立了混沌工程专栏以飨读者。

我们在启动篇中谈到混沌工程的发展不是一蹴而就的, Chaos Monkey 开创了混沌工程的先河,从对基础设施的扰动( EC2 实例随机终止 Chaos Monkey 、模拟可用区中断 Chaos Gorilla、模拟区域中断 Chaos Kong 等),到利用应用网关控制爆炸半径,再到精细化流量配比以区分影响,直至引入断路器实现真正无人值守的混沌工程实验平台。本篇是混沌工程专栏的第二篇,笔者会探讨大家比较关心的第一个问题——为了能够成功实施混沌工程实验有哪些可行性要求:对实现对象的架构要求?对实验技术能力的要求?对实验工具的要求?还是实验可控性的要求?通常分析这样的问题,我们必须首先弄清楚混沌工程实验的目标。有了明确的目标,才可以深入地评估所做的混沌工程实验是否“可行”,能否“成功实施“。
# 混沌工程的目标——实现韧性架构
正如 AWS CTO Werner Vogels 常说的“故障是注定的,随着时间的流逝,一切终将归于失败”。我们必须接受故障发生是新常态的想法,处在部分故障的系统正常运行是完全可行的。当我们处理多达几十个 EC2 实例的小型系统时,100% 的健康运行通常是正常状态,故障则是一种特殊情况。然而,在处理大规模系统时,即 100% 的健康运行几乎是不可能实现的。因此,运维的新常态便是接受部分故障。处在部分故障中的系统要求仍能正常运行对外提供服务,这就需要架构本身具备 Resilient 能力。这里我并不想把 “Resilient ” 翻译成弹性,而应该是韧性(具备恢复能力)。混沌工程就是利用实验提前探知系统风险,通过架构优化和运维模式的改进来解决系统风险,真正实现上述韧性架构,降低企业损失,提高故障免疫力。
#韧性架构的重要特征
##冗余性
架构的设计要增加冗余性,以便提高该系统的整体可用性。如在 AWS 云中,这意味着将其部署到多个可用区,甚至跨多个区域进行部署。
1.png

正如上图中所看到的那样,组件 X 的可用性是 99%(按今天的标准来说非常糟糕),但并行放置,增加冗余性,可以将系统的可用性提高到99.99%!如果将三个组件 X 并行放置,那么就可以达到 6 个 9 的可用性!这个结果很惊人,这就是为什么我们总是建议客户跨多个可用区设计架构。
##扩展性
架构的设计必须要考虑扩展性,即启用 Auto Scaling ,根据需求动态扩展资源 – 而不是手动执行 – 确保可以满足各种流量模式。如在 AWS 云中,可使用 Application Auto Scaling 功能为 EC2,DynamoDB 和 EMR 等服务提供相同的自动扩展引擎,以支持 AWS 外部服务的自动扩展。
##不可变基础设施
不可变基础设施指的是,每次部署都会替换相应的组件,不做更新。应用部署则使用金丝雀发布(俗称灰度发布),以减少部署新版本应用时出现故障的风险。使用这种技术,可以在真实的生产环境中进行测试,并在需要时进行快速回滚。
##无状态应用
无状态应用是自动扩展和不可变基础设施的先决条件,要求应用必须独立于先前的请求或会话,处理所有客户端请求,并且不会存储在本地磁盘或内存中。
##避免级联故障

级联故障指的是因依赖关系引发的局部故障导致整个系统崩溃(俗称蝴蝶效应)。架构设计必须考虑级联故障的处理方式:

  • 转移切换:当一个集群宕机时,所有的流量都转移到另一个集群,如跨可用区切换,或者跨区域切换。
  • 重试退避:指数退避算法逐渐对客户端重试请求减速,避免网络拥塞,同时添加抖动保证性能,详细讨论参看这里。
  • 超时机制:过载请求会将连接耗尽,导致系统宕机。超时机制的引入,服务的质量会下降但不至于系统全面崩溃。
  • 幂等操作:由于暂时的错误,客户端可能多次发送相同的请求,可能导致系统处理错误。幂等操作,一种可以反复重复的操作,没有副作用或应用程序的失败,可以消除上述隐患。
  • 服务降级:当服务器压力剧增的情况下,有策略地减少或退化部分服务,以此释放服务器资源以保证核心任务的正常运行,如只读模式、停用耗时耗资源的功能等等。
  • 拒绝服务:请求过载时,按优先级开始丢弃相应的请求。
  • 服务熔断:若某个目标服务调用过慢或者有大量超时,直接熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回响应,快速释放资源,待目标服务情况好转则恢复调用。

##基础设施即代码
基础设施即代码可减轻繁琐的手工配置和部署任务,由于可用完全相同的方式反复执行,因此解决了随时间推移引发的配置漂移问题,当有故障发生,基础设施的恢复快速且有效。同时可对基础架构以代码的形式进行版本控制,管理其更新、审核、验证和回溯分析。

弄清楚了混沌工程的目标,现在可以来深入讨论如何来评估混沌工程实验的可行性条件。
# 混沌工程的可行性评估模型
在执行混沌工程实验时,我们需有一个通用的标准来,判断这个实验可不可行,做得好不好。混沌工程的可行性评估模型,结合了亚马逊和Netflix的混沌工程成熟度模型,从成熟度等级和接纳指数两个维度来衡量混沌工程实验成功实施的可行性:
##混沌工程实验的成熟度等级

成熟度可以反映出混沌工程实验的可行性、有效性和安全性。成熟度的级别也会因为混沌工程实验的投入程度而有差异。这里将成熟度等级分为1、2、3、4、5级进行描述,等级越高成熟度越好,混沌工程实验的可行性、有效性和安全性会更有保障。
WechatIMG145.png

##混沌工程实验的接纳指数
接纳指数通过对混沌工程实验覆盖的广度和深度来描述对系统的信心。暴露的脆弱点就越多,对系统的信心也就越足。类似成熟度等级,对接纳指数也定义了 1、2、3、4 级进行描述。
WechatIMG146.png

##混沌工程实验的可行性路线图
把当前项目进行成熟度等级和接纳指数的评估,将两者的结果合并放在一张图上,就可构建出类似于魔力象限的坐标轴。这不仅可以了解当前项目进行混沌工程实验的可行性,同时还可以与其他项目进行差异对比。此外,根据之前所讨论的混沌工程实验目标,设定想要达到的成熟度等级和接纳程度,便获得可行性路线图,了解自身努力的方向。
2.png

综上,本文是混沌工程专栏的第二篇,在此我们弄清楚了混沌工程实验的目标,并通过对混沌工程的成熟度等级和接纳指数的深入描述,探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性。

原文链接:AWS云上混沌工程实践之可行性评估篇(作者:黄帅)

AWS 云上混沌工程实践之启动篇

henrysher 发表了文章 • 0 个评论 • 470 次浏览 • 2019-04-27 09:27 • 来自相关话题

【编辑的话】亚马逊 AWS 官方博客开通了混沌工程专栏,此为首篇介绍混沌工程的文章。从混沌工程的基本概念出发,对现实中混沌工程实践的突出困惑做了分析和解答,并以混沌工程的演进时间线为例,详述了混沌工程社区的发展,不是一蹴而就,而是在实践中逐步深入对混沌工程的理 ...查看全部
【编辑的话】亚马逊 AWS 官方博客开通了混沌工程专栏,此为首篇介绍混沌工程的文章。从混沌工程的基本概念出发,对现实中混沌工程实践的突出困惑做了分析和解答,并以混沌工程的演进时间线为例,详述了混沌工程社区的发展,不是一蹴而就,而是在实践中逐步深入对混沌工程的理解:从最初对基础设施的扰动实验(Chaos Monkey),发展出整套猴子军团 Simian Army,为控制实验的爆炸半径提出故障注入测试(FIT),再到精细化流量配比以对照区分,直至引入断路器实现真正的无人值守。

工程师团队最不愿碰到的便是大半夜被电话叫醒,开始紧张地查验问题,处理故障以及恢复服务。也许就是因为睡前的一个很小的变更,因某种未预料到的场景,引起蝴蝶效应,导致大面积的系统混乱、故障和服务中断,对客户的业务造成影响。特别是近几年,尽管有充分的监控告警和故障处理流程,这样的新闻在 IT 行业仍时有耳闻。问题的症结便在于,对投入生产的复杂系统有多少信心。监控告警和故障处理都是事后的响应与被动的应对,那有没有可能提前发现这些复杂系统的弱点呢?
#混沌工程 Chaos Engineering
在分布式系统上进行由经验指导的受控实验,观察系统行为并发现系统弱点,以建立对系统在规模增大时因意外条件引发混乱的能力和信心。
#混沌工程发展简介
2008年8月, Netflix 主要数据库的故障导致了三天的停机, DVD 租赁业务中断,多个国家的大量用户受此影响。之后 Netflix 工程师着手寻找替代架构,并在 2011 年起,逐步将系统迁移到 AWS 上,运行基于微服务的新型分布式架构。这种架构消除了单点故障,但也引入了新的复杂性类型,需要更加可靠和容错的系统。为此, Netflix 工程师创建了 Chaos Monkey ,会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮,有足够的弹性,可以容忍计划外的故障。至此,混沌工程开始兴起。
aws-chaos-engineering-start1.png

混沌工程演进时间线

图中展示了混沌工程从 2010 年演进发展的时间线:

  • 2010 年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具:Chaos Monkey
  • 2011 年 Netflix 释出了其猴子军团工具集:Simian Army
  • 2012 年 Netflix 向社区开源由 Java 构建 Simian Army,其中包括 Chaos Monkey V1 版本
  • 2014 年 Netflix 开始正式公开招聘 Chaos Engineer
  • 2014 年 Netflix 提出了故障注入测试(FIT),利用微服务架构的特性,控制混沌实验的爆炸半径
  • 2015 年 Netflix 释出 Chaos Kong ,模拟 AWS 区域(Region)中断的场景
  • 2015 年 Netflix 和社区正式提出混沌工程的指导思想 —— Principles of Chaos Engineering
  • 2016 年 Kolton Andrus(前 Netflix 和 Amazon Chaos Engineer )创立了 Gremlin ,正式将混沌实验工具商用化
  • 2017 年 Netflix 开源 Chaos Monkey 由 Golang 重构的 V2 版本,必须集成 CD 工具 Spinnaker 来使用
  • 2017 年 Netflix 释出 ChAP (混沌实验自动平台),可视为应用故障注入测试(FIT)的加强版
  • 2017 年 由Netflix 前混沌工程师撰写的新书“混沌工程”在网上出版
  • 2017 年 Russell Miles 创立了 ChaosIQ 公司,并开源了 chaostoolkit 混沌实验框架
今天,许多公司包括 FANG,都有自己的 Chaos Engineer ,使用某种形式的混沌工程实验,来提高现代架构的可靠性。由于混沌工程的目的是给复杂的分布式系统引入扰动,并观察系统行为,借此发现系统弱点。因此,混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式,都需要科学的分析和有经验的混沌工程专家指导。根据笔者的观察,多数用户对混沌工程实践踌躇不前,总绕不开下面这几个问题:问题 1:混沌工程是不是只适合像 FANG 这样技术成熟的大公司,拥有复杂的分布式系统,很强的研发和运维能力?答:否。混沌工程进行的是探索系统复杂性的开放实验,目的是改善原有的系统架构和运维模式,加强业务服务的健壮性。没有像 FANG 那样复杂的分布式系统,一样需要混沌工程实践来达到健壮性的目的,只是混沌工程设计实施的复杂性不同、实践的成熟度不同:技术成熟的大公司,由于其系统的复杂性更大,无法完全理解透彻其上下游纷繁的依赖关系,因此更需要借助混沌工程实践,并利用自身较强的研发和运维能力,来深入了解系统行为以提高稳定性。另外,从资源获取的角度上看,在云上实施混沌工程实验,对其他公司而言,更加便捷有效。问题 2:混沌工程实验像 Chaos Monkey 只是杀杀机器而已,运维看看就好了吧?答:否。回溯混沌工程发展的时间线,业界对混沌工程的理解是逐步深入的。 Netflix 开发的 Chaos Monkey 成为了混沌工程的开端,但混沌工程不仅仅是 Chaos Monkey 这样一个随机终止 EC2 实例的实验工具。随后混沌工程师们发现,终止 EC2 实例只是其中一种实验场景。因此, Netflix 提出了 Simian Army 猴子军团工具集,除了 Chaos Monkey 外还包括:
  • Latency Monkey 在 RESTful 客户端到服务器通信中引入随机延迟,以模拟服务降级并测量上游服务是否正确响应。
  • Conformity Monkey 在发现不符合最佳实践的实例时将其关闭。
  • Doctor Monkey 会在每个实例中运行健康检查,同时也通过其他外部监控指标来检测不健康的实例。一旦检测到不健康的实例,将它们从服务中删除,并且在实例所有者找到问题的原因后终止。
  • Janitor Monkey 搜索未使用的资源并按规则处理,以确保AWS上的环境资源有效避免浪费。
  • Security Monkey 在发现安全违规或漏洞时,如发现未正确配置的AWS安全组,并终止使用该违规安全组的实例。此外,还会确保所有的 SSL 和 DRM 证书有效且无需续订。
  • 10-18 Monkey (l10n-i18n)针对多个区域和国家的客户提供服务的实例,检查有关语言和字符集的配置。
  • Chaos Gorilla 模拟了 AWS 可用区域(AZ)的中断,以验证服务是否会自动平衡至可用的 AZ,而无需人工干预,也不会给用户带来可见的影响。
使用 Simian Army 进行混沌工程实验,看起来似乎已经很完美。类似像 Latency Monkey 的引入,由于服务之间的调用链传递,到最后这个小的扰动到底会引发多大的故障,没有人可以预测。在生产上做这样不可控的实验,是很危险的。随着故障注入测试(FIT)的提出,社区开始关注利用应用架构的特性,特别是微服务架构,来控制实验的爆炸半径,比如 Netflix 使用 Zuul 强大的流量检查和管理功能,将受影响的请求隔离到特定的测试帐户或特定设备,避免 100% 的混乱。进一步分析发现, FIT 的执行过程也影响了整个系统的监控指标,即实验群体与其他非实验群体的统计指标混合不可分辨:无法确定实验的进行时间,无法评估其影响是否超过了系统本身的噪音。为了进一步的区分,则需要进行更多更大的实验,这将有可能给用户带来不必要的中断。因此需要对实验集群和非实验群集的流量配比进行精细控制,同时因应无人值守的实验要求,则引入微服务架构中的断路器,如其超出预定义的误差预算,自动结束实验。这就是为何 Netflix 提出了新的 ChAP(混沌实验自动平台)以加强故障注入测试。综上所述,混沌工程的发展不是一蹴而就的, Chaos Monkey 是其开端,但社区对混沌工程的理解在逐步深入,从对基础设施的扰动( EC2 实例随机终止等),到利用应用网关控制爆炸半径,再到精细化流量配比以区分影响,直至引入断路器实现真正的无人值守。混沌工程 9 年来的发展,由浅入深,由基础设施演进到应用架构,不是单单运维看看就好。问题 3:混沌工程实验的概念听着很吸引人,可是不知道从而下手。有没有什么实际可落地的框架和工具呢?答:笔者有幸参与了混沌工程的革新实践,总结起来对混沌工程的理解有两点特别重要:
  • 尽量减少实验的爆炸半径(故障注入测试的引入)
  • 为了确保不会破坏生产业务,工程团队需“精心策划”混沌工程实验。

混沌实验不只是测试,而是生成新知识的过程( Chaos Monkey -> Simian Army -> FIT -> ChAP ),混沌工程试验不仅仅是测试系统的一个案例。另一方面,混沌工程是一种产生新知识的方法。正是因为现代软件系统往往太复杂,任何人都无法完全理解它们,所以工程师通过混沌工程实验以揭示系统的更多面。

当然混沌工程实验有其自身的技术门槛,因此必须专家的指导并配以完善的混沌实验框架和工具。此为整个系列的首篇,后面笔者会深入探讨有关混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式等等问题 – stay tune for next episode!

原文链接:AWS云上混沌工程实践之启动篇(作者:黄帅)

AWS 云上混沌工程实践之可行性评估篇

henrysher 发表了文章 • 0 个评论 • 420 次浏览 • 2019-04-27 10:19 • 来自相关话题

【编者的话】本文是亚马逊 AWS 博客混沌工程专栏的第二篇,该文厘清了混沌工程实验的目标,利用实验提前探知系统风险,采用架构和运维体系优化的方式来解决系统弱点,真正实现韧性架构,降低企业损失,提高故障免疫力。并通过对混沌工程实验的成熟度等级和接纳指数的深入描述 ...查看全部
【编者的话】本文是亚马逊 AWS 博客混沌工程专栏的第二篇,该文厘清了混沌工程实验的目标,利用实验提前探知系统风险,采用架构和运维体系优化的方式来解决系统弱点,真正实现韧性架构,降低企业损失,提高故障免疫力。并通过对混沌工程实验的成熟度等级和接纳指数的深入描述,探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性,以及未来的路线图计划。

自首篇《AWS云上混沌工程实践之启动篇》发表之后,引起了大家的兴趣,不少读者发信讨论。为了更好地围绕混沌工程实践分享我们的知识和经验,特此成立了混沌工程专栏以飨读者。

我们在启动篇中谈到混沌工程的发展不是一蹴而就的, Chaos Monkey 开创了混沌工程的先河,从对基础设施的扰动( EC2 实例随机终止 Chaos Monkey 、模拟可用区中断 Chaos Gorilla、模拟区域中断 Chaos Kong 等),到利用应用网关控制爆炸半径,再到精细化流量配比以区分影响,直至引入断路器实现真正无人值守的混沌工程实验平台。本篇是混沌工程专栏的第二篇,笔者会探讨大家比较关心的第一个问题——为了能够成功实施混沌工程实验有哪些可行性要求:对实现对象的架构要求?对实验技术能力的要求?对实验工具的要求?还是实验可控性的要求?通常分析这样的问题,我们必须首先弄清楚混沌工程实验的目标。有了明确的目标,才可以深入地评估所做的混沌工程实验是否“可行”,能否“成功实施“。
# 混沌工程的目标——实现韧性架构
正如 AWS CTO Werner Vogels 常说的“故障是注定的,随着时间的流逝,一切终将归于失败”。我们必须接受故障发生是新常态的想法,处在部分故障的系统正常运行是完全可行的。当我们处理多达几十个 EC2 实例的小型系统时,100% 的健康运行通常是正常状态,故障则是一种特殊情况。然而,在处理大规模系统时,即 100% 的健康运行几乎是不可能实现的。因此,运维的新常态便是接受部分故障。处在部分故障中的系统要求仍能正常运行对外提供服务,这就需要架构本身具备 Resilient 能力。这里我并不想把 “Resilient ” 翻译成弹性,而应该是韧性(具备恢复能力)。混沌工程就是利用实验提前探知系统风险,通过架构优化和运维模式的改进来解决系统风险,真正实现上述韧性架构,降低企业损失,提高故障免疫力。
#韧性架构的重要特征
##冗余性
架构的设计要增加冗余性,以便提高该系统的整体可用性。如在 AWS 云中,这意味着将其部署到多个可用区,甚至跨多个区域进行部署。
1.png

正如上图中所看到的那样,组件 X 的可用性是 99%(按今天的标准来说非常糟糕),但并行放置,增加冗余性,可以将系统的可用性提高到99.99%!如果将三个组件 X 并行放置,那么就可以达到 6 个 9 的可用性!这个结果很惊人,这就是为什么我们总是建议客户跨多个可用区设计架构。
##扩展性
架构的设计必须要考虑扩展性,即启用 Auto Scaling ,根据需求动态扩展资源 – 而不是手动执行 – 确保可以满足各种流量模式。如在 AWS 云中,可使用 Application Auto Scaling 功能为 EC2,DynamoDB 和 EMR 等服务提供相同的自动扩展引擎,以支持 AWS 外部服务的自动扩展。
##不可变基础设施
不可变基础设施指的是,每次部署都会替换相应的组件,不做更新。应用部署则使用金丝雀发布(俗称灰度发布),以减少部署新版本应用时出现故障的风险。使用这种技术,可以在真实的生产环境中进行测试,并在需要时进行快速回滚。
##无状态应用
无状态应用是自动扩展和不可变基础设施的先决条件,要求应用必须独立于先前的请求或会话,处理所有客户端请求,并且不会存储在本地磁盘或内存中。
##避免级联故障

级联故障指的是因依赖关系引发的局部故障导致整个系统崩溃(俗称蝴蝶效应)。架构设计必须考虑级联故障的处理方式:

  • 转移切换:当一个集群宕机时,所有的流量都转移到另一个集群,如跨可用区切换,或者跨区域切换。
  • 重试退避:指数退避算法逐渐对客户端重试请求减速,避免网络拥塞,同时添加抖动保证性能,详细讨论参看这里。
  • 超时机制:过载请求会将连接耗尽,导致系统宕机。超时机制的引入,服务的质量会下降但不至于系统全面崩溃。
  • 幂等操作:由于暂时的错误,客户端可能多次发送相同的请求,可能导致系统处理错误。幂等操作,一种可以反复重复的操作,没有副作用或应用程序的失败,可以消除上述隐患。
  • 服务降级:当服务器压力剧增的情况下,有策略地减少或退化部分服务,以此释放服务器资源以保证核心任务的正常运行,如只读模式、停用耗时耗资源的功能等等。
  • 拒绝服务:请求过载时,按优先级开始丢弃相应的请求。
  • 服务熔断:若某个目标服务调用过慢或者有大量超时,直接熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回响应,快速释放资源,待目标服务情况好转则恢复调用。

##基础设施即代码
基础设施即代码可减轻繁琐的手工配置和部署任务,由于可用完全相同的方式反复执行,因此解决了随时间推移引发的配置漂移问题,当有故障发生,基础设施的恢复快速且有效。同时可对基础架构以代码的形式进行版本控制,管理其更新、审核、验证和回溯分析。

弄清楚了混沌工程的目标,现在可以来深入讨论如何来评估混沌工程实验的可行性条件。
# 混沌工程的可行性评估模型
在执行混沌工程实验时,我们需有一个通用的标准来,判断这个实验可不可行,做得好不好。混沌工程的可行性评估模型,结合了亚马逊和Netflix的混沌工程成熟度模型,从成熟度等级和接纳指数两个维度来衡量混沌工程实验成功实施的可行性:
##混沌工程实验的成熟度等级

成熟度可以反映出混沌工程实验的可行性、有效性和安全性。成熟度的级别也会因为混沌工程实验的投入程度而有差异。这里将成熟度等级分为1、2、3、4、5级进行描述,等级越高成熟度越好,混沌工程实验的可行性、有效性和安全性会更有保障。
WechatIMG145.png

##混沌工程实验的接纳指数
接纳指数通过对混沌工程实验覆盖的广度和深度来描述对系统的信心。暴露的脆弱点就越多,对系统的信心也就越足。类似成熟度等级,对接纳指数也定义了 1、2、3、4 级进行描述。
WechatIMG146.png

##混沌工程实验的可行性路线图
把当前项目进行成熟度等级和接纳指数的评估,将两者的结果合并放在一张图上,就可构建出类似于魔力象限的坐标轴。这不仅可以了解当前项目进行混沌工程实验的可行性,同时还可以与其他项目进行差异对比。此外,根据之前所讨论的混沌工程实验目标,设定想要达到的成熟度等级和接纳程度,便获得可行性路线图,了解自身努力的方向。
2.png

综上,本文是混沌工程专栏的第二篇,在此我们弄清楚了混沌工程实验的目标,并通过对混沌工程的成熟度等级和接纳指数的深入描述,探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性。

原文链接:AWS云上混沌工程实践之可行性评估篇(作者:黄帅)

AWS 云上混沌工程实践之启动篇

henrysher 发表了文章 • 0 个评论 • 470 次浏览 • 2019-04-27 09:27 • 来自相关话题

【编辑的话】亚马逊 AWS 官方博客开通了混沌工程专栏,此为首篇介绍混沌工程的文章。从混沌工程的基本概念出发,对现实中混沌工程实践的突出困惑做了分析和解答,并以混沌工程的演进时间线为例,详述了混沌工程社区的发展,不是一蹴而就,而是在实践中逐步深入对混沌工程的理 ...查看全部
【编辑的话】亚马逊 AWS 官方博客开通了混沌工程专栏,此为首篇介绍混沌工程的文章。从混沌工程的基本概念出发,对现实中混沌工程实践的突出困惑做了分析和解答,并以混沌工程的演进时间线为例,详述了混沌工程社区的发展,不是一蹴而就,而是在实践中逐步深入对混沌工程的理解:从最初对基础设施的扰动实验(Chaos Monkey),发展出整套猴子军团 Simian Army,为控制实验的爆炸半径提出故障注入测试(FIT),再到精细化流量配比以对照区分,直至引入断路器实现真正的无人值守。

工程师团队最不愿碰到的便是大半夜被电话叫醒,开始紧张地查验问题,处理故障以及恢复服务。也许就是因为睡前的一个很小的变更,因某种未预料到的场景,引起蝴蝶效应,导致大面积的系统混乱、故障和服务中断,对客户的业务造成影响。特别是近几年,尽管有充分的监控告警和故障处理流程,这样的新闻在 IT 行业仍时有耳闻。问题的症结便在于,对投入生产的复杂系统有多少信心。监控告警和故障处理都是事后的响应与被动的应对,那有没有可能提前发现这些复杂系统的弱点呢?
#混沌工程 Chaos Engineering
在分布式系统上进行由经验指导的受控实验,观察系统行为并发现系统弱点,以建立对系统在规模增大时因意外条件引发混乱的能力和信心。
#混沌工程发展简介
2008年8月, Netflix 主要数据库的故障导致了三天的停机, DVD 租赁业务中断,多个国家的大量用户受此影响。之后 Netflix 工程师着手寻找替代架构,并在 2011 年起,逐步将系统迁移到 AWS 上,运行基于微服务的新型分布式架构。这种架构消除了单点故障,但也引入了新的复杂性类型,需要更加可靠和容错的系统。为此, Netflix 工程师创建了 Chaos Monkey ,会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮,有足够的弹性,可以容忍计划外的故障。至此,混沌工程开始兴起。
aws-chaos-engineering-start1.png

混沌工程演进时间线

图中展示了混沌工程从 2010 年演进发展的时间线:

  • 2010 年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具:Chaos Monkey
  • 2011 年 Netflix 释出了其猴子军团工具集:Simian Army
  • 2012 年 Netflix 向社区开源由 Java 构建 Simian Army,其中包括 Chaos Monkey V1 版本
  • 2014 年 Netflix 开始正式公开招聘 Chaos Engineer
  • 2014 年 Netflix 提出了故障注入测试(FIT),利用微服务架构的特性,控制混沌实验的爆炸半径
  • 2015 年 Netflix 释出 Chaos Kong ,模拟 AWS 区域(Region)中断的场景
  • 2015 年 Netflix 和社区正式提出混沌工程的指导思想 —— Principles of Chaos Engineering
  • 2016 年 Kolton Andrus(前 Netflix 和 Amazon Chaos Engineer )创立了 Gremlin ,正式将混沌实验工具商用化
  • 2017 年 Netflix 开源 Chaos Monkey 由 Golang 重构的 V2 版本,必须集成 CD 工具 Spinnaker 来使用
  • 2017 年 Netflix 释出 ChAP (混沌实验自动平台),可视为应用故障注入测试(FIT)的加强版
  • 2017 年 由Netflix 前混沌工程师撰写的新书“混沌工程”在网上出版
  • 2017 年 Russell Miles 创立了 ChaosIQ 公司,并开源了 chaostoolkit 混沌实验框架
今天,许多公司包括 FANG,都有自己的 Chaos Engineer ,使用某种形式的混沌工程实验,来提高现代架构的可靠性。由于混沌工程的目的是给复杂的分布式系统引入扰动,并观察系统行为,借此发现系统弱点。因此,混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式,都需要科学的分析和有经验的混沌工程专家指导。根据笔者的观察,多数用户对混沌工程实践踌躇不前,总绕不开下面这几个问题:问题 1:混沌工程是不是只适合像 FANG 这样技术成熟的大公司,拥有复杂的分布式系统,很强的研发和运维能力?答:否。混沌工程进行的是探索系统复杂性的开放实验,目的是改善原有的系统架构和运维模式,加强业务服务的健壮性。没有像 FANG 那样复杂的分布式系统,一样需要混沌工程实践来达到健壮性的目的,只是混沌工程设计实施的复杂性不同、实践的成熟度不同:技术成熟的大公司,由于其系统的复杂性更大,无法完全理解透彻其上下游纷繁的依赖关系,因此更需要借助混沌工程实践,并利用自身较强的研发和运维能力,来深入了解系统行为以提高稳定性。另外,从资源获取的角度上看,在云上实施混沌工程实验,对其他公司而言,更加便捷有效。问题 2:混沌工程实验像 Chaos Monkey 只是杀杀机器而已,运维看看就好了吧?答:否。回溯混沌工程发展的时间线,业界对混沌工程的理解是逐步深入的。 Netflix 开发的 Chaos Monkey 成为了混沌工程的开端,但混沌工程不仅仅是 Chaos Monkey 这样一个随机终止 EC2 实例的实验工具。随后混沌工程师们发现,终止 EC2 实例只是其中一种实验场景。因此, Netflix 提出了 Simian Army 猴子军团工具集,除了 Chaos Monkey 外还包括:
  • Latency Monkey 在 RESTful 客户端到服务器通信中引入随机延迟,以模拟服务降级并测量上游服务是否正确响应。
  • Conformity Monkey 在发现不符合最佳实践的实例时将其关闭。
  • Doctor Monkey 会在每个实例中运行健康检查,同时也通过其他外部监控指标来检测不健康的实例。一旦检测到不健康的实例,将它们从服务中删除,并且在实例所有者找到问题的原因后终止。
  • Janitor Monkey 搜索未使用的资源并按规则处理,以确保AWS上的环境资源有效避免浪费。
  • Security Monkey 在发现安全违规或漏洞时,如发现未正确配置的AWS安全组,并终止使用该违规安全组的实例。此外,还会确保所有的 SSL 和 DRM 证书有效且无需续订。
  • 10-18 Monkey (l10n-i18n)针对多个区域和国家的客户提供服务的实例,检查有关语言和字符集的配置。
  • Chaos Gorilla 模拟了 AWS 可用区域(AZ)的中断,以验证服务是否会自动平衡至可用的 AZ,而无需人工干预,也不会给用户带来可见的影响。
使用 Simian Army 进行混沌工程实验,看起来似乎已经很完美。类似像 Latency Monkey 的引入,由于服务之间的调用链传递,到最后这个小的扰动到底会引发多大的故障,没有人可以预测。在生产上做这样不可控的实验,是很危险的。随着故障注入测试(FIT)的提出,社区开始关注利用应用架构的特性,特别是微服务架构,来控制实验的爆炸半径,比如 Netflix 使用 Zuul 强大的流量检查和管理功能,将受影响的请求隔离到特定的测试帐户或特定设备,避免 100% 的混乱。进一步分析发现, FIT 的执行过程也影响了整个系统的监控指标,即实验群体与其他非实验群体的统计指标混合不可分辨:无法确定实验的进行时间,无法评估其影响是否超过了系统本身的噪音。为了进一步的区分,则需要进行更多更大的实验,这将有可能给用户带来不必要的中断。因此需要对实验集群和非实验群集的流量配比进行精细控制,同时因应无人值守的实验要求,则引入微服务架构中的断路器,如其超出预定义的误差预算,自动结束实验。这就是为何 Netflix 提出了新的 ChAP(混沌实验自动平台)以加强故障注入测试。综上所述,混沌工程的发展不是一蹴而就的, Chaos Monkey 是其开端,但社区对混沌工程的理解在逐步深入,从对基础设施的扰动( EC2 实例随机终止等),到利用应用网关控制爆炸半径,再到精细化流量配比以区分影响,直至引入断路器实现真正的无人值守。混沌工程 9 年来的发展,由浅入深,由基础设施演进到应用架构,不是单单运维看看就好。问题 3:混沌工程实验的概念听着很吸引人,可是不知道从而下手。有没有什么实际可落地的框架和工具呢?答:笔者有幸参与了混沌工程的革新实践,总结起来对混沌工程的理解有两点特别重要:
  • 尽量减少实验的爆炸半径(故障注入测试的引入)
  • 为了确保不会破坏生产业务,工程团队需“精心策划”混沌工程实验。

混沌实验不只是测试,而是生成新知识的过程( Chaos Monkey -> Simian Army -> FIT -> ChAP ),混沌工程试验不仅仅是测试系统的一个案例。另一方面,混沌工程是一种产生新知识的方法。正是因为现代软件系统往往太复杂,任何人都无法完全理解它们,所以工程师通过混沌工程实验以揭示系统的更多面。

当然混沌工程实验有其自身的技术门槛,因此必须专家的指导并配以完善的混沌实验框架和工具。此为整个系列的首篇,后面笔者会深入探讨有关混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式等等问题 – stay tune for next episode!

原文链接:AWS云上混沌工程实践之启动篇(作者:黄帅)

AWS 云上混沌工程实践之可行性评估篇

henrysher 发表了文章 • 0 个评论 • 420 次浏览 • 2019-04-27 10:19 • 来自相关话题

【编者的话】本文是亚马逊 AWS 博客混沌工程专栏的第二篇,该文厘清了混沌工程实验的目标,利用实验提前探知系统风险,采用架构和运维体系优化的方式来解决系统弱点,真正实现韧性架构,降低企业损失,提高故障免疫力。并通过对混沌工程实验的成熟度等级和接纳指数的深入描述 ...查看全部
【编者的话】本文是亚马逊 AWS 博客混沌工程专栏的第二篇,该文厘清了混沌工程实验的目标,利用实验提前探知系统风险,采用架构和运维体系优化的方式来解决系统弱点,真正实现韧性架构,降低企业损失,提高故障免疫力。并通过对混沌工程实验的成熟度等级和接纳指数的深入描述,探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性,以及未来的路线图计划。

自首篇《AWS云上混沌工程实践之启动篇》发表之后,引起了大家的兴趣,不少读者发信讨论。为了更好地围绕混沌工程实践分享我们的知识和经验,特此成立了混沌工程专栏以飨读者。

我们在启动篇中谈到混沌工程的发展不是一蹴而就的, Chaos Monkey 开创了混沌工程的先河,从对基础设施的扰动( EC2 实例随机终止 Chaos Monkey 、模拟可用区中断 Chaos Gorilla、模拟区域中断 Chaos Kong 等),到利用应用网关控制爆炸半径,再到精细化流量配比以区分影响,直至引入断路器实现真正无人值守的混沌工程实验平台。本篇是混沌工程专栏的第二篇,笔者会探讨大家比较关心的第一个问题——为了能够成功实施混沌工程实验有哪些可行性要求:对实现对象的架构要求?对实验技术能力的要求?对实验工具的要求?还是实验可控性的要求?通常分析这样的问题,我们必须首先弄清楚混沌工程实验的目标。有了明确的目标,才可以深入地评估所做的混沌工程实验是否“可行”,能否“成功实施“。
# 混沌工程的目标——实现韧性架构
正如 AWS CTO Werner Vogels 常说的“故障是注定的,随着时间的流逝,一切终将归于失败”。我们必须接受故障发生是新常态的想法,处在部分故障的系统正常运行是完全可行的。当我们处理多达几十个 EC2 实例的小型系统时,100% 的健康运行通常是正常状态,故障则是一种特殊情况。然而,在处理大规模系统时,即 100% 的健康运行几乎是不可能实现的。因此,运维的新常态便是接受部分故障。处在部分故障中的系统要求仍能正常运行对外提供服务,这就需要架构本身具备 Resilient 能力。这里我并不想把 “Resilient ” 翻译成弹性,而应该是韧性(具备恢复能力)。混沌工程就是利用实验提前探知系统风险,通过架构优化和运维模式的改进来解决系统风险,真正实现上述韧性架构,降低企业损失,提高故障免疫力。
#韧性架构的重要特征
##冗余性
架构的设计要增加冗余性,以便提高该系统的整体可用性。如在 AWS 云中,这意味着将其部署到多个可用区,甚至跨多个区域进行部署。
1.png

正如上图中所看到的那样,组件 X 的可用性是 99%(按今天的标准来说非常糟糕),但并行放置,增加冗余性,可以将系统的可用性提高到99.99%!如果将三个组件 X 并行放置,那么就可以达到 6 个 9 的可用性!这个结果很惊人,这就是为什么我们总是建议客户跨多个可用区设计架构。
##扩展性
架构的设计必须要考虑扩展性,即启用 Auto Scaling ,根据需求动态扩展资源 – 而不是手动执行 – 确保可以满足各种流量模式。如在 AWS 云中,可使用 Application Auto Scaling 功能为 EC2,DynamoDB 和 EMR 等服务提供相同的自动扩展引擎,以支持 AWS 外部服务的自动扩展。
##不可变基础设施
不可变基础设施指的是,每次部署都会替换相应的组件,不做更新。应用部署则使用金丝雀发布(俗称灰度发布),以减少部署新版本应用时出现故障的风险。使用这种技术,可以在真实的生产环境中进行测试,并在需要时进行快速回滚。
##无状态应用
无状态应用是自动扩展和不可变基础设施的先决条件,要求应用必须独立于先前的请求或会话,处理所有客户端请求,并且不会存储在本地磁盘或内存中。
##避免级联故障

级联故障指的是因依赖关系引发的局部故障导致整个系统崩溃(俗称蝴蝶效应)。架构设计必须考虑级联故障的处理方式:

  • 转移切换:当一个集群宕机时,所有的流量都转移到另一个集群,如跨可用区切换,或者跨区域切换。
  • 重试退避:指数退避算法逐渐对客户端重试请求减速,避免网络拥塞,同时添加抖动保证性能,详细讨论参看这里。
  • 超时机制:过载请求会将连接耗尽,导致系统宕机。超时机制的引入,服务的质量会下降但不至于系统全面崩溃。
  • 幂等操作:由于暂时的错误,客户端可能多次发送相同的请求,可能导致系统处理错误。幂等操作,一种可以反复重复的操作,没有副作用或应用程序的失败,可以消除上述隐患。
  • 服务降级:当服务器压力剧增的情况下,有策略地减少或退化部分服务,以此释放服务器资源以保证核心任务的正常运行,如只读模式、停用耗时耗资源的功能等等。
  • 拒绝服务:请求过载时,按优先级开始丢弃相应的请求。
  • 服务熔断:若某个目标服务调用过慢或者有大量超时,直接熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回响应,快速释放资源,待目标服务情况好转则恢复调用。

##基础设施即代码
基础设施即代码可减轻繁琐的手工配置和部署任务,由于可用完全相同的方式反复执行,因此解决了随时间推移引发的配置漂移问题,当有故障发生,基础设施的恢复快速且有效。同时可对基础架构以代码的形式进行版本控制,管理其更新、审核、验证和回溯分析。

弄清楚了混沌工程的目标,现在可以来深入讨论如何来评估混沌工程实验的可行性条件。
# 混沌工程的可行性评估模型
在执行混沌工程实验时,我们需有一个通用的标准来,判断这个实验可不可行,做得好不好。混沌工程的可行性评估模型,结合了亚马逊和Netflix的混沌工程成熟度模型,从成熟度等级和接纳指数两个维度来衡量混沌工程实验成功实施的可行性:
##混沌工程实验的成熟度等级

成熟度可以反映出混沌工程实验的可行性、有效性和安全性。成熟度的级别也会因为混沌工程实验的投入程度而有差异。这里将成熟度等级分为1、2、3、4、5级进行描述,等级越高成熟度越好,混沌工程实验的可行性、有效性和安全性会更有保障。
WechatIMG145.png

##混沌工程实验的接纳指数
接纳指数通过对混沌工程实验覆盖的广度和深度来描述对系统的信心。暴露的脆弱点就越多,对系统的信心也就越足。类似成熟度等级,对接纳指数也定义了 1、2、3、4 级进行描述。
WechatIMG146.png

##混沌工程实验的可行性路线图
把当前项目进行成熟度等级和接纳指数的评估,将两者的结果合并放在一张图上,就可构建出类似于魔力象限的坐标轴。这不仅可以了解当前项目进行混沌工程实验的可行性,同时还可以与其他项目进行差异对比。此外,根据之前所讨论的混沌工程实验目标,设定想要达到的成熟度等级和接纳程度,便获得可行性路线图,了解自身努力的方向。
2.png

综上,本文是混沌工程专栏的第二篇,在此我们弄清楚了混沌工程实验的目标,并通过对混沌工程的成熟度等级和接纳指数的深入描述,探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性。

原文链接:AWS云上混沌工程实践之可行性评估篇(作者:黄帅)

AWS 云上混沌工程实践之启动篇

henrysher 发表了文章 • 0 个评论 • 470 次浏览 • 2019-04-27 09:27 • 来自相关话题

【编辑的话】亚马逊 AWS 官方博客开通了混沌工程专栏,此为首篇介绍混沌工程的文章。从混沌工程的基本概念出发,对现实中混沌工程实践的突出困惑做了分析和解答,并以混沌工程的演进时间线为例,详述了混沌工程社区的发展,不是一蹴而就,而是在实践中逐步深入对混沌工程的理 ...查看全部
【编辑的话】亚马逊 AWS 官方博客开通了混沌工程专栏,此为首篇介绍混沌工程的文章。从混沌工程的基本概念出发,对现实中混沌工程实践的突出困惑做了分析和解答,并以混沌工程的演进时间线为例,详述了混沌工程社区的发展,不是一蹴而就,而是在实践中逐步深入对混沌工程的理解:从最初对基础设施的扰动实验(Chaos Monkey),发展出整套猴子军团 Simian Army,为控制实验的爆炸半径提出故障注入测试(FIT),再到精细化流量配比以对照区分,直至引入断路器实现真正的无人值守。

工程师团队最不愿碰到的便是大半夜被电话叫醒,开始紧张地查验问题,处理故障以及恢复服务。也许就是因为睡前的一个很小的变更,因某种未预料到的场景,引起蝴蝶效应,导致大面积的系统混乱、故障和服务中断,对客户的业务造成影响。特别是近几年,尽管有充分的监控告警和故障处理流程,这样的新闻在 IT 行业仍时有耳闻。问题的症结便在于,对投入生产的复杂系统有多少信心。监控告警和故障处理都是事后的响应与被动的应对,那有没有可能提前发现这些复杂系统的弱点呢?
#混沌工程 Chaos Engineering
在分布式系统上进行由经验指导的受控实验,观察系统行为并发现系统弱点,以建立对系统在规模增大时因意外条件引发混乱的能力和信心。
#混沌工程发展简介
2008年8月, Netflix 主要数据库的故障导致了三天的停机, DVD 租赁业务中断,多个国家的大量用户受此影响。之后 Netflix 工程师着手寻找替代架构,并在 2011 年起,逐步将系统迁移到 AWS 上,运行基于微服务的新型分布式架构。这种架构消除了单点故障,但也引入了新的复杂性类型,需要更加可靠和容错的系统。为此, Netflix 工程师创建了 Chaos Monkey ,会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮,有足够的弹性,可以容忍计划外的故障。至此,混沌工程开始兴起。
aws-chaos-engineering-start1.png

混沌工程演进时间线

图中展示了混沌工程从 2010 年演进发展的时间线:

  • 2010 年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具:Chaos Monkey
  • 2011 年 Netflix 释出了其猴子军团工具集:Simian Army
  • 2012 年 Netflix 向社区开源由 Java 构建 Simian Army,其中包括 Chaos Monkey V1 版本
  • 2014 年 Netflix 开始正式公开招聘 Chaos Engineer
  • 2014 年 Netflix 提出了故障注入测试(FIT),利用微服务架构的特性,控制混沌实验的爆炸半径
  • 2015 年 Netflix 释出 Chaos Kong ,模拟 AWS 区域(Region)中断的场景
  • 2015 年 Netflix 和社区正式提出混沌工程的指导思想 —— Principles of Chaos Engineering
  • 2016 年 Kolton Andrus(前 Netflix 和 Amazon Chaos Engineer )创立了 Gremlin ,正式将混沌实验工具商用化
  • 2017 年 Netflix 开源 Chaos Monkey 由 Golang 重构的 V2 版本,必须集成 CD 工具 Spinnaker 来使用
  • 2017 年 Netflix 释出 ChAP (混沌实验自动平台),可视为应用故障注入测试(FIT)的加强版
  • 2017 年 由Netflix 前混沌工程师撰写的新书“混沌工程”在网上出版
  • 2017 年 Russell Miles 创立了 ChaosIQ 公司,并开源了 chaostoolkit 混沌实验框架
今天,许多公司包括 FANG,都有自己的 Chaos Engineer ,使用某种形式的混沌工程实验,来提高现代架构的可靠性。由于混沌工程的目的是给复杂的分布式系统引入扰动,并观察系统行为,借此发现系统弱点。因此,混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式,都需要科学的分析和有经验的混沌工程专家指导。根据笔者的观察,多数用户对混沌工程实践踌躇不前,总绕不开下面这几个问题:问题 1:混沌工程是不是只适合像 FANG 这样技术成熟的大公司,拥有复杂的分布式系统,很强的研发和运维能力?答:否。混沌工程进行的是探索系统复杂性的开放实验,目的是改善原有的系统架构和运维模式,加强业务服务的健壮性。没有像 FANG 那样复杂的分布式系统,一样需要混沌工程实践来达到健壮性的目的,只是混沌工程设计实施的复杂性不同、实践的成熟度不同:技术成熟的大公司,由于其系统的复杂性更大,无法完全理解透彻其上下游纷繁的依赖关系,因此更需要借助混沌工程实践,并利用自身较强的研发和运维能力,来深入了解系统行为以提高稳定性。另外,从资源获取的角度上看,在云上实施混沌工程实验,对其他公司而言,更加便捷有效。问题 2:混沌工程实验像 Chaos Monkey 只是杀杀机器而已,运维看看就好了吧?答:否。回溯混沌工程发展的时间线,业界对混沌工程的理解是逐步深入的。 Netflix 开发的 Chaos Monkey 成为了混沌工程的开端,但混沌工程不仅仅是 Chaos Monkey 这样一个随机终止 EC2 实例的实验工具。随后混沌工程师们发现,终止 EC2 实例只是其中一种实验场景。因此, Netflix 提出了 Simian Army 猴子军团工具集,除了 Chaos Monkey 外还包括:
  • Latency Monkey 在 RESTful 客户端到服务器通信中引入随机延迟,以模拟服务降级并测量上游服务是否正确响应。
  • Conformity Monkey 在发现不符合最佳实践的实例时将其关闭。
  • Doctor Monkey 会在每个实例中运行健康检查,同时也通过其他外部监控指标来检测不健康的实例。一旦检测到不健康的实例,将它们从服务中删除,并且在实例所有者找到问题的原因后终止。
  • Janitor Monkey 搜索未使用的资源并按规则处理,以确保AWS上的环境资源有效避免浪费。
  • Security Monkey 在发现安全违规或漏洞时,如发现未正确配置的AWS安全组,并终止使用该违规安全组的实例。此外,还会确保所有的 SSL 和 DRM 证书有效且无需续订。
  • 10-18 Monkey (l10n-i18n)针对多个区域和国家的客户提供服务的实例,检查有关语言和字符集的配置。
  • Chaos Gorilla 模拟了 AWS 可用区域(AZ)的中断,以验证服务是否会自动平衡至可用的 AZ,而无需人工干预,也不会给用户带来可见的影响。
使用 Simian Army 进行混沌工程实验,看起来似乎已经很完美。类似像 Latency Monkey 的引入,由于服务之间的调用链传递,到最后这个小的扰动到底会引发多大的故障,没有人可以预测。在生产上做这样不可控的实验,是很危险的。随着故障注入测试(FIT)的提出,社区开始关注利用应用架构的特性,特别是微服务架构,来控制实验的爆炸半径,比如 Netflix 使用 Zuul 强大的流量检查和管理功能,将受影响的请求隔离到特定的测试帐户或特定设备,避免 100% 的混乱。进一步分析发现, FIT 的执行过程也影响了整个系统的监控指标,即实验群体与其他非实验群体的统计指标混合不可分辨:无法确定实验的进行时间,无法评估其影响是否超过了系统本身的噪音。为了进一步的区分,则需要进行更多更大的实验,这将有可能给用户带来不必要的中断。因此需要对实验集群和非实验群集的流量配比进行精细控制,同时因应无人值守的实验要求,则引入微服务架构中的断路器,如其超出预定义的误差预算,自动结束实验。这就是为何 Netflix 提出了新的 ChAP(混沌实验自动平台)以加强故障注入测试。综上所述,混沌工程的发展不是一蹴而就的, Chaos Monkey 是其开端,但社区对混沌工程的理解在逐步深入,从对基础设施的扰动( EC2 实例随机终止等),到利用应用网关控制爆炸半径,再到精细化流量配比以区分影响,直至引入断路器实现真正的无人值守。混沌工程 9 年来的发展,由浅入深,由基础设施演进到应用架构,不是单单运维看看就好。问题 3:混沌工程实验的概念听着很吸引人,可是不知道从而下手。有没有什么实际可落地的框架和工具呢?答:笔者有幸参与了混沌工程的革新实践,总结起来对混沌工程的理解有两点特别重要:
  • 尽量减少实验的爆炸半径(故障注入测试的引入)
  • 为了确保不会破坏生产业务,工程团队需“精心策划”混沌工程实验。

混沌实验不只是测试,而是生成新知识的过程( Chaos Monkey -> Simian Army -> FIT -> ChAP ),混沌工程试验不仅仅是测试系统的一个案例。另一方面,混沌工程是一种产生新知识的方法。正是因为现代软件系统往往太复杂,任何人都无法完全理解它们,所以工程师通过混沌工程实验以揭示系统的更多面。

当然混沌工程实验有其自身的技术门槛,因此必须专家的指导并配以完善的混沌实验框架和工具。此为整个系列的首篇,后面笔者会深入探讨有关混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式等等问题 – stay tune for next episode!

原文链接:AWS云上混沌工程实践之启动篇(作者:黄帅)