混沌工程-初识

标签: | 发表时间:2021-07-08 22:46 | 作者:
出处:https://mp.weixin.qq.com

公司新成立了一个稳定性团队,20年的重要目标之一就是开展混沌工程。为了后续更好的开展工作,记录关于“混沌工程”相关的知识以及工程实践。

内容来源:《混沌工程:Netflix系统稳定性之道》摘录以及个人思考总结。


概要

定义:主动发现系统中脆弱点的一整套方法论。

目的:如何让系统在不确定性中获益?

接受“系统越复杂,越脆弱”的事实,让系统在每一次失败中获益,然后不断进化。在实践中,用一系列的实验来真实的验证系统在各类故障场景下的表现,通过频繁大量的实验,使得系统本身的“反脆弱性”持续增强,让组织建立对系统抵御生产环境中失控条件的能力以及信心。

初衷:通过实验性的方法,让人们建立复杂分布式系统能够在生产中抵御事件能力的信息。

出现:最早由Netflix的技术团队提出,现已经演变成计算机科学的一门新兴学科,即“混沌工程”。

现状:目前业内的认知和实践积累较少,但它实际上是一种提高技术架构弹性能力的复杂技术手段。

挑战:服务规模不断增长,服务间依赖带来的不确定性指数级增长。软件可用性面临两大挑战:

  1)自身复杂度激增;

  2)开发者引入复杂性的同时对风险的低估和忽视;

方法:通过一系列可控实验和执行实验原则,揭示出系统中随时发生的各类事件是如何逐步导致系统整体不可用的。

书籍:《混沌工程:Netflix系统稳定性之道》

工具

Chaos Dingo:支持在Azure相关服务上进行实验。

Chaos-http-proxy:向http注入故障的代理服务工具。

Tugbot:可在基于docker的生产环境中进行测试的框架。

Chaos Lambda:办公期间可随机关闭AWS ASG节点的工具。

Blockade:基于docker,可测试网络故障和网络分区的工具。

Pumba:基于docker的混沌工程测试工具以及网络模拟工具。

Simoorg:LinkedIn开发的故障注入工具,以扩展,很多关键组件可插拔。

Chaos Lemur:测试高可用性系统弹性的工具,可本地部署,允许随机关闭BOSH虚拟机。

Monkey-Ops:Go语言实现,可在OpenShift V3.X上部署并在其中生成混沌工程实验。可随机停止OpenShift组件。

ChaosBlade:阿里开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具,是内部MonkeyKing对外开源的项目,结合了阿里各业务的最佳创意和实践。

链接:https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md

 

背景

由很多微服务组成的分布式系统中,永远难以全面掌握什么事件会导致系统局部不可用,甚至全面崩溃。主要因素:

1)系统架构演进:服务集群→分布式→微服务→容器化(K8S&docker)→上云;

2)版本迭代增速:CICD、敏捷、devops、ABtest;

3)用户需求变更:复杂化、多样化、快速化、小众化;

对系统的要求:扩展性、稳定性、弹性能力、容错灾备能力;

软件系统现状:系统复杂性提高、问题定位成本高;

要解决的问题:生产环境下的分布式系统在面对失控条件时依然具备较强的“可观测性”和故障恢复能力;

主要验证方式:故障注入;

开展“混沌工程”的意义

开发者的能力和认知水平有边界,不可能所有的细节都可以预估到,系统很脆弱,各种潜在不可预期的突发事件在所难免。

我们需要在异常触发之前,尽可能地去筛选出会导致出现有异常问题的、容易造成故障的、系统中明显裂痕的环节,这也是混沌工程所肩负的意义。

能让复杂系统中根深蒂固的混乱和不稳定性浮出水面,让我们更全面了解系统中固有的现象,然后进行及时修复、加固和防患于未然,才能打造更具弹性的软件工程系统。

 

思考

1、设计良好的系统,需要考虑哪些因素?

可靠性、安全性、可扩展性、可定制化、可伸缩性、可维护性、用户体验等。

2、混沌工程解决什么问题?

生产环境下,分布式系统在面对失控条件时是否具备较强的“可观测性”和故障恢复能力。

3、开展混沌工程要考虑的维度有哪些?

1)建立稳定状态的假设(清晰可衡量的指标)

2)用多样的生产事件做验证(多样性降低误差)

3)在生产环境做验证(真实场景)

4)自动化开展实验(持续运行)

5)控制最小化爆炸半径(影响范围)

4、Netflix开展混沌工程总结的三点经验

1)建立面向失败设计和拥抱失败的技术文化(技术文化)

   思想上,引入混沌工程的核心是通过引入一些风险去暴露已有的不易发现的问题,而不是创造问题。这样有助于问题的发现和处理,降低潜在故障带来的影响。

2)定义一个清晰可度量的目标(定义目标)

  前期:对历史故障的复现率以及解决率,确保故障改进的有效性;

  中期:监控发现率,验证故障发现能力的全面性和监控的完备程度;

  后期:故障的“发现-定位-恢复”市场这种综合性指标;

3)在控制风险的前提下不断提升混沌工程效率(技术推广)

  先从简单的场景开始尝试,逐渐增加组织对系统的信心(要明白准备工作比落地执行更重要)。

 

