GIAC 混沌工程与系统稳定性设计模式 2019,06,22 脱敏版 v0,3

2020-03-16 136浏览

1.混沌⼯程与系统稳定性设计模式 v0.3 道⻓（伍斌） 2019.06.22
2.道⻓（伍斌）、吾真本能辅导软件开发团队⼜快⼜好地交付软件的ThoughtWorks技术教练因搞编程道场，⼈称“道⻓”。经常在简书上撰写敏捷开发相关的博客，署名“吾真本”。⼯作20多年，做过开发、测试、项⽬管理、技术教练。 2
3.⽬录什么是混沌⼯程为什么要做混沌⼯程稳定性设计是混沌⼯程“维稳”8步法的关键 3
4.听众问题为何使⽤测试不能解决复杂系统问题？如何证明我的系统是复杂系统？什么因素让系统变成复杂系统？有没有办法通过消除这些因素让系统变成⾮复杂？系统变多⼤满⾜了多少需求才会变成复杂系统？对项⽬中的QA实践有什么帮助？项⽬的复杂度到了什么程度之后，才需要做所谓混沌⼯程呢？是不是这个概念对于绝⼤多数“企业级应⽤”都是没有⽤的呢？如何说服领导在⽣产环境实践混沌⼯程？在什么阶段引⼊混沌⼯程？引⼊混沌⼯程时，如何有效规避⻛险？ 4
5.什么是混沌⼯程？
6.最早实现混沌⼯程的奈⻜公司 1997：奈⻜成⽴，DVD邮寄租赁 2007：流媒体服务（免费插件， 1,000部流媒体影⽚）；微软技术栈（单块架构，纵向容量伸缩） 2008.08：数据库损坏，3天停机（含DVD邮寄）；从单块架构迁移到AWS分布式云架构 2009.06：12,000部流媒体影⽚；数百个微服务，⼤规模分布式系统的复杂性，随机的服务中断 2010：Chaos Monkey；失效注⼊ 6
7.混沌⼯程，指在分布式系统上进⾏试验的探索性实践，旨在建⽴⼈们对于系统能够应对⽣产环境中的动荡状态的信⼼。——混沌⼯程原则 7
8.为什么要做混沌⼯程？
9.1年前的⼀天…… “故障于16:21左右开始，16:50分开始陆续恢复。” “访问某⾥云官⽹控制台和MQ、NAS、OSS等产品功能出现问题，引发了⼤量吐槽。” “上线⼀个⾃动化运维新功能中，执⾏了⼀项变更验证操作。” “这⼀功能在测试环境验证中并未发⽣问题。” “上线到⾃动化运维系统后，触发了⼀个未知代码bug。” “错误代码禁⽤了部分内部IP，导致部分产品访问链路不通。” “后续⼈⼯介⼊后，⼯程师团队快速定位问题进⾏了恢复。” “对于这次故障，没有借⼝，我们不能也不该出现这样的失误！” “我们将认真复盘改进⾃动化运维技术和发布验证流程，敬畏每⼀⾏代码，敬畏每⼀失误必然会发⽣只是敬畏还不够 9
10.复杂和混沌的系统⽆法预测
11.复杂系统：⼀组相互之间以及与环境之间存在互动关系的⼦系统，且不完全被中央系统所控制。 11
12.复杂性来⾃哪⾥？⾮线形系统：输出的变化与输⼊的变化不成⽐例蝴蝶效应三体问题 12
13.蝴蝶效应（⾮线形系统） 1961：美国⽓象学家洛伦兹，第⼆次⽤计算机计算⼀段时间的⽓候变化从昨天的中间结果0.506（实际精度是 0.506127）开始往后咖啡天壤之别 1963：海鸥 1972：巴⻄的蝴蝶，得克萨斯州的⻰卷⻛对于⾮线形系统整体不等于各部分之和导致结果出现巨⼤差异的微⼩初始条 13
14.蝴蝶效应：导致不同后果的细微原因不易发现 14
15.三体问题（典型的⾮线性系统） 1887：瑞典国王奥斯卡⼆世，60岁寿诞，太阳系的稳定性问题已知三点质量的初始位置和速度（或动量），根据⽜顿运动定律和⽜顿万有引⼒定律，求解其后续运动。法国数学家庞加莱简化了问题，提出了限制性三体问题：假设⼀个双体问题，互相围绕旋转，再增加⼀个质量远⼩于他们的第三体，求第三体收到双体的引⼒之和会出现怎样的轨迹。庞加莱最终的结论发现，即使是限制性三体问题，也会因为初始值稍有偏差⽽导致后续结果⽆法预测。 15
16.三体换成三服务呢？每个服务都通过了测试…… 某⾥云30分钟线上故障 “这⼀功能在测试环境验证中并未发⽣问题。” “上线到⾃动化运维系统后，触发了⼀个未知代码bug。” 16
17.为何“在测试环境验证中并未发⽣问题”？测试⼈员⾛进⼀家酒吧。要了⼀杯啤酒。要了0杯啤酒。要了99999杯啤酒。要了⼀只蜥蜴。要了负1杯啤酒。要了⼀个sfdeljknesv。 17
18.为何“在测试环境验证中并未发⽣问题”？开发⼈员⾯对分布式计算的谬误⽹络可靠延迟为零带宽是⽆限的⽹络是安全的拓扑不会改变只有⼀个管理员传输成本为零⽹络是同质的 18
19.稳定性设计：混沌⼯程“维稳”8步法的关键
20.混沌⼯程的⽬的不是搞破坏，⽽是⽤试验进⾏探索和演练，来增强系统的稳定性。 20
21.系统稳定性（弹性/韧性），指系统在可接受的⼲扰情况下，能够承受局部破坏，并在可接受的时间内进⾏⾃我恢复的能⼒。 21
22.混沌⼯程“维稳”8步法 *0. 先决条件：限制爆炸半径和受害者；建⽴可观测性；制定关闭混沌试验后回归稳态的⽅案；制定应急预案 1. 定义稳态：定义系统正常*业务*⾏为的“稳态” *2. 稳定性设计：运⽤稳定性系统设计⽅法实现业务稳态 3. 建⽴假设：假设业务稳态在引⼊⼲扰时保持平稳 4. 引⼊⼲扰：模拟真实世界的⼲扰并引⼊系统 5. 对⽐试验：根据试验和对照组的数据试图证明业务稳态假设不成⽴ *6. 进⾏改进：根据试验结果改进系统稳定性设计 *7. 持续试验：重复上述过程 22
23.分布式系统“维稳”的稳定性设计模式 “要躲避的坑”（10+2个反模式） 1 集成点 12 ⽆限⻓结果集 “不信有好事”（9+3个好模式） 2 连累反应 1 超时 3 层叠失效 2 断路器 4 ⽤户 3 舱壁 5 阻塞的线程 4 稳态 6 ⾃⿊式攻击 5 快速失败 7 放⼤效应 6 任其崩溃并替换 8 失衡的系统容量 7 握⼿ *9 ⼀窝蜂 8 考验机 *10 做出误判的机器 9 将中间件解耦 11 缓慢的响应 *10 卸下负载 23
24.1 集成点传⼊数据的每⼀个连接，都可以令系统停⽌响应 24
25.2 连累反应由于⼀台服务器停机，令其他服务器必须接过其负载⽽不堪重负 25
26.3 层叠失效某⼀层的失效导致其调⽤层发⽣失效 26
27.4 ⽤户随着⽤户流量的增⻓，最终它将超过系统的容量 27
28.5 阻塞的线程所有线程都在开开⼼⼼地运⾏，但只在那⾥“等待⼽多” 28
29.6 ⾃⿊式攻击指系统（或有⼈类参与的扩展系统）参与合谋来与⾃身作对 29
30.7 放⼤效应存在“多对⼀”或“多对少”的关系的多⽅规模增⼤，令另⼀⽅遭受放⼤的影响⽽崩溃 30
31.8 失衡的系统容量⼀个层级或服务能向另⼀个层级或服务，发送超过后者处理能⼒的⼤量请求，从⽽淹没后者 31
32.*9 ⼀窝蜂当启动多台服务器（如在代码升级和重新启动之后），或⼀个 cron作业在任何⼀个整点时间被触发，或当配置管理系统推出⼀个变更时，⼀堆服务器同时对某⼀台服务器（如数据库）施加的瞬时负载 32
33.*10 做出误判的机器对于系统预期状态的“信念”，在⾃动化平台与管理员之间所发⽣的冲突 33
34.11 缓慢的响应 “慢得好像死了” 34
35.12 ⽆限⻓结果集查询数据库、遍历结果集并处理每⼀⾏结果的程序，没有明确限制可以处理的结果数量 35
36.1 超时只要认为响应不会到来，就可以停⽌等待 36
37.2 断路器如果调⽤执⾏成功，那么⼀切平安⽆事。但如果调⽤执⾏失败，断路器会将其记录下来。⼀旦失败次数或频率超过阈值，断路器将跳闸并“断开电路” 37
38.3 舱壁能将船分隔成若⼲独⽴的⽔密隔间的隔板，可防⽌⽔从⼀个部分流到另⼀个部分。使得船体即使被洞穿⼀次也不会沉没，能控制损害范围 38
39.4 稳态分布式系统的“维稳”，⽐如针对每个累积资源的机制，要相应存在另⼀个机制以回收该资源 39
40.5 快速失败如果系统⽆法满⾜SLA要求，则需要快速通知调⽤者。不要让调⽤者等待错误信息，也不要让他们等到超时为⽌。否则只会让你的问题成为他们的问题 40
41.6 任其崩溃并替换创建系统级稳定性所能做的最好的事情，就是放弃组件级的稳定性，并尽快更换组件，以回到系统最初⼲净的刚完成启动的状态 41
42.7 握⼿发送⽅和接收⽅两个设备之间⽤于规范两者之间通信⽅式的过程，让服务器通过限制⾃⼰的⼯作量来保护⾃⼰ 42
43.8 考验机能够⽤⽹络错误、协议错误或应⽤程序级错误等各种低层错误，来“考验”被测软件的测试服务器。因为每个系统最终都会偏离接⼝规范 43
44.9 将中间件解耦通过在系统之间传递数据和事件的中间件来实现集成；通过让参与其中的系统不必了解其他系统的特定知识，⽽只是对其进⾏调⽤来实现解耦 44
45.*10 卸下负载当负载过⾼时，就开始拒绝新的⼯作请求。这与快速失败模式相关 45
46.*11 背压机制请求的消费⽅将其处理请求的速度通知发送⽅，让⾃⼰能慢些⼯作，从⽽创造安全性 46
47.*12 节速器减缓缺乏判断能⼒的⾃动化机制出错时的速度 47
48.48
49.听众问题
50.听众问题为何使⽤测试不能解决复杂系统问题？测试只能检测已定义的测试⽤例，但⽆法保证⽤户和真实的⽣产环境（⽹络错误、协议错误或应⽤程序级错误）遵循任何测试⽤例。 50
51.听众问题如何证明我的系统是复杂系统？什么因素让系统变成复杂系统？有没有办法通过消除这些因素让系统变成⾮复杂？系统变多⼤满⾜了多少需求才会变成复杂系统？复杂系统：⼀组相互之间以及与环境之间存在互动关系的⼦系统，且不完全被中央系统所控制。 51
52.听众问题混沌⼯程对项⽬中的QA实践有什么帮助？混沌⼯程重在⽤试验从不可预知中探索学习；失效注⼊测试重在先⼊为主的进⾏检测 52
53.听众问题项⽬的复杂度到了什么程度之后，才需要做所谓混沌⼯程呢？是不是这个概念对于绝⼤多数“企业级应⽤”都是没有⽤的呢？没有上云和没有使⽤⼤规模分布式系统的企业级应⽤，也离不开“维稳”的稳定性设计 53
54.听众问题如何说服领导在⽣产环境实践混沌⼯程？医疗系统能否使⽤混沌⼯程？借鉴⼀下药物临床试验，这是医学研究中的最⾼标准。 54
55.听众问题在什么阶段引⼊混沌⼯程？⽣产事故问题定位时间越来越⻓导致⽣产事故的原因不清的情况逐渐增多越来越多的⽣产事故是由未预料到的使⽤场景导致 55
56.听众问题引⼊混沌⼯程时，如何有效规避⻛险？限制爆炸半径和受害者确保所涉及的系统落地了系统稳定性设计需要具备有效的可观测性识别系统稳态制定结束混沌试验后回归系统稳态的⽅案制定应急预案 56
57.混沌成熟度模型熟练度⾼级熟练简单未在⽣产环境做试验⼿⼯管理混沌过程试验结果只反应系统指标，⽽⾮业务指标只对试验对象注⼊简单失效事件，如“关闭节点” ⼊⻔混沌⼯程这样的创新项⽬不会获批⼏乎没有系统实践混沌⼯程在组织内部不为⼈知早期⽤户并不经常进⾏混沌⼯程试验摸索投资采⽤⽂化 57 源⾃Chaos Engineering第9章，参考了InfoQ的相关译⽂应⽤度
58.混沌成熟度模型熟⾼级熟练练度复制⽣产流量进⾏试验⾃助式创建试验，⾃动运⾏试验，需⼿动监控和停⽌试验试验结果反映聚合的业务指标对试验对象注⼊诸如⽹络延迟的扩展失效事件⼿⼯整理和汇总试验结果试验是静态定义好的⼯具⽀持试验组和控制组的历史数据对⽐混沌试验获得正式批准有兼职⼯程师专⻔做混沌⼯程多个团队有兴趣参与⼀些关键服务不定期地进⾏混沌试验简单⼊⻔摸索投资 58 源⾃Chaos Engineering第9章，参考了InfoQ的相关译⽂采⽤⽂化应⽤度
59.混沌成熟度模型熟⾼级练度在⽣产环境中运⾏试验⾃动化地进⾏混沌试验的创建、结果分析和停⽌混沌试验框架集成到持续交付⼯具中在试验和控制组之间对⽐业务指标为试验组注⼊诸如服务层失效和组合失效事件持续搜集试验结果⼯具⽀持试验组和控制组数据的交互式对⽐成⽴专⻔的混沌⼯程⼯具团队事故响应会集成到框架中以创建回归混沌试验⼤多数关键服务定期进⾏混沌试验有时会在事故响应和演练⽇中进⾏试验性验证熟练简单⼊⻔摸索投资采⽤ 59 源⾃Chaos Engineering第9章，参考了InfoQ的相关译⽂⽂化应⽤度
60.混沌成熟度模型混沌试验运⾏在开发的每⼀步和每个环境中全⾃动地设计、执⾏和及早中⽌混沌试验混沌试验框架集成到A/B测试及其他试验系统中以最⼩化噪⾳注⼊诸如使⽤模式变化及响应/状态突变的⼲扰试验具有动态的范围和影响以寻找关键影响点试验数据能反映出收⼊损失能根据试验数据进⾏容量预测试验数据能识别服务的关键程度所有关键服务都频繁进⾏混沌试验⼤部分⾮关键服务也频繁运⽤混沌混沌试验成为新⼯程师的必修课如不提申请则系统组件都默认纳⼊混沌试验熟练度⾼级熟练简单⼊⻔摸索投资采⽤⽂化 60 源⾃Chaos Engineering第9章，参考了InfoQ的相关译⽂应⽤度
61.总结
62.总结不要⽌步于所发现的“根本原因”，简单地惩罚替罪⽺了事。因为⼤部分现实问题都是⾮线形问题，既⽆法预测，⼜不易发现导致异常结果的细微原因⽤所发现的“根本原因”作为启发，本着“不信有好事”和“能在局部破坏下实现⾃愈”的设计原则，进⾏系统的稳定性设计，把分布式系统各个⼦服务打造成“明哲⾃保”的⾃治⼦系统，从⽽维持整个系统的稳定性稳定性设计和24个稳定性模式，是混沌⼯程“维稳”8步法的关键 62
63.