阿里资深软件测试工程师推荐—混沌工程(Chaos Engineering)初识

阿里资深软件测试工程师推荐—混沌工程(Chaos Engineering)初识_第1张图片

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system's capability to withstand turbulent conditions in production.

——Principles of Chaos

混沌工程是在分布式系统上进行实验的学科,目的是建立对系统抵御生产环境中失控条件的能力以及信心。

一、概述

工程师团队最不愿碰到的便是大半夜被电话叫醒,开始紧张地查验问题,处理故障以及恢复服务。也许就是因为睡前的一个很小的变更,因某种未预料到的场景,引起蝴蝶效应,导致大面积的系统混乱、故障和服务中断,对客户的业务造成影响。特别是近几年,尽管有充分的监控告警和故障处理流程,这样的新闻在 IT 行业仍时有耳闻。问题的症结便在于,对投入生产的复杂系统有多少信心。监控告警和故障处理都是事后的响应与被动的应对,那有没有可能提前发现这些复杂系统的缺陷呢?

阿里资深软件测试工程师推荐—混沌工程(Chaos Engineering)初识_第2张图片

混沌工程在分布式系统上进行由经验指导的受控实验,观察系统行为并发现系统缺陷,以建立对系统在规模增大时因意外条件引发混乱的能力和信心。

1. 混沌工程的发展简史

2008年8月, Netflix 主要数据库的故障导致了三天的停机, DVD 租赁业务中断,多个国家的大量用户受此影响。之后 Netflix 工程师着手寻找替代架构,并在2011年起,逐步将系统迁移到 AWS 上,运行基于微服务的新型分布式架构。这种架构消除了单点故障,但也引入了新的复杂性类型,需要更加可靠和容错的系统。为此, Netflix 工程师创建了 Chaos Monkey ,会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮,有足够的弹性,可以容忍计划外的故障。至此,混沌工程开始兴起。

阿里资深软件测试工程师推荐—混沌工程(Chaos Engineering)初识_第3张图片

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

  • 2010年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具:Chaos Monkey

  • 2011年 Netflix release了其猴子军团工具集:Simian Army

  • 2012年 Netflix 向社区开源由 Java 构建 Simian Army,其中包括 Chaos Monkey V1 版本

  • 2014年 Netflix 开始正式公开招聘 Chaos Engineer

  • 2014年 Netflix 提出了故障注入测试(FIT),利用微服务架构的特性,控制混沌实验的爆炸半径

  • 2015年 Netflix release了 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 release了 ChAP (Chaos Automation Platform, 混沌实验自动平台),可视为应用故障注入测试(FIT)的加强版

  • 2017年 由Netflix 前混沌工程师撰写的新书“混沌工程”在网上出版

  • 2017年 Russell Miles 创立了 ChaosIQ 公司,并开源了 chaostoolkit 混沌实验框架

Netflix公司介绍

2. Chaos Monkey & Simian Army

为了更好的理解混沌工程,这里我们再着重介绍一下Chaos Monkey和Simian Army。Chaos Monkey 通过关停一个或多个虚拟机来模拟 service 实例的失效。Chaos Monkey 的名字来源于其工作的方式:如同一只野生的、武装了的猴子,在数据中心释放后,造成的严重破坏。

Chaos Monkey 的原则:避免大多数失效的主要方式就是经常失效。失效一定会发生,并且无法避免。在大多数情况下,我们的应用设计要保证当服务的某个实例下线时仍能继续工作,但是在那些特殊的场景下,我们需要确保有人在值守,以便解决问题,并从问题中进行经验学习。基于这个想法,Chaos Monkey 仅会在工作时间内被使用,以保证工程师能发现警告信息,并作出适当的回应。

混沌工程实验像 Chaos Monkey 只是杀杀机器而已?这是错误的理解。回溯混沌工程发展的时间线,业界对混沌工程的理解是逐步深入的。Netflix 开发的 Chaos Monkey 成为了混沌工程的开端,但混沌工程不仅仅是 Chaos Monkey 这样一个随机终止 EC2 实例的实验工具。随后混沌工程师们发现,终止 EC2 实例只是其中一种实验场景。因此, Netflix 提出了 Simian Army 猴子军团工具集,除了 Chaos Monkey 外还包括:

  • Chaos Gorilla:Chaos Monkey的升级版,模拟整个Amazon Availability Zone的故障,以此验证在不影响用户,且无需人工干预的情况下,能够自动进行可用区的重新平衡。

  • Chaos Kong:Chaos Gorilla的升级版,模拟整个region(一个region由多个Amazon Availability Zone组成)的故障。

  • Latency Monkey:在RESTful服务的调用中引入人为的延时来模拟服务降级,测量上游服务是否会做出恰当响应。通过引入长时间延时,还可以模拟节点甚至整个服务不可用。

  • Conformity Monkey:查找不符合最佳实践的实例,并将其关闭。例如,如果某个实例不在自动伸缩组里,那么就该将其关闭,让服务所有者能重新让其正常启动。

  • Doctor Monkey:查找不健康实例的工具,除了运行在每个实例上的健康检查,还会监控外部健康信号,一旦发现不健康实例就会将其移出服务组。(隔离出服务,并且给相关人员足够的纠错时间,最终再关闭。)

  • Janitor Monkey:查找不再需要的资源,将其回收,这能在一定程度上降低云资源的浪费。

  • Security Monkey:这是Conformity Monkey的一个扩展,检查系统的安全漏洞,同时也会保证SSL和DRM证书仍然有效。

  • 10-18 Monkey:进行本地化及国际化的配置检查,确保不同地区、使用不同语言和字符集的用户能正常使用Netflix。

使用 Simian Army 进行混沌工程实验,看起来似乎已经很完美。类似像 Latency Monkey 的引入,由于服务之间的调用链传递,到最后这个小的扰动到底会引发多大的故障,没有人可以预测。在生产上做这样不可控的实验,是很危险的。随着故障注入测试(FIT,Failure Injection Testing)的提出,社区开始关注利用应用架构的特性(特别是微服务架构)来控制实验的爆炸半径,比如 Netflix 使用 Zuul 强大的流量检查和管理功能,将受影响的请求隔离到特定的测试帐户或特定设备,避免100%的混乱。(本文来自公众号:朱小厮的博客,ID: hiddenkafka)

进一步分析发现, FIT 的执行过程也影响了整个系统的监控指标,即实

你可能感兴趣的:(软件测试,自动化,小程序,apache,功能测试)