1、云原生架构下的混沌工程实践阿里云智能事业群-高可用架构团队目录混沌工程三连问混沌工程是什么？为什么要实施混沌工程？怎样实施混沌工程？落地案例介绍未来展望混沌工程的概念2017.8月出版PRINCIPLES OF CHAOS ENGINEERINGChaos Engineering is the discipline of experimenting on a distributed systemin order to build confidence in the systems capabilityto withstand turbulent conditions in production

2、.混沌工程是在分布式系统上进行实验的学科,目的是建立对系统抵御生产环境中失控条件的能力以及信心。预计2019.6月上市我对混沌工程的理解一种拥抱失败的技术文化一套抽象严谨的实践原则一种主动防御的稳定性手段一个高速发展的技术领域混沌工程的起源数据中心单点故障业务上云水平扩展能力基础设施运维可靠第三方节点数增加故障率升高ChaosMonkey验证韧性能力源自Chaos Engineering书籍在过去五年左右的时间里，只有仅有的一次节点掉线影响了我们的服务。当时正是混乱猴子终止了一个由于部署失误而没有冗余的服务节点造成了问题。幸运的是，这个故障发生在白天工作时间，在这个故障的服务刚刚部署不久后，对

3、用户的影响也非常小。混乱猴子的美妙之处就在于此，它能尽可能地将服务节点失效的痛苦提到最前，同时让所有工程师在构建一个具有足够弹性应对失败的系统上，达成一个一致的目标。混沌工程原则从故障驱动到故障驱动故障管理活动保障故障应急稳定性度量混沌工程持续集成监控发现限流预案资损防控架构治理一个高速发展的技术领域小结混沌工程作为一个蓬勃发展的技术领域，体现了一种反脆弱的技术思想，提供了一套严谨的实践原则，帮助企业更主动的提升稳定性云迁移（Cloud-Migrate）云就绪（Cloud-Ready）云原生（Cloud-Native）企业上云的几个阶段打法保留原有系统，搭建新系统支持新业务平滑迁移原有系统正常

4、运行，逐渐进行优化和改造不破不立利用新技术和新思路搭建系统，替换老系统顾旧立新挑战稳定的服务质量友好的错误体验企业利益避免重大故障的发生提升组织的效能技术积累构建更具韧性的系统更快速的技术演进客户责任为什么要实施混沌工程减小业务损失，让重大风险在可控范围提前暴露提升系统弹性，持续验证系统对极端场景的容错能力增强团队信心，验证稳定性措施有效性，量化团队价值混沌工程的引入（0-1）结合技术架构，选择实验工具最小爆炸半径，控制实验风险混沌工程的推广（1-N）建立面向失败设计的技术文化围绕战略制定目标，围绕目标设计组织复用成熟产品，提升效能企业如何开始实施混沌工程？一款好的实验工具需要满足哪些条件？丰

5、富度资源、主机、容器、应用 易用性开发框架、实验工具、产品平台开放程度闭源、OpenAPI、支持扩展、开源集成方式代码依赖、架构依赖、无依赖多语言Java、Go、C+、语言无关 活跃状态已停滞、维护、活跃阿里混沌工程的技术演进路线延伸阅读：阿里电商故障治理和故障演练实践开源工具混沌之刃（ChaosBlade）ChaosBlade是一款遵循混沌实验模型，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，它的特点是操作简洁、无侵入、扩展性强。GitHub 地址：https:/ create dubbo delay-time 3000-consumer-service com.

6、example.HelloService-version 1.0.0blade create cpu fullload-cpu-count 4结束示例：blade destroy 6435335635bbaca5（实验ID）code:200,success:true,result:command:cpu fullload-cpu-count 4-debug false-help false控制爆炸半径，减小实施风险建立面向失败设计的技术文化面向失败设计，因为每一块硬盘，每一个业务系统，每一种技术组件都有出错的可能！分布式系统需要制定分级策略，防止非核心业务拖垮核心业务！工具系统需要优先实现容灾

