2021 STATE OF CHAOS ENGINEERING
在过去的十二年里，我有机会参与并见证了混沌工程的发展。出身卑微，最常遇到的问题是“你为什么要这样做？”到今天的位置，帮助确保世界顶级公司的可靠性，这是一段相当长的旅程。
我第一次开始实践这门学科，早在它有名字之前几年，在亚马逊，我们的工作就是防止零售网站宕机。当我们取得成功时，Netflix 写了他们关于 Chaos Monkey 的规范博客文章（十年前的今年 7 月）。这个想法成为主流，许多工程师都被迷住了。在亚马逊完成任务后，我急忙加入 Netflix，深入研究这个领域。我们能够进一步推动艺术发展，构建跨越整个 Netflix 生态系统的以开发人员为中心的解决方案，最终带来另外 9 个可用性和世界知名的客户体验。
五年前，我的联合创始人 Matthew Fornaciari 和我创立了 Gremlin，其使命很简单：建立更可靠的互联网。我们都欣喜若狂地看到这次实践已经走了多远。社区中的许多人都渴望获得更多关于如何最好地利用这种方法的数据，因此我们很自豪地展示了第一份混沌工程状态报告。
全球的工程团队使用 Chaos Engineering 故意将危害注入他们的系统、监控影响并修复故障，以免对客户体验产生负面影响。这样做，他们避免了代价高昂的停机，同时减少了 MTTD 和 MTTR，让他们的团队为未知做好准备，并保护客户体验。事实上，Gartner 预计，到 2023 年，将混沌工程实践作为 SRE 计划一部分的 80% 的组织将其平均解决时间 (MTTR) 减少 90%。我们从首份混沌工程状态报告中看到了同样的相似之处：表现最好的混沌工程团队拥有四个 9 的可用性，MTTR 不到一小时。
科尔顿安德鲁斯
格雷姆林首席执行官
主要发现
- 增加可用性和减少 MTTR 是混沌工程最常见的两个好处
- 经常进行混沌工程实验的团队有 >99.9% 的可用性
- 23% 的团队的平均解决时间 (MTTR) 不到 1 小时，60% 的团队不到 12 小时
- 网络攻击是最常运行的实验，与报告的主要故障一致
- 虽然仍然是一种新兴实践，但大多数受访者 (60%) 至少运行过一次混沌工程攻击
- 34% 的受访者在生产环境中进行混沌工程实验
Things break
调查显示，前 20% 的受访者拥有超过四个 9 的服务，这是一个令人印象深刻的水平。 23% 的团队的平均解决时间 (MTTR) 不到 1 小时，60% 的团队平均解决时间 (MTTR) 不到 12 小时。
您的服务的平均可用性是多少？
| 可靠性 | 占比 | |
| <=99% | 42.5% | |
| 99.5%-99.9% | 38.1% | |
| >=99.99% | 19.4% |
每月平均高严重性事件数 (Sev 0 和 1)
| 1-10 | 81.4% | |
| 10-20 | 18.6% |
您的平均解决时间 (MTTR) 是多少？
| MTTR | 占比 |
| <1 hour | 23.1% |
| 1 hour - 12 hours | 39.8% |
| 12 hours - 1 day | 15.5% |
| 1 day - 1 week | 15.2% |
| > 1 week | 0.5% |
| I don't know | 5.9% |
我们所做的其中一项更有益的事情是每天进行红色与蓝色攻击。 我们让平台团队介入，对我们和我们的服务进行攻击，并将其视为真实的生产事件，通过响应并查看我们所有的运行手册并确保我们被覆盖。
当事情确实发生时，最常见的原因是错误的代码推送和依赖问题。 这些不是相互排斥的。 来自一个团队的错误代码推送可能会导致另一个团队的服务中断。 在团队拥有独立服务的现代系统中，测试所有服务的故障恢复能力非常重要。 运行基于网络的混沌实验，例如延迟和黑洞，确保系统解耦并且可以独立失败，从而最大限度地减少服务中断的影响。
您的事件 (SEV0 和 1) 的百分比是由以下原因引起的：
| <20% | 21-40% | 41-60% | 61-80% | >80% | |
| 错误的代码部署（例如，部署到生产环境的代码中的错误导致事件） | 39% | 24% | 19% | 11.8% | 6.1% |
| 内部依赖问题（非 DB）（例如，贵公司运营的服务中断） | 41% | 25% | 20% | 10.1% | 3.7% |
| 配置错误（例如，云基础设施或容器编排器中的错误设置导致事件） | 48% | 23% | 14% | 10.1% | 5.2% |
| 网络问题（例如，ISP 或 DNS 中断） | 50% | 19% | 13% | 15.7% | 1.7% |
| 第 3 方依赖问题（非 DB）（例如，与支付处理器的连接断开） | 48% | 23% | 13% | 14.3% | 1.7% |
| 托管服务提供商问题（例如，云提供商 AZ 中断） | 61% | 14% | 9% | 12.5% | 3.9% |
| 机器/基础设施故障（本地）（例如，停电） | 64% | 14% | 6% | 12% | 4.4% |
| 数据库、消息传递或缓存问题（例如，导致事件的数据库节点丢失） | 58% | 18% | 18% | 5.2% | 1.2% |
| 未知 | 66% | 10% | 15% | 7.4% | 1% |
谁知道
可用性监控因公司而异。例如，Netflix 的流量非常稳定，他们可以使用服务器端每秒的视频启动次数来发现中断。与预测模式的任何偏差都表示中断。 Google 将真实用户监控与窗口结合使用来确定单个中断是否会产生重大影响，或者多个小事件是否会影响服务，从而对事件的原因进行更深入的分析。很少有公司像 Netflix 和 Google 那样拥有一致的流量模式和复杂的统计模型。这就是为什么使用综合监控的标准正常运行时间作为监控服务正常运行时间的最流行方法位于顶部，而许多组织使用多种方法和指标。我们惊喜地发现所有受访者都在监控可用性。这通常是团队为积极改善应用程序中的客户体验而采取的第一步。
您使用什么指标来定义可用性？
| 可用性指标 | 占比 |
| 错误率（失败请求/总请求） | 47.9% |
| 延迟 | 38.3% |
| 订单/交易与历史预测 | 21.6% |
| 成功请求/总请求 | 44% |
| 正常运行时间/总时间段 | 53.3% |
您如何监控可用性？
| 监控方式 | 占比 |
| 真实用户监控 | 37.1% |
| 健康检查/合成 | 64.4% |
| 服务器端响应 | 50.4% |
在查看谁收到有关可用性和性能的报告时，人们越接近操作应用程序，他们收到报告的可能性就越大也就不足为奇了。 我们相信，随着构建和运营的思维方式在组织中变得普遍，DevOps 将运维和开发紧密结合在一起的趋势是使开发人员与运维保持一致。 我们还相信，随着数字化程度的提高和在线用户体验变得更加重要，我们将看到接收可用性和绩效报告的 C 级员工的百分比增加。
谁监控或接收可用性报告？
| CEO | 15.7% |
| CFO or VP of Finance | 11.8% |
| CTO | 33.7% |
| VP | 30.2% |
| Managers | 51.1% |
| Ops | 61.4% |
| Developers | 54.5% |
| Other | 1.2% |
谁监控或接收性能报告？
| CEO | 12% |
| CFO or VP of Finance | 10.6% |
| CTO | 36.1% |
| VP | 28.3% |
| Managers | 51.8% |
| Ops | 53.8% |
| Developers | 54.1% |
| Other | 2% |
最好表现者
表现最好的人有 99.99% 以上的可用性和不到一小时的 MTTR（上面突出显示）。 为了获得这些令人印象深刻的数字，我们调查了团队使用的工具。 值得注意的是，自动缩放、负载平衡器、备份、部署的选择推出以及通过运行状况检查进行监控在顶级可用性组中更为常见。 其中一些，例如多区域，是昂贵的，而其他的，例如断路器和选择推出，是时间和工程专业知识的问题。
始终进行混沌实验的团队比从未进行过实验或临时进行实验的团队具有更高的可用性水平。 但 ad-hoc 实验是实践的重要组成部分，可用性 > 99.9% 的团队正在执行更多的 ad-hoc 实验。
混沌工程实验的频率（按可用性）
| Never performed an attack | Performed ad-hoc attacks | Quarterly attacks | Monthly attacks | Weekly attacks | Daily or more frequent attacks | |
| >99.9% | 25.7% | 28.4% | 16.2% | 6.8% | 17.6% | 5.4% |
| 99%-99.9%% | 35.7% | 25% | 11.6% | 10.3% | 8.5% | 8.9% |
| <99%% | 49.4% | 18.1% | 13.3% | 8.4% | 8.4% | 2.4% |
按可用性使用工具
| >99.9% | 99%-99.9% | <99% | |
Autoscaling |
65% | 52% | 43% |
| DNS failover/elastic IPs | 49% | 33% | 24% |
| Load balancers | 77% | 64% | 71% |
| Active-active multi-region, AZ or DC | 38% | 29% | 19% |
| Active-passive multi-region, AZ, or DC | 45% | 34% | 30% |
| Circuit breakers | 32% | 22% | 16% |
| Backups | 61% | 46% | 51% |
| DB replication | 51% | 47% | 37% |
| Retry logic | 41% | 33% | 31% |
| Select rollouts of deployments (Blue/Green, Canary, feature flags) | 51% | 36% | 27% |
| Cached static pages when dynamic unavailable | 26% | 26% | 19% |
| Monitoring with health checks | 70% | 58% | 53% |
混沌工程的演变
2010 年，Netflix 将 Chaos Monkey 引入他们的系统。 这种节点的伪随机故障是对实例和服务器随机故障的响应。 Netflix 希望团队为这些故障模式做好准备，因此他们加快了流程，要求对实例中断具有弹性。 它创建了对可靠性机制的测试，并迫使开发人员在构建时考虑到失败。 基于该项目的成功，Netflix 开源了 Chaos Monkey，并创建了 Chaos Engineer 角色。 从那时起，混沌工程已经发展到遵循科学过程，并且实验已经扩展到主机故障之外，以测试堆栈上下的故障。
谷歌搜索“混沌工程”
| 年份 | 搜索次数 |
| 2016 | 1290 |
| 2017 | 6990 |
| 2018 | 19100 |
| 2019 | 24800 |
| 2020 | 31317 |
对于失败中花费的每一美元，学习一美元的教训
-----“MASTER OF DISASTER”
------JESSE ROBBINS
2020 年，混沌工程成为主流，并成为 Politico 和彭博社的头条新闻。 Gremlin 举办了有史以来规模最大的混沌工程活动，有超过 3,500 名注册者。 Github 拥有超过 200 个混沌工程相关项目，拥有 16K+ 星。 最近，AWS 宣布他们自己的公开混沌工程产品 AWS 故障注入模拟器将于今年晚些时候推出。
Chaos Engineering today
混沌工程正变得越来越流行和改进：60% 的受访者表示他们已经运行过混沌工程攻击。 Chaos Engineering 的创建者 Netflix 和 Amazon 是尖端的大型组织，但我们也看到更成熟的组织和较小的团队采用。 使用混沌工程的团队的多样性也在增长。 最初的工程实践很快被站点可靠性工程 (SRE) 团队采用，现在许多平台、基础设施、运营和应用程序开发团队正在采用这种实践来提高其应用程序的可靠性。 主机故障，我们归类为状态类型攻击，远不如网络和资源攻击流行。 我们已经看到了模拟与依赖项的丢失连接或对服务的需求激增的情况。 我们还看到更多的组织将他们的实验转移到生产中，尽管这还处于早期阶段。
使用 Gremlin 平台的 459,548 次攻击
68% 的客户使用 K8S 攻击
您的组织多久练习一次混沌工程？
| 每日或更频繁的攻击 | 每周攻击 | 每月攻击 | 每季度攻击 | 执行临时攻击 | 从未进行过攻击 | |
| >10,000员工 | 5.7% | 8% | 4.6% | 16.1% | 31% | 34.5% |
| 5,001-10,000 员工 | 0% | 13.2% | 18.4% | 21.1% | 23.7% | 23.7% |
| 1,001-5,000 员工 | 8.3% | 11.1% | 8.3% | 9.7% | 22.2% | 40.3% |
| 100-1,000 员工 | 10.9% | 10.9% | 8.6% | 10.9% | 22.7% | 35.9% |
| <100 员工 | 3.7% | 7.3% | 9.8% | 8.5% | 15.9% | 54.9% |
哪些团队参与了混沌实验？
| Application Developers | 52% |
| C-level | 10% |
| Infrastructure | 42% |
| Managers | 32% |
| Operations | 49% |
| Platform or Architecture | 37% |
| SRE | 50% |
| VPs | 14% |
您的组织中有多少百分比使用混沌工程？
| 百分比 | |
| 76%+ | 7.3% |
| 51-75% | 17.7% |
| 26-50% | 21% |
| <25% | 54% |
你在什么环境下进行过混沌实验？
| Dev/Test | 63% |
| Staging | 50% |
| Production | 34% |
按类型划分的攻击百分比
| Network | 46% |
| Resource | 38% |
| State | 15% |
| Application | 1% |
按目标类型划分的攻击百分比
| Host | 70% |
| Container | 29% |
| Application | 1% |
混沌实验结果
混沌工程最令人兴奋和最有价值的方面之一是发现或验证错误。 这种做法可以更容易地在未知问题影响客户之前发现它们并确定事件的真正原因，从而加快修补过程。 对我们调查的回复中显示的另一个主要好处是更好地理解架构。 运行混沌实验有助于识别对我们的应用程序产生不利影响的紧密耦合或未知依赖关系，并且通常会消除创建微服务应用程序的许多好处。 从我们自己的产品中，我们发现客户经常发现事件、缓解问题并使用 Chaos Engineering 验证修复。 我们的调查受访者经常发现他们的应用程序在减少 MTTR 的同时提高了可用性。
使用混沌工程后，你体验到了什么好处？
| 提高可用性 | 47% |
缩短平均解决时间 (MTTR) mean time to resolution |
45% |
缩短平均检测时间 (MTTD) mean time to detection |
41% |
| 减少了交付到生产环境的错误数量 | 38% |
| 减少中断次数 | 37% |
| 减少页面数 | 25% |
混沌工程的未来
采用/扩展混沌工程的最大障碍是什么？
| 缺乏认识 | 20% |
| 其他优先事项 | 20% |
| 缺乏经验 | 20% |
| 时间不够 | 17% |
| 安全问题 | 12% |
| 害怕出事 | 11% |
采用混沌工程的最大障碍是缺乏意识和经验。紧随其后的是“其他优先事项”，但有趣的是，超过 10% 的人提到担心可能出现问题也是一个禁忌。确实，在实践混沌工程时，我们正在将故障注入系统，但使用遵循科学原理的现代方法，并有条不紊地将实验隔离到单一服务中，我们可以有意识地实践而不破坏客户体验。
我们相信混沌工程的下一阶段涉及向更广泛的受众开放这一重要的测试过程，并使其更容易在更多环境中安全地进行实验。随着实践的成熟和工具的发展，我们希望工程师和操作员能够更容易和更快地设计和运行实验，以提高其系统跨环境的可靠性——今天，30% 的受访者正在生产中运行混沌实验。我们相信，混沌实验将变得更有针对性和自动化，同时也变得更加普遍和频繁。
我们对混沌工程的未来及其在使系统更可靠方面的作用感到兴奋。
人口统计
本报告的数据源包括一项包含 400 多个回复的综合调查和 Gremlin 的产品数据。 调查受访者来自各种规模和行业，主要是软件和服务。 混沌工程的采用已经冲击了企业，近 50% 的受访者为员工人数超过 1,000 人的公司工作，近 20% 的受访者为员工人数超过 10,000 人的公司工作。
该调查强调了云计算的一个转折点，近 60% 的受访者在云中运行大部分工作负载，并使用 CI/CD 管道。 容器和 Kubernetes 正在达到类似的成熟度，但调查证实服务网格仍处于早期阶段。 最常见的云平台是 AWS，占比接近 40%，GCP、Azure 和本地云平台紧随其后，占比约为 11-12%。
400 多名合格的受访者
贵公司有多少员工？
| >10,000 | 21.4% |
| 5,001-10,000 | 9.3% |
| 1,001-5,000 | 17.7% |
| 100-1,000 | 31.4% |
| <100 | 20.1% |
你的公司几岁了？
| Over 25 years old | 25.8% |
| 10 to 25 years old | 32.9% |
| 2 to 10 years old | 27.3% |
| Less than 2 years old | 14% |
贵公司属于哪个行业？
| Software & Services | 50.2% |
| Banks, Insurance & Financial Services | 23.2% |
| Energy Equipment & Services | 0.7% |
| Retail & eCommerce | 18.3% |
| Technology Hardware, Semiconductors, & Related Equipment | 7.6% |
你的职位是什么？
| Software Engineer | 32.2% |
| SRE | 25.3% |
| Engineering Manager | 18.2% |
| System Administrator | 8.8% |
| Non-technical Executive (ex: CEO, COO, CMO, CRO) | 4.9% |
| Technical Executive (ex: CTO, CISO, CIO) | 10.6% |
云中占生产工作负载的百分比是多少？
| >75% | 35.1% |
| 51-75% | 23.1% |
| 25-50% | 21.4% |
| <25% | 20.4% |
使用 CI/CD 管道部署的生产工作负载的百分比是多少？
| >75% | 39.8% |
| 51-75% | 21.1% |
| 25-50% | 20.4% |
| <25% | 18.7% |
百分之几的生产工作负载使用容器？
| >75% | 27.5% |
| 51-75% | 19.9% |
| 25-50% | 23.6% |
| <25% | 29% |
百分之几的生产工作负载使用 Kubernetes（或其他容器编排器）？
| >75% | 19.4% |
| 51-75% | 22.4% |
| 25-50% | 18.4% |
| <25% | 39.8% |
百分之多少的生产环境路由利用了服务网格？
| >75% | 0.1% |
| 51-75% | 116.5% |
| 25-50% | 17.9% |
| <25% | 55.5% |
除了检查调查结果外，我们还汇总了有关 Gremlin 用户技术环境的信息，以了解哪些特定工具和堆栈层最常成为混沌工程实验的目标。 这些发现如下。
您的云提供商是什么？
| Amazon Web Services | 38% |
| Google Cloud Platform | 12% |
| Microsoft Azure | 12% |
| Oracle | 2% |
| Private Cloud (On Premises) | 11% |
你的容器编排器是什么？
| Amazon Elastic Container Service | 13% |
| Amazon Elastic Kubernetes Service | 19% |
| Custom Kubernetes | 16% |
| Google Kubernetes Engine | 12% |
| OpenShift | 6% |
您的消息传递提供者（ messaging provider）是什么？
| ActiveMQ | 5% |
| AWS SQS | 17% |
| Kafka | 25% |
| IBM MQ | 1% |
| RabbitMQ | 13% |
你的监控工具是什么？
| Amazon CloudWatch | 28% |
| Datadog | 13% |
| Grafana | 18% |
| New Relic | 9% |
| Prometheus | 18% |
你的数据库是什么？
| Cassandra | 5% |
| DynamoDb | 14% |
| MongoDB | 16% |
| MySQL | 22% |
| Postgres | 22% |
贡献者
Dynatrace
Dynatrace 提供软件智能以简化云复杂性并加速数字化转型。 借助自动和智能的大规模可观察性，我们的一体化平台可提供有关应用程序性能和安全性、底层基础架构以及所有用户体验的准确答案，使组织能够更快地创新、更有效地协作并交付更多 以更少的努力获得价值。
Epsagon
Epsagon 使团队能够立即可视化、理解和优化他们的微服务架构。 借助我们独特的轻量级自动仪表，消除了与其他 APM 解决方案相关的数据和手动工作方面的空白，从而显着减少了问题检测、根本原因分析和解决时间。
Grafana Labs
Grafana Labs 提供了一个围绕 Grafana 构建的开放且可组合的监控和可观察性平台，Grafana 是用于仪表板和可视化的领先开源技术。 超过 1,000 家客户（如 Bloomberg、JP Morgan Chase、eBay、PayPal 和 Sony）使用 Grafana Labs，全球有超过 600,000 个 Grafana 活跃安装。 商业产品包括 Grafana Cloud，一个集成了 Prometheus 和 Graphite（指标）的托管堆栈，Grafana Enterprise，一个具有企业功能、插件和支持的 Grafana 增强版； Loki（原木）和 Tempo（痕迹）与 Grafana； 和 Grafana Metrics Enterprise，它为大规模运行的大型组织提供 Prometheus 即服务。
LaunchDarkly
LaunchDarkly 由 Edith Harbaugh 和 John Kodumal 于 2014 年创立，是软件团队用来构建更好的软件、更快、风险更低的功能管理平台。 开发团队使用功能管理作为将代码部署与功能发布分开的最佳实践。 使用 LaunchDarkly，团队可以控制从概念到发布再到价值的整个功能生命周期。 每天为超过 1 万亿个功能标志提供服务，LaunchDarkly 被 Atlassian、Microsoft 和 CircleCI 的团队使用。
PagerDuty
PagerDuty, Inc. (NYSE:PD) 是数字运营管理领域的领导者。 在一个永远在线的世界中，各种规模的组织都信任 PagerDuty 可以帮助他们每次都为客户提供完美的数字体验。 团队使用 PagerDuty 实时识别问题和机会，并召集合适的人员更快地解决问题并在未来预防问题。 知名客户包括 GE、思科、基因泰克、艺电、Cox Automotive、Netflix、Shopify、Zoom、DoorDash、Lululemon 等。
本文：https://architect.pub/2021-state-chaos-engineering
