随着云原生概念的兴起，越来越多的系统服务在往云原生演进，在演进阶段如何保障系统的稳定性和高可用性，是每个系统负责人都要关注的问题。通过混沌工程可以很好的解决这个问题，其发展至今，也被赋予了更多的意义，如提升故障应急效率、发现系统缺陷、降低故障复发率、提升用户体验等等，近几年混沌工程得到更多企业的关注。 ChaosBlade 是阿里巴巴开源的一款混沌工程实验执行工具，其易用性和丰富的场景受到大家的广泛关注。本次分享会围绕云原生架构，介绍 ChaosBlade 的设计、特性与实践，最后分享如何基于 ChaosBlade 搭建一个自动化的混沌实验平台。

听众受益

1. 了解云原生架构下混沌工程的价值； 

2. 了解 ChaosBlade 整体设计与新特性； 

3. 了解 ChaosBlade 在云原生架构下的实践； 

4. 了解如何基于 ChaosBlade 搭建混沌实验平台。 

Often chaos engineering is either used as a buzzword to get more VC funding or dreaded as a headache to operators and developers. “We create enough chaos just by releasing software!” But if we can understand the role of Chaos Engineering in regards to Resilience Engineering and take a methodical approach to how we inject system faults, not only will our insights be more actionable but we’ll also be able to build confidence in overall resilience and impact our teams less. In this talk I’ll cover Resilience & Reliability, Resilience & Chaos, focusing on the problem, minimizing your blast radius while also maximizing the insights, monitoring best practices for chaos tests and building enough confidence to test an entire system outage.

通常情况下，混沌工程给我们的印象不是被用来拉风险投资的流行词汇，就是让开发运维头疼的可怕存在。当然你也可以说：“我们仅仅通过发布软件就制造了足够的混乱！”但如果我们能够真正理解混沌工程在弹性工程中扮演的角色，并有条不紊地将故障注入系统，那么这个实验就更具可操作性，更能让我们对整个系统弹性建立信心，那么，团队遭受到的打击也就更少。这个演讲会涵盖弹性及可靠性，弹性及混沌的内容，聚焦于如何在减小爆炸半径的同时也获得更大的观察结果，监控混沌实验的实践，并在整个系统宕掉的时候有足够的信心。

随着敏捷开发、DevOps 实践、微服务架构和治理的出现，极大地提升了应用交付的能力，缩短了业务上市周期。新的挑战要求业务敏捷化、技术迭代化的同时，还必须保证业务持续的高可用性和稳定性，过去传统的灾备方式已无法跟上这个节奏。混沌工程正是因应这个挑战，主动注入故障以期提前发现潜在问题，迭代改进架构和运维方式，最终实现业务韧性。当然主动注入是有风险的，特别是当混沌工程用于生产中，海内外互联网公司近十年来进行了大量的实践探索。现在传统企业也都开始遇到这些互联网公司曾经经历过的问题，不过由于本身的组织、文化和运营方式的不同，这些公司是否能够应用混沌工程。今年上半年的 QCon 北京大会，我们回答了这个问题，并分享了 AWS 上从 0 到 1 的混沌工程实验设计和持续迭代的方法与经验。 

本次分享将在之前的基础上，继续探讨混沌工程从 1 到 100 的迭代过程，这中间遇到了哪些新挑战新问题以及我们如何应对。特别地，随着参与混沌工程的应用团队逐步增多，实验场景数量大幅度增加，如何保证其正常开展的同时加快迭代速度，实现混沌工程实践的透明化、可视化和自动化。

听众受益

1. 了解混沌工程从 1 到 100 过程中的新问题和新挑战； 
2. 了解混沌工程的迭代过程以及影响其迭代速度的主要因素； 
3. 了解如何实现混沌工程实践的可视化； 
4. 了解如何实现混沌工程实践的平台化。