随着云原生技术及大量开源软件的引入，IT系统架构逐步从传统的MVC三层架构（表示层UI、数据访问层DAL、业务逻辑层BLL）向微服务、平台容器化架构演进，新的技术架构中服务调用关系错综复杂、开源软件单点故障风险高等都给传统运维方式提出挑战。亟需不定期在生产业务系统中开展混沌演练，进一步提升业务系统的高可用，从而在实际生产中检验系统稳定性，提高业务系统应急和高可用保障能力。
混沌工程属于一门新兴的技术学科，行业认知和实践积累比较少，大多数IT团队对它的理解还没有上升到一个领域概念。阿里电商域在2010年左右开始尝试故障注入测试的工作，希望解决微服务架构带来的强弱依赖问题。
混沌工程是一种提高技术架构弹性能力的复杂技术手段。混沌工程经过实验可以确保系统的可用性，它旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。
混沌演练常用的工具有阿里开源的ChaosBlade、Netflix开源的ChaosMonkey。
4.1 演练场景选取
序号 | 主题 | 分类 | 场景 |
1 | 技术组件依赖主题 | 数据库层 | 数据库切换 |
2 | 大量备份恢复 | ||
3 | 数据库单节点服务中断 | ||
4 | 数据库主机单点挂掉 | ||
5 | 数据库连接数满 | ||
6 | 索引失效 | ||
7 | 大量慢SQL |
4.2 系统架构
4.3 演练目标
通过混沌演练验证云原生及大量开源软件等新技术在基础设施和软件方面的高可用性能力，在演练过程中发现应急处理和高可用能力的盲点与不足，持续提升业务连续性保障尤其是高可用保障能力、以及应急保障能力。
本次演练选取的是技术组件依赖主体-数据库层（开源MySQL数据库）7个应用场景，通过本次混沌演练实施操作，及时发现MySQL数据库在技术保障上的不足，及时分析、处理和优化数据库结构，从而进一步提升MySQL数据库对业务系统支撑的应用保障能力。
4.4 演练影响
影响业务：演练期间运营商某业务系统使用会受到短暂影响，例如系统登陆、业务数据交互等功能会出现短暂性异常。
影响范围：业务系统使用人员。
4.5 风险评估与应急措施
对本次演练进行充分的准备，包括演练前检查，演练中业务保障、演练后的生产验证，针对每个环境可能出现的风险点进行预估，并制定应对举措如下：
阶段 | 风险预估 | 应对举措 |
演练前 | 检查场景涉及服务器硬件故障 | 演练前对演练对象进行集中巡检，确保无硬件问题 |
检查场景设计服务器存在性能瓶颈 | 演练前实时关注演练系统的性能情况，如有性能瓶颈提前优化 | |
演练中 | 单容器、单虚拟机、单物理机、单应用节点、单Slave节点在故障模拟后无法重启 | 单设备故障不影响业务连续性，演练当前硬件维修人员现场保障 |
极端情况下，如误操作，可能导致单集群的故障 | 切换到应急系统或容灾系统 | |
演练后 | 业务影响反馈超时或失败 | 做好全方位的生产验证测试 |
4.6 演练详细步骤
本次混沌演练工具主要选用的是ChaosBlade和脚本相结合，演练主要采用攻防对抗的方式进行实施，实现故障注入的随机触发，故障半自动化恢复。
1.涉及设备信息
VIP | 内网IP | 主机名 | 用户名 | 登陆方式 |
1.1.1.10 | 1.1.1.1 | hostname1 | mysql | ssh |
1.1.1.2 | Hostname2 | mysql | ssh |
软件 | 版本 | 作用 |
keepalived | 1.3.6 | VIP检测 |
mysql | 5.7.32 | 数据库 |
2.故障注入
故障注入主要特征是混沌工程中的故障随机性，本文涉及MySQL数据库故障演练场景主要包含有数据库切换，大量备份恢复等7个场景，采用chaosblade模拟故障随机触发。
如下选择其中一个故障场景进行介绍。
场景一：数据库切换
故障操作
序号 | 操作步骤 | 验证方法和操作命令 | 预期结果 |
1 | 停止VIP主机mysql实例 | 1.ssh登陆1.1.1.10主机 2.执行命令： $sh chaosblade-Failure.sh”，选择故障选项（故障实现方式：主动宕库） | 命令执行成功，3306进程不存在 |
3.故障分析、故障恢复
故障分析和故障恢复主要描述演练场景下故障的处理过程，以及故障分析的实际操作、分析过程，详细的展现各演练场景中分别对故障分析和故障恢复处理的整过过程，从而更加高效的提高数据库的稳定性，提升业务系统保障能力。
如下选择其中一个故障场景进行介绍。
场景一：数据连接数满
故障分析和恢复
序号 | 操作步骤 | 验证方法和操作命令 | 预期结果 |
1 | 故障分析 | 1.ssh登陆1.1.1.10主机 2.监控告警 3.执行命令： sh chaosblade-Check.sh，选择分析选项 | 1.定位到故障类型：mysql连接数满，新mysql连接不成功 |
2 | 故障恢复 | 1.登陆数据库$mysql -h1.1.1.10 -u** -P3306 -p 2.检查连接数和业务连接情况 mysql>show variables like '%max_connections%'; mysql>select count(*) from information_schema.processlist; 3.查询阻塞sql确定阻塞情况 mysql>select * from information_schema.innodb_lock_waits; mysql>select * from information_schema.innodb_locks; mysql>select * from information_schema.innodb_trx where trx_id=’’\G 4.查杀阻塞的sql, mysql>kill pid;或者扩大最大连接数mysql>set GLOBAL max_connections=1000; | 1.故障节点新mysql连接正常 2.keepalived运行正常 3.mysql数据库正常 4.远程登陆VIP数据库正常 5.业务访问正常 |
3 | （业务验证） | 运营商业务系统登陆，模块功能使用 | 业务验证正常 |
4.7 总结
本次演练采用工具+脚本的方式主动故障随机式注入，有效检验了数据库系统高可用性能，验证了在极端情况下，数据库架构的高可用保障能力，同时也为场景能力平台化做好准备，以及随机化故障的应对和处理积累了经验，提升数据库对业务支撑的连续性保障能力。
