大厂在混沌工程领域的实践

近几年大家对于生产服务的稳定性越来越重视，无论是在技术大会还是企业的技术规划中，混沌工程越来越多的被提及到。上周末看了 2 个大厂落地混沌工程的视频案例，让我对混沌工程有了一些新的理解。

这篇文章，我总结了阿里和字节在落地混沌工程方面的一些技术实践，还有我的一些理解和思考。

为什么需要混沌工程？

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

• 业务迭代速度越来越快（业务要求技术更快的交付）；

• 应用系统架构愈发复杂（技术支撑业务的必然发展趋势）；

• 跨团队协作成本越来越高（大规模协作的信息失真和延时）；

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

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

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

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

混沌工程面临哪些挑战？

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

定义：通过有目的的注入真实的故障来锻炼提升系统的稳定性，改善团队的应急效率。

目的：可控的主动暴露问题，通过一系列手段来修复收敛问题，最终达到问题可量化、系统可信赖，最后达成不断的主动挖掘问题解决问题的机制。

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

投入成本高

成本主要集中在这几点：

• 生产集群有很多的服务实例，模拟故障软硬件成本高；

• 系统架构太复杂，涉及多个团队和人员，人力投入成本高；

• 服务之间各种依赖，实施故障注入需要内外部多方协作配合；

• 混沌工程需要长期的人力和时间投入，影响正常的业务迭代；

实施风险高

风险主要有如下几点：

• 发生重大生产故障怎么办？

• 注入的故障影响范围和程度是否可控？

• 万一生产系统真的挂了影响到用户使用怎么办？

• 生产数据很关键，注入故障产生的脏数据怎么处理？

收益不明显

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

• 系统上线这么久，都很稳定，有必要实施混沌工程吗？

• 除了注入故障观察系统表现，还有其他明显的有价值的产出吗？

企业如何落地混沌工程？

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

• 建立稳定状态的假设（制定合适的目标）；

• 多样化现实世界事件（选择合适的场景）；

• 在生产环境运行实验（在真实环境运行实验）；

• 持续自动化运行实验（避免人为误操作风险）；

• 最小化控制爆炸半径（控制实验的影响范围和程度）；

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

试验探索期

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

• 通过简单的故障注入了解混沌工程的运行机制；

• 小范围的试点，判断混沌工程的可行性，让相关成员熟悉流程；

• 可以快速验证故障恢复手段的有效性，快速分析出实施故障注入的风险；

• 实施时屏蔽业务系统部署细节，抽象故障模型，降低故障注入难度和资源成本；

熟练实验期

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

• 实现故障演练创建和执行的自动化；

• 可以自动收集演练的数据，半自动的识别风险和结果分析；

• 有高效的场景管理手段，丰富的故障场景类型和成熟故障熔断措施；

• 可以从业务链路视角开展故障注入，发现并提升感知和修复故障的能力（监控/告警/响应）；

常态演练期

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

• 覆盖范围基本覆盖大部分业务，故障演练成为研发体系的一部分；

• 演练自动化，形成完备的生产稳定性保障预案，沉淀了丰富的案例库；

• 沉淀了适合自身的最佳实践，系统稳定性保障体系成熟，可以联动业务部门常态化演练；

• 混沌工程团队和相关人员之类的协调配合熟练高效，有明显的正向产出，进一步支撑业务运营；

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

混沌工程的建设演进之路

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

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

• 实施人员对系统要有深入的了解；

• 混沌工程要面向开发者，提高感知故障、排除故障的能力；

• 大规模推广时候需要结合业务团队特性来量身定做方案，主动推动；

• 控制演练范围-注意实施时间-从历史故障入手再做一些探索性的验证；

• 低成本故障注入才能帮助业务快速验证故障下的系统表现和恢复手段；

• 不同系统处于不同阶段，需要以不同的混沌工程实验帮助提升稳定性建设；