1。背景从2010年Netflix推出第一版ChaosMokey到现在，混沌工程的发展虽然历时十年，但实际上只是在少数几家大厂才走向成熟。对于大多数研发学生来说，混沌工程仍然是一个相对较新的领域。分布式和微服务已经成为主流的系统架构设计方案，大规模分布式系统的可用性保障能力越来越成为人们关注的焦点。混沌工程也开始在各大企业如雨后春笋般萌芽生长，但大多还处于初级探索阶段。在实践过程中，他们也遇到了这样或那样的技术上和认知上的问题。这些问题不可避免地会阻碍混沌工程的快速实施。下面介绍字节跳动混沌工程实践中的一个关键阶段：基于场景的主动实验。希望本文能帮助大家加深对混沌工程价值的认识，为设计混沌工程实验和实施混沌工程建设提供更多思路。2、什么是基于场景的主动实验？混沌工程的高级原则要求能够在生产环境中自动运行实验。这个目标不可能一蹴而就。根据混沌工程成熟度模型（CMM）[4]，建设应从“熟练”和“应用”两个维度同时进行。其中，“熟练”体现了混沌工程系统的有效性和安全性，“应用”衡量了混沌工程实验覆盖的广度和深度。在混沌工程建设的中前期，这两点是混沌工程成功实施的关键路径。在混沌工程的初始阶段，通常会搭建一个故障注入测试平台（FIT，FaultInjectTesting），集成一些常见故障场景或异常事件的模拟能力，业务或QA同学设计并执行实验来验证弹性的系统能力。在这个阶段，基础设施和业务系统的实施可能处于比较粗放的状态。混沌工程平台的故障注入能力需要兼容各种业务架构实现方案和软硬件环境。业务同学在进行实验时，不仅需要设计实验故障场景（机房网络故障、下游服务宕机等），配置演练环境（目标服务、实验集群等）控制实验的爆炸半径),并找到能够描述实验过程中服务状态稳定性的指标(如metrics,logs等)或者告警等),然后手动启动实验,执行者要不断观察变化判断系统容灾逻辑或弹性策略是否正确触发，业务系统性能是否达到预期等稳定性指标。如果在执行过程中发现异常，需要立即终止实验，以减少实验的影响。整个实验过程人工成本高，实验操作门槛高。另外，现阶段商科学生对混沌工程的价值和概念的理解还处于比较初级的水平，很难主动在自己的服务上设计实验。更不可能保证实验的规范化进行。因此，更加难以保证混沌工程实验的及时性和业务系统弹性容灾策略的持续有效性。如何突破这个阶段，成功达到混沌工程的终极目标？通过不断的思考，我们认为混沌工程的建设需要一个过渡阶段，即基于场景的主动演练。所谓场景化主动演练，就是设计混沌工程的实验标准，分阶段定义技术规范，匹配工程能力，逐步引导人们和企业走在混沌工程建设的高速公路上，共同推动熟练应用。CMM模型。因此，基于场景的主动实验是混沌工程自动化建设的关键路径。混沌工程演进图3.如何构建基于场景的主动实验首先要明确混沌工程的终极目标，以终为始，推导出应该有什么样的技术规范和标准能力现阶段建成。然后，根据当前业务基础设施现状和实验需求构建通用实验场景，混沌工程平台将在实验风险可控的情况下，主动对业务系统进行实验。这样，在满足业务需求的同时，可以促进相关技术规范和基础能力的建设，减少对商科生资源的依赖。以字节跳动为例，要在生产环境中自动执行可控的混沌工程实验，现阶段应具备的能力包括：能够在生产环境中持续运行实验，具有控制爆炸半径的能力实验选择命中业务痛点和常见实验场景，构建通用自动化执行实验能力能够描述服务稳定性常用指标自动检测稳定性指标变化自动终止实验【当实验爆炸半径可控时不需要】场景主动实验CapabilityTopology4.ActiveExperimentsFIT平台要求业务同学分析业务容灾场景并制定实验，然后执行实验进行验证。混沌工程平台仅提供部分技术支持和建议。当商科学生对混沌工程的认识不高时，很难保证实验的主动性、覆盖面和时效性。如果想让商科学生配合混沌工程的一些基础能力的建设，难度可想而知。转变思维方式，变业务主动权为平台主动权！混沌平台会主动针对业务系统的某个场景进行混合实验，验证服务的弹性。商科学生只需要关注实验结果即可。只要实验场景贴合业务痛点，实验结果对业务构建弹性系统有意义，商科学生自然会认可混沌工程的价值，会更加积极参与混沌工程实验和基础设施建设建造。5、混沌工程在实验场景中的价值在于发现业务系统中潜在的薄弱环节，提高业务系统的弹性，即服务的可用性和稳定性。因此，活跃的实验场景也应该满足这个前提。在字节跳动中，第一个实现主动实验的场景是验证服务调用链的强依赖和弱依赖。所谓强弱依赖是指当接入的下游服务出现异常（服务宕机、响应超时、接口返回失败等）时，是否会影响调用方的稳定性和可用性。比如在querycachemiss或者失败后，可以继续回源访问数据库。缓存问题不会影响服务可用性。这个缓存是弱依赖。为什么选择这个场景？公司的很多线上运营事故都是由于不合理的依赖造成的。字节跳动有很多高QPS的海量服务体系。为了保证用户体验，它对高可用性和高稳定性有很高的要求。它将通过缓存、服务覆盖、数据覆盖等多种容灾策略，减少强依赖服务的数量。.此外，在字节跳动的服务治理体系中，根据服务之间的强弱依赖调用关系，针对某些故障场景预设了自动容灾和降级策略。例如，当服务管理系统检测到系统负载过高时，可以自动降级弱依赖下游，使用FailFast来缓解系统负载。因此，业务领导者通常更关注服务的强依赖和弱依赖。服务依赖于调用链6.自动化主动设计和执行实验意味着将业务端的人力成本转移到混乱的平台上。混乱的平台必须使用通用化和自动化的执行能力来降低人力成本。需要强调的是，这里的泛化和自动化必须符合混沌工程的最终目标，能够承载过渡阶段的职责。可以从混沌工程的高层原理来分析[2]：服务稳定状态假设：找到能够描述服务稳定状态的通用指标，可以是metrics、alarms等。在实验执行之前，这些稳态指标应处于稳定状态；进行实验时，如果服务的可用性或稳定性受到影响，稳定性指标会发生变化，如指标曲线剧烈波动、触发告警等；实验结束后，稳定性指标会恢复到之前的稳定状态。如果在进行实验时稳态假设发生变化，这就是强依赖性。在生产环境中运行实验：建议在风险可控的条件下在生产环境中运行实验，因为系统的行为会因环境和流量模式而异，并且系统用户不会像您预期的那样与您的系统进行交互.系统进行交互。当然，在生产环境中进行混沌工程实验很可能是有害的。为避免对用户体验造成较大影响，必须控制实验的爆炸半径，如筛选掉少量实验流量。这就需要混沌平台具备实验性的流量筛选和调度能力。多样化的真实世界事件：即模拟各种故障的能力。因为是场景化实验，对多样性的诉求没有FIT那么强烈。最小化“爆炸半径”：如果选择在线上环境进行实验，需要具备筛选实验流量的能力，即过滤掉实验所需的最小流量，严格控制实验范围“爆炸”。连续自动化运行实验：通过工程化能力，将实验目标过滤、实验流量筛选、实验执行、稳态检测、实验报告生成、实验结果反馈收集串联成自动化执行流程，减少人为依赖.此外，混沌工程实验从来都不是一蹴而就的。通过规范化运行实验，持续保证服务的高可用和弹性机制符合预期。混沌工程高级原理VII。服务标准和技术规范一个公司通常有很多条产品线，每个产品中包含很多微服务，还依赖于中台服务或基础组件。这些不同模块的开发语言、Service框架、技术栈等可能各不相同。为了实现混沌工程的泛化和自动化能力，需要制定一些通用的服务标准和技术规范。混沌工程不仅需要了解业务系统当前的技术栈，还需要能够预测未来的技术发展趋势，帮助业务提前规划可行的技术规范并协助建设。比如，如何定义服务的稳定状态？在字节跳动中，我们定义了一个服务级别指标指标，从调用者的角度来描述服务的稳定状态：.调用者从响应数据包中解析稳定性字段并报告指标。一些异常场景（比如被叫没有响应）导致调用方无法解析出稳定域，会报一个特殊的不稳定值。之所以在响应报文中单独定义一个稳定字段，是为了区分系统错误和业务错误。因为业务错误并不表示服务有问题，所以我们更关注系统错误。比如删除好友，被叫返回好友不存在的错误。这个错误并不意味着系统的稳定性有问题。该规范最初仅用于字节跳动的少数核心服务。其他服务通常有自己的稳定性指标，有些服务可能需要多个度量指标来描述服务的稳定性。由于混沌工程的通用性需要一个通用的指标来描述所有服务的稳定性状态，经过评估，我们使用稳定性指标作为混沌工程服务的通用稳定性描述指标，并计划推广到全公司，无论服务框架或开发语言，它可以快速且低成本地实施。8.字节跳动混沌工程概述字节跳动混沌工程体系主要包括场景化主动实验平台、FIT平台、红蓝对抗平台。场景化主动实验平台：从平台的角度主动对业务发起混沌实验，在验证业务系统的高可用性和灵活性的同时推进服务标准化和技术标准化建设，提高混沌工程的价值输出和影响力，贡献力量为实现混沌工程的最终目标铺平道路。FIT平台：业务类学生可自行验证业务容灾机制的正确性，具备多种异常事件和故障模拟能力，提供灵活的可视化实验编排能力。红蓝对抗平台：从第三方角度，通过系统、随机的对抗实验，验证业务系统的高可用水平、监控告警的有效性，以及人工干预的时机、故障定位和故障恢复异常情况下的时间是否达标等字节跳动混沌工程总体架构图9.字节跳动场景化主动实验构建方案场景化主动实验流程图1.实验目标同步推进混沌的“精通”和“应用”工程建设，并以生产环境自动执行混沌工程实验为目标，构建场景化主动实验的流程和标准。选取实验场景来验证服务之间的强弱依赖和调用关系。实验可自动运行，具有控制实验爆炸半径的能力。通过验证强弱依赖调用关系的正确性，可以推断服务的稳定性指标是否标准化，促进稳定性指标的标准化。2.实验对象首先要实现字节跳动的核心服务，建立模型基准，然后扩展到更广泛的范围。3.Stabilityindicators&volutionautomaticdetection稳定性指标：由于稳定性指标已经被大部分核心业务作为通用的稳定性描述指标，场景化主动演练将稳定性指标作为稳定性描述的核心指标，同时辅助在判断接口qps成功、失败qps、调用下游成功qps、失败qps、pct99等指标。指标波动检测方案：自动化执行实验需要混沌平台能够自动检测稳定性指标的变化，因为不同服务的指标曲线不同，同一个服务在不同时间的指标曲线也不同，所以预设曲线fluctuate上限阈值的效果肯定不是很好。因此，在项目启动阶段，我们直接探索metrics曲线波动的自动动态检测：一种是Netflix推出的AB测试方案，比较实验曲线和样本曲线的差异，以及另一种是实时计算曲线的变化趋势。要求具备更灵活的流量筛选能力和实验环境隔离能力。现阶段的建设难度和成本都比较高，所以我们选择方案2。自动波动检测：首先参考在线报警的检测方案：在进行主动演练时，先用机器学习训练检测对稳定性指标进行实时建模，然后利用该模型实时检测指标曲线的变化。但由于活跃实验时间短（一个实验节点只有60~120秒），metrics数据点稀疏（一个节点实验时间内只能收集到2~4个数据点），实验流量低（爆炸半径控制5~10QPS），因此基于机器学习的检测效果不理想。因此，我们改为结合多种统计规则的检测算法，根据近期的历史数据动态生成曲线合理的波动范围阈值，然后在实验过程中实时检测增量数据点的波动范围。如果一个数据点超过波动范围阈值，则判断为不稳定。经过不断优化，最终将该场景下的指标检测效果优化到了预期的水平。优化方案：在实践中，我们发现单个稳定性指标的曲线偶尔会出现意想不到的波动噪声，影响曲线检测结果的准确性。因此，我们增加了噪声过滤策略：通过比较多条相关稳定性指标曲线的波动相似度来过滤噪声。比如下游依赖服务注入故障后，下游服务调用失败的指标曲线会上升。如果稳定性指标曲线也上升，且两条曲线的变化趋势相似，则认为曲线变化受实验影响。影响。该策略可以有效滤除偶尔出现的曲线波动噪声。具备稳定状态检测能力，在基于场景的主动实验中，可以根据稳定状态的检测结果，自动推断下游依赖服务是强依赖还是弱依赖。4.最小化爆炸半径控制为了保证实验的通用性，降低构建实验流程的成本，我们选择在生产环境中进行实验，所以最小化爆炸半径控制的能力非常重要。字节跳动的生产环境有灰度上线服务的金丝雀集群。服务启动时，会先升级集群，验证服务的正确性。该集群实例比较少，支持通过修改集群权重来调整进入集群的流量。经验证，在实验流量为5~10QPS时，可以保证稳定性指标检测的准确性。因此，在进行实验时，首先从服务金丝雀集群中随机选择一个实例作为实验目标，计算实例流量与预期流量的偏差重新生成权重值，然后通过修改集群权重来调整实例流量.5、验证方式字节跳动的微服务管理平台通过聚合服务的Trace日志，生成服务间的调用拓扑图。通过OpenAPI可以查询一个服务的所有一级下游依赖服务列表。然后将一段时间的宕机故障逐一注入到下游依赖服务中，同时检测服务的稳定性指标是否有异常波动，从而推断下游依赖服务是否强依赖或弱依赖。需要注意的是，由于实验是对下游依赖的服务一个一个进行，为了避免上一个实验对下一个实验的干扰，我们在两个实验之间增加了一个间隔，具体间隔取决于指标检测算法用过的。6.实验报告实验完成后，平台会将下游依赖服务优劣势的推理结果、执行上下文、稳态指标的监控视图、检测结果汇总成实验报告并将其发送给服务负责人。服务负责人确认实验报告。如果发现实验结果不符合预期，可以通过执行上下文、监控视图等信息辅助定位问题。同时可以在实验报告中注明未达到预期的原因、问题修复方案及修复进度等。平台会定期跟进维修进度，并提醒服务负责人更新结果。若实验结果达到预期或问题已修复，实验报告将进入报表状态，同时记录服务优劣势的推断结果，并输出到服务治理平台上线服务治理。7、实验结果自动保证。业务系统不断迭代，下游依赖也在动态变化。意外引入强依赖会增加系统的可用性风险，因此也需要定期进行基于场景的主动实验。所有已完成的活动实验都可以启用测试结果的自动验证。每隔一定时间自动执行实验，验证下游依赖服务的强弱依赖，并与历史实验结果进行对比，将变化的部分通过实验报告发送给服务。主要的。经服务负责人确认后，新的验证结果将更新存储并发送至服务治理平台。8.场景化主动实验完整实验过程流程图X.场景化主动实验的价值我们的验证范围从核心服务开始，逐步扩展到外围服务。核心服务的验证结果基本符合预期，但仍存在少数稳定性指标不规范、容灾逻辑不符合预期的情况。通过实验结果的自动保障机制，也及时发现了代码变更导致的容灾逻辑失效。周边服务的验证问题较多。稳定性指标严重不规则，无法评估服务的稳定性。容灾逻辑覆盖率低，导致强依赖过多，服务可用性风险较高。需要不断推动业务优化升级，为高可用弹性系统的建设提供一些思路或参考方案。11、近期在基于场景的主动实验方面的工作近期，我们推出了一项新功能，在保证结果的情况下，自动向弱依赖服务注入随机故障，进一步探索弱依赖服务的抗风险能力。我们认为弱依赖服务在任何故障场景下都不应该影响服务的可用性。此外，场景化主动实验还接入了服务的上线流程，当服务变灰时会触发实验，让服务负责人更及时地发现不符合预期的系统变化。及时处理，必要时可以立即终止或回滚Live更改。12、场景化主动实验的未来规划通过场景化主动实验，我们已经能够持续保障字节跳动核心服务的稳定性、指标的标准化、强弱依赖的正确性以及抗风险能力下一步，我们将把场景化主动实验扩展到更大的服务范围和更多的业务场景，让场景化主动实验发挥更大的价值。此外，我们也在思考打通上下游服务，从点到线到面，从更高维度的系统角度探索启发式智能混沌实验。
