大佬教程收集整理的这篇文章主要介绍了混沌工程:通过不断试错的方法来管理风险,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
起源:Netflix 和 Chaos Monkey@H_673_8@
2008 年 Netflix 在整体微服务化和数据中心迁移至 AWS 云的背景下,开始了在生产环境进行系统弹性的测试。最早为大家熟知的是 Chaos Monkey,一个在生产环境中随机选择并关闭服务节点的工具。它的名字来源于其工作的方式:如同一只野生、武装的猴子,释放到在数据中心,来造成严重的破坏。@H_673_8@
Chaos Monkey 的原则是:避免失败的最好办法就是经常失败。通过主动破坏自身环境,来发现系统的弱点。频繁的故障演练使开发团队能从问题中学习经验,从而对服务集群的稳定性有更高的重视。@H_673_8@
发展:Simian Army@H_673_8@
Chaos Monkey 之后,更多猴子陆续加入,统称为 Simian Army。它由一系列捣乱工具构成,其中的成员可用于随机关闭实例、服务调用中引入长时间延迟、模拟整个区域的断电场景等。并且通过与持续发布平台集成,自动进行线上演练。@H_673_8@
混沌工程:Chaos ENGIneering@H_673_8@
Netflix 在多年稳定性的实践历程中,总结了「混沌工程」的理念。@H_673_8@
在复杂的分布式服务体系中,包含大量的交互、依赖点,故障发生的随机性和不可预测性都大大的增加了。混沌工程提倡通过不断重复失败过程,帮助我们发现系统中潜在的、可能导致灾难的脆弱环节,推动我们主动找出解决方案,从而不断打造更具弹性(系统应对故障、从故障中恢复的能力)的系统,建立对系统抵御生产环境中失控条件的能力以及信心。就像打疫苗可以预防疾病一样,通过混沌工程来提升系统的免疫力。@H_673_8@
可以把混沌工程看作是为了揭示系统的弱点而进行的实验,实验中分为「控制组」和「实验组」:@H_673_8@
通过这两组之间的稳定状态的差异来验证系统对故障的容错能力。注入故障后破坏稳定状态的难度越大,我们对系统的信心就越强。@H_673_8@
举个例子,如下图:@H_673_8@
1、设定系统故障容错的假设:API 服务调用 Gallery 服务,当 Gallery 不可用时,API 对 Gallery 的故障可优雅降级,不会导致系统不可用@H_673_8@
2、设定实验范围:生产环境中,通过切小部分流量的方式,创建实验组、控制组环境@H_673_8@
3、故障注入:API 调用 Gallery 的 rpc 请求注入中断故障@H_673_8@
4、稳态验证:通过 GetGallery 监控指标进行容错假设的验证,预期故障注入后:@H_673_8@
以下从 5 个角度描述了应用混沌工程的理想方式(源自 Netflix 的经验总结:http://principlesofchaos.org):@H_673_8@
1、建立稳定状态的假设@H_673_8@
我们将系统正常运行时的状态定义为系统的“稳定状态”,可以使用稳定状态来建立混沌实验的假设,一般是这样的形式:我们向系统中注入不同类型的故障事件后,不会导致系统稳定状态发生明显的变化@H_673_8@
可以借助监控体系中的可度量指标来定义、观测系统的稳定状态,比如:@H_673_8@
2、用多样化的现实世界事件做验证@H_673_8@
引入现实中破坏稳态的故障事件,例如:服务器宕机、网络延迟、错误响应等。@H_673_8@
3、在生产环境中进行实验@H_673_8@
从功能性的故障测试角度(比如:验证预案的有效性、服务间的强弱依赖)来看,线下的测试环境也可满足预期。随着故障演练的成熟和系统对故障容错能力信心的提升,可逐步推广采用生产环境流量进行实验,保证系统执行方式的真实性。@H_673_8@
4、自动化实验以持续运行@H_673_8@
混沌实验的初始阶段可以手动执行,快速落地并获得收益,但这是劳动密集型、不可持续的。@H_673_8@
后期可逐渐演进混沌工程的工具和平台,将实验的编排执行与结果分析自动化运行,以此来提升效率、扩大规模。@H_673_8@
5、最小化爆炸半径@H_673_8@
在生产环境中进行混沌实验,让系统的薄弱环节曝光,有导致生产环境崩溃的风险,并造成不必要的客户投诉,所以需要最小化爆炸半径,保证这些后续影响最小化,精细化控制故障的影响范围。@H_673_8@
以下是混沌工程的应用场景,以及所能带来的收益:@H_673_8@
应用场景@H_673_8@ |
收益@H_673_8@ |
强弱依赖治理@H_673_8@ |
自动化周期性的获取应用间的强弱依赖关系,验证和预期是否一致,并对不符合预期的强依赖推动其弱依赖化,配置限流、降级策略;@H_673_8@ 系统链路的容量评估:当某个弱依赖挂掉时,整体的容量是否有影响?@H_673_8@ |
降级预案演练@H_673_8@ |
在真实故障场景中,验证降级预案的容错能力,是否能将系统的 SLA 维持在相对较高的水平。避免非故障场景下预案功能正常,故障场景下却失效了@H_673_8@ |
架构容灾评测@H_673_8@ |
批量回放通用的故障场景,验证极端情况下个体组件的故障不会影响整个系统,监控报警、降级、主备切换、故障迁移等容灾手段的健壮性。提前发现并修复风险@H_673_8@ |
红蓝演练@H_673_8@ Game Day@H_673_8@ |
通过蓝军、红军的方式以战养战,反复验证故障的【发现 → 诊断 → 解决】流程准确度和应急效率,提升团队的经验值和信心,避免在各种报警中自乱手脚@H_673_8@
|
故障复盘@H_673_8@ |
通过对线上故障的重现,验证故障复盘的后续 todo 项落地效果如何,完成流程闭环。发生过的故障也可时常演练,看是否有劣化趋势@H_673_8@ |
监控报警@H_673_8@ |
校验报警是否符合预期:监控报警覆盖度、监控维度是否正确、告警阈值是否合理、告警是否快速、告警接收人是否正确,优化无效告警@H_673_8@ |
混沌工程是一种偏方法论的理念,本身不绑定任何平台或框架。那么基于这种理念,如何指导在应用上的落地呢?以下是我的一些想法@H_673_8@
首先我们需要引入真实场景下可能出现的故障,然后才可进行混沌实验。@H_673_8@
按 SaaS 类、PaaS 类、IaaS 类的故障全景图:@H_673_8@
可以通过故障事件发生的频率和影响范围来排定引入的优先级。从开发成本、运维效率、规模化推广的角度考虑,建议复用一些成熟的开源组件或商业工具,参考 CNCF 混沌工程的开源项目(CNCF 云原生全景图 https://landscape.cncf.io/)@H_673_8@
以下是两个 star 较多、开源社区较为活跃的混沌工程项目。故障注入都做到了开箱即用、业务无感知,不需要业务配合写一些混沌工程相关的代码,也不需要更改系统的部署逻辑。@H_673_8@
ChaosBlade(https://github.com/chaosblade-io):阿里开源@H_673_8@
提供了丰富的故障场景,包括:@H_673_8@
Chaos Mesh(github.com/chaos-mesh/chaos-mesh):PingCAP开源@H_673_8@
面向 Kubernetes 的云原生混沌工程平台,覆盖网络、磁盘、文件系统、操作系统等故障场景,并提供了交互友好的 Dashboard 让用户轻松进行故障注入和稳态指标观测@H_673_8@
基于故障注入的能力,将混沌实验的流程平台化,让用户更方便的使用。如下图:@H_673_8@
(1)平台产品层@H_673_8@
基于上文「3. 应用场景和收益」一节所描述的场景,总结实践经验和演练规范,抽象为开箱即用、简洁易懂的产品 @H_673_8@
(2)服务层@H_673_8@
(3)底层基础能力@H_673_8@
1、引入混沌工程,需要建立面向失败和拥抱失败的技术文化(可以使系统暴露出已有问题的设计)@H_673_8@
组织内沟通到位,达成一致,从思想上认同混沌工程的价值。混沌工程的核心是通过引入一些风险变量去暴露已有问题,而不是创造问题和事故。在恰当的时间和可控的爆炸半径下进行实验,有助于问题的发现和处理,降低潜在故障带来的影响。@H_673_8@
如果不愿意实施混沌实验的原因是:对系统在注入事件后的反应缺乏信心,害怕实验会给客户带来影响。然而该发生的故障还是会发生,即使实验暴露风险点的同时也会导致一些小的负面影响,但是提前了解和控制影响范围,也比最终措手不及的应对大规模事故要好的多。@H_673_8@
2、实施混沌工程,需要定义一个清晰可衡量的目标@H_673_8@
混沌工程的业务价值并不适合用过程指标来衡量,比如:模拟了多少种实验场景、发起多少次实验等等。@H_673_8@
需要配合其他稳定性手段一起来衡量,比如:@H_673_8@
3、推广混沌工程,要在控制风险的前提下不断提升效率@H_673_8@
越贴近生产环境的实验,结果越真实,同时风险也越大。可以先从测试环境、简单的故障场景开始尝试,明确系统稳定状态、止损停止条件、服务自身可恢复的兜底预案后,再逐渐过渡生产环境全链路的复杂场景。@H_673_8@
先人工手动跑通完整流程,然后总结各场景混沌实验的规范,最后将流程规范平台化,可以定期的自动化运行,从而提升了效率,持续获得混沌实验的价值。 @H_673_8@
混动工程实验可以简单如在测试环境中某个实例运行 kill -9
来模拟一个服务节点的突然宕机,也可以复杂到在线上挑选一小部分流量,按一定规律或频率自动运行一系列实验。@H_673_8@
Netflix 总结了混沌工程的成熟度模型,包含「熟练度」和「应用度」两个维度,给出了明确的方向建议。概括如下:@H_673_8@
熟练度:反映混沌工程项目的有效性和安全性@H_673_8@
故障注入场景@H_673_8@ |
演练环境@H_673_8@ |
稳态结果分析@H_673_8@ |
演练流程@H_673_8@ |
|
入门@H_673_8@ |
kill节点@H_673_8@ |
线下:dev/test环境@H_673_8@ |
全人工@H_673_8@ |
|
简单@H_673_8@ |
网络延迟@H_673_8@ CPU、IO高@H_673_8@ |
线下仿真:复制生产流量@H_673_8@ |
服务应用指标(如 接口错误率)@H_673_8@ |
自动:故障注入@H_673_8@ |
高级@H_673_8@ |
服务延迟、异常@H_673_8@ |
线上生产环境@H_673_8@ |
业务指标(如订单量)@H_673_8@ |
自动:CI 持续集成,持续验证@H_673_8@
|
熟练@H_673_8@ |
服务返回结果修改@H_673_8@ 动态调整爆炸半径@H_673_8@ |
线上生产环境@H_673_8@ |
实验组、交互组的稳态指标交互式对比@H_673_8@ |
全自动:@H_673_8@
|
应用度:反映混沌工程覆盖的广度和深度,即业务的实践推广@H_673_8@
@H_673_8@ |
业务覆盖@H_673_8@ |
组织演练@H_673_8@ |
暗中进行@H_673_8@ |
少数非关键服务@H_673_8@ |
无组织,偶尔尝试@H_673_8@ |
适当投入@H_673_8@ |
少数关键服务@H_673_8@ |
多个团队有兴趣,参与不定期演练@H_673_8@ |
正式采用@H_673_8@ |
大多数关键服务@H_673_8@ |
混沌工程团队,定期演练@H_673_8@ 故障复盘,回归验证@H_673_8@ |
成为文化@H_673_8@ |
所有关键服务、系统组件@H_673_8@ 多数非关键服务@H_673_8@ |
Game day 红蓝演练@H_673_8@ |
以上是大佬教程为你收集整理的混沌工程:通过不断试错的方法来管理风险全部内容,希望文章能够帮你解决混沌工程:通过不断试错的方法来管理风险所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。