混沌工程

混沌工程发展简介

•  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 混沌实验框架

混沌工程的现实功用

• 对于架构师：验证系统架构的容错能力，比如验证现在提倡的面向失败设计的系统；

• 对于开发和运维：提高故障的应急效率，实现故障告警、定位、恢复的有效和高效性；

• 对于测试：弥补传统测试方法留下的空白，混沌工程从系统的角度进行测试，降低故障复发率，这有别于传统测试方法从用户角度的进行方式；

• 对于产品和设计：通过混沌事件查看产品的表现，提升客户使用体验；

混沌工程和故障注入

• 复杂的分布式服务体系中，故障发生的随机性和不可预测性都大大增加

  • 随着服务化、微服务和持续集成的逐渐普及，快速迭代的门槛越来越低，但是对复杂系统稳定性的考验却在成倍增长
    • 分布式系统天生包含大量的交互、依赖点，故障点层出不穷：硬盘故障、网络故障、流量激增压垮某些组件、外部系统故障、不合理的降级方案等等都会成为常见问题；
    • 人力无法改变此种局面，更需要做的是致力于在这些异常被触发之前尽可能多地识别出会导致此类异常的系统脆弱环节或组件，进而有针对性地对其加固，以避免故障发生，打造出更具弹性的系统；这正是混沌工程诞生的原因之一；
• 混沌工程是一种通过实证探究的方式来理解系统行为的方法，也是一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学；
  • 混沌工程是在分布式系统上进行实验的学科，旨在提升系统容错性，建立系统抵御生产环境中发生不可预知问题的信心
  • 混沌工程的意义在于，能让复杂系统中根深蒂固的混乱和不稳定性浮出表面，让工程师可以更全面地理解这些系统性固有现象，从而在分布式系统中实现更好的工程设计，不断提高系统弹性

• 混沌工程，故障注入（FIT）和故障测试在侧重点和工具集上有一些重叠

  • 混沌工程是发现新信息的实验过程，而故障注入则是对一个特定的条件或变量的测试方法

  • 测试和实验有着重要区别

    • 测试通过仅产生二元的结果，即真或者假，从而用于判定测试是否通过；但测试并不能发掘出系统未知的或尚不明确的认知，它仅仅是对已知的系统属性可能的取值进行测验；

    • 而实验可以产生新的认知，而且通常还能开辟出一个更广袤的对复杂系统的认知空间；

• 混沌工程并非是简单的制造服务中断等故障

  • 并不是全都可以有建设性、高效地发现问题

  • 另外，还存在一些非故障类场景，例如流量激增、资源竞争条件、拜占庭故障、非计划中的或非正常组合的消息处理等等

混沌工程实验的输入样例

• 模拟整个云服务区域或整个数据中心故障；

• 跨多实例删除部分 Kafka topic 来重现生产环境中发生过的问题；

• 挑选一个时间段，和针对一部分流量，对其涉及的服务间调用注入一些特定的延时；

• 方法级别的混乱（运行时注入）：让方法随机抛出各种异常；

• 在代码中插入一些指令可以允许在这些指令之前运行故障注入；

• 强制系统节点间的时间不同步；

• 在驱动程序中执行模拟 I/O 错误的程序；

• 让某个 Elasticsearch 集群 CPU 超负荷；

故障注入输入样例

• CPU高负载

• 磁盘高负载：频繁读写磁盘

• 磁盘空间不足

• 优雅的下线应用：使用应用的stop脚本平滑的停止应用

• 通过kill进程直接停止应用，可能造成数据不一致

• 网络恶化：随机改变一些包数据，使数据内容不正确

• 网络延迟：将包延迟一个特定范围的时间

• 网络丢包：构造一个tcp不会完全失败的丢包率

• 网络黑洞：忽略来自某个ip的包

• 外部服务不可达：将外部服务的域名指向本地环回地址或将访问外部服务的端口的OUTPUT数据包丢弃