从1到100：混沌工程实践的可视化与平台化 黄帅 191018

2020-03-01 267浏览

  • 1.从 1 到 100： 混沌工程实践的可视化与平台化 黄帅 亚马逊AWS专业服务部 资深云架构顾问
  • 2.自我介绍
  • 3.自我介绍 • 黄帅 [Henry Huang] - 云架构咨询顾问 • 来自亚马逊 AWS 专业服务部 • 负责企业级客户的云架构设计和优化 • 近来专注于混沌工程实验设计和落地实施 * AWSre:Invent2017, 2018 讲师 * AWSre:Inforce2019 讲师 * QCon Beijing 2019 讲师 @henrysher
  • 4.小小调查 • 听过混沌工程的 (请举手) • 有在实践混沌工程的 (请举手) • 听过QCon北京专题的 (请举手)
  • 5.目录 • 故障简史 – 阿波罗登月 • 十年演进，重塑混沌 • 混沌工程 从 1 到 100 * 混沌工程实验场景的模版化 * 混沌工程的平台化 * 混沌工程的可视化 * 混沌工程的游戏日计划
  • 6.故障简史 – 阿波罗登月
  • 7.“ Everything fails, all the time ” -- Werner, Vogels (CTO, Amazon.com)source:https://de.wikipedia.org/wiki/Werner_Vogels_(Informatiker)#/media/Datei:Wernervogels_ddp.jpg
  • 8.[ 1970年 阿波罗13号 ] 2号氧气罐的爆 炸，所有氧气存储将在3个小时内消失， 同时也将失去水、电力和推进系统。 你永远不知道会发生什么事 -- 吉姆·洛威尔（Jim Lovell）source:https://history.nasa.gov/afj/ap13fj/08day3-problem.html1961–1972
  • 9.自我介绍 玛格丽特·汉密尔顿 最早提出软件工程的概念，在阿波罗登月计划中负 责软件系统开发。 有一次，她的女儿在模拟舱玩的时候不小心按错了 键。她开始思考，既然故障总是会发生，提前进行 故障演练模拟就变得非常重要。 类似的事在阿波罗8号发生之后，她开启了最早的 故障场景模拟测试。source:https://commons.wikimedia.org/wiki/File:Margaret_Hamilton_-_restoration.jpg
  • 10.十年演进，重塑混沌
  • 11.十年前，混沌工程的先驱遇到了什么困境？ 十年后，为何我们开始热烈地讨论“混沌工程”？
  • 12.自我介绍 由于施工 导致光纤被切断source:https://www.slideshare.net/AmazonWebServices/leadership-session-networking-net209l-aws-reinvent-2018
  • 13.自我介绍 由于垃圾箱火灾 导致光纤被损坏source:https://www.slideshare.net/AmazonWebServices/leadership-session-networking-net209l-aws-reinvent-2018
  • 14.软件可以用新技术实现弯道超车 可是，故障不会 随之，消失殆尽 收益 入云阶段 (Stage of Adoption) 传统的故障防治法 再造 软件变得 … • 分布式化 • 无状态化 • 迭代演进 • 快速变化 • 非常复杂 项目 云上现代应用技术 • 敏捷管理 • 云原生架构 • DevOps实践 落 卸下 后技术欠债 传统的故障 防治方法 基础 迁移 时间 • 几乎都是单流程的 • 有状态依赖的 • 静态的 • 为预防设计 • 比较复杂
  • 15.混沌工程的时机与机遇 • 随着敏捷开发、DevOps实践、云原生架构和治理的出现，极大地提升了应 用交付的能力，缩短了业务上市周期。 • 业务敏捷化、技术迭代化的同时，还必须保证业务持续的高可用性和稳定性， 过去传统的灾备方式已无法跟上这个节奏。 • 混沌工程正是因应这个挑战，主动注入故障，以期提前发现潜在问题，迭代 改进架构和运维方式，最终实现业务韧性。
  • 16.如果你不提早发现和解决问题（引入混沌工程） 最后问题会来（周末／半夜）解决你
  • 17.系统架构的本质演进 • 脆弱系统难以修改。许多组织拥有无法更改 的应用程序，维护成本非常高，但是由于它 们对业务至关重要，因此仍然运行。 • 健壮系统可承受一定程度的压力而不会失去 其功能，但是如果压力和变化继续，则该系 统可能会带来损失。 • 韧性系统在设计和实现时考虑到压力和适应 性特征，从而应对更大的压力和变化，并最 大程度地提供价值。 • 反脆弱系统是一个智能系统，构建复杂有难 度，但一旦建立起来，将基于变更来驱动业 务，甚至能提供创新变更。source:https://developers.redhat.com/blog/2016/07/20/from-fragile-to-antifragile-software/
  • 18.混沌工程的目标 韧性架构 基础设施即代码 无状态应用 扩展性 冗余性 不可变基础设施 避免级联故障 转移 重试 超时 幂等 服务 拒绝 服务 切换 退避 机制 操作 降级 服务 熔断
  • 19.Netflix 混沌工程的投资回报率模型 过去一年中， 混沌工程提前发现了2次大故障和8次小故障，避免了整个组织大约70万美金的损失。 混沌工程团队，总共3个成员，薪水支出15万美金/人。 开展混沌工程实验，本身需要1万美金的成本。 请问，投资回报率是多少？ 投资回报率= 700,000-10,000-3*150,000 10,000+3*150,000 = 52.17% 5,600美元/分钟 引用自 Netflix 报告：The Business Case for Chaos Engineering, 2018 IT 故障引发的损失 引用自 Gartner 报告
  • 20.混沌工程：从 1 到 100
  • 21.混沌工程从 0 到 1：持续迭代的闭环体系
  • 22.混沌工程：从 1 到 100 • 混沌工程的实验场景：从1个增加到100个 • 实施混沌工程的业务应用数量：从1个增加到100个 • 实施混沌工程的人员数量：从1位增加到100位
  • 23.混沌工程：从 1 到 100 • 混沌工程的实验场景：从1个增加到100个 • 实施混沌工程的业务应用数量：从1个增加到100个 • 实施混沌工程的人员数量：从1位增加到100位
  • 24.新挑战：混沌工程实验场景的管理 第1个实验场景 实验准备 故障注入 指标搜集 结果判断 环境清理 第2个实验场景 实验准备 故障注入 指标搜集 结果判断 环境清理 … … … … … 实验准备 故障注入 指标搜集 结果判断 环境清理 … 第100个实验场景
  • 25.解决方案：混沌工程实验场景的模版化 • 模版类别（分类） • 合并同类项 +（实验场景模版） +（运行时配置） • 模版仓库（维护） 模版类别 实验场景模板
  • 26.运行时配置 以大文件故障注入场景为例 • 混沌工程实验名称 • [通用]未完成是否自动回退？ • [通用]等待实验完成的时间 • [专有]文件大小 • [通用]详细日志输出
  • 27.常见的混沌工程实验场景模版 模版类别 具体的实验场景模版（举例） 依赖型故障 AWS 托管服务异常：ELB／S3 / DynamoDB／Lambda … 主机型故障 EC2 实例异常终止，EC2 实例异常关闭，EBS 磁盘卷异常卸载，RDS 数据 库实例故障切换，ElastiCache 实例故障切换，容器异常终止，容器异常关 闭，… 操作系统内故障 CPU、内存、磁盘空间、IOPS 占满或突发过高占用，大文件，只读系统， 系统重启，熵耗尽，… 网络故障 网络延迟，网络丢包，DNS 解析故障，DNS 缓存毒化，VIP 转移，网络黑 洞，… 服务层故障 不正常关闭连接，进程被杀死，暂停／启用进程，内核奔溃，… 请求拦截型故障 异常请求，请求处理延迟，…
  • 28.新挑战：混沌工程实验数量级增长 混沌工程实验总数 = 应用数量 X 每个应用的实验数量 2,000 20 实验总数的增加会带来 • 实验的时间开销 • 实验的资源开销 • 实验的管理开销 100
  • 29.解决方案：混沌工程的平台化 混沌工程平台化的功能要求 （Goblin 实验平台） Goblin 是欧洲中世纪传说的一个小怪物，调皮且贪玩。 他们经常具有类似于童话般的魔法能力。
  • 30.从1到100：混沌工程的平台化 • • • • • • • • • • 基本要求 业务指标观测服务 流量生成服务 故障注入服务 护栏服务 暂停服务 改进方案推荐服务 流水线服务 告警服务 权限管理服务
  • 31.Goblin 实验平台 * 基本要求 • 能运行实验 • 能观测指标 • 失败能警报 • 可暂停实验
  • 32.业务指标观测服务
  • 33.观测指标的设计 • 指标类型 * 业务性指标：价值最大，探测难度最大 * 应用层指标：健康状况 * 基础设施指标：较易获取，只反映基础设施的运行状况 • 指标对照 * 应定义指标的稳定状态进行对照 * 如无法准确定义稳定状态，则使用多个指标的阈值联合进行对照 • 指标观测和记录系统
  • 34.流量生成服务 • 生产环境 * 使用真实的用户流量（或分支） • 非生产环境 * 使用脱敏的用户流量（镜像） * 制造测试用的流量 o 流量分支 o 流量镜像 o 流量生成
  • 35.故障注入服务 • 基于 Host 的 Agent • 基于 Guest OS 的 Agent • 基于 程序虚拟机 的 Agent（JVM） • 无 Agent （SSH，API Call 等等）
  • 36.AWS上故障注入的简单示例 JSON Templates JSON EC2 Chaos Toolkit AWS 服务 API Jenkins 流水线配置 运行时配置 AWS System Manager Amazon Elasticsearch Service 场景模版 Amazon S3 RDS Linux
  • 37.护栏服务 常见的护栏作用 护栏，又称“保护性防护”，在一般情况 下，是一个边界部件，以防止危险或阻止 进入危险区域为主要目的。 混沌工程中的护栏服务 故障注入时，护栏服务将侦测混沌工程实 验的破坏程度，以最大程度地减小破坏半 径为目标。当实验几乎要影响到真实用户 体验时，触发混沌工程实验的暂停服务。
  • 38.暂停服务 暂停服务启动后，将停止混沌工程实验： • • • • 进行环境清理与恢复 保障真实用户的体验 最大程度地减少破坏半径 与护栏服务配合使用
  • 39.改进方案推荐服务 • 混沌工程实验的最终目标 （优化应用架构，促进业务韧性） • 没有改进方案，等于实验白做了 （根本原因分析 改进方案推荐）
  • 40.流水线服务 • 流程化 • 自动化 • 定期化 • 透明化
  • 41.告警服务
  • 42.权限管理服务 • 权限管理是混沌工程的重中之重 !!! （混沌工程实验会用于生产环境） • 混沌工程的主要权限管理范围 +（故障注入方式对资源的修改权限） +（指标收集和观测权限） +（告警触发权限） +（护栏服务和暂停服务触发权限） +（流水线触发和审批权限） +（… …）
  • 43.Goblin Architecture Dev Team Application Service Global Monitoring Service Global Analytics Interface Goblin Load Generator Service Global Notification Service Goblin Injection Service Goblin Guardian Service Goblin Core Global Permission Mgmt Service Goblin Pipeline Interface Regularly Goblin Assessment Service Goblin Red Team Regularly Goblin Scenarios Global Pipeline Service
  • 44.混沌工程：从 1 到 100 • 混沌工程的实验场景：从1个增加到100个 • 实施混沌工程的业务应用数量：从1个增加到100个 • 实施混沌工程的人员数量：从1位增加到100位
  • 45.新挑战：混沌工程效果评估的复杂性 混沌工程实验结果数 = 应用数量 X 每个应用的实验结果数 10,000 100 100 实验结果数的增加会带来 • 实验效果评估的复杂度
  • 46.解决方案：混沌工程的可视化要求 混沌工程的成熟度评估模型 混沌工程的自动式可视化 Goblin 是欧洲中世纪传说的一个小怪物，调皮且贪玩。 他们经常具有类似于童话般的魔法能力。
  • 47.混沌工程可行性评估模型
  • 48.混沌工程实验成熟度等级 成熟度等级 1级 2级 3级 4级 5级 已实现韧性架构 架构抵御故障的能力 无抵御故障的能力 一定的冗余性 冗余且可扩展 已使用可避免级联故障 的技术 实验指标设计 无系统指标监控 实验结果只反映系统状 态指标 实验结果反映应用的健 康状况指标 实验结果反映聚合的业 务指标 可在实验组和控制组之 间比较业务指标的差异 在生产环境中运行实验 包括生产在内的任意环 境都可以运行实验 自动结果分析，自动终 止实验 全自动的设计、执行和 终止实验 实验框架和持续发布工 具集成 工具支持交互式的比对 实验组和控制组 可注入如对系统的不同 使用模式、返回结果和 状态的更改等类型的事 件 实验环境选择 只敢在开发和测试环境 中运行实验 可在预生产环境中运行 实验 实验自动化能力 全人工流程 利用工具进行半自动运 行实验 实验工具使用 未在生产环境中，用复 制的生产流量来运行实 验 自助式创建实验，自动 运行实验，但需要手动 监控和停止实验 无实验工具 采用实验工具 故障注入场景 爆炸半径范围 只对实验对象注入一些 简单事件，如突发高 CPU高内存等等 可对实验对象进行一些 较复杂的故障注入，如 EC2实例终止、可用区 故障等等 对实验对象注入较高级 的事件，如网络延迟 对实验组引入如服务级 别的影响和组合式的故 障事件 环境恢复能力 无法恢复正常环境 可手动恢复环境 可半自动恢复环境 部分可自动恢复环境 韧性架构自动恢复 可通过实验工具持续收 集实验结果和报告，并 完成简单的故障原因分 析 实验结果可预测收入损 失、容量规划、区分出 不同服务实际的关键程 度 实验结果整理 没有生成的实验结果， 需要人工整理判断 使用实验框架 可通过实验工具的到实 可通过实验工具持续收 验结果，需要人工整理、 集实验结果，但需要人 分析和解读 工分析和解读
  • 49.混沌工程实验接纳指数 接纳指数 描述 1级 公司重点项目不会进行混沌工程实验； 只覆盖了少量的系统； 公司内部基本上对混沌工程实验了解甚少； 极少数工程师尝试且偶尔进行混沌工程实验。 2级 混沌工程实验获得正式授权和批准； 由工程师兼职进行混沌工程实验； 公司内部有多个项目有兴趣参与混沌工程实验； 极少数重要系统会不定期进行混沌工程实验。 3级 成立了专门的混沌工程团队； 事件响应已经集成在混沌工程实验框架中以创建对应的回归实验； 大多数核心系统都会定期进行混沌工程实验； 偶尔以Game Day的形式，对实验中发现的故障进行复盘验证。 4级 公司所有核心系统都会经常进行混沌工程实验； 大多数非核心系统也都会经常进行混沌工程实验； 混沌工程实验是工程师日常工作的一部分； 所有系统默认都要参与混沌工程实验，不参与需要特殊说明。
  • 50.韧性分数 • 韧性（Resilience）是指软件通过适度降级和快速恢复而在遇到故障 时保持可用性的能力。 • 只能通过在遇到故障情况时分析应用程序的行为来衡量软件的韧性。 • 混沌工程实验用于验证是否已使用预防故障的最佳实践以及软件行为 是否已达到韧性目标。 • 韧性分数是一种报告机制，用于衡量服务对故障的韧性。 最佳实践采纳情况 存在的可用性风险 混沌工程实验成熟度等级模型
  • 51.混沌工程成熟度等级 - 量化蜘蛛图 Security Frequency Infrastructure Injection Application Injection Availability Environment Selection
  • 52.常见的混沌工程实验场景模版 模版类别 具体的实验场景模版（举例） 依赖型故障 AWS 托管服务异常：ELB／S3 / DynamoDB／Lambda … 主机型故障 EC2 实例异常终止，EC2 实例异常关闭，EBS 磁盘卷异常卸载，RDS 数据 库实例故障切换，ElastiCache 实例故障切换，容器异常终止，容器异常关 闭，… 操作系统内故障 CPU、内存、磁盘空间、IOPS 占满或突发过高占用，大文件，只读系统， 系统重启，熵耗尽，… 网络故障 网络延迟，网络丢包，DNS 解析故障，DNS 缓存毒化，VIP 转移，网络黑 洞，… 服务层故障 不正常关闭连接，进程被杀死，暂停／启用进程，内核奔溃，… 请求拦截型故障 异常请求，请求处理延迟，…
  • 53.混沌工程可视化示例
  • 54.混沌工程：从 1 到 100 • 混沌工程的实验场景：从1个增加到100个 • 实施混沌工程的业务应用数量：从1个增加到100个 • 实施混沌工程的人员数量：从1位增加到100位
  • 55.新挑战：混沌工程技能和流程培训
  • 56.游戏日计划（Game Day） 混沌工程的“游戏日计划”是一个基于 团队的交互式和开放式的学习与练习。 旨在测试系统中模拟各种事件响应的流 程，比如故障发生、被侵入、扩展要求 等等。目的是训练团队的响应能力以及 建立如何应对的“肌肉记忆 ”。 AWS GameDay
  • 57.总结
  • 58.混沌工程的时机和机遇 • 随着敏捷开发、DevOps实践、云原生架构和治理的出现，极大地提升了应 用交付的能力，缩短了业务上市周期。 • 业务敏捷化、技术迭代化的同时，还必须保证业务持续的高可用性和稳定性， 过去传统的灾备方式已无法跟上这个节奏。 • 混沌工程正是因应这个挑战，主动注入故障，以期提前发现潜在问题，迭代 改进架构和运维方式，最终实现业务韧性。
  • 59.从1到100：混沌工程的模版化 • 模版类别（分类） • 合并同类项 +（实验场景模版） +（运行时配置） • 模版仓库（维护） 模版类别 具体的实验场景模版（举例） 依赖型故障 AWS 托管服务异常：ELB／S3 / DynamoDB／Lambda … 主机型故障 EC2 实例异常终止，EC2 实例异常关闭，EBS 磁盘卷异常卸 载，RDS 数据库实例故障切换，ElastiCache 实例故障切换， 容器异常终止，容器异常关闭，… 操作系统内故障 CPU、内存、磁盘空间、IOPS 占满或突发过高占用，大文件， 只读系统，系统重启，熵耗尽，… 网络故障 网络延迟，网络丢包，DNS 解析故障，DNS 缓存毒化，VIP 转移，网络黑洞，… 服务层故障 不正常关闭连接，进程被杀死，暂停／启用进程，内核奔 溃，… 请求拦截型故障 异常请求，请求处理延迟，…
  • 60.从1到100：混沌工程的平台化 • • • • • • • • • • 基本要求 业务指标观测服务 流量生成服务 故障注入服务 护栏服务 暂停服务 改进方案推荐服务 流水线服务 告警服务 权限管理服务
  • 61.从1到100：混沌工程的可视化 • 韧性（Resilience）是指软件通过适度降级和快速恢复而在遇到故障 时保持可用性的能力。 • 只能通过在遇到故障情况时分析应用程序的行为来衡量软件的韧性。 • 混沌工程实验用于验证是否已使用预防故障的最佳实践以及软件行为 是否已达到韧性目标。 • 韧性分数是一种报告机制，用于衡量服务对故障的韧性。 最佳实践采纳情况 存在的可用性风险 混沌工程实验成熟度等级模型
  • 62.从1到100：混沌工程的游戏日计划 混沌工程的“游戏日计划”是一个基于 团队的交互式和开放式的学习与练习。 旨在测试系统中模拟各种事件响应的流 程，比如故障发生、被侵入、扩展要求 等等。目的是训练团队的响应能力以及 建立如何应对的“肌肉记忆 ”。 AWS GameDay
  • 63.
  • 64.