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

文字内容
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