1 Chaos 体系
1.1 Chaos 之混沌工程
混沌工程是在分布式系统上进行实验的学科,通过一系列可控的实验和执行实验的原则，揭示出分布式系统中随时或天灾或人为发生的各类事件是如何逐步导致系统整体不可用的，目的是建立对系统抵御生产环境中失控条件的能力以及信心。最近 2 年国内著名互联网公司已经开始意识并逐步实施，提高系统服务质量。
1.2 混沌的框架原则的理解
爱奇艺金融科技团队的混沌原则更多的是应对不可预知场景下系统架构、人员架构对于问题的应对能力，如隔离、告警、自我修复能力等，主要倾向工程层面、架构层面、研发流程体系层面、灾难预警恢复层面等。
1.3 Chaos - Monkey
理想的 Chaos Monkey 是 Chaos 体系的执行者，是基于场景为某个特定目标而生的，是一种可执行、可按预期销毁的手段。它主要负责寻找系统中任意一个盲区，并且利用盲区对系统实现某种程度并且可控的破坏。
2 矛盾大战的目的和设计
爱奇艺金融科技团队在高安全、高并发、高可用上遇到了很多挑战，同时金融系统相比于常规系统，在用户隐私、资金安全、敏感数据上有极高的要求，因此我们构建 Chaos 攻防模型，不断实施攻防对抗，逐步提高系统健壮性，为业务保驾护航。
目标如下 ：
混沌工程自循环之生产关系 ：
按照不同时期、不同要求、不同目标训练建设 Chaos Monkey 的可实施、可落地的攻击能力。
Chaos Monkey 能力训练满足要求后，按照假定目标制定整个实施计划，包括执行时间、执行过程、影响范围、执行手段、结果预期、故障恢复、是否静默执行等，最后进行自动化实施准备。
执行前 check 无异常后开始实施同时观察监控系统、业务系统、告警系统，实施结束后恢复当前系统并给出相应反馈包括详细描述，优化建议等。
业务 owner 收到结果反馈后需对已存问题进行 review、评估整改方案、修复计划并检查同类问题，最后进行系统升级。
收到业务系统升级上线通知后再次与业务 review 预期目标，然后进行验证性攻击检验修复效果同时记录 case 库。
业务 owner 也可以向 Chaos Monkey 申请攻击来验证当前系统的真实情况。
3 Chaos 攻防的拷问及设计实施原则
Chaos 攻防的拷问 ：
设计实施原则 ：
4 攻防战绩
4.1 执行大类分布
4.2 已执行攻防 case 分类列表
4.3 实战案例举例
例 1：验证支付系统微服务 Spring Cloud 套件的高可用机制
涉及 Eureka Server、Client、Ribbon LB 及当前业务对配置掌握的合理性。
例 2：攻击金融业务系统中非核心依赖的中间件
暴露发现系统设计的健壮性问题。
5 思考总结
5.1 总结
随着 Chaos 体系的逐渐成熟，体系内自驱力逐渐减少，Chaos 会进入一个新的阶段就是常态化。这个阶段不再是以暴露发现系统现有实施问题为主，而是面向系统架构的将来以及系统健壮性、可用性的稳固。主要有以下几点：
（1）自动化安全巡视
Chaos 将进入不定期按照已经积累 case 库进行自动化巡检。
（2）基础架构高可用由谁来监控
Chaos 进行不定期面向架构层面进行实弹演习，检验他们的战备值班能力。
（3）新技术、中间件的探索验证
对于新技术、新中间件甚至是自研的中间件可利用 Chaos Monkey 进行符合业务需求的健壮性、可用性探测验证。
（4）举一反三
建立线上故障 case 库，定时重播线上故障。
5.2 思考
（1）让业务能更直观的感觉到他守护的东西及带来的价值；
（2）增加覆盖面，有的放矢，针对实际情况调整目标及方向；
（3）建立可视化、模板化能力。丰富 case 库并支持重复攻击演练及跟踪。
原文链接 ：
攻防大战的背后——矛盾双修
