攻防大战的背后——矛盾双修
1 Chaos体系
1.1 Chaos之混沌工程
1.2 混沌的框架原则的理解
爱奇艺金融科技团队的混沌原则更多的是应对不可预知场景下系统架构、人员架构对于问题的应对能力，如隔离、告警、自我修复能力等，主要倾向工程层面、架构层面、研发流程体系层面、灾难预警恢复层面等。
1.3 Chaos - Monkey
理想的Chaos Monkey是Chaos体系的执行者，是基于场景为某个特定目标而生的，是一种可执行、可按预期销毁的手段。它主要负责寻找系统中任意一个盲区，并且利用盲区对系统实现某种程度并且可控的破坏。
2 矛盾大战的目的和设计
爱奇艺金融科技团队在高安全、高并发、高可用上遇到了很多挑战，同时金融系统相比于常规系统，在用户隐私、资金安全、敏感数据上有极高的要求，因此我们构建Chaos攻防模型，不断实施攻防对抗，逐步提高系统健壮性，为业务保驾护航。
目标如下：
建立Chaos Monkey的攻击能力、执行流程来辅助及验证服务架构的实施效果，从而给架构演进提供指导和参考价值； 建立架构与业务的生产关系，达到架构与业务的双向促进，提高系统稳定性、可用性、健壮性； 通过架构与业务生产关系的良性循环，提高技术同学对整个系统的掌控力、技术实力更好的为业务服务。
Chaos攻击能力的建设及升级：
制定计划及设置风险范围：
Chaos Monkey能力训练满足要求后，按照假定目标制定整个实施计划，包括执行时间、执行过程、影响范围、执行手段、结果预期、故障恢复、是否静默执行等，最后进行自动化实施准备。
执行与反馈：
执行前check无异常后开始实施同时观察监控系统、业务系统、告警系统，实施结束后恢复当前系统并给出相应反馈包括详细描述，优化建议等。
系统优化及能力提升：
业务owner收到结果反馈后需对已存问题进行review、评估整改方案、修复计划并检查同类问题，最后进行系统升级。
修复验证及业务需求：
收到业务系统升级上线通知后再次与业务review预期目标，然后进行验证性攻击检验修复效果同时记录case库。
业务owner也可以向Chaos Monkey申请攻击来验证当前系统的真实情况。
3 Chaos 攻防的拷问及设计实施原则
Chaos 攻防的拷问：
支付、金融架构设计是否存在问题？ 原来的架构设计是不是不再符合我们的预期了？ 设计方案和当前生产系统实现之间差了多少？ 支付、金融服务底线都是什么，支付、金融服务的隔离颗粒度？ 我们能承受哪些，能承受多长时间，我们不能承受哪些？ 我们系统的高可用程度？ 高可用节点切换过程会发生什么？ HA的切换手段、切换(不可用)的间隔？ 切换成功的时间和一致性的时间是不是有关？等等。
设计实施原则：
为设计漏洞、代码缺陷而生同时面向生产环境，做到要发现问题更要可控; 不拘于手段和形式。不论是使用开源工具，还是切断网线、偷偷杀掉进程、还是进程植入，内存数据篡改都是一种面向某个目的可实施手段; 监控告警辅助支撑，最大化风险评估，细化到流量的损失控制等。
4 攻防战绩
4.1 执行大类分布
4.2 已执行攻防case分类列表
4.3 实战案例举例
例1：验证支付系统微服务Spring Cloud套件的高可用机制
涉及Eureka Server、Client、Ribbon LB及当前业务对配置掌握的合理性。
验证结果：当前架构能在30s内应对下游节点的无前兆故障。
优化建议：调整LB的探测时间，Eureka Client、Ribbon Cache缓存时间，服务心跳续约，Eureka Server服务剔除、数据同步时间等加强架构对故障的应对能力同时减少类似问题对业务的影响。
例2：攻击金融业务系统中非核心依赖的中间件暴露发现系统设计的健壮性问题。
执行结果：非核心依赖中间件发生服务抖动、服务故障时系统无降级策略，直接导致整个业务无法服务，不符合架构原则。
优化建议：业务系统增加对非核心依赖故障的降级及切换策略。优化连接池配置来应对当非核心依赖中间件出现问题时降低性能损耗及减少切换的时间差。
5 思考总结
5.1 总 结
随着Chaos体系的逐渐成熟，体系内自驱力逐渐减少，Chaos会进入一个新的阶段就是常态化。这个阶段不再是以暴露发现系统现有实施问题为主，而是面向系统架构的将来以及系统健壮性、可用性的稳固。主要有以下几点：
Chaos将进入不定期按照已经积累case库进行自动化巡检。
（2）基础架构高可用由谁来监控Chaos进行不定期面向架构层面进行实弹演习，检验他们的战备值班能力。
（3）新技术、中间件的探索验证
对于新技术、新中间件甚至是自研的中间件可利用Chaos Monkey进行符合业务需求的健壮性、可用性探测验证。
（4）举一反三
建立线上故障case库，定时重播线上故障。5.2 思 考
也许你还想看