小米chaosblade的故障注入平台实践

共 3748字,需浏览 8分钟

 ·

2021-04-29 16:27

1. 背景





当今社会互联网应用越来越广泛,用户量日益剧增。在人们对互联网服务的依赖性增大的同时,也对服务的可用性和体验感有了更高的要求。那么如何保障服务在运营过程中能一直给用户提供稳定的、不间断的、可靠可信的服务呢?

例如一个金融产品,如果出现过一次问题,那可能带来巨大的损失。大家都知道金融产品的系统架构和服务逻辑是相当复杂的,至此大家都会第一时间联想到测试工程师,他们会通过单元测试、集成测试、性能测试等来验证服务的稳定性。但尽管如此,也是远远不够的,因为错误可以在任何时间以任何形式发生,尤其是对分布式系统。所以这里就需要引入混沌工程(Chaos Engineering)。

二 混沌工程介绍




混沌工程是一套通过在系统基础设施上进行实验,主动找出系统中的脆弱环节的方法学,最早由Netflix及相关团队提出。它旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试系统在各种压力下的行为,识别并修复故障问题,避免造成严重后果。2012年,Netflix开源了Chaos Monkey。今天,许多公司(包括谷歌,亚马逊,IBM,耐克等)都采用某种形式的混沌工程来提高现代架构的可靠性。
混沌工程和故障测试的区别
相同点:
  • 都是基于故障注入来引入的。 

不同点:
  • 混沌工程是一种生成新信息的实践,而故障测试是测试一种情况的一种特定方法。

  • 故障测试会在具体的场景实施注入实验和验证预期,而混沌工程实验是围绕一个“稳态状态”通过更多场景来验证。

  • 混沌工程建议是在生产环境中进行实验。

混沌工程非常适合揭露生产系统中未知的弱点,但如果确定混沌工程实验会导致系统出现严重问题,那么运行该实验就没有任何意义。
目前国内有相关使用的公司内的实践偏向于故障测试,即在一个具体场景下实施故障注入实验并验证预期是否得到满足。这种测试的风险相对可控,坏处是并没有通过故障注入实验探索更多的场景,暴露更多的潜在问题,测试结果比较依赖实施人的经验。当然这也是我们认为在混沌工程目标之路上必经的一个阶段。
故障测试预期、验证与混沌工程定义的稳态状态行为是存在差异的,差异的根本原因还是组织形态的不同。2014年,Netflix团队创建了一种新的角色,叫作混沌工程师(Chaos Enigneer),并开始向工程社区推广。而国内大部分企业目前并没有一个专门的职位来实施混沌工程,项目目标、业务场景、人员结构、实施方式的不同导致了对于稳定状态行为的定义不太标准。当然我们目前也没有Chaos Enigneer。所以基于不同的定义标准、不同的组织型态和不同的阶段,我们在混沌工程实验的引入和使用也是更偏向故障测试。

三 混沌工程原则




以下原则描述了应用混沌工程的理想方式,这些原则来实施实验过程。对这些原则的匹配程度能够增强我们在大规模分布式系统的信心。

围绕稳态行为构建假设
专注于系统的可测量输出结果,而非系统的内部属性。在短时间内测量输出结果并将此作为系统稳态的代表。整体系统的数据吞吐量、错误率、延迟百分比等皆可作为稳态行为的关键性表示指标。通过关注实验中各系统行为模式,混沌工程能够验证系统是否正常工作——而无需尝试解析其工作原理。

多样化真实世界的事件
混沌变量应直接反映各类现实世界事件。我们应该考虑各类或者相关联的故障,任何可能导致稳态中断的事件皆应被视为混沌实验当中的潜在变量。由于多元化的业务和高复杂的系统架构,可能会遇到非常多种类型的故障,这里已经有人优先分析P1和P2故障,按照IaaS、PaaS、SaaS层的角度绘制了故障画像,如下图

在生产环境中运行实验
从功能性的故障测试角度来看,非生产环境去实施故障注入是可以满足预期的,所以最早的强弱依赖测试就是在日常环境中完成的。不过,因为系统行为会根据环境和流量模式有所不同,为了保证系统执行方式的真实性与当前部署系统的相关性,推荐的实施方式还是在生产环境,但是目前很多企业还是没有做到生产环境实验。

持续自动化运行实验
使用故障注入平台化代替手动实验,自动构建编排和分析。

最小化爆炸半径

混沌工程建议在线上环境进行实验,但是导致系统异常甚至异常放大的可能性是存在的。从实施角度看,最好是通过技术手段来有效的减少异常带来的影响,例如通过系统稳态指标来有效停止注入、限流、流量切换、数据隔离等方式都是减少业务影响的手段。


四 故障注入平台的构建





平台目标

  1. 提供多样化、可视化操作的故障注入自动化平台

  2. 作为各种演练和故障测试及验证的统一入口

  3. 积累沉淀多种实验方案,建立系统上线健壮性评估基线


