混沌工程是近年来新出现的概念，主要用于稳定性方面的研究，英文全称为chaos engineering，由网飞公司最先提出。因为最开始混沌工程称作chaos monkey，形容就像有一只猴子在系统中捣乱一样，以至于到现在每次提到混沌工程都会用一只捣乱的猴子来比喻。
在上个文章中探讨了微服务架构中规模化产品的集群化的验证方式，这样的目的是可以实现针对服务可持续的验证。微服务架构它的特点之一是服务太多，很难保障所有的服务都是可用的，有可能出现这样的一个情况就是晚上上线的时候，产品的各个业务形态都是正常的，但是到第二天的时候，某个服务由于某些问题导致服务不可用然后影响到具体的业务形态，从而影响到客户的使用，接着而来的就是各种复盘以及问题的追究，这种是最让人头疼的。也会让业务交付的团队承担不应该属于自己的问题。那么这就涉及一个很核心的问题，这问题到底是谁的责任了？总不能让运维去承担吧。
https://gitee.com/lengdanran/chaostoolkit-experiment
ChaosMeta 是蚂蚁集团开源的一款云原生混沌工程平台。它凝聚了蚂蚁集团在公司级大规模红蓝攻防演练实践中多年积累的方法论、技术以及产品。由“风险目录”（内部对各领域技术组件的通用风险场景手册）作为理论指导，结合技术实践，为蚂蚁集团多年的各种大促活动保驾护航。
来源 | https://dzone.com/articles/top-open-source-projects-for-sres-and-devops
作者 | Nir Sharma 译者 | Sambodhi 策划 | 田晓旭 构建可扩展的、高可靠性的软件系统是每个 SRE 的终极目标。本文概述了在监控、部署和维护领域中最受欢迎的几个开源项目。 成功的 SRE 之路就在于不断的学习。对于 SRE/DevOps 来说，目前已经有许多优秀的开源项目，每个项目都有新的、激动人心的实现，而且常常会面对独特的挑战。这些开源项目完成了繁重的工作，因此你可以更轻松地完成自己的工作。 在本文中，我们将介绍在监控、部署和维护领域中最受欢迎的几个开源项目。在这些项目中，有一
大家吼，我是你们的朋友煎饼狗子——喜欢在社区发掘有趣的作品和作者。【每日精选时刻】是我为大家精心打造的栏目，在这里，你可以看到煎饼为你携回的来自社区各领域的新鲜出彩作品。点此一键订阅【每日精选时刻】专栏，吃瓜新鲜作品不迷路！
在 InfoQ 混沌工程系列访谈中，企业如今对混沌工程普遍的感知是：企业内部不同部门认知不统一，业内对混沌工程没有相对统一的评价标准。随着云基础设施的广泛应用，混沌工程不断与国内大公司碰撞出火花。2020 年初，中国信通院开始组织专家进行混沌工程技术研究，提出应用混沌工程方法来验证云原生系统的韧性架构。
那到底是先有Class还是先有Object？JVM 是怎么处理这个“鸡·蛋”问题呢？
这个月的8号、9号，个人很荣幸参加了China.NET Conf 2019 , 中国.NET开发者峰会，同时分享了技术专题《.NET技术架构下的混沌工程实践》，给广大的.NET开发小伙伴介绍混沌工程和高可用性改造实践。会后大家伙聚餐的时候，陈计节老师建议大家将各自的议题分享到社区，分享给大家。因此，今天和大家分享我的技术专题《.NET技术架构下的混沌工程实践》。
随着分布式、云原生成为主流的系统架构设计方案，大规模分布式系统的稳定性保障能力越来越成为业界关注的重点。如今，混沌工程作为保障系统稳定性的利器，受到业界广泛关注，中国信通院作为国内最早推进混沌工程标准化工作的单位，联合混沌工程实验室全体成员单位、社区、媒体共同发起国内首个混沌工程问卷调查，以期掌握我国混沌工程的接纳程度和特点。 本报告采用在线调查加线下访谈的方式，共回收有效问卷 1016 份、访谈企业 17 家。报告的第一部分介绍调查背景，第二部分介绍我国混沌工程当前使用情况，第三部分是混沌工程致力于提
作者：yorkoliu，腾讯 IEG 业务运维专家 一、前言 上一篇文章《云原生背景下的运维价值思考与实践(上)》 重点介绍了云原生背景下运维转型的思考，围绕着整个 DevOps 交付链，贴近业务不断输出运维的能力与价值。这篇内容我想谈谈 DevOps 的下半段，通过我们的构建服务稳定性保障实践，利用 SRE 的思想与方法，不断去冲刺稳定性的终极目标：“提升 MTBF（平均故障时间间隔）、降低 MTTR（故障平均修复时间）”，很多小伙伴会有疑问，DevOps 与 SRE 到底是什么样的关系？在 Google
不管在将软件投入生产之前进行多么困难的测试以发现错误，错误总是会发生 - 云和可用区域会出现问题，网络会崩溃，是的，错误会让人感觉它们的存在。容错性（Resilience/弹性）是指一个系统承受这些错误的能力 - 例如，一个高度容错性的系统，一个由松散耦合的微服务构建的系统，它本身可以很容易地重新启动和扩展，在不影响用户的情况下克服这些错误。混沌工程是在系统出现故障之前，将其注入系统的实践。混沌工程现在被认为是确保当今频繁变化和高度复杂的系统实现所需的容错性的基本方法。通过混沌工程，可以在引起用户问题之前发现和纠正未预料到的故障场景。
通过前面对混沌工程工具的详细分析，我们已经对如何进行故障注入有了更明晰的了解。然而，本文将详细介绍混沌工程的具体实施过程，以便提供全面的指导。
腾讯互娱运营活动每天的访问人次超过 100 亿次，高峰的 QPS 超过 100 万，每天活动代码发布更新超过 500 次，数据量也超过 200 TB。面对海量的用户请求和快捷的版本发布迭代速度，如何才能又快又稳地保障服务的运营？腾讯互娱活动运营团队给出的解决方案是 DevOps 和云原生。
本篇文章整理自腾讯互娱高级工程师吴召军在 PingCAP Infra Meetup 上的演讲实录，欢迎点击【阅读原文】查看视频回放，后台回复 “135” 即可获取本期 PPT 链接。
导读：与任何新概念一样，混沌工程时常被误解。本文会探讨混沌工程是什么以及不是什么。
测试您可以预测的事故是必不可少的。但是随着数字化转型和云原生架构带来的复杂性，团队需要一种方法来确保应用程序能够承受生产的“混乱”。混沌工程满足了这一需求，因此组织可以提供在任何条件下都可以正常运行的强大、有弹性的云原生应用程序。
奈飞公司提出混沌工程实践后，伴随着业务上云，国内企业纷纷仿效，不少工具厂商也推出了相应的工具。但有些企业的运维部门在实践混沌工程时，主要是用工具厂商所提供的工具，或使用自研的工具，进行故障注入探索性测试。其间缺乏针对该企业以前所发生的生产环境线上事故设计混沌工程实验。这导致将“混沌工程实验”做成了场景较为简单和单一的针对基础设施层的“故障注入探索性测试”。其后果就是测试做了不少，但发现的未知的复杂系统的失效模式却不够多。另外这些测试与线上事故缺乏直接关联，导致难以体现混沌工程实践的价值。
本篇是《数智万物下的运维思考》第3部分“流程”第3章的“故障管理中的事前管理”的部分内容。主要梳理一下最近行业中比较火的混沌工程，本文简单先从以下5个方面介绍一下我对混沌工程的理解：
随着计算机、通信技术和区域医疗协同服务的不断发展，信息的安全与保密显得越来越重要。医学图像作为诊断依据的重要部分需要在公网上传播，为了防止病人敏感信息的非法泄漏，研究医学图像加密有着重要的意义。
周末比较无聊，在浏览论坛的时候，偶然看到一个程序猿提问的问题，他时这样提问的：突然想到一个很菜的问题, 倒底先有Object还是先有Class?所有类都是Object的子类, Object是作为一个类
软件和系统开发是创新和解决未知问题的练习。软件和系统是容易出错的，因为它们是由具有不同观点和技能的人（很可能是多人）制作的。技术变得越来越分散和复杂，尤其是随着微服务的推动。很少有人拥有完整的端到端知识 […]
2014年，Netflix团队创建了一种新的角色，叫作混沌工程师（Chaos Enigneer），并开始向工程社区推广。项目目标、业务场景、人员结构、实施方式的不同导致了对于稳定状态行为的定义不太标准。
混沌测试是一种基于系统状态的测试方法。通过对系统状态进行测量，可以测试系统在不同条件下的运行状态，这是测试过程的基础。
近年来，随着系统架构逐渐向微服务架构演化，开发效率以及系统扩展性大幅提高。但同时，系统的复杂性也随之提高，传统的测试方法已经不能全面理解和覆盖系统所有可能的行为，测试的有效性被大打折扣。我们通过各种测试、SRE、DevOps、金丝雀发布、蓝绿部署、预案、故障演练等方法，希望能够防患于未然。但服务规模不断增长，服务之间的依赖性所带来的不确定性也呈指数级增长。在这样的服务调用网中，任何一环出现的正常或异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。
在分布式系统架构下，服务间的依赖日益复杂，很难评估单个服务故障对整个系统的影响，并且请求链路长，监控告警的不完善导致发现问题、定位问题难度增大，同时业务和技术迭代快，如何持续保障系统的稳定性和高可用性受到很大的挑战。我们知道发生故障的那一刻不是由你来选择的，而是那一刻来选择你，你能做的就是为之做好准备。所以构建稳定性系统很重要的一环是混沌工程，在可控范围或环境下，通过故障注入，来持续提升系统的稳定性和高可用能力。
随着数字经济转型逐步深化，众多企业正迈入全面上云阶段。然而，云计算架构所带来的复杂性也让稳定性面临极大挑战。伴随着云计算规模的快速增长，云服务作为社会基础设施的重要性也日益提升。腾讯云深知质量乃生命线，稳定性至关重要且不容忽视。
很多人都会把混沌工程和测试区分不清楚，我从执行时机、执行后是否对系统产生新认知，做了一张图如下。
近来 FreeWheel 微服务业务团队的业务逐渐扩大，单体服务已经无法胜任，于是我们如火如荼地开展了向微服务迁移的工作，一时间，服务如雨后春笋般冒了出来。在享受微服务带来便利的同时，我们也面临着众多服务带来的整体稳定性的考验。尽管我们有着完善的监控和报警系统，一旦故障发生，总是能第一时间通知到工程师来排查问题，但是这些都是事后的响应和应对。如何能提前了解系统可能会出啥问题，啥时候会出问题，出了问题怎么应对变得至关重要。混沌工程是帮助解决这一问题的不二选择，本文主要聊一下 FreeWheel 微服务业务团队在混沌工程道路上的实践。
混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。由Netflix在2010年底提出，2012开源Chaos Monkey(混乱猴子)，中间经过了一系列的演化。具体路线为：
ChaosBlade 项目覆盖基础资源、应用服务、容器服务等混沌实验场景。在实验工具设计之初就考虑了场景模型统一，便于场景扩展和沉淀，也为平台托管实验工具实现统一场景调用提供模型依据。ChaosBlade 项目中所有的实验场景均遵循此实验模型设计，下面通过实验模型的推导、介绍、意义和具体的应用来详细介绍此模型。
随着云计算技术的快速发展，越来越多的企业和组织将其业务迁移到云平台，以实现更高效、灵活和可扩展的资源管理。然而，由于云环境的复杂性高，也为业务稳定性带来了一定的挑战，那如何确保业务的高可用性和数据的安全性呢？进行跨 AZ（可用区）容灾和混沌演练变得尤为重要。
其实落地混沌工程的原因很简单，业务和技术的复杂性提升带来的不可控风险和成本越来越高。这些复杂性主要体现在这几个方面:
Ctrip SRE，负责携程网站系统可靠性保障，探索和落地高可用体系的运维架构，如多活容灾、全链路压测、混沌工程、AIOPS等。
🎉大家好！猫头虎博主来啦！在云原生和微服务的时代，系统的复杂性日益增加，如何确保系统的健壮性和可靠性成为了一个巨大的挑战。Chaos Engineering（混沌工程）为我们提供了一种新的方法，通过主动注入故障来验证系统的弹性。在这篇博文中，我将带领大家探索如何在服务网格中进行故障注入实验，分享Chaos Engineering的最佳实践，并深入研究服务网格如Istio中的故障注入功能。对于关心系统健壮性、微服务稳定性和混沌工程 的读者，这篇文章将为你提供丰富的实践知识！🚀
“There (is) order and even great beauty in what looks like total chaos. If we look closely enough at the randomness around us, patterns will start to emerge.”
LitmusChaos[1]是一个开源的混沌工程平台，它允许团队通过受控的方式诱导混沌测试来识别基础设施中的弱点和潜在的中断。混沌工程验证了业务服务的弹性，并帮助 DevOps 流水线主动构建对软件和基础设施故障更具弹性的代码。
什么是混沌工程？用一句简单的话来解释，就是使用科学方法，用做有对照组的实验，来实证复杂的分布式软件系统，能够在生产环境抵御来自现实世界不可预知的各种状况。
如今是数据驱动时代，数据库作为企业的核心资产之一，其安全性和稳定性显得尤为重要。然而，面对复杂多变的业务场景和不断演变的技术挑战，如何把握现有数据库架构可承受故障的故障级别、发生故障后的高可用性方案是否有效，成为了许多数据库用户关注的焦点，也是腾讯云MySQL在服务众多重保用户时思考的问题。
对于国外的“网红”技术，国内公司都是要试一下的。继云计算、大数据、人工智能、微服务和区块链之后，混沌工程也引起了国内IT领导们的注意。他们会叫来手下技术骨干说：“试一试混沌工程吧”。
叮铃铃~ 程序员小陈的电话响了，刚进入梦乡的他睡眼朦胧的在黑暗中摸出手机，“喂...... 哪位......” “最近升级的 2.3.7 版本，又出现了 bug，客户在问了，尽快处理下！” “好...... 这就去......” 加班修 Bug 已成为小陈的家常便饭。查验问题，处理故障，恢复服务...... 估计前半夜又没得睡了。这样的经历，作为程序员的你一定也并不陌生。 近年来，云原生架构的广泛应用及微服务的普及令开发的便捷性大幅提升，随之而来，复杂的分布式服务体系中，故障发生的随机性和不可测试性也大大
Chaos Mesh 是一个云原生的混沌测试平台，在去年的最后一天，我们开源了这个项目，以帮助大家更好的进行混沌实验。从开源到现在近一年的时间里，Chaos Mesh 在所有贡献者的共同努力下，在不断完善新功能的同时，也在易用性和稳定性上取得了阶段性的成果。今天，我们自豪的宣布 Chaos Mesh 1.0 正式发布！
为了保障云上客户的系统稳定性，最近研究了混沌工程 Chaos Engineering 的历史和相关工具。本篇探讨下混沌工程的历史，社区给的实践原则，同时演示下混沌工具 Chaos-mesh 在腾讯云 TKE 上的使用。
随着微服务的盛行以及容器技术的普及，借助 Kubernetes 的容器编排能力，部署一套分布式系统的难度也越来越低。但随之而来的是越来越复杂的系统，以及越来越难的系统可靠性测试，有时仅仅是一个接口的故障，就可能导致整个系统的雪崩。在雪崩中，找到那个最初故障的接口也十分困难，因为到处都在报错。
来源 | https://github.com/wizardbyron/principlesofchaos_zh-cn/
本文已存放在 https://github.com/wizardbyron/principlesofchaos_zh-cn 上，欢迎来 PR
混沌工程的核心是通过实验的方式来验证系统在稳定下下它的不稳定性，从而通过混沌工程实验的方式来模拟这种情况并给出合理的解决方案，所以它最重要的不是混沌实验，而是实验背后的解决方案。业内最早实践混沌工程的公司是Netfix，混沌工程具体它的定义为：“混沌工程是一门在系统上进行实验的科学，目的是建立系统抵御生产环境中失控情况的能力以及信心”。比如在生产环境中数据库的实例突然瘫痪，云服务器的实例突然消失以及底层服务出现雪崩等等一系列的故障情况下，这个时候整个系统层面需要考虑的是出现这种极端以及很平常的故障下，如何使用技术的手段来保障系统依然能够给客户提供价值从而保障系统的可用性，特别是在分布式架构下服务复杂的调用链以及涉及众多中间件，更加需要考虑在异常的情况下系统的伸缩性和高可用性。
上篇文章，总体上分析了chaosmesh和chaosblade两个工具的对比和原理，本文继续分析chaosmesh的原理；几个常用的项dnsChaos、stressChaos、NetworkChaos和IOChaos注入项的原理。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
