其实落地混沌工程的原因很简单，业务和技术的复杂性提升带来的不可控风险和成本越来越高。这些复杂性主要体现在这几个方面：

业务的迭代提速从日常的版本更新周期和采用的迭代模型就可见一斑。我14年刚入行时一般都是一个月一个版本，大多还是采用的瀑布或者双V模型。近几年看到的听到的业务迭代周期基本到了一周/双周一个版本，迭代模型也越来越多的变成了敏捷或者“公交车模型”。

应用系统架构的复杂度演变，从单体式架构到集群，再到分布式、微服务。面对线上服务稳定性挑战，最头疼的就是线上故障发生的时间和范围无法预测，故障发生后对系统的影响难以评估，以及面对故障时如何快速定位和修复问题，如何快速应急响应。

跨团队协作的问题，其实一直是团队管理的重点和痛点。多人大规模的跨团队甚至跨部门协作，如何保证目标一致，信息及时同步且不失真，高效的协作行动。

这些因素极大的制约了线上服务的稳定性和业务的可用性。而混沌工程的出现，就是赋予系统在面对失控条件时具备较强的“可观测性”和故障恢复能力。

谈落地混沌工程之前，先了解一下关于混沌工程的定义和目的。

要落地混沌工程，其实面临很多的挑战，这些挑战因素归类后主要分为如下几点：

成本主要集中在这几点：

风险主要有如下几点：

企业内推行很多项目，都会面临投入产出的评估。落地混沌工程也要面临这些挑战：

实施混沌工程需要遵守一些经典原则，主要有如下几点：

在遵循这些守则之后，目前业内对混沌工程的落地实施，我总结后认为可以分为三个阶段。

第一个阶段，主要是通过小范围试点，让团队了解混沌工程的意义和价值，同时拿到一些比较明显的结果，便于后续扩大范围开启实验。这个阶段的特征主要有如下几点：

第二个阶段，基本都是组织专门的团队，通过高度的自动化手段来实验，获取更多数据，发现更多问题。这个阶段的特征主要有：

第三个阶段，基本上混沌工程的演练范围已经可以覆盖大部分业务，应急手段和预案也比较熟练，可以作为日常的线上服务稳定性保障手段。这个阶段的特征主要如下：

经历这三个阶段之后，就可以将混沌工程作为日常研发和质量运营的一部分，长期运营下去。

混沌工程不仅可以提升线上系统的稳定性，还能为业务运营持续提升支撑，同时也可以提升团队的组织协作能力。下面两幅图是阿里和字节的混沌工程演练体系和最佳实践。

当然，在落地实践混沌工程时，一定要注意这几点前提：