混沌工程在创业公司的实践

阅读量:

前言

混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。2016年,Netflix将在生产环境开展的对系统弹性测试的经验总结为《Principles Of Chaos》,揭示了混沌工程的实施原则:建立一个围绕稳定状态行为的假说、多样化真实世界的事件、在生产环境中运行实验、持续自动化运行实验、最小化爆破半径。

酷家乐技术架构演进与混沌工程的联系

2015年开始,酷家乐整体架构开始向微服务化迈进。从早期的单体应用,经过垂直/水平拆分,再由共享能力下沉抽象出业务中台。架构的剧烈演进带来了以下三个突出问题:

  • 架构的大规模变更过程导致稳定性故障频发
  • 架构的复杂化导致“流程优化(code review/上线等)及稳定性盘点” 等形式的保障方式无法满足稳定性保障需求
  • 需要验证服务治理、监控警报、devops等基础设施在故障出现时能有效工作,协助团队快速消灭问题

具体来说,在架构和团队膨胀到一定阶段,要想完全消除线上故障已经成为不可能的任务。当故障发生时,微服务架构能否准确进行出错重试、限流、熔断、流量控制;报警响应是否及时,提供的监控信息是否支持迅速排障;devops研发平台是否能够允许应用迅速回滚,快速上线紧急修复,等等,都成为降低业务损失的重要一环。

因此,从故障驱动的角度出发,提前挖掘当前架构、链路、系统存在的隐患,验证基础设施的完备性,限制故障影响的范围,成为需要思考的方向。混沌工程有助于达到以上三个目的,将稳定性保障方式从“流程优化(code review/上线等)及稳定性盘点” 拓展到“故障的隔离/自修复/快速响应”。

酷家乐混沌工程的实施方式

首先,基于对当前的技术架构以及团队结构的认知,在具体实施过程中需要满足以下条件:

  • 从创业公司的角度,方案的实施必须契合整体架构的长期演进方向,满足低成本、高收益、可复用三个要求。在技术方案的选择上,可以通过开源和自研相结合的方式,在降低成本的同时最大限度贴合自身的架构特点。
  • 从当前的运维方式,处于虚拟机部署方式向容器化过渡过程中,需要支持虚拟机、docker、k8s三种攻击模式。
  • 从安全角度,线上故障注入为高危动作,需要有严格的权限控制流程。在实施前期,允许团队在线下及预发环境中验证故障注入方案的合理性。

其次,为了更真实模拟线上故障,我们对历史故障数据进行了大量分析,将相关故障场景抽象为五大类:应用类、存储类、基础设施类、中间件、业务特性。抽象的故障场景即为需要实现的故障注入能力。

故障场景抽象

再次,综合实施条件和实施能力目标,对开源方案进行筛选。目前,开源方案可以分为三类:一类,从chaosMonkey衍生、以容器化部署应用作为攻击目标,采用go语言作为技术栈,如pumba、kube-monkey,chaosblade;另一类,基于python强大运维优势的开源方案,可以较快的实现运维层面的攻击,如chaostoolkit;最后一类为侵入代码层进行攻击,如byte-monkey,在字节码层面给jvm应用注入相应故障。

经过比对,Pumba通过调用DockerAPI的方式来实现container级别的相关攻击,包含随机kill、stop、remove、pause、网络状况模拟等,是在docker部署方式下攻击方式比较丰富的一种方案。此外,阿里巴巴近期开源Chaosblade,功能强大,除了基础的CPU、disk、I/O、network外,还支持docker、dubbo、jvm的攻击,同时支持攻击后迅速回滚,是在k8s部署方式下最优方案。

开源方案极大的方便了工程的实施,但并不能解决全部的问题,如:Chaosblade对于非dubbo架构(Spring Cloud体系等)缺乏有效支持。因此,需要基于酷家乐自身的架构特性,对相关场景进行补充。在架构层面上,更好支持Spring Cloud体系;在业务层面上,通过服务治理平台提供限流、熔断、mock等功能实现业务接口层面的故障注入。

最后,为了提升故障注入工具的易用性,同时实现权限管控、大规模攻击、指令下发、历史记录、方案预演等必需功能,我们设计并实现了酷家乐混沌工程平台-Ares。Ares借助于saltstack实现攻击指令下发,以应用为维度实现权限管控,并将最小攻击目标限定在单个应用上。Ares平台架构图如下所示。

Ares平台架构图

作为一个案列,下图展示了一次“应用暂停攻击”对应的监控指标变化。攻击实施后,监控看板能清晰展示数据截断。攻击发生后,我们可以进一步验证相关警报是否发出、上游业务表现是否正常、人员问题排查是否到位、相关预案是否完善等。

应用暂停攻击

未来展望

混沌工程是一门实验学科,用于建立对系统抵御生产环境中失控条件的能力以及信心。从目前的落地方式上看,故障注入是其中最重要的一环,平台支持的故障注入场景的丰富性和粒度很大程度上影响实验结果。本文侧重于故障模拟部分的介绍,对应于混沌工程“多样化真实事件”原则。关于混沌工程其他原则的进一步思考,我们简单罗列如下:

  • 建立一个围绕稳定状态行为的假说
    我们需要在故障攻击前,确定系统稳定工作状态的指标,用于判定故障发生后系统的工作情况。
  • 在生产环境中运行试验
  • 持续自动化运行试验
    场景设计完成后,需要有某种调度机制,自动化持续执行。
  • 最小化爆破半径
    故障影响范围分析,确保在生成环境执行过程中,对用户影响最小。

综上,稳定工作指标的选取、系统工作状态的判定、调度机制以及故障影响范围分析是下一步实施考量方向。


comments powered by Disqus