蚂蚁集团于2016年开始建设混沌工程体系，经历近6年的发展，目前以红蓝攻防为主要形式的混沌工程已有相当大的规模，从技术、机制、文化等层面驱动蚂蚁集团风险防控水位不断提升。
本文主要介绍蚂蚁集团的混沌工程体系，包括蚂蚁混沌工程的发展历程、业务特色、关键技术和平台以及未来规划(本文仅仅转载发展历程和业务特色两部分)。
发展历程
蚂蚁的混沌工程技术依托于红蓝攻防模式进行全面落地，红军（研发&质量&SRE）构建稳定的系统，技术蓝军持续注入风险异常，相互对抗和提升。蚂蚁混沌工程的发展分为三个阶段，我们称为三个代际的混沌工程。
第一代，时间为2016至2018年，重点是故障注入体系建设。
第一代混沌工程主要围绕着故障注入展开，当时蚂蚁的技术故障缺乏完整的体系进行防控，更多是各个业务系统根据自身重要性进行相关投入，风险防控的水位参差不齐，因此技术蓝军以减少故障为主要目标，开始进行故障注入的演练工作，当时主要针对运行中的应用系统，内容包括系统可用性和资金安全两个方面，建设了故障注入相关的技术和平台，组织了几次攻防演练活动，尤其在资金安全核对、变更风险识别方面起到了很好的牵引效果。
第二代，时间为2018年至2020年，重点是混沌工程边界拓展。
混沌工程领域边界的拓展主要体现在两个方面。第一，混沌工程不局限在故障注入，故障背后的本质是对技术风险的认知，我们提出风险挖掘的命题，包括资金风险的挖掘，变更影响面的挖掘等；第二，混沌工程开始面向软件完整生命周期，不再仅仅针对系统运行阶段进行故障注入，在开发，测试，发布，运行，数据处理等软件生命周期的各个阶段，我们都探索并落地了相应的故障注入能力，例如源码注入，测试用例注入，发布变更注入，在离线数据同步和计算注入，等等。同时，大型攻防演练活动已逐渐形成内部品牌，分别是面向高可用领域的527和面向资金安全领域的1218(分别表示5月27日和12月18日，蚂蚁历史上在这两天发生过两次必须铭记的重大故障，不忘教训而取此名)，通过技术运营等方式，开始在蚂蚁技术工程师中建立混沌工程的心智，宣导风险防控意识和文化，稳定优先的理念深入蚂蚁每一个技术人员的内心。
第三代，时间为2020年至今，重点是混沌工程角色的转变升级，由“验证”升级为“牵引和驱动”。
技术风险体系建设已经非常完善，连续多年全站故障数下降比例超出目标。在这种背景下，如何保鲜现存的技术风险防控能力，如何驱动建设更丰富的防控手段，成为主要命题。混沌工程在这个阶段的角色发生了重大变化，相比之前，我们大大增加了日常攻防演练的频率和数量(2021年故障注入次数在亿次级别，频率为以天粒度进行持续回归)，结合风险挖掘，仿真环境，自动化度量等技术，将攻防演练做到常态化持续运行，不断发现防控问题，揭示防控水位，牵引防控能力保鲜，驱动防控能力建设。在技术层面，统一攻防切面Awatch技术，仿真运行环境，混沌靶场，污点分析等硬核技术逐渐沉淀出来，后文也会针对性介绍。
同时，我们认为智能化和产品化会是下一代混沌工程的核心主题，通过智能化的方式提升混沌工程效率，逐渐达到专家经验的风险分析水平，并将智能化能力融入到产品中，快速帮助一个新业务建立起混沌工程技术体系，我们也会逐渐通过开源、产品等方式将这套技术对外部开放。
业务特色
蚂蚁集团的业务对稳定性和资金安全的要求非常高，因此除了通用的混沌工程技术建设外，还更加有自己的业务特色，主要体现在以下5个方面(本文只列出前3个)：
1、面向业务的故障注入
目前业界的混沌工程实践，主要是故障注入的方向，而在该方向中，做的最多的是较为通用的系统可用性和稳定性的故障注入，例如制造应用服务器集群内某些机器宕机，制造服务调用链路中某些节点服务访问超时，等等，无论是使用自研的技术和平台，还是使用开源的技术然后自建平台，在混沌工程的实施层面，基本都是这方面的内容。
蚂蚁的混沌工程也包含上面部分的内容，除此之外，蚂蚁的混沌工程实践更加面向业务。面向业务的故障注入的提出有其背景，由于蚂蚁的业务大多具有金融属性，对业务正确性的要求极高，对资金相关故障是零容忍的，根据内部数据分析，蚂蚁的生产故障跟资金相关的，多数为业务内部逻辑错误导致，某些逻辑错误在测试阶段难以发现，发生的条件及其复杂，因此对该类型故障的设计，就必须紧贴业务进行。
面向业务的故障注入，基于蚂蚁自研的统一JAVA字节码框架Awatch(该技术在下文会有介绍)，在技术上能够做到代码级的替换注入，即用故障注入设计的代码片段，在系统运行过程中，动态替换掉业务原本运行的代码片段，从而达到非常灵活的业务逻辑层面的错误。
代码级的故障注入能够做到，以上逻辑中的发送消息和执行内部逻辑的顺序颠倒，即模拟在业务还未完成的情况下就发送了业务完成的消息，试验在这种场景下业务会有何种表现。
2、风险挖掘
除了故障注入之外，蚂蚁还在风险挖掘领域进行了很多实践工作，是对混沌工程的一种拓展。
风险挖掘，主要是指各个技术风险领域的风险点挖掘，例如资金领域的资金表和资金服务的识别等，识别出的风险点，是攻击环节中场景设计的主要来源，也是攻防演练在日常进行持续运营的重要驱动力。风险挖掘工作中的主要组成部分包括源数据的采集，基于风险模型的分析等，目前蚂蚁能够做到在生产环境中持续进行数据采集，结合实时和离线分析，使识别出的风险点具备保鲜的能力。
以资金领域为例，蚂蚁技术蓝军基于Awatch(该框架在前文的故障注入中有提到)，对生产环境的应用系统进行数据层访问的请求采集，然后结合资金业务领域的模型以及专家经验，识别出具有资金属性的表和字段，例如金额，币种，费率，状态等，我们认为这些字段是有潜在资金风险的，即这类字段出现数据错误后极有可能导致资损故障，因此需要由资金核对规则对其进行检查，以及通过演练对核对规则是否有效进行验证。
3、面向软件生命周期的混沌工程
目前业界的混沌工程实践，大多是面向软件运行时的，即针对已发布上线并运行(开发测试环境中运行也可认为是运行时)的系统，制造故障。
蚂蚁的混沌工程面向软件完整的生命周期，即“开发-测试-发布-运行-数据处理”的全过程。
开发阶段，进行源代码级别的故障注入，在源代码中增加注入代码，目的是检验code review是否做的足够充分和细致。
测试阶段，进行测试用例级别的故障注入，检验测试用例是否有效，是否符合标准的测试用例规范，例如是否有断言(不写断言，测试用例总会通过，有风险)。
发布阶段，发布本质上是一种变更行为，在这个阶段进行的是针对变更的故障注入，蚂蚁技术风险建设有统一变更核心，通过各种变更防御规则对有风险的变更进行拦截，变更故障注入模拟不符合规则的变更。
运行阶段，包括系统稳定性和可用性的故障注入，面向业务的故障注入，以及风险挖掘等，这部分也是业界的主要实践领域。
数据处理阶段，在线运行的系统，产生的数据会周期性同步至离线，离线进行加工处理之后的数据，又会被一些在线系统使用，在这个过程中也会进行故障注入，例如在离线数据同步发生延迟，数据计算过程中出现数据错误和丢失等等。
网友评论