功能目标

  1. 帮助业务发现更多未知的影响业务稳定的问题

  2. 验证业务的告警有效性和完整性

  3. 验证业务的故障预案是否有效


平台构建

目前业内模拟故障的工具比较多样化,支持的功能和场景也各有优劣。通过对比来看,chaosblade支持功能和场景比较丰富,同时社区也是比较活跃的。我们在充分验证了大部分注入功能后,选择了它作为底层注入的核心模块。


chaosblade 所支持的场景,可以参考文档:

https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/


整个故障注入一共分为四个阶段:

平台构建的思路还是以四个主流程为核心来开展。分类来看平台模块如下图所示:

目前平台的注入场景我们支持了系统层和网络层类型,主要包含了网络延迟、丢包、cpu满载、内存满载、磁盘IO满载场景。这些场景都是热插拔式集成到平台,方便平台场景灵活调整和扩展。



五 演练实践





实操演练我们挑选了1个相对较稳定的业务A(业务A是一个多节点的任务调度和目标抓取的服务),对业务A的测试环境进行了实验,同时业务方很期待如此稳定的系统是否存在或者有更多的缺陷。
整个过程概览如下:
  1. 定义并测量系统的“稳定状态”,精确定义指标
  2. 创建假设
  3. 线上流量复制持续导入测试环境
  4. 模拟现实世界中可能发生的事情
  5. 证明或反驳假设
  6. 结和反馈问题优化

稳态指标
业务方任务系统在运行时,以下指标可以代表系统的稳态。
  • 集群服务整体CPS
  • 任务提交响应延迟
  • 任务提交成功率
  • 任务解析失败率
  • 目标获取成功率
  • 数据一致性和完整性

创建假设

假设某些节点在存在性能或者网络相关问题的时候,可能存在任务提交响应延迟,不影响稳态。

假设存在节点宕机,不影响稳态(此处不做介绍)。


线上流量导入

流量复制和测试环境导入在这里不做介绍。


模拟故障

使用系统层+网络层随机注入场景模拟。

下表格为故障注入平台中故障场景的配置。
注入功能名称
说明
Cpu注入
负载达到90%
内存注入
内存消耗达到90%
网络丢包
丢包率30%
网络延迟
增加100ms

在平台选择我们提供的系统场景故障模板和注入目标(一个注入任务中,单个机器只能注入一种场景,场景和机器随机选择)


通过选择的注入模板和目标,生成一个注入计划,如下图:

执行注入,如下图,在注入过程中,操作者是可用随时结束和暂停注入任务的。


人为暂停指定目标,点击继续会继续注入


跟踪和观察

在整体的观察中发现了以下几个问题:
  • 服务cps陡降

  • 提交成功的任务,失败率大幅提升

  • 用户任务提交出现不同程度延迟

  • 关联服务进程异常退出

  • 监控不细粒,能发现cps和失败率增加,但定位困难

发现整个服务的cps有陡降,意味着服务的处理能力下降严重。

任务执行失败数量增加,意味着任务提交了,但是服务并没有按照预期来完成。

用户提交延迟和超时增加

结束整个注入任务


注入任务结束后,业务所有指标逐步恢复了正常。

证明或反驳假设

  • 假设:某些节点在存在性能或者网络相关问题的时候,可能存在任务提交响应延迟,不影响稳态。

  • 证明:存在任务提交响应延迟,间接性意味cps的下降。

  • 反驳:发现非预期的 任务执行失败增加和关联进程异常退出的问题,监控缺失和不细粒等问题。


总结和反馈

添加本次注入总结和反馈:





六 其他问题





1、任何用户都能对任何机器做注入吗?
答:不可以。 
平台目前涉及到多个维度的权限:用户在职状态,平台用户权限,用户和机器权限,平台和机器权限。


2、当因为注入导致目标机器满载或者丢包严重,sre同学无法登陆机器,平台是如何能正常中止?
答:系统在对目标机器注入时会开白名单,例如丢包或者网络中断的场景会导致其他用户无法登陆,但是我们的任务机是不受影响的。系统性能满载的注入,我们会控制满载程度,不会让机器直接满载到无法工作的情况。后面也有个性化参数配置,用户在设置方位内可调整。
3、平台是否能自动判断停止注入?如果不能,人工中止忘记了注入会一直持续吗?
答:目前还无法自动判断是否需要停止注入。如果人工中止操作忘记了,用户在选择注入模板或者自己配置注入计划的时候,会有一个持续注入时间,超过这个时间,注入任务自动结束。

七 未来规划





功能规划
步完善本文中提到的按照IaaS、PaaS、SaaS层的角度绘制的故障画像中的故障场景。
结合SLO、降级和流量调度,缩小爆炸半径,为线上注入实验做准备。
能主动探测绘制流量和服务调用关系拓扑。


浏览 12
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报