新能源天使基金在合肥成立，规模3亿元，助力创新创业发展
06-17
本文从业务角度介绍了微信支付混沌工程的实施思路。它采用多分区架构控制最小爆炸半径，探索高价值的基础组件和微信支付核心业务场景，并基于高可用原理和历史故障分析推导出的综合混沌工程构建实践。
断层原子的发展。 01. 为什么需要混沌工程 1.1 目标起点 微信支付是国家关键信息基础设施，服务于数千万商户和数亿用户，可用性要求高于5个9。
1.2 分析：影响可用性的主要因素及对策为了分析影响可用性的因素，我们对微信支付近年来的故障审核数据进行了分类，发现软硬件异常引起的故障占比较高（基础设施和组件）下图中，上游和下游部分）。微信支付针对功能/程序缺陷等各种导致失败的因素采取了相应的措施：单元测试、集成测试、UAT测试、流量回放；容量不足：归一化压力测试，自动弹性伸缩；人为破坏（人为损坏）（原因）：进入IDC登录、变更审核、权限控制、模块认证；但对于软硬件故障，虽然基础组件会涉及一些容错处理，但设计是否全面、开发是否充分实现、真实场景是否有效，都没有统一的工具。
和验收标准，并推动解决。如何验证系统具备应对软硬件异常的容灾能力？我们调查了企业和行业使用的方法，其中演练和混沌工程是最常见和最有效的。
它们都强调在线实施，旨在提高系统的可靠性和灵活性，但方法和侧重点不同（两者概念和想法的差异对实际实施影响较大）。 1.2.1 练习 练习通常有明确的执行计划和期望，要求注入故障的影响已知且明确。
更加注重人的反应和应急预案，也考虑非系统因素。例如，验证某个系统出现故障后，人为干预的过程和机制是否顺畅。
1.2.2 混沌工程（公司和业界对混沌工程概念有很多介绍，不懂的可以先自行搜索，不再赘述。）混沌工程比较偏重注重发现未知风险，更注重系统的灵活性。
，不涉及系统外因素。其中，Netflix提出的混沌工程五项原则是业界的普遍共识：建立稳定状态假设；用各种现实世界的事件来验证它；在生产环境中进行实验；自动化实验以继续运行；控制并最小化爆炸半径。
多种多样的项目和控制爆炸半径的方法与演习有很大不同。正是通过控制爆炸半径，混沌工程中注入故障的强度和复杂性远高于演练能力，可以更全面、更真实地模拟现网故障，达到“发现未知风险”的目的。
此前，演练是微信支付容灾验证的重要手段。我们发现，由于演练没有系统的爆炸半径控制方法，演练在工具开发、监测和稳态识别、事件多样性、自动化等方面需要做更多的工作。
定制开发和人工实时观察需要更多的工作。劳动力投资成本高。
因此，引入混沌工程系统来有效控制爆炸半径，更大程度地注入异常，并适当构建自动化能力来识别系统弱点并促进持续治理以提高可用性是一个值得探索的方向。 1.3 实现的可行性混沌工程存在两大矛盾：故障有效，注入的故障与实际故障环境接近；业务安全，注入的故障对现有网络业务无影响或影响较小。
为了贴近真实环境，注入故障越贴近真实环境就越有效，但这必然会影响业务可用性。而且，微信支付对可用性要求很高，不接受不可预测的风险。
如果业务安全问题不解决，引入混沌工程“探索未知风险”的期望将难以实现。 2019年，微信商业支付进行了多分区改造，将业务流量引导至不同分区。
各分区之间相互独立，互不影响。通过DevOps部署保证分区之间的环境一致性。
将故障注入分区隔离的IDC环境并分配可控流量，既可以贴近生产环境，又可以保证故障收敛，控制爆炸半径。这样，微信商户支付就具备了实施Chaos Project的条件和可行性。
02.如何实施。从业界实施混沌工程的经验来看，基本都是围绕Netflix提出的五项原则展开的。
建立稳定状态的假设，即从用户的角度衡量业务的健康度。一般情况下，企业都有现成的业务监控，大多数情况下不需要额外开发。
使用各种现实世界事件进行验证将丰富注入故障的类型，并且自动化实验持续运行将减少人工参与的成本。两者都需要额外的开发，但先开发哪些、能在多大程度上与业务目标结合，更重要的是开发人力成本与可挖掘的风险和收益之间的ROI考虑。
在生产环境中进行实验和控制爆炸半径最小化是混沌工程有效性和安全性的两个关键问题。因此，实施混沌工程的主要难点是：安全有效的实验；高效、全面的风险探索。
2.1 安全有效的实验。不同技术选型对应的有效性和安全性如下： 最小爆炸半径选择有效性和安全性（资源、数据隔离） 结论1、测试环境不足，距离生产环境较远。
完全隔离不利于安全。 2. 共享线上环境，特定流量注入有限，无法模拟共享基础设施故障隔离，负载抢占不足和脏数据写入风险 3. 共享线上环境，金丝雀机器扩容，特定路由有限，无法注入组件类不足的风险故障隔离和脏数据写入与4类似，但不是整个链路。
4、独立部署在线无状态服务，在线共享组件和存储有限，无法注入组件类。故障隔离不充分，脏数据写入风险不合适 5、线上环境独立部署，包括组件和存储，有效、安全、合适。
成本高而且本质上是一样的。 66. 多分区架构上的独立混沌分区是有效的、安全的、适用的。
需要解决外部依赖传递。一般来说，有效性和安全性很难同时满足两者，需要在两者之间进行权衡。
越是想要真实的恢复故障，就需要在真实环境下用业务流量来模拟故障，这会影响业务安全；但如果一味追求安全，就无法对业务产生良好的影响。如果出现任务影响，就无法还原发生故障的真实场景，也很难发现问题。
可以结合实验目标，确定业务可以接受的最低安全性，然后选择最有效的解决方案。 2.1.1 安全性：方案选择不影响线上业务控制爆炸半径。
爆炸半径还可以在混沌工程实施的不同阶段进行调整。您对系统的可用性越有信心，它就越接近真实环境。
因此，前期可以在效率较低的环境中进行实验。当通过实验方法很难发现新的问题，并且发现的问题已经得到解决时，就可以考虑升级为有效。
更高的方案。对于微信商业支付，如上所述，我们在2018年进行了多分区改造。
因此，我们在多分区架构的基础上，单独规划了分区路由和4个业务分区。部署的业务逻辑模块、存储、组件等都与生产分区完全一致。
前期将模拟流量放入混沌分区，然后注入故障。当对系统有足够的信心时，稍后会将故障注入到生产分区中。
由于多分区只是改造了核心业务，还存在外部依赖服务。为了防止混沌实验对外部依赖的影响，对不同场景下的风险源进行了相应的处理： 区外风险源分析和响应计划分区路由分割分区外部依赖读取和接受，控制流量写入：用户数据（累计金额、账单、支付凭证、风控报告）体验流量使用特定用户池->特定标签，丢弃并写入：商户数据（累计金额、频次限制、风控报告）体验流量使用特定商户pool -> 特定标签，丢弃并写入：业务数据以特定标签上报，丢弃并写入：监控上报增加分区维度，系统识别后区分调用其他部门的下游依赖和外部依赖分区类似商户系统（通知回调）特定标记，丢弃特殊限制和批准。
考虑“数据篡改”类型的故障，可能会导致写入脏数据，尤其是篡改业务执行主体（如商户ID、用户ID），写入脏的真实业务数据的风险。因此，“篡改执行主体”的错误是被禁止的。
考虑到所执行实验的风险，我们增加了对这些场景的批准：“修改”类型的失败加上批准。为了避免脏写异常影响真实环境，leader会进行二次评估并确认。
非资源所有者执行审批。比如在别人的模块上进行实验（常见的是模块共置、在母机上进行实验标定），以避免无法检测到其他业务异常。
批准非工作时间的实验。避免实验异常和长时间的干预。
2.1.2 有效：接近真实环境。我们主要在孤立的混沌分区中进行实验。
实验环境与真实环境的一致性越高，真实环境中出现类似问题的概率就越大。静态：部署环境的一致性。
部署环境的一致性主要维度如下： 维度一致性要求。响应解决方案。
地势高。部署在同一位置。
校园内多校区部署。随机选择校园机器。
实验机房/交换机/机架。低的。
对于上层来说相对不透明。而且可测试空间小（爆炸半径太大）。
项目并不要求模型中涉及此类差异的故障较少，网上基本一致。该项目不需要高度一致的容器版本以及操作系统中一致的容器规格。
二进制（代码）统一部署极高，配置完全一致极高。我们在DevOps部署工具中实现了上述对区域、园区、容器、二进制文件和配置的高一致性要求，以便在线模块和变更发布时必须与生产环境保持一致。
持续的。动态：实验流量的保真度。
实验流量接近线上流量的目的是为了恢复机器/容器的负载情况，恢复业务执行的分支。在一些复杂的组合场景下，两者是否会引发未知的风险。
我们从两个维度来评价流量模拟程度：对流量指标的基础要求较高，需要场景覆盖、核心链路覆盖所有线上依赖的服务接口、请求并发量、平均或峰值TPS1。接近各种线上场景的流量占比2。
基于这两个指标，有两个不同的方向： 流量类型构建方式 优点 人工流量 基于业务用例和规则，开发执行脚本 1. 开发简单 2. 流量可控性强 流量回放 素材在线录制、替换、重构数据、模拟边界调用、模拟随机数、时间等系统调用等。 1、流量和线上的一致性和丰富性强 2、后期新场景投入成本低。
考虑前期建设 由于成本和不确定性，我们选择了人工流方案。 2.2 高效全面的风险探索在构建混沌工程体系以及从0到1的业务落地时，我们遇到了两类问题：工具业务零基础，应该优先考虑哪些故障原子？我们应该先构建有缺陷的原子还是先提高实验效率？如何首先识别高风险？如何找出所有风险？是否有可能用很少的投资或没有投资来完成混沌实验？我们选择从业务目标出发，优先考虑高价值的风险点，通过与业务目标相匹配的工具逐步丰富故障原子。
根据不同阶段的侧重点，项目实施路径分为两个阶段： 2.2.1 探索高价值风险 前期如何在有限的人力和工具条件下探索高价值风险（高ROI）？更简单的方法是：随机注入。工具团队可以根据近年来的故障类型，按照优先级开发相应的故障原子，无差别地注入到目标模块中。
当当前阶段自动进样和稳态分析还不完善时，仍然需要人工参与。这种方法有两个局限性：业务团队的实施需要大量的人力投入：人工注入故障、人工观察分析业务监控、监控偏差。
是否影响业务、是否分散风险、是否存在其他潜在风险；工具团队无法有的放矢，无法投入有效的人力进行最有价值的原子开发。为了快速发现高价值风险，从而提高大家的参与热情，我们选择了以下两种策略：将实验对象从高价值覆盖到低价值。
基于这一思路，得出了优先实施的模块。 1）公共组件：RPC框架、队列、存储、缓存、安全认证、日志等； 2）生命线业务：缴费、退款。
基于高可用的原则，我们可以对工具进行拆解，获取需要开发的原子需求和需要注入的资源。设计路径如上图所示。
基于历史故障和常见的高可用需求原则，假设某个组件??/业务满足高可用原则，根据这个原则，将其拆解为故障原子和需要注入的注入范围（目标），而某个业务或组件要实现的混沌实验方案如下图：通过这些策略，我们很快发现了微信基础组件中HTTP访问模块、事件中心、跨城等多个高危共性问题成分。 2.2.2 风险识别后期，如何增强覆盖范围，发现更多未知的黑天鹅风险？上述方法只能覆盖有限的故障域，实际故障往往是由多个事件同时发生触发的。
因此，通过后期加强单原子乱注入和组合断层注入，可以发现更多的中长尾问题。对于组合故障，如果也是无差别策略，那么组合空间巨大。
以微信支付委托代扣业务为例：单次故障注入：18个模块*15个故障原子= ，即单个原子无差别注入次数； 2个组合空间为C=5，任意组合空间为 。即使该工具具有自动注入和自动分析的能力，实验周期和资源消耗也会非常高。
因此，合理修剪是必要的。可以采用基于相关性从强到弱的多种故障组合，如：模块内的依赖效应（包括三园区容灾设计）；业务内模块之间的依赖效应；企业之间的依赖效应；基础设施之间的依赖效应；潜在的依赖效应。
2.2.3 自动化 从实验流程来看，除了“修复问题”之外，其他三个流程都可以在一定程度上实现自动化。自动设计一个实验任务由4部分组成：业务资产：集群、模块、接口；集群是多个模块的总称，例如存储集群包括访问模块、存储模块、元数据模块；系统资源：业务资产执行所依赖的机器、容器、网络、CPU、磁盘、进程、文件、内存、共享内存等；故障类型：每个系统资源都有多种故障，如机器重启、机器时间错误等，如网络包括缓慢、丢包、紊乱等故障程度：除少数0-1类故障外比如机器重启，其他故障大多涉及一定程度的故障，比如网络丢包30%。
不同级别的性能略有不同。一般来说，故障程度分为几个级别。
如果单机丢包为10%、30%、50%、80%、%，则结合多机情况。做一个实验，先圈出包含的业务资产，然后梳理其所依赖的系统资源（除了磁盘、文件、共享内存，其他的一般都包含），然后展开系统资源的故障类型，最后确定失败的程度。
策略有两种：标记资产类型，例如标记为某种类型的存储集群，应用设计好的实验模板库生成实验任务；标记适用于业务的高可用原则，如单机/园区消除能力、异常防御、分区切换、旁路冗余设计等，切掉全面扩展的无效值。例如，单机淘汰原则只能容忍下游单机或园区单机故障，因此不会产生多机故障，而旁路冗余设计的业务可以容忍旁路模块中的所有机器故障，因此几乎不需要产生单机故障。
因此，业务需要做的是：划定资产范围和依赖的系统资源，并标记资产类型或适用哪些高可用性原则，然后就可以自动生成实验任务。自动执行系统的建设并非一蹴而就。
从手动执行到自动化，我们经历了三个阶段：手动执行单个故障，主要解决0-1问题，主要关注故障原子的构建；单批执行多个故障，采用yaml文件记录排列方式，支持串行和并行调度。应用于业务先行实验和定位问题。
定时执行/事件触发执行主要用于变更回归和可用性检查场景。因为定时执行还依赖于后续的“自动分析”，所以放在最后。
自动分析上述自动执行减少了“点击”操作的工作量。实验必须“完全”自动化，并与自动分析相结合，即自动判断是否偏离稳态。
一是当稳态偏离正常范围时及时停止，避免发生次生灾害；其次，只有实现自动分析，才能实现低成本的“定时执行”。否则，每次自动执行后都需要依赖人工分析，这是不可持续的。
我们根据实验的时间（实验开始时间到实验结束的一段时间）自动匹配相关的稳态警报： 业务：业务用例维度监控是否触发警报。强优先级，触发后停止实验。
模块：上下游调用关系是否发生告警。中优先级，触发后实验不会停止，并显示在实验报告中。
IP/容器：机器和容器是否有资源异常告警。中优先级，触发后实验不会停止，并显示在实验报告中。
业务自定义监控。上述无法自动覆盖的监控将在业务配置后自动采集。
2.2.4 风险处理：除了处理负责人发现的风险外，方法还有：个别问题：知名组件和业务负责人处理共性问题，通过SOA治理、架构大规模消除建模和改进研发流程以实现组织目标。价值最大化。
针对不同时期出现的问题，采取不同的策略： 已有：采用SOA治理平台促修复（SOA治理是微信支付风险和异常项管理平台，提供统一的异常接入、展示、通知、关注指标数据在部门内部形成统一的风险管理共识，混沌工程将发现的风险接入SOA治理平台，快速管理大规模的共性风险。新增：新增通过MR管道访问控制和变更访问控制进行阻塞，必须经过处理后才能通过。
03.结果我们通过设计实验（构建原子）——执行实验——分析结果（挖掘问题）——修复问题的一套流程进行推进，在业务风险挖掘和工具构建方面取得了良好的效果。 3.1 业务成果 自2016年上线以来，线上失败0次，执行了60+个实验计划，+个实验任务，覆盖业务、框架、组件多个场景，探索多重风险。
3.2 工具建设成果微信支付构建了从0到1的混沌工程体系（由业务连续性架构中心和支付运维团队共建）。它已支持30多种故障原子。
典型原子：页面支持拖拽排列、串并排列，可配置定时启动实验，实现规范化验证风险。通过关联微信支付模块调用异常告警和业务监控告警，可以识别被测模块/IP中潜在的异常情况，并在实验报告中展示，提高实验后分析的效率。
04.总结与展望 4.1 总结 本文从业务角度介绍了混沌工程在微信支付实践中的实施思路。它采用多分区架构来控制最小爆炸半径。
首先探索高价值的基础组件和微信支付核心业务场景，并基于高可用原理和历史故障分析导出故障原子的发展。发现不少共性风险，推动修复治理。
4.2 展望 4.2.1 更丰富的断层原子构造的有效性和安全性始终是一个权衡因素。如上所述，微信支付采用独立的混沌分区架构实现，前期采用模拟流量。
因此，除了篡改数据、原子之外，在控制请求量的情况下，注入故障的爆炸半径很小，对线路的影响极低。但由于对业务安全的思维惯性，我们在构建故障原子时，基本遵循的是练习的思路：先了解组件原理，将原子逐一定制组件/业务，从而得到一个提前交付周期长。
如果在控制爆炸半径的基础上，开放更多的断层注入自由度，注入更多强度更大的断层，就能以较低的成本发现更有价值的风险。 4.2.2 自动化和稳态识别自动化包括：故障注入和异常判定。
当前系统支持故障注入的自动化和简单的稳态识别。识别的准确性和召回率还有空间，因此大多数异常判定仍然需要人工分析。
自动异常判断需要相对先进的AI能力，并且很难根据某些特定规则覆盖所有场景。如果能够实现全面自动化，混沌工程就可以低成本地在其他业务中实施。
此外，还可以注入大量组合断层，探索更多未知风险。 4.2.3 支持多种爆炸半径的实验本文在多个分区上部署独立的混沌分区来控制爆炸半径。
对于大多数非核心支付或非支付业务来说，不存在多分区环境。因此，在其他业务中实施混沌工程，还是需要根据业务的安全性和有效性来做出选择。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-06
06-18
06-17
06-17
06-17
06-06
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用