7、！故障处理流程和人员能力也非常重要！围绕企业战略制定项目目标 服务可用性 异常体验满意度 API成功率 服务体验故障预防事故处理系统韧性 资损故障预防 历史故障覆盖率 监控发现率 故障处理时长 预案有效性 架构容灾 依赖治理 故障自愈 结合项目目标，设计组织结构强弱依赖破坏性测试资损演练容灾演练红蓝对抗故障演练预案演练突袭演练SRE测试研发技术支持项目经理运营GameDay通过平台能力，标准化实验流程准备(PAREPARE)执行(EXECUTE)验证(CHECK)恢复(RECOVER)计划PLAN执行DO记录RECORD分析ANALYSIS观察OBSERVE还原RECOVER混沌工程插件架构评

8、估、流量导入 实验场景模拟稳态数据拉取、验证实验恢复建设实验平台，提升规模化能力小结引入和推广混沌工程，您需要结合企业特点，选择适合当下的工具或产品；最小爆炸半径，控制实验风险；建立面向失败的技术文化，接受不确定性；围绕企业战略，有针对性的设计组织和实施；建设实验平台，提升规模化能力；新零售云服务云业务落地场景举例新零售业务稳定性的挑战挑战线下场景，用户对故障容忍度低无法彻底规避网络问题，尤其是门店网络要求云端服务要具备较高的可用性终端的异常提示要面向用户友好现场人员要熟悉处理手段难点如何证明稳定性措施有效性？如何减少实验对业务带来的影响？如何常态化的实施实验？最小化爆炸半径，实现常态化的实验

9、企业级分布式应用服务A企业级分布式应用服务A企业级分布式应用服务B分布式关系型数据库服务应用配置分布式关系型数据库服务分布式关系型数据库服务企业级分布式应用服务B应用配置企业级分布式应用服务D企业级分布式应用服务企业级分布式应用服务B企业级分布式应用服务D统一接入层统一接入层统一接入层统一接入层亲橙里店POS A亲橙里店POS B庆春店POS A云服务稳定性专有云混沌工程实践运行态运行态特定流不通黑洞/随机丢包系统异常内核异常服务交互运行环境运行时服务器交换机网络层网络层系统系统层层硬件硬件层层设备级别流量黑洞设备级别流量黑洞 SLOT级别流量黑洞级别流量黑洞随机流量丢弃随机流量丢弃网络延迟、

10、包乱序、丢包 NTP/YUM/DNS 异常文件系统ReadOnly内存页分配错误内核futex死锁模拟 Kernel Panic系统配置异常系统权限异常DPDK 网络异常网络异常磁盘磁盘IO Hang CPU/MEM/磁盘Inode 各类资源耗尽系统Load高 OOM用户态用户态CPU异常异常服务强制退出服务强制退出服务优雅退出服务优雅退出整机故障整机故障异常重启异常重启交换机交换机 上行上行/下行下行 端口（端口（RANGE）异常异常 服务器宕机服务器宕机/掉盘掉盘NVME SSD 异常异常PCIE Degrade特定流五元组流量不通特定流五元组流量不通特定特定IP流量不通流量不通 特定源和

11、目的访问单通特定源和目的访问单通Request 参数空参数空/特殊特殊Query/协议错误协议错误用户流量徒增用户流量徒增/雪崩雪崩Connect 超时超时/失败失败Connect 连接数满连接数满Response 异常异常系统参数异常系统参数异常网络设备单端口拥塞网络设备单端口拥塞K8S异常仿真异常仿真ECS IOhang 模拟模拟Docker异常仿真异常仿真内核级函数错误模拟内核级函数错误模拟RMDA 异常异常SPDK 异常异常云业务稳定性保障的挑战微服务容器开源组件云服务有什么有哪些第三方组件，用了哪些云服务，有哪些自开发的应用服务，他们之间的关系是什么样的，他们和底层的容器，云服务器的关系是什么样子的？做什么我的第三方组件，云服务和应用服务需要具备哪些高可用能力怎么做如何提高这些组件的高可用能力面向云业务的高可用服务阿里云菜单搜索 AHAS，免费公测中云业务混沌实验方案云原生业务（稳态分析）架构感知&组件识别架构组件分析云原生业务（稳态验证）白屏化式实验未来规划开源连接特性容器服务日志服务云监控其他架构感知方案故障演练限流降级高可用分析帮助云原生业务提升高可用能力的云服务（AHAS）社区建设口令：chaos