在过去的十二年里，我有机会参与并见证了混沌工程的发展。出身卑微，最常遇到的问题是“你为什么要这样做？”到今天的位置，帮助确保世界顶级公司的可靠性，这是一段相当长的旅程。
我第一次开始实践这门学科，早在它有名字之前几年，在亚马逊，我们的工作就是防止零售网站宕机。当我们取得成功时，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% |
