混沌工程攻防大战的背后——矛盾双修 1Chaos体系1.1Chaos之混沌工

1Chaos体系
1.1Chaos之混沌工程
混沌工程是在分布式系统上进行实验的学科,通过一系列可控的实验和执行实验的原则，揭示出分布式系统中随时或天灾或人为发生的各类事件是如何逐步导致系统整体不可用的，目的是建立对系统抵御生产环境中失控条件的能力以及信心。最近2年国内著名互联网公司已经开始意识并逐步实施，提高系统服务质量。
1.2混沌的框架原则的理解

文章图片
爱奇艺金融科技团队的混沌原则更多的是应对不可预知场景下系统架构、人员架构对于问题的应对能力，如隔离、告警、自我修复能力等，主要倾向工程层面、架构层面、研发流程体系层面、灾难预警恢复层面等。
1.3Chaos-Monkey
理想的ChaosMonkey是Chaos体系的执行者，是基于场景为某个特定目标而生的，是一种可执行、可按预期销毁的手段。它主要负责寻找系统中任意一个盲区，并且利用盲区对系统实现某种程度并且可控的破坏。
2矛盾大战的目的和设计
爱奇艺金融科技团队在高安全、高并发、高可用上遇到了很多挑战，同时金融系统相比于常规系统，在用户隐私、资金安全、敏感数据上有极高的要求，因此我们构建Chaos攻防模型，不断实施攻防对抗，逐步提高系统健壮性，为业务保驾护航。
目标如下：
建立ChaosMonkey的攻击能力、执行流程来辅助及验证服务架构的实施效果，从而给架构演进提供指导和参考价值；
建立架构与业务的生产关系，达到架构与业务的双向促进，提高系统稳定性、可用性、健壮性；
通过架构与业务生产关系的良性循环，提高技术同学对整个系统的掌控力、技术实力更好的为业务服务。
混沌工程自循环之生产关系：

文章图片
Chaos攻击能力的建设及升级：
按照不同时期、不同要求、不同目标训练建设ChaosMonkey的可实施、可落地的攻击能力。
制定计划及设置风险范围：
ChaosMonkey能力训练满足要求后，按照假定目标制定整个实施计划，包括执行时间、执行过程、影响范围、执行手段、结果预期、故障恢复、是否静默执行等，最后进行自动化实施准备。
执行与反馈：
执行前check无异常后开始实施同时观察监控系统、业务系统、告警系统，实施结束后恢复当前系统并给出相应反馈包括详细描述，优化建议等。
系统优化及能力提升：
业务owner收到结果反馈后需对已存问题进行review、评估整改方案、修复计划并检查同类问题，最后进行系统升级。
【混沌工程攻防大战的背后——矛盾双修】修复验证及业务需求：
收到业务系统升级上线通知后再次与业务review预期目标，然后进行验证性攻击检验修复效果同时记录case库。
业务owner也可以向ChaosMonkey申请攻击来验证当前系统的真实情况。
3Chaos攻防的拷问及设计实施原则
Chaos攻防的拷问：
支付、金融架构设计是否存在问题？
原来的架构设计是不是不再符合我们的预期了？
设计方案和当前生产系统实现之间差了多少？
支付、金融服务底线都是什么，支付、金融服务的隔离颗粒度？
我们能承受哪些，能承受多长时间，我们不能承受哪些？
我们系统的高可用程度？
高可用节点切换过程会发生什么？
HA的切换手段、切换(不可用)的间隔？
切换成功的时间和一致性的时间是不是有关？等等。
设计实施原则：
为设计漏洞、代码缺陷而生同时面向生产环境，做到要发现问题更要可控;
不拘于手段和形式。不论是使用开源工具，还是切断网线、偷偷杀掉进程、还是进程植入，内存数据篡改都是一种面向某个目的可实施手段;
监控告警辅助支撑，最大化风险评估，细化到流量的损失控制等。
4攻防战绩
4.1执行大类分布

文章图片
4.2已执行攻防case分类列表

文章图片
4.3实战案例举例
例1：验证支付系统微服务SpringCloud套件的高可用机制
涉及EurekaServer、Client、RibbonLB及当前业务对配置掌握的合理性。
验证结果：当前架构能在30s内应对下游节点的无前兆故障。
优化建议：调整LB的探测时间， EurekaClient、RibbonCache缓存时间，服务心跳续约， EurekaServer服务剔除、数据同步时间等加强架构对故障的应对能力同时减少类似问题对业务的影响。