混沌工程和软件系统稳定性实践在技术大会上没啥可讲的？

什么是混沌工程？用一句简单的话来解释，就是使用科学方法，用做有对照组的实验，来实证复杂的分布式软件系统，能够在生产环境抵御来自现实世界不可预知的各种状况。

混沌工程在官网(PRINCIPLES OF CHAOS ENGINEERING)的正式定义，是一门对软件系统进行实验的学科，目的是建立对系统承受生产环境中动荡条件的能力的信心。

根据InfoQ最近3年推出的DevOps和云技术趋势鸿沟曲线显示，在国外，混沌工程实践已经在2022年跨过早期采纳者和早期大众之间的鸿沟，进入业界主流。因为国内业界对于创新工程实践的采纳相对滞后，估计混沌工程在国内应该有3～5年左右就能跨过鸿沟，进入主流。

混沌工程在Thoughtworks公司的技术雷达上的位置，也能从侧面印证这一点。

技术雷达可视化了该公司以企业定制化软件开发见长的开发人员所远离和青睐的各种最新的软件开发技术和过程。雷达从外到内，分为4个环。最外的暂缓环中的技术，是开发人员所远离的。之后从外到内依次是评估环、试点环和采纳环。越往圆心的环中的技术，开发人员越青睐。

混沌工程在2017年首次进入技术雷达，就进入了试点环。此后的两年，就一直停留在这个环。与混沌工程相关的安全混沌工程，2018年首次进入技术雷达，是在评估环。同年晚些时候，又移动到了试点环。

技术雷达的评估环，可以对应鸿沟曲线的创新者(Innovators)区间；试点环对应早期采纳者(Early Adopters)区间；采纳环对应早期大众(Early Majority)和后期大众(Late Majority)区间。

喜欢应用新技术的Thoughtworks的开发人员，目前应该属于鸿沟曲线的早期采纳者，正向早期大众转化。

最近我在K+全球软件研发行业创新峰会2023北京大会中，做“混沌工程应用”专题的出品人。在收集和筛选演讲话题时，发现一些企业，不太愿意来分享。原因是前两年在国内“混沌工程”早期试点阶段，他们已经在大会上分享过这个话题了。最近也没有什么新的内容可讲。

具体来说，根据我在之前所参与的相关咨询项目中的观察，大部分企业实践混沌工程，主要集中在两个方面。

第一，构建工具平台。包括工具平台的建设过程，以及相关的系统架构。

第二，故障注入实验。包括故障库、故障注入编排和故障注入演练。其中故障库中的原子故障，主要是针对基础设施层和容器平台层的虚拟机、容器、pod和node。如果是甲方购买了乙方的虚拟机和容器平台，然后再在上面做相关的故障注入实验，本质上是甲方再次花钱为乙方做回归测试。

企业一旦在上面两个方面开展混沌工程应用工作，过程就相对固化下来。自然在分享了一次之后，就没有什么可再分享的新内容了。另外，这两个方面，是不是给你一个在小池塘中荡舟的四平八稳的感觉，而不是混沌工程本应有的面对大海般动荡和不确定的生产环境事件的感觉。

混沌工程和软件系统稳定性工程实践，如何做得有好内容可讲？

可以做下面两类更有意思的实践。

第一，人的协作相关的实践。比如可以问自己下面的问题。

1 企业各个角色，如业务人员、开发人员、测试人员、运维人员、平台团队，在混沌工程应用中的协作机制是什么样的？

2 你们用了什么机制，保障所注入的故障能反映多样化的生产环境的现实世界的动荡情况？比如是否归纳了以往生产系统停机的原因并将其纳入故障库？是否实践了蓝军行动？蓝军小组由哪个部门牵头领导？是公司级别的？还是部门级别的？还是开发组级别的？蓝军与红军是如何协作的？能否举一个红蓝军协作开展混沌工程实验（从测试环境到生产环境）的整个过程的例子？

3 你们在实践混沌工程时，遇到了什么阻力？你们是如何应对阻力的？

4 企业内的分布式系统一般会由多个开发团队维护。即使分布式系统中的所有单个服务都正常运行，这些服务之间的交互也可能会导致不可预测的结果。这些结果，再加上影响生产环境的罕见但具有破坏性的现实世界的事件，使得这些分布式系统本质上是混沌的。你们的混沌工程实践，是否主要是集中于单个团队所维护的单个服务？如果涉及两个团队所维护的两个服务之间的交互的故障注入实验，你们是如何协调这两个团队进行实验的？

第二，有挑战的技术和过程相关的实践。比如可以问自己下面的问题。

1 故障注入实验是否经常在生产环境执行？还是只在测试或准生产环境执行？如果从未在生产环境执行，顾虑是什么？

2 你们所实践的混沌工程应用，与传统的测试团队的软件测试，以及与运维部门的传统故障演练，有什么区别？差异化优势在哪里？

3 如何保障故障注入后的最小化爆炸半径？

4 你们所开展的故障注入实验，是否主要针对基础设施层或容器平台层？是否有针对应用服务层做故障注入实验？比如服务不可用时的后备设置不当，由于超时调整不当而导致用户的重试风暴，当所依赖的服务接收过多流量时发生延时、服务中断或返回错误码，单点故障崩溃时的所导致的级联故障等等。

5 你们向领导汇报混沌工程成效时，具体使用了哪些指标？成效数据前后是如何对比的？

你可以思考上面这9组问题。选出一个能启发你把混沌工程和软件系统稳定性工程实践做得有意思的，并尝试解决该问题。在这个过程中，相信你会有好内容可讲。

我已经在知乎开设了“吾真本说软件系统稳定运行”专栏，并建了相关的讨论小组。如果你对混沌工程和软件系统稳定性工程实践感兴趣，欢迎在知乎我的专栏里给我留言“混沌讨论”，我会告诉你我的联系方式，拉你进入讨论小组，一起讨论。

企业生意蒸蒸日上，软件系统稳定运行。这就是“吾真本说软件系统稳定运行”专栏所关注的。