云原生架构下的混沌工程实践，讲述了什么是混沌工程，混沌工程的5项原则。为什么要引入混沌工程?介绍了混沌工程开源工具chaosblade混沌之刃，统一实验模型描述混沌事件，控制爆炸半径减小实施风险，建立面向失败设计的技术文化，通过平台能力标准化实验流程，从系统分层来守护稳定性。
混沌工程与系统稳定性设计模式：讲述了在现有混沌工程原则基础上改进的“维稳”8步法，此外讲述了“维稳”的设计模式。
ChaosBlade: 云原生架构下的混沌工程探索与实践，讲述了ChaosBlade的基石-混沌实验模型(Target实验靶点+Scope实验范围+Matcher规则匹配器+Action实验行为)，ChaosBlade 丰富的实验场景。
分布式服务架构下混沌工程实践，讲述了混沌工程的实施步骤，分布式架构下面临的问题以及分布式服务的高可用原则。
云原生架构下的混沌工程实践 来自阿里巴巴周洋(花名中亭)-2019
1) 建立稳定状态的假设；
2) 用多样的现实世界事件做验证；
3) 在生产环境中进行实验；
4) 自动化实验以持续运行；
5) 最小化爆炸半径。
统一实验模型描述混沌事件
控制爆炸半径减小实施风险
建立面向失败设计的技术文化
混沌工程与系统稳定性设计模式：来自道⻓伍斌(“维稳”8步法和“维稳”设计模式)-2020
听众们的疑问
什么是混沌工程
为什么要混沌工程
复杂的和混沌的系统无法预测
复杂系统：一组相互之间以及环境之间存在互动关系的子系统，且不完全被中央系统所控制。
稳定性设计：混沌工程'维稳'8步法
混沌⼯程的⽬的不是搞破坏，⽽是⽤试验进⾏探 索和演练，来增强系统的稳定性。
系统稳定性（弹性/韧性），指系统在可接受的⼲ 扰情况下，能够承受局部破坏，并在可接受的时 间内进⾏⾃我恢复的能⼒。
混沌⼯程“维稳”8步法 ：
*0). 先决条件：限制爆炸半径和受害者；建⽴可观测性；制定关闭混沌 试验后回归稳态的⽅案；制定应急预案；
1)定义稳态：定义系统正常*业务*⾏为的“稳态” ；
2) 稳定性设计：运⽤稳定性系统设计⽅法实现业务稳态
3.)建⽴假设：假设业务稳态在引⼊⼲扰时保持平稳
4). 引⼊⼲扰：模拟真实世界的⼲扰并引⼊系统
*5). 对⽐试验：根据试验和对照组的数据试图证明业务稳态假设不成⽴
*6). 进⾏改进：根据试验结果改进系统稳定性设计
*7). 持续试验：重复上述过程
备注：加*部分在混沌工程现有原则基础上增加的部分。
分布式系统“维稳”的稳定性设计模式
“要躲避的坑”（10+2个反模式） ：
1 集成点 ， 2 连累反应 ， 3 层叠失效 ， 4 ⽤户， 5 阻塞的线程 ， 6 ⾃⿊式攻击 ， 7 放⼤效应 ， 8 失衡的系统容量， 9 ⼀窝蜂，10 做出误判的机器 ，11 缓慢的响应
集成点：传⼊数据的每⼀个连接，都可以 令系统停⽌响应
连累反应：由于⼀台服务器停机，令其他服 务器必须接过其负载⽽不堪重负
层叠失效：某⼀层的失效导致其调⽤层发⽣失效
⽤户：随着⽤户流量的增⻓，最终它将超过系统的容量
阻塞的线程：所有线程都在开开⼼⼼地运⾏， 但只在那⾥“等待⼽多”
⾃⿊式攻击：指系统(或有⼈类参与的扩展系 统）参与合谋来与⾃身作对
放⼤效应：存在“多对⼀”或“多对少”的关系的 多⽅规模增⼤，令另⼀⽅遭受放⼤的影响⽽崩溃
失衡的系统容量：⼀个层级或服务能向另⼀个层级或服务，发送超过后者处理能⼒ 的⼤量请求，从⽽淹没后者
⼀窝蜂：当启动多台服务器（如在代码升级和重新启动之后），或⼀个cron作业在任何⼀个整点时间被触发，或当配置管理系统推出⼀个变更时，⼀堆服务器同时对某 ⼀台服务器（如数据库）施加的瞬时负载
做出误判的机器：对于系统预期状态的“信念”，在⾃动化平台与管理员之间所发⽣的冲突
缓慢的响应：“慢得好像死了”
⽆限⻓结果集 “不信有好事”(9+3个好模式)
1 超时，2 断路器， 3 舱壁，4 稳态，5 快速失败，6 任其崩溃并替换， 7 握⼿， 8 考验机 ，9将中间件解耦，10 卸下负载
⽆限⻓结果集：查询数据库、遍历结果集并处理 每⼀⾏结果的程序，没有明确限 制可以处理的结果数量
超时：只要认为响应不会到来，就可以停⽌等待
断路器：如果调⽤执⾏成功，那么⼀切平安⽆事。但如果调⽤执⾏失败， 断路器会将其记录下来。⼀旦失败次数或频率超过阈值，断路器 将跳闸并“断开电路”
舱壁：能将船分隔成若⼲独⽴的⽔密隔间的隔板，可防⽌⽔从⼀个部分流到另⼀个部分。使得船体即使被洞穿⼀次也不会沉没，能控制损害范围
稳态：分布式系统的“维稳”，⽐如针对每个累积资源的机制，要相应存在 另⼀个机制以回收该资源
快速失败：如果系统⽆法满⾜SLA要求，则需要快速通知调⽤者。不要让调⽤者等待错误信息，也不要让他们 等到超时为⽌。否则只会让你的问题成为他们的问题
任其崩溃并替换：创建系统级稳定性所能做的最好的事情，就是放弃组件级的稳定性，并尽快更换组件，以回到系统最初⼲净的刚完成启动的状态
握⼿：发送⽅和接收⽅两个设备之间⽤于规范两者之间通信⽅式的过程，让服务器通过限制⾃⼰的⼯作量来保护⾃⼰
考验机：能够⽤⽹络错误、协议错误或应⽤程序级错误等各种低层错误， 来“考验”被测软件的测试服务器。 因为每个系统最终都会偏离接⼝ 规范
将中间件解耦：通过在系统之间传递数据和事件 的中间件来实现集成；通过让参与其中的系统不必了解其他系统的特定知识，⽽只是对其进⾏调⽤来实现解耦
卸下负载：当负载过⾼时，就开始拒绝新的⼯作请求。这与快速失败模式相关
背压机制：请求的消费⽅将其处理请求的速 度通知发送⽅，让⾃⼰能慢些⼯ 作，从⽽创造安全性
节速器：减缓缺乏判断能⼒的⾃动化机制出错时的速度
ChaosBlade: 云原生架构下的混沌工程探索与实践，来自阿里巴巴技术专家和混沌工程布道师肖长军(花名：穹谷)-2019.10.19
ChaosBlade（混沌之刃）是一款遵循混沌实验模型，简单易用，功能强大的混沌实验工具(场景丰富度高、使用简洁，易于理解、动态加载，无侵入、场景扩展方便)
Github 地址：https://github.com/chaosblade-io/chaosblade
ChaosBlade 的基石-混沌实验模型
Target 实验靶点：实验的组件
Scope 实验范围：集群、机器、Pod
Matcher规则匹配器：匹配条件
Action实验行为：具体执行的实验规则
简洁：层次清晰通俗易懂 四层，边界清晰
通用：覆盖目前所有故障场景，基础资源、应用、容器或 serverless 架构
易实现：实验场景共建简单，定义清晰的接口规范
语言：领域无关 可以扩展多语言、多领域实现
ChaosBlade 丰富的实验场景
基础资源 chaosblade-exec-os：CPU 负载、内存占用、网络延迟/丢包/阻塞、 杀进程、宕机、重启、磁盘填充、IO Hang、IO burn、shell 脚本
应用服务
service mesh：调用延迟、异常、超时
分布式跟踪：打标签标识
消息：投递延迟、异常、超时、重发
熔断限流：sentinel 限流失效、异常
web容器servlet：请求延迟、异常
数据库：servlet druid/tddl/mysql/ postgresql 连接池满、调用延迟、异常
容器服务chaosblade-exec-docker：内存溢出，进程 CPU 负载， 指定类和方法做延迟、异常、修改返回值、修改参数
容器服务chaosblade-exec-k8s：杀 POD、停止 POD、kubelet 异常、断网、 删容器、容器服务异常、etcd 异常等；容器内应用进程、基础资源场景
分布式服务架构下混沌工程实践，来自阿里巴巴混沌工程布道师肖长军(花名：穹谷)-2019
混沌工程的原则同周洋部分，下面仅列出分布式有关的信息。