知名公司的混沌工程实践有：谷歌的DiRT计划（灾难恢复测试，已经进行了数千次），Slack的灾难剧场，微软云平台混沌工程等。很多公司把混沌工程实验做成“Game Day”，用游戏比赛的有趣竞争状态来进行混沌实验，而不是制造如临大敌的气氛。
混沌工程的系统方法、原则和步骤，不止应用于分布式大型软件，也应用于软硬件一体的互联系统，如汽车自动驾驶系统。混沌工程也应用到了网络安全领域。
本文详细介绍各大企业实践混沌工程的优秀流程，经验教训，人为阻力，人和组织的能力提升，我们能从中学习到一些宝贵的洞见。
演练前须知
1、设计模式的容错性
始终让备用容量在线，然后考虑如何让出故障的计算机从服务中移除，进一步实现自动替换故障机器。整个替换的耗时短暂且合理，重试次数合理。
2、保持数据持久性
所有演练规划和涉及的故障都必须确保数据不会丢失。因此可能需要保留额外的数据副本。
3、高效协作和开放心态
当这些人讨论灾难实验计划时，一些被孤立的知识就能浮现出来，对某个人而言显而易见的漏洞，对其他人则是不确定的风险。这个讨论环节立马就获得收益，相关的假说和实验就没有必要安排了，先解决该漏洞再说。
混沌工程在高效协作下最有价值。但混沌工程团队对其他人的系统进行实验，双方很可能会形成冲突关系，导致混沌工程遭到拒绝。
如果混沌工程师的心态是帮助其他团队，并通过工具提供支持，那冲突就能大大降低。混沌工程参与者就拥有对系统可靠性的共同所有权。
如果发现系统漏洞的证据都被锁定在专有系统或专有协议中，其真实价值就会被损害，所以应该遵循开放的原则来实践混沌工程，鼓励开放培训资源、获取权限、同行评审、方法论、源代码和数据。
灾难剧场演练流程
每次演练都始于担忧。例如，如果一个园区因为地震，和其他园区发生通信中断，会发生什么？
针对故障引入后会发生什么，建立可靠的稳态假说。将所有专家和感兴趣的人聚集在一个房间或视频会议（包含上下游依赖组件的工程师），有助于缓解混乱。可以邀请管理层参与灾难剧场，得到他们的支持。
演练的准备工作如果没有确认就不要启动演练，它包括：
- 本次演练的学习目标是什么？如何评估从演练得到的价值？
- 初期进行灾难实验时，先从小处着手，以尽量小的单元作为目标。再逐步加大规模。
- 实验安排的时机，是否考虑了特定场景，比如具有潜在意外行为的新特性/新子系统正在发布，新的基础设施正在引入？
- 在哪些服务区域/机器引入故障，如何模拟故障？实验流量是否足够让故障被检测出来？
- 针对注入的故障，会发生传递性故障么？会传递到什么范围（爆炸半径）？
- 可观察性如何保障，仪表盘在哪看？能快速检测哪些告警，日志和指标？推荐指标有线上问题工单数，服务出错率，延迟，自动容量伸缩耗时，资源占有率等。
- 识别应对故障的冗余和自动补救机制，以及执行手册。
- 预留充分的演练时间，让所有人能听清指令和讨论。
- 公开发布演练公告，鼓励关注。让值班同学密切监控。
- 演练时间通常要错开重大假期和公司各种年度活动的安排。
- 指定一个经验丰富的主持人来指导混沌工程的全流程。
- 指定过程记录员，记录故障发生及解决的事件、跟踪行动和时间。
- 其他可选角色包括：执行命令者，观察者，协调者等。
演练过程须知：
- 如果发生计划偏移，出现对客户的意外故障，则终止实验。
- 把演练故障当成真实停机事故一样对待
- 尽可能一次只测试一个假说，并把自动化反应和人的反应区分开来。注意一个假说也可以是多个故障同时注入的组合。
- 不要开发使实例失效的新方法，掩盖了现有失效行为的根因。
- 演练结束时，参会者花一点时间进行即时反思。并在会后为大家汇报演练发现的事实。让更多人了解组织可以使用哪些技术来容忍生产环境的各种故障，为系统可靠性和开发环境质量提出建议。
演练帮助这些不常合作的参会者，朝着改善系统安全性的目标共同努力，当事故真正发生时就能非常高效的协作。
同时，反思我们如何让用户注意不到故障的发生，我们的盲区在哪里？
哪些手工行为可以自动化。哪些行为不能，也不应该自动化？新的自动化除了付出成本，也可能会给运维工程师带来新的任务行动。可高效自动化操作的系统往往是脆弱的，允许低效率有时是个好事，人们有足够的时间针对未预期故障制定补救决策。
演练是系列化的，当漏洞被发现，我们会规划再次演练以验证补救措施是否生效。
常见的灾难测试类型与启发
场景一：异常大的流量峰值导致服务的平均延迟，但是不会违背SLO。
当被服务用户足够多时，哪怕没有承诺的合同，用户也会把稳定服务下的性能看作应当如此（即SLO-隐形合同）。
场景二：非关键后端服务发生故障，不会导致连锁反应失控。
通过大量故障注入测试，尽可能发现关键的依赖关系，建立“如果失效后发生什么”的充分认知。
场景三：特定网络区域中的计算资源意外丢失。
对于分布式系统，流量高峰达到多少就应该考虑紧急情况的资源分配？确保团队能自如地转移容量和主备切换。
场景四：数据损坏时，能从系统的最新备份中还原。
确保恢复过程正确，备份可以正常工作，这个过程是否发生数据不一致问题，如何处理？
场景五：区域性的网络故障导致机器离线。
应该从不同大小的规模对网络故障进行测试，通过精心设计的防火墙规则，证明系统的容忍故障能力。
场景六：关闭告警组件后，故障注入行为能否被发现？
场景七：所有系统都重启，能否尽快重新开机并正常服务？
灾难该如何总结？