混沌测试是一种基于系统状态的测试方法。通过对系统状态进行测量,可以测试系统在不同条件下的运行状态,这是测试过程的基础。
测试您可以预测的事故是必不可少的。但是随着数字化转型和云原生架构带来的复杂性,团队需要一种方法来确保应用程序能够承受生产的“混乱”。混沌工程满足了这一需求,因此组织可以提供在任何条件下都可以正常运行的强大、有弹性的云原生应用程序。
奈飞公司提出混沌工程实践后,伴随着业务上云,国内企业纷纷仿效,不少工具厂商也推出了相应的工具。但有些企业的运维部门在实践混沌工程时,主要是用工具厂商所提供的工具,或使用自研的工具,进行故障注入探索性测试。其间缺乏针对该企业以前所发生的生产环境线上事故设计混沌工程实验。这导致将“混沌工程实验”做成了场景较为简单和单一的针对基础设施层的“故障注入探索性测试”。其后果就是测试做了不少,但发现的未知的复杂系统的失效模式却不够多。另外这些测试与线上事故缺乏直接关联,导致难以体现混沌工程实践的价值。
不管在将软件投入生产之前进行多么困难的测试以发现错误,错误总是会发生 - 云和可用区域会出现问题,网络会崩溃,是的,错误会让人感觉它们的存在。容错性(Resilience/弹性)是指一个系统承受这些错误的能力 - 例如,一个高度容错性的系统,一个由松散耦合的微服务构建的系统,它本身可以很容易地重新启动和扩展,在不影响用户的情况下克服这些错误。混沌工程是在系统出现故障之前,将其注入系统的实践。混沌工程现在被认为是确保当今频繁变化和高度复杂的系统实现所需的容错性的基本方法。通过混沌工程,可以在引起用户问题之前发现和纠正未预料到的故障场景。
在 InfoQ 混沌工程系列访谈中,企业如今对混沌工程普遍的感知是:企业内部不同部门认知不统一,业内对混沌工程没有相对统一的评价标准。随着云基础设施的广泛应用,混沌工程不断与国内大公司碰撞出火花。2020 年初,中国信通院开始组织专家进行混沌工程技术研究,提出应用混沌工程方法来验证云原生系统的韧性架构。
软件和系统开发是创新和解决未知问题的练习。软件和系统是容易出错的,因为它们是由具有不同观点和技能的人(很可能是多人)制作的。技术变得越来越分散和复杂,尤其是随着微服务的推动。很少有人拥有完整的端到端知识 […]
导读:与任何新概念一样,混沌工程时常被误解。本文会探讨混沌工程是什么以及不是什么。
混沌工程是近年来新出现的概念,主要用于稳定性方面的研究,英文全称为chaos engineering,由网飞公司最先提出。因为最开始混沌工程称作chaos monkey,形容就像有一只猴子在系统中捣乱一样,以至于到现在每次提到混沌工程都会用一只捣乱的猴子来比喻。
近年来,随着系统架构逐渐向微服务架构演化,开发效率以及系统扩展性大幅提高。但同时,系统的复杂性也随之提高,传统的测试方法已经不能全面理解和覆盖系统所有可能的行为,测试的有效性被大打折扣。我们通过各种测试、SRE、DevOps、金丝雀发布、蓝绿部署、预案、故障演练等方法,希望能够防患于未然。但服务规模不断增长,服务之间的依赖性所带来的不确定性也呈指数级增长。在这样的服务调用网中,任何一环出现的正常或异常的变化,都有可能对其他服务造成类似蝴蝶效应一般的影响。
2014年,Netflix团队创建了一种新的角色,叫作混沌工程师(Chaos Enigneer),并开始向工程社区推广。项目目标、业务场景、人员结构、实施方式的不同导致了对于稳定状态行为的定义不太标准。
通过主动测试系统在压力下的响应方式,我们可以在故障出现之前识别并修复故障。 最终,混沌工程的目标是增强我们系统的稳定性和弹性。
混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。由Netflix在2010年底提出,2012开源Chaos Monkey(混乱猴子),中间经过了一系列的演化。具体路线为:
原文链接:https://www.infoq.cn/article/EEKM947YbboGtD_zQuLw
很多人都会把混沌工程和测试区分不清楚,我从执行时机、执行后是否对系统产生新认知,做了一张图如下。
“混沌工程实验性价比太低了。测试、研发和运维三个部门都投入了大量人力物力,在准生产环境做了不少故障注入实验。但发现的问题还是比较少。”在一次混沌工程实践回顾会上,一位测试人员如是说。
什么是混沌工程?用一句简单的话来解释,就是使用科学方法,用做有对照组的实验,来实证复杂的分布式软件系统,能够在生产环境抵御来自现实世界不可预知的各种状况。
随着摩尔定律的终结,单机计算性能已达到了极限,然而,我们的软件系统不论是规模还是复杂度一直在增长,所以软件系统都不约而同的朝着分布式化方向发展。近年来,随着云服务、容器的出现,某些分布式系统也更容易微服务化。
混沌工程是一种提高技术架构弹性能力的复杂技术手段,旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试系统在各种压力下的行为,识别并修复故障问题,避免造成严重后果。
在分布式系统架构下,服务间的依赖日益复杂,很难评估单个服务故障对整个系统的影响,并且请求链路长,监控告警的不完善导致发现问题、定位问题难度增大,同时业务和技术迭代快,如何持续保障系统的稳定性和高可用性受到很大的挑战。我们知道发生故障的那一刻不是由你来选择的,而是那一刻来选择你,你能做的就是为之做好准备。所以构建稳定性系统很重要的一环是混沌工程,在可控范围或环境下,通过故障注入,来持续提升系统的稳定性和高可用能力。
与集中式架构相比,分布式架构的系统复杂性呈指数级增长,混沌工程在信创转型、分布式架构转型、小机下移等过程中有效保障了生产的稳定性。本文分享了 TiDB 分布式数据库在银行核心业务系统落地中进行混沌测试的场景设计和实践。
从2005年Peter Rodgers博士提出微web服务,到2014年ThoughtWorks首席科学家Martin Fowler与James Lewis共同提出微服务概念至今已多年,这期间也是互联网及互联网+发展的高速期,消费市场变化莫测,消费者也变得越来越挑剔,很多公司和产品由于无法跟上市场的快速变化而纷纷倒下。越来越多的互联网巨头甚至传统行业都开始对自己的遗留系统进行微服务改造,通过把系统拆分为更加灵活、有业务边界上下文、松散耦合、可独立部署的服务来应对快速变化的消费市场。
这是一篇2020年2月7日发布在公众号上的文章,最近在重学混沌工程和SRE相关的知识,将之前记录的学习笔记及这两年新的一些思考和理解进行了重新整理,计划更新一个系列。
对于国外的“网红”技术,国内公司都是要试一下的。继云计算、大数据、人工智能、微服务和区块链之后,混沌工程也引起了国内IT领导们的注意。他们会叫来手下技术骨干说:“试一试混沌工程吧”。
“混沌工程实验性价比太低了。测试、研发和运维三个部门都投入了大量人力物力,在准生产环境做了不少故障注入实验。但发现的问题还是比较少。”在一次混沌工程实践回顾会上,一位测试人员如是说。 近十几年来,随着企业业务不断微服务化,并迁移到复杂分布式的云生产环境,云上各个微服务业务系统之间相互访问的稳定性,以及与所依赖的第三方系统之间相互访问的稳定性,都会受到错综复杂的云生产环境的未知暗债(“暗债”是 IT 系统中具有以下特点的漏洞——在引发故障之前,这些漏洞不为人知或不可见。"暗债“源自物理学术语“暗物质”,两者都
近日,云原生计算基金会 (CNCF) 宣布云原生的混沌工程 Chaos Mesh 正式进入 CNCF 沙箱托管项目,这是 CNCF 接纳的第二个由 PingCAP 团队设计并研发的项目。
Chaos Mesh 是一个云原生的混沌测试平台,在去年的最后一天,我们开源了这个项目,以帮助大家更好的进行混沌实验。从开源到现在近一年的时间里,Chaos Mesh 在所有贡献者的共同努力下,在不断完善新功能的同时,也在易用性和稳定性上取得了阶段性的成果。今天,我们自豪的宣布 Chaos Mesh 1.0 正式发布!
继2020年7月作为沙盒项目进入 CNCF 后,Chaos Mesh[1] 1.0 于近日正式发布,Chaos Mesh 1.0 是重要里程碑,经过开源社区内10个月的努力,Chaos Mesh 在功能、可扩展性和易用性方面已经准备就绪。不仅支持更多混沌注入的类型,提高了框架组件的稳定性,并且增加了 Chaos Dashboard 组件用来改善 Chaos Mesh 的易用性。
LitmusChaos[1]是一个开源的混沌工程平台,它允许团队通过受控的方式诱导混沌测试来识别基础设施中的弱点和潜在的中断。混沌工程验证了业务服务的弹性,并帮助 DevOps 流水线主动构建对软件和基础设施故障更具弹性的代码。
体现在开发者的世界大抵就是:如果你不提早发现和解决问题,最后问题就会在周末 / 半夜来解决你。
混沌工程师一门新兴的技术学科,它的初衷是通过实验性的方法,让人们建立复杂分布式系统能够在生产中抵御事件能力的信息。
随着分布式、云原生成为主流的系统架构设计方案,大规模分布式系统的稳定性保障能力越来越成为业界关注的重点。如今,混沌工程作为保障系统稳定性的利器,受到业界广泛关注,中国信通院作为国内最早推进混沌工程标准化工作的单位,联合混沌工程实验室全体成员单位、社区、媒体共同发起国内首个混沌工程问卷调查,以期掌握我国混沌工程的接纳程度和特点。 本报告采用在线调查加线下访谈的方式,共回收有效问卷 1016 份、访谈企业 17 家。报告的第一部分介绍调查背景,第二部分介绍我国混沌工程当前使用情况,第三部分是混沌工程致力于提
公司新成立了一个稳定性团队,20年的重要目标之一就是开展混沌工程。为了后续更好的开展工作,记录关于“混沌工程”相关的知识以及工程实践。
负责B站基础架构存储/微服务质量保障,一直从事中间件的质量工程建设工作,专注于分布式系统测试方案设计,应用和推广。
Tech 导读 本文从整体介绍了混沌演练的实践流程,读者可以通过本文了解到混沌实践的典型演练场景、重要考核指标以及风险控制方案等。
Chaos Engineering(混沌工程),相信搞互联网的或多或少都听过,Netflix 发明了 Chaos Monkey,经过社区的发展回馈,慢慢形成了 Chaos Engineering。
原文链接:https://www.infoq.cn/article/bxGvrb_CxAZD6Wv3fUj8
TakinTalks社区专家团成员。拥有多年开发和运维经验,专注高可用领域,目前负责中国人寿混沌工程等多项高可用举措的规划和落地实施,对于构建高可用系统具有深入的理解和实践经验。
企业如何规模化地赋能团队,以应对上云后所遭遇的未知暗债?在解决这个复杂问题的过程中,混沌工程诞生了。
Chaos Mesh® 是基于 K8s 的混沌测试平台,而对于部署在物理机上的应用来说,混沌测试同样重要。本文将向大家介绍一款基于 Chaos Mesh®️ 打造的混沌工程测试工具 Chaosd,用于在物理机环境上注入故障,并提供故障恢复功能。
一个系统的复杂性往往是无法预知的,而且这种状态是很难琢磨,因为任何的系统总是在确定性的状态下存在一种不可预知的非确定性,这样的案例可以说是有很多的,比如XX城市的X系统由于网络故障导致系统不可用,可以说这样的案例太多。所以针对每个系统而言都是存在稳定状态和不稳定状态,很说明确的说混沌与不确定性是一回事。其实在系统的边界而言,或者是从系统最初设计以及保障角度而言,混沌状态它首先代表的是系统是处于一个稳定性的状态,只是系统在运行的过程中由于局部技术问题以及可能存在的全局技术问题导致系统出现不稳定的状态,虽然我们很清楚这种现状是客观存在并且可能是无法改变的,但是作为技术团队,需要站在系统的高可用,可靠性,稳定性等等角度,需要最大寻求系统的确定性以及让系统的运行始终在可以掌控的范围内。混沌工程的核心需要解决的是模拟现实中可能会出现的不可预知的情况以及本身客观存在的情况,比如网络故障,云服务器大面积出现瘫痪等情况了,那么在这种情况发生后,如何能够使用成熟的技术方案保障产品的可用性以及保存数据的完整性,而不至于在现实中真的出现该问题的时候表现的束手无策。
Apache APISIX 是一个高性能、可扩展的微服务 API 网关。它是 Apache 软件基金会的顶级项目之一,为全球数百家公司提供服务,处理其关键任务流量,包括金融、互联网、制造、零售和运营商。客户包括美国宇航局、欧盟数字工厂、中国移动和腾讯。
阿里云在那天,至少挂半小时。“我们在运维上的一个操作失误,导致一些客户访问阿里云官网控制台和使用部分产品功能出现问题,引发了大量吐槽。”
近来 FreeWheel 微服务业务团队的业务逐渐扩大,单体服务已经无法胜任,于是我们如火如荼地开展了向微服务迁移的工作,一时间,服务如雨后春笋般冒了出来。在享受微服务带来便利的同时,我们也面临着众多服务带来的整体稳定性的考验。尽管我们有着完善的监控和报警系统,一旦故障发生,总是能第一时间通知到工程师来排查问题,但是这些都是事后的响应和应对。如何能提前了解系统可能会出啥问题,啥时候会出问题,出了问题怎么应对变得至关重要。混沌工程是帮助解决这一问题的不二选择,本文主要聊一下 FreeWheel 微服务业务团队在混沌工程道路上的实践。
为了保障云上客户的系统稳定性,最近研究了混沌工程 Chaos Engineering 的历史和相关工具。本篇探讨下混沌工程的历史,社区给的实践原则,同时演示下混沌工具 Chaos-mesh 在腾讯云 TKE 上的使用。
CNCF 技术监督委员会(TOC)已经投票接受 Chaos Mesh 作为 CNCF 的孵化项目。
2008 年 Netflix 在整体微服务化和数据中心迁移至 AWS 云的背景下,开始了在生产环境进行系统弹性的测试。最早为大家熟知的是 Chaos Monkey,一个在生产环境中随机选择并关闭服务节点的工具。它的名字来源于其工作的方式:如同一只野生、武装的猴子,释放到在数据中心,来造成严重的破坏。
领取专属 10元无门槛券
手把手带您无忧上云