混沌初开，方兴未艾。混沌工程的概念由Netflix在2014年提出，近些年阿里，华为，腾讯，百度，工商银行等国内企业都有该领域的实践。
蚂蚁集团于2016年开始建设混沌工程体系，经历近6年的发展，目前以红蓝攻防为主要形式的混沌工程已有相当大的规模，从技术、机制、文化等层面驱动蚂蚁集团风险防控水位不断提升。
本文主要介绍蚂蚁集团的混沌工程体系，包括蚂蚁混沌工程的发展历程、业务特色、关键技术和平台以及未来规划。
一、发展历程
蚂蚁的混沌工程技术依托于红蓝攻防模式进行全面落地，红军（研发&质量&SRE）构建稳定的系统，技术蓝军持续注入风险异常，相互对抗和提升。蚂蚁混沌工程的发展分为三个阶段，我们称为三个代际的混沌工程。
第一代，时间为2016至2018年，重点是故障注入体系建设。
第一代混沌工程主要围绕着故障注入展开，当时蚂蚁的技术故障缺乏完整的体系进行防控，更多是各个业务系统根据自身重要性进行相关投入，风险防控的水位参差不齐，因此技术蓝军以减少故障为主要目标，开始进行故障注入的演练工作，当时主要针对运行中的应用系统，内容包括系统可用性和资金安全两个方面，建设了故障注入相关的技术和平台，组织了几次攻防演练活动，尤其在资金安全核对、变更风险识别方面起到了很好的牵引效果。
第二代，时间为2018年至2020年，重点是混沌工程边界拓展。
混沌工程领域边界的拓展主要体现在两个方面。第一，混沌工程不局限在故障注入，故障背后的本质是对技术风险的认知，我们提出风险挖掘的命题，包括资金风险的挖掘，变更影响面的挖掘等；第二，混沌工程开始面向软件完整生命周期，不再仅仅针对系统运行阶段进行故障注入，在开发，测试，发布，运行，数据处理等软件生命周期的各个阶段，我们都探索并落地了相应的故障注入能力，例如源码注入，测试用例注入，发布变更注入，在离线数据同步和计算注入，等等。同时，大型攻防演练活动已逐渐形成内部品牌，分别是面向高可用领域的527和面向资金安全领域的1218(分别表示5月27日和12月18日，蚂蚁历史上在这两天发生过两次必须铭记的重大故障，不忘教训而取此名)，通过技术运营等方式，开始在蚂蚁技术工程师中建立混沌工程的心智，宣导风险防控意识和文化，稳定优先的理念深入蚂蚁每一个技术人员的内心。
第三代，时间为2020年至今，重点是混沌工程角色的转变升级，由“验证”升级为“牵引和驱动”。
技术风险体系建设已经非常完善，连续多年全站故障数下降比例超出目标。在这种背景下，如何保鲜现存的技术风险防控能力，如何驱动建设更丰富的防控手段，成为主要命题。混沌工程在这个阶段的角色发生了重大变化，相比之前，我们大大增加了日常攻防演练的频率和数量(2021年故障注入次数在亿次级别，频率为以天粒度进行持续回归)，结合风险挖掘，仿真环境，自动化度量等技术，将攻防演练做到常态化持续运行，不断发现防控问题，揭示防控水位，牵引防控能力保鲜，驱动防控能力建设。在技术层面，统一攻防切面Awatch技术，仿真运行环境，混沌靶场，污点分析等硬核技术逐渐沉淀出来，后文也会针对性介绍。
（第三代混沌工程在技术风险中的角色）
同时，我们认为智能化和产品化会是下一代混沌工程的核心主题，通过智能化的方式提升混沌工程效率，逐渐达到专家经验的风险分析水平，并将智能化能力融入到产品中，快速帮助一个新业务建立起混沌工程技术体系，我们也会逐渐通过开源、产品等方式将这套技术对外部开放。
（蚂蚁混沌工程总览大图）
二、业务特色
蚂蚁集团的业务对稳定性和资金安全的要求非常高，因此除了通用的混沌工程技术建设外，还更加有自己的业务特色，主要体现在以下5个方面：
1、面向业务的故障注入
目前业界的混沌工程实践，主要是故障注入的方向，而在该方向中，做的最多的是较为通用的系统可用性和稳定性的故障注入，例如制造应用服务器集群内某些机器宕机，制造服务调用链路中某些节点服务访问超时，等等，无论是使用自研的技术和平台，还是使用开源的技术然后自建平台，在混沌工程的实施层面，基本都是这方面的内容。
蚂蚁的混沌工程也包含上面部分的内容，除此之外，蚂蚁的混沌工程实践更加面向业务。面向业务的故障注入的提出有其背景，由于蚂蚁的业务大多具有金融属性，对业务正确性的要求极高，对资金相关故障是零容忍的，根据内部数据分析，蚂蚁的生产故障跟资金相关的，多数为业务内部逻辑错误导致，某些逻辑错误在测试阶段难以发现，发生的条件及其复杂，因此对该类型故障的设计，就必须紧贴业务进行。
面向业务的故障注入，基于蚂蚁自研的统一JAVA字节码框架Awatch(该技术在下文会有介绍)，在技术上能够做到代码级的替换注入，即用故障注入设计的代码片段，在系统运行过程中，动态替换掉业务原本运行的代码片段，从而达到非常灵活的业务逻辑层面的错误。举例来说，业务原本的代码逻辑如下：
public void doBiz(){ // 执行系统内业务逻辑 doInternalBiz(); // 发送业务完成的消息 sendBizFinishMsg(); }
代码级的故障注入能够做到，以上逻辑中的发送消息和执行内部逻辑的顺序颠倒，即模拟在业务还未完成的情况下就发送了业务完成的消息，试验在这种场景下业务会有何种表现，即故障注入后的代码逻辑变为：
public void doBiz(){ // 发送业务完成的消息 sendBizFinishMsg(); // 执行系统内业务逻辑 doInternalBiz(); }
代码化注入非常灵活，以上场景还可以设计为，业务内部逻辑完成后，不发送业务完成的消息，即：
public void doBiz(){ // 执行系统内业务逻辑 doInternalBiz(); // 发送业务完成的消息 // sendBizFinishMsg(); }
可以看到，代码化的故障注入，已完全不局限于服务调用延时，机器宕机等基础故障的制造，而是能够制造个性化十足的具有强烈业务语义的故障，这也是当前蚂蚁技术攻防演练中的主流故障注入模式。
2、风险挖掘
除了故障注入之外，蚂蚁还在风险挖掘领域进行了很多实践工作，是对混沌工程的一种拓展。
风险挖掘，主要是指各个技术风险领域的风险点挖掘，例如资金领域的资金表和资金服务的识别等，识别出的风险点，是攻击环节中场景设计的主要来源，也是攻防演练在日常进行持续运营的重要驱动力。风险挖掘工作中的主要组成部分包括源数据的采集，基于风险模型的分析等，目前蚂蚁能够做到在生产环境中持续进行数据采集，结合实时和离线分析，使识别出的风险点具备保鲜的能力。
以资金领域为例，蚂蚁技术蓝军基于Awatch(该框架在前文的故障注入中有提到)，对生产环境的应用系统进行数据层访问的请求采集，然后结合资金业务领域的模型以及专家经验，识别出具有资金属性的表和字段，例如金额，币种，费率，状态等，我们认为这些字段是有潜在资金风险的，即这类字段出现数据错误后极有可能导致资损故障，因此需要由资金核对规则对其进行检查，以及通过演练对核对规则是否有效进行验证。
举例来说，业务访问数据库的SQL语句是：
insert into pay_order(id, gmt_create, user_id, pay_amount, status) values(1, 2021-12-20 10:00:0
采集技术会实时拦截待执行的SQL语句，进行SQL解析，得到字段及其对应的值，再根据字段的命名和值的类型，筛选出具有资金属性的字段。例如解析到pay_amount字段，其命名中带有amount关键字，并且值为数值类型，由于蚂蚁的应用开发遵循标准的命名和类型规范，金额字段通常都带有amount或amt关键字，值是double类型，所以这类字段就可以准确识别出来。
另外，还可以分析出风险字段的取值范围，流量分布等，这些信息对攻击场景的设计都有很大帮助。
同时，结合污点分析技术，还可以将表字段与上层服务的参数进行准确关联，即识别出资金服务及其关键资金参数，污点分析技术会在下文讲述。
除了资金领域之外，在变更领域，也有变更影响面的风险挖掘。分布式系统中常用动态配置技术进行配置的动态管理，蚂蚁也有自研的一套分布式动态配置管理和推送系统，配置推送属于一种变更行为，通过风险挖掘，可以识别出一次配置推送，影响到哪些业务服务，影响到哪些资金表，等等。
3、面向软件生命周期的混沌工程
目前业界的混沌工程实践，大多是面向软件运行时的，即针对已发布上线并运行(开发测试环境中运行也可认为是运行时)的系统，制造故障。
蚂蚁的混沌工程面向软件完整的生命周期，即“开发-测试-发布-运行-数据处理”的全过程。
- 开发阶段，进行源代码级别的故障注入，在源代码中增加注入代码，目的是检验code review是否做的足够充分和细致。
- 测试阶段，进行测试用例级别的故障注入，检验测试用例是否有效，是否符合标准的测试用例规范，例如是否有断言(不写断言，测试用例总会通过，有风险)。
- 发布阶段，发布本质上是一种变更行为，在这个阶段进行的是针对变更的故障注入，蚂蚁技术风险建设有统一变更核心，通过各种变更防御规则对有风险的变更进行拦截，变更故障注入模拟不符合规则的变更，例如模拟一个发生在中午12点的变更(12点属于午餐时间段，业务高峰期，本来不允许变更)，检验相应的变更防御规则是否能够拦截该变更；或者模拟变更导致的系统故障，检验变更核心是否能够发现该故障并关联到正确的变更，并将该变更回滚；另外，变更影响面(变更影响的服务，变更影响的资金表等)也是风险挖掘的主要方向之一。
- 运行阶段，包括系统稳定性和可用性的故障注入，面向业务的故障注入，以及风险挖掘等，这部分也是业界的主要实践领域。
- 数据处理阶段，在线运行的系统，产生的数据会周期性同步至离线，离线进行加工处理之后的数据，又会被一些在线系统使用，在这个过程中也会进行故障注入，例如在离线数据同步发生延迟，数据计算过程中出现数据错误和丢失，等等。
蚂蚁的混沌工程面向软件完整的生命周期，通过混沌工程来检验每个阶段的防控是否到位，全方位保障软件系统的可用性，稳定性，以及业务逻辑的正确性
4、超大规模的混沌工程体系
蚂蚁的混沌工程体系规模极大，主要体现在以下几方面：
- 参与混沌工程的团队和人数多，几乎涵盖所有蚂蚁业务及其技术团队，直接参与混沌工程的工程师人数有近千人
- 混沌工程覆盖的应用系统多，覆盖数千个应用系统
- 通过混沌工程发现的问题多，包括系统问题，业务问题，配置问题等，2021年全年发现问题500+
- 混沌工程中的攻防演练执行的次数多，2021年全年各领域的攻防演练次数合计达到上亿级别，大部分演练以天为粒度进行持续回归
5、根基守护
数据完整是容灾的前置条件，一旦关键业务数据遭到破坏对业务影响将会是灾难性的。据不完全统计，近年来国内外互联网公司发生的或大或小的数据丢失事件(即我们常说的“删库跑路”)多达十几起，产生的破坏性影响让人震惊。针对这些根基数据，存在有相当多的操作敞口，可能由于无意或恶意操作造成的数据破坏而带来灾难性影响，更严重者几乎可导致不可逆转的毁灭性影响。我们把可能对这些根基数据产生破坏性影响的变更功能或操作路径定义为核按钮。结合行业内发生过的数据破坏事件可以发现，大部分有影响力的数据丢失事件都是因为内部员工或者已离职员工因为误操作或者恶意为之而引发，并且被破坏数据往往很难在短时间内恢复甚至彻底丢失，造成了严重的业务声誉影响及资金损失。为此我们建立了一套核按钮保护保护机制, 来进行根基守护。
核按钮保护具有以下几个基本原则：
事前：三权分立，最小化授权
- 三权分立原则: 在全公司范围内针对所有涉及生产变更的系统去特权化，杜绝单一账户或用户具备可一杆到底的权限。实现审批权限，操作权限，审计权限相互隔离。即不允许单一账户具备所有权限，或单用户被授权所有角色权限；
- 最小化授权原则: 针对所有技术权限的申请及授权，必须遵循最小够用原则，按照岗位职责需要，申请最小够用的权限，做到权职相符。
事中：可审计，可预警，可熔断
- 光有权限的控制只能降低核按钮事件发生的概率，从控制论角度我们的防护系统还需要形成一套可识别(自我学习), 可反馈, 可动态干预的闭环系统；因此需要针对生产环境的一切黑屏或白屏的操作具有实时或准实时的风控审计能力，具有识别针对根基对象的恶意尝试行为（如恶意破坏，制造重大故障)，以及识别针对根基对象不符合数据安全要求的操作行为，能够进行及时的预警及具备事中熔断操作的能力。
事后：可反悔，可快恢, 可攻防检验
- 可反悔，可快恢：假设事前的最小化授权，事中的熔断措施等都被突破，最终依然造成了核心数据被恶意删除、损毁事件发生，我们依然需要有底线级别的应急手段，确保相关的操作能够可反悔或者这些受影响的数据可以在短时间内快速恢复；这就需要更进一步，在我们的核心数据系统内核层面及机器操作系统内核级别建立底线级别的数据回收站快速回收恢复能力。
- 可攻防检验：相关变更功能需要预留可攻防检验的切面，具备可灰度攻防检验的能力。
目前，蚂蚁的根基守护已具备如下核按钮的保护能力：
- 数据库核按钮保护
- 规模运维核按钮保护
- 研发核按钮保护
（根基守护整体业务框架）
总而言之，蚂蚁的混沌工程实践在业务上有着自身显著特色，在技术方面，蚂蚁在混沌工程多年的实践中，也有很多积累，下面介绍部分关键技术以及平台。
三、关键技术和平台
1、统一切面技术组件Awatch
前文在介绍故障注入和风险挖掘时，多次提到Awatch这项技术，并且带有“统一JAVA字节码框架”的修饰词，这是因为Awatch诞生于蚂蚁技术蓝军的故障注入实践，随着基于JAVA字节码技术的上层需求越来越丰富，例如蓝军的风险识别的数据采集，基础安全团队的风险行为拦截，仿真环境的流量mock等，我们逐渐意识到Awatch不再只是一个字节码技术框架，他的定位应该是一个统一的应用切面。
Awatch是蚂蚁技术风险部和基础安全部共建的蚂蚁应用切面基础设施，构建了应用进程内切面的从SDK->Agent端->管控端->稳定性的一体化完整解决方案。
字节码技术并不是一项特别新颖的技术，在开源社区也有jvm-sandbox这种优秀的字节码注入工具，那么蚂蚁自研的Awatch有什么特点和创新呢？我们认为，一个单纯的字节码注入工具不可能满足蚂蚁的基础设施现状和生产环境的稳定性要求，Awatch是基于蚂蚁基础设施能力，从能力组件视角提供了从【编程SDK->注入Agent端->管控端->稳定性】的全链路支持，从业务场景视角提供了从【研发-验证-部署-配置-监控-应急】全周期一整套解决方案。
三板斧是指蚂蚁技术风险规范中的“变更三板斧”，即蚂蚁的所有生产环境的变更，必须严格遵循“可监控，可灰度，可回滚”三项规定，三板斧的规范极大程度的减少了生产环境由变更导致的故障数量
（Awatch的整体落地架构）
可以看到，完整的Awatch架构，不仅包括涉及字节码技术的core层和提供编程接口的framework层（大多数字节码工具只做到了这两层），更重要的是上层的底座平台，通过提供完整的监控，应急，变更等管控能力，强有力的保障了Awatch在生产环境的稳定性，极大程度的提升了Awatch的运维效率。即便是在framework层，也做了很多与性能和稳定性相关的功能，例如自降级，全局保护，前置过滤等。
目前Awatch在蚂蚁集团内部已支持20多个业务场景，包括技术蓝军的故障注入，基础安全的应用安全切面RASP(应用运行时自我防护)，仿真流量mock，业务变更沙箱流量录制等。
其中，基础安全RASP场景，在今年的双11大促中，已于蚂蚁交易支付链路的91个核心系统中部署，并且做到了生产环境100%部署，实施过程中0故障，并且以不降级的方式安然度过大促，RASP峰值2.219亿TPM，Awatch的性能和稳定性已经过双11的检验。
Awatch将在2022年进行开源，我们希望这项技术能够帮助到更多的用户，通过开源构建更加丰富的Awatch应用场景，逐步打造Awatch的技术生态。
2、仿真环境
混沌工程在生产环境进行真实的故障注入的效果肯定是最佳的，因为真实的故障是发生在生产环境的，故障的发现和应急，故障处理过程中各团队之间的协同，也是面向生产环境的，但是，在生产环境进行真实的故障注入，大概率会导致故障，业务无法容忍。那么，如何解决这个矛盾，技术蓝军实践过生产环境无损攻击等方法，例如通过制造错误日志但不影响应用运行的方式来模拟故障，不过这种方式有其局限性，一方面难以达到理想的真实度，另一方面在故障处理全链路中，较多检验的是故障发现能力，对应急恢复的帮助较小。
如果有一套独立的环境，运行在生产环境的机房，部署架构与生产环境具有高度的相似性，流量来自于生产环境的真实流量，数据层面与生产环境隔离，两者之间互不影响，那么在这个环境中就可以安心的进行真实的故障注入，仿真环境就是这样的一套环境。
仿真环境不仅服务于混沌工程，还能够支持变更，测试联调等工作，仿真环境的建设目的，一方面是把线上变更防御、应急、演练等工作前移到仿真环境中，进一步降低线上故障，另一方面是能让测试、回归、联调等工作提效，其基本的设计是流量复制生产流量，依赖的存储如Oceanbase(蚂蚁自研的分布式数据库产品)使用数据同步、闪回等技术定时和生产保持一致。目前仿真环境投入了对标生产环境3%的机器，蚂蚁全业务共计1500多个应用搭建了仿真环境，核心场景的TPS对标生产有6%，流量覆盖核心系统的95%
仿真环境是蚂蚁技术基础设施的重点方向之一，目前正在逐步攻克诸多的技术难题，如复杂流量的真实性、稳定性，成本优化等，由于篇幅所限，本文不再展开讲述。
3、混沌靶场
混沌靶场是指在生产环境中，由技术蓝军自建的一套小型分布式系统，专门用于在生产环境进行故障注入。混沌靶场提出的主要考虑是，目前蚂蚁技术风险的各种防线，大多为通用防线，即提供各个业务通用的防御能力，例如高可用领域中的服务限流，通用定位(服务异常定位等)，通用变更防御(通用防御规则)，等等，这些能力不因应用系统的差异而发生变化，因此没有必要一定通过注入业务系统对其进行检验，靶场系统接入这些通用防御能力之后，通过注入靶场系统也能够达到相同的检验目的，同时不会因故障注入而影响业务。
混沌靶场和仿真环境互为补充，混沌靶场面向通用防线，仿真环境面向业务个性化防线，二者都以制造真实故障为主要手段，检验技术风险各防线的防御能力。
4、污点分析技术
上文提到蚂蚁在混沌工程中的业务实践中，风险挖掘是非常重要的一部分内容，在风险挖掘的技术中，除了基于Awatch的数据采集，结合风险模型的实时和离线分析等技术之外，还包括污点分析这项创新技术。
污点分析作为一种经典的信息流分析技术，可以追踪指定的关键数据字段在程序中的传播和流向。通过指定关注的数据(source)作为污点，分析该数据字段是否在程序中可以传播到指定的终点(sink)。举例来说：
上图展示了接口函数sample的入参SampleRequest(source)在示例程序中的传播流转，最终影响SampleEnum枚举值(sink)的取值。通过指定不同的source和sink，污点分析可以应用于各种不同场景，例如检测数据漏洞，精准灰度引流等。
在蚂蚁的混沌工程领域，污点分析技术主要用于风险挖掘，具体来讲，通过污点分析，结合前文提到的资金表，我们可以分析出资金表中具体某个字段(例如某个金额字段amount)，对应的上层入口服务或者消息中的具体参数(例如某个服务中的参数request中的amount字段)，从而识别出资金服务和资金消息等更加贴近业务的资金风险，设计出更加面向业务的故障注入场景。
污点分析技术在蚂蚁的混沌工程领域目前处于起步阶段，目前的实践效果还是不错的，今后我们将会基于这项技术探索更多的混沌工程应用场景。
5、混沌工程平台
平台方面，蚂蚁在几年混沌工程实践中，先后建设了高可用攻防平台，资金安全攻防平台，研发质量攻防平台，风险挖掘平台等，平台具备完整的风险挖掘，故障注入，演练度量能力，并且能够进行故障注入的持续回归，度量的自动化，风险挖掘的自动化，等等。
下图为高可用攻防平台中执行的一次变更攻击，平台会给出攻击详情，以及本次攻击在防御侧的度量结果。
五、面向未来
蚂蚁将历史上发生过的两次重大技术故障日——5月27日和12月18日这两天，设立为集团层最高级别纪念日之一，并将混沌工程(红蓝攻防)作为蚂蚁技术日最主要的活动，传承和检验技术人对风险的敬畏和能力。截止到2021年，蚂蚁攻防演练已成功举办12届。
如果说双11等大促是外部客户对我们的检验，那么“527”和“1218”就是蚂蚁技术人在内部对自己的考验。在这两个时间点约一周的时间里，蓝军比平时更为集中的攻击，红军也更加谨慎的防守，氛围十分紧张热烈，内部有一句话形容的非常贴切：“我们疯起来连自己都打”。每当大考开始，红蓝军各业务的CTO作为军长领军，通过排名和奖励机制，各个业务在这场大考中相互PK各自的技术风险防控水平，参加人数最多时达到千人左右。
（最近一期蚂蚁混沌工程攻防大演练于2021年12月13日～17日举办，图为蚂蚁集团《第十二届红蓝攻防大演练》首席技术官倪行军在红蓝攻防总结会中发言）
（图为蚂蚁集团《第十二届红蓝攻防大演练》KO会上蓝军副军长技术风险部陈亮发言）
（最近一期蚂蚁混沌工程攻防大演练于2021年12月13日～17日举办，图为蚂蚁集团《第十二届红蓝攻防大演练》KO会上各红军军长签署军令状）
目前“527”和“1218”已经成为蚂蚁技术的重要品牌，除了红蓝攻防之外，还包括技术风险阶段性总结，各类技术风险的颁奖活动，技术风险论坛等。通过这些活动，持续不断地在蚂蚁工程师心中强化技术风险意识，宣导技术风险和混沌工程的文化。
当前蚂蚁的混沌工程需要人参与的部分占比还比较大，包括故障注入场景设计，风险挖掘准确度分析等，未来蚂蚁的混沌工程中智能化会占据比较高的比重，通过智能化的方式提升混沌工程的效率，降低混沌工程的成本。同时，在不断打磨混沌工程相关技术产品的同时，我们也将积极投入开源事业，让这些优秀的技术能够帮助到更多的用户。