混沌工程是一种实践思想,方法论,本身不绑定任何工具或者技术。不过在进行推广和实施时,考虑到真实性、容错性、开发成本、运维效率等因素,建议复用成熟的开源组件或者商业化工具。

 


相关 [混沌 工程] 推荐:

混沌工程-初识

- -
公司新成立了一个稳定性团队,20年的重要目标之一就是开展混沌工程. 为了后续更好的开展工作,记录关于“混沌工程”相关的知识以及工程实践. 内容来源:《混沌工程:Netflix系统稳定性之道》摘录以及个人思考总结. 定义:主动发现系统中脆弱点的一整套方法论. 目的:如何让系统在不确定性中获益. 接受“系统越复杂,越脆弱”的事实,让系统在每一次失败中获益,然后不断进化.

「我是工程師」

- georgexsh - 石墨工房 5.1β
有不少工程師、或是自認為是工程師的人,在言談之間(尤其是對象是非工程師時)喜歡用「因為我是工程師,所以……」、或是「因為工程師性格使然,所以……」來當開場白,以下再展開自己要說的話. 我對工程師沒有意見、對工程師性格沒有意見,我自己也用過「xx工程師」的名片;我比較覺得有意思的,是用這些話開場的人當下的想法.

遭遇工程师

- Chrisoul - 槽边往事
谢谢大家的关心,几个小时前Google Plus恢复了我的帐号,看来暂时我还不用离开. 因为前一篇Blog的缘故,有些网友猜测是因为博文而使得我获释. 虚荣心让我想立即承认这一点,但是对不起,真的不是这样的,我的Blog并没有那么大影响力,尤其是在英文世界里. 而且,因为我上次张贴了一张人类进化谱系的漫画,我在国外驻京记者圈里成功赢得了“种族主义者”这一臭名昭著的称号,大概没有什么人愿意帮助一个黄种人中的“种族主义者”.

谈工程变更

- - 人月神话的BLOG
在这里只谈纯粹软件意义上的工程变更和配置管理相关规范流程,不涉及到产品级的工程变更包括的硬件和各种配套件层面,以方便按一个简化的思路来理解工程变更的流程和核心模型. 变更分需求类变更和实际故障bug两种,在定制的时候由于两种不同类型的变更本身处理流程也有差别,因此本身也可能进行不同的流程定制,最终归集到代码和实现层面.

工程师效率

- - 后端技术 by Tim Yang
很好奇程序员这个群体这些年效率是变低了还高了,在社交媒体中,各个阶层的兴趣圈都有自己的段子手及内容帐号,段子手发的内容会让你笑cry,内容帐号发的内容可让你享受阅读的快感,这些快感会比写代码见效快. 写完一个模块的代码通常要一整天或者几天时间,代码调通运行没有问题才会体验到愉悦,而社交媒体只需要一些碎片时间就可以达到高潮.

搜狐武汉工程院招聘Python工程师、Java工程师...

- sun - BT的花 blogs
搜狐将在武汉成立工程院,我目前负责武汉工程院的筹备和初期建设工作. 武汉工程院的目标是吸引华中地区的优秀工程师,配合北京总部的规划进行项目实施;为将来的业务发展储备人才. 武汉工程院也会逐步配置独立的产品和运营团队,争取早日主动驱动业务增长. 初期的办公地点离华科大不远,办公室预计元旦前可交付使用.

知乎招募工程师

- oxygen - 知乎的博客
Python工程师  有两年以上软件开发经验. 至少一年 Python 开发经验. 对开源技术有强烈的兴趣和爱好,参与或向开发者提交过bug和patch. 热爱探索和钻研,熟悉文本挖掘、自然语言处理相关知识能使用C/C++独立实现复杂的算法结构熟悉开源搜索项目(Lucene,Sphinx等)极强的逻辑分析能力对开源技术有强烈的兴趣和爱好,参与或向开发者提交过bug和patch认为自己是技术geek有极强的责任感.

Eclipse工程编码设置

- - 开源软件 - ITeye博客
新建一个项目,首先要做的就是设置编码,如果忽略此步,将导致很严重的问题. Trunk项目从Branch合并而来的文件,编码为UTF-8,如果Trunk下的编码使用默认的GB18030,将导致乱码. 如果再将此问题提交到svn上,后果很严重. 1.改变整个工作空间的编码. eclipse->window->preferences->General->Content Types->选中需要设置的文件类型->Default encoding:UTF-8->Update.

浅谈技术工程师的进步

- belltoy - caoz的和谐blog
本来发微博的,越说越多,算了,发篇博客把,说点工程师如何取得进步的问题,. 1:描述和记录问题要精确,数字化,“负载很高,连接很多,速度很卡”这种描述都是不对的,负载uptime值多少,连接数具体有多少,平时正常多少,高峰多少,访问延迟有多大,全部要数字化,而且要有问题状况下和平时的对比,养成这样的习惯,技术分析能力才会有进步.

爱光阅读书目工程

- wwq0327 - xiuli blog
这个儿童阅读书目工程,这几天已经有了不断的发展,. (1)这是新浪微博上的话题“爱光儿童阅读书目”记录:. 爱光儿童书目工程#,豆瓣小站,http://site.douban.com/117499/ ,大家喜欢小站吧,让小站走进千家万户. (3)南通张剑平老师作为志愿者给项目设计了LOGO图标,. (4)爱光儿童阅读书目项目WIKI整理,.