从 2010 年 Netflix 上线 Chaos Mokey 的第一个版本到如今，虽然混沌工程开展已历时十年，但其实只在少数大厂外面有较成熟的落地，对绝大部分研发同窗来说，混沌工程还是一个比较生疏的范围。
散布式和微效劳化曾经成为主流的系统架构设计方案，大规模散布式系统的可用性保障才能越来越成为关注的重点。混沌工程也末尾如雨后春笋般在各大企业外部萌芽生长，但大部分还处于初期的探求阶段，在实际进程中也遇到了这样或那样的成绩，有技术上也有认知层面上的，这些成绩难免会对混沌工程的快速落地产生阻力。
下面引见一下字节跳动在混沌工程实际进程中的一个关键阶段：场景化自动实验。希望本文可以协助大家加深对混沌工程价值的了解，对设计混沌工程实验、落地混沌工程树立提供更多的思绪。
二、什么是场景化自动实验混沌工程的初级准绳要求可以在消费环境自动的运转实验，这个目的并不是一挥而就的。
依据混沌工程成熟度模型(CMM)[4]阐明，要辨别从“熟练度”和“运用度”两个维度同时停止树立。其中，“熟练度”表现了混沌工程系统的有效性和安全性，“运用度”权衡了混沌工程实验掩盖的广度和深度。在混沌工程树立的中前期，这两点都是混沌工程成功落地的关键途径。
在混沌工程的初级阶段，通常都会树立一个缺点注入测试平台(FIT，Fault Inject Testing)，集成一些常见的缺点场景或异常事情的模拟才能，由业务或 QA 同窗设计并执行实验来验证系统的韧功才能。
在这个阶段，基础架构和业务系统的完成都能够处于比较集约形状，混沌工程平台的缺点注入才能需求兼容各种业务架构的完成方案和软硬件环境，执行实验时，业务同窗不只要设计实验的缺点场景(机房网络缺点、下游效劳宕机等)、配置演练环境(目的效劳、实验集群等控制实验的爆炸半径)，还要找到可以描画实验时效劳形状的波动性的目的(如 metrics、日志或告警等)，然先手动启动实验，执行人还要不停的察看波动性目的的变化，判别系统的容灾逻辑或弹性策略能否被正确触发、业务系统的表现能否契合预期等等。假设在执行进程中发现异常，需求立刻终止实验，收敛实验影响。
整个实验进程的人力成本较高，实验的操作门槛也较高，再加上这个阶段业务同窗对混沌工程价值和理念的认知还处于较初级水平，很难会自动对本人的效劳设计实验，更无法保证明验的常态化执行。因此，混沌工程实验的时效性和业务系统的弹性容灾策略继续有效就比较难以保证了。
如何打破这个阶段、成功抵达混沌工程的终极目的呢?
经过不断的思索，我们以为混沌工程树立需求一个过渡阶段，即场景化自动演练。
所谓场景化自动演练，就是在明白混沌工程的终极树立目的的前提下，以终为始，分阶段去设计混沌工程的实验标准、定义技术标准，搭配工程化才能，逐渐将人和业务引导到混沌工程树立的高速公路上，共同推进 CMM 模型的熟练度和运用度。
所以，场景化自动实验是通向混沌工程自动化树立的关键途径。
首先需求明白混沌工程的最终目的，以终为始，反推以后阶段应该树立什么样的技术标准和标准才能。
然后，依据业务以后的基础架构现状和实验诉求构建一个通用的实验场景，由混沌工程平台方在保证明验风险可控的条件下自动对业务系统停止实验。这样，在满足业务需求的同时又可以推进相关技术标准和基础才能的树立，而且对业务同窗的资源依赖较少。
以字节跳动为例，要实如今消费环境自动的执行可控的混沌工程实验，以后阶段应该具有的才能包括：
可以在消费环境继续的运转实验并具有实验爆炸半径的控制才能
选定一个命中业务痛点且通用的实验场景，构建通用的自动化执行实验才能
可以描画效劳波动性的通用目的
自动检测波动性目的的变化
自动终止实验【在实验爆炸半径可控的状况下，非必须】
FIT 平台需求业务同窗剖析业务容灾场景并制定实验，然后执行实验停止验证，混沌工程平台方只是给予一些技术支持和建议。在业务同窗对混沌工程认知度不高状况下，实验的自动性、掩盖率、时效性都很难保证，假设再想让业务同窗去配合树立一些混沌工程的基础才能难度就可想而知。
转换一下思绪，将业务自动改为平台自动!由混沌平台针对业务系统的某个场景自动执行混动实验来验证效劳的弹功才能，业务同窗只需关注实验结果。只需实验场景契合业务痛点、实验结果对业务构建弹性系统有意义，业务同窗自然会认可混沌工程的价值，也会愈加积极的参与混沌工程实验和混沌工程的基础树立。
五、实验场景混沌工程的价值是发现业务系统中潜在薄弱环节，提升业务系统韧功才能，即效劳可用性和波动性，所以自动实验场景也应该满足这个前提。
在字节跳动，自动实验落地的第一个场景是验证效劳调用链的强弱依赖关系。所谓强弱依赖关系，就是当拜访的下游效劳异常(效劳宕机、照应超时、接口前往失败等)时，调用方的波动性和可用功用否会遭到影响。例如，查询缓存 miss 或失败后可以继续回源拜访数据库，缓存的成绩并不会影响效劳可用性，这个缓存就是个弱依赖。
为什么要选择这个场景呢?公司的很多线上运营事故都是由于不合理的依赖关系招致的。字节跳动有很多高 QPS 的海量效劳系统，为了保证用户体验，对高可用高波动性的要求很高，会经过各种缓存、效劳兜底、数据兜底等容灾策略来增增强依赖效劳的数量。另外，在字节跳动的效劳管理体系中，会依据效劳间的强弱依赖调用关系为某些缺点场景预设自动容灾升级的策略。比如，当效劳管理系统检测到系统负载过高时，可以自动对弱依赖的下游执行升级，经过 FailFast 来缓解系统的负载。因此，业务担任人通常都会比较关注效劳的强弱依赖关系。
(责任编辑：admin)