随着分布式、云原生成为主流的系统架构设计方案，大规模分布式系统的稳定性保障能力越来越成为业界关注的重点。如今，混沌工程作为保障系统稳定性的利器，受到业界广泛关注，中国信通院作为国内最早推进混沌工程标准化工作的单位，联合混沌工程实验室全体成员单位、社区、媒体共同发起国内首个混沌工程问卷调查，以期掌握我国混沌工程的接纳程度和特点。
本报告采用在线调查加线下访谈的方式，共回收有效问卷 1016 份、访谈企业 17 家。报告的第一部分介绍调查背景，第二部分介绍我国混沌工程当前使用情况，第三部分是混沌工程致力于提高的系统稳定性现状，第四部分聚焦混沌工程的发展建议。本报告以调查结果为基础，力争详实客观地反映混沌工程领域应用现状与痛点需求，为广大从业人员、专家学者和研究机构提供真实可信的数据参考。
【核心观点】
国内软件系统稳定性有较大可提升空间。
调查数据显示，近 20% 的受访用户所负责的产品可用性低于 2 个 9（意味着用户每个月要忍受超过 7.3 小时的服务故障），超过 4 成产品的可用性低于 3 个 9（意味着用户每个月要忍受超过 44 分钟的服务故障）。
故障发生之后的解决情况也差强人意：仅不到一半的用户故障平均发现时长（MTTD）小于 1 小时；故障平均修复时长普遍超过 1 小时，超过 6 成故障修复时间（MTTR）高于 1 小时，甚至有约 20% 的服务故障修复时间超过 12 小时。
日益复杂的 IT 系统与快速迭代的软件交付为系统稳定性的保障带来更多挑战和不确定性，国内软件系统稳定性仍有较大提升空间。
混沌工程应用当前成熟度偏低，市场需要成熟、完善的混沌工程商业产品及咨询服务。
超过 3 成企业仅在小范围使用混沌工程，仅 8.68% 的企业较大规模地应用混沌工程，混沌工程在企业内部渗透率有待进一步提高；
近半数企业在研发、测试环境中使用混沌工程，仅不到 20% 的企业在生产环境中开展混沌工程演练，混沌工程在内部使用的技术复杂度不够高；
阻碍用户大规模、深度使用混沌工程的主要障碍是：缺乏相关经验以及担心故障注入对生产环境带来风险。
未来，需面向市场推出成熟、可信的混沌工程产品或建设咨询服务，以提升混沌工程的技术认可度、降低用户使用门槛、消除使用顾虑，成为推动行业步入快车道的催化剂。
混沌工程是提升产品可用性的有效手段，是建立稳定性优先战略的技术核心。
调查数据显示，随着混沌工程使用频率提升，低可用性（可用性低于 99%）的产品占比急剧萎缩，高可用性（可用性高于 99.99%）的产品占比迅速增长。
混沌工程通过在生产环境中执行探索性测试以发现系统中的隐藏问题，在软件系统稳定性维护上展现出巨大价值，其中提升服务可用性及降低故障修复时间是两大主要收益。65% 的受访用户认为采用混沌工程提升了服务可用性，49.85% 的受访者认为混沌工程帮助降低了 MTTR。
企业需要建立稳定性优先（Stability First）的战略，构建系统稳定性保障体系，稳固推进数字化转型进程。
企业期待构建完整、可度量的系统稳定性保障体系。
线下访谈数据显示，业务系统开发人员面对日益复杂的技术架构，急需应用适配新型 IT 架构的稳定性保障工具、建设路径指引以及稳定性度量体系；
受访用户普遍表示，合理借力合作伙伴或技术研究机构的技术支持和实践经验，可以很大程度规避新技术采纳过程中可能遇到的障碍，缩短技术成熟周期。
以下为详细数据解读
第一部分 【混沌工程应用现状】
发展阶段：混沌工程在企业内部的应用处于起步阶段
1）混沌工程普及率较低，未来有广阔增长空间：受访用户中有超过 3 成从未使用过混沌工程，仅 3.94% 左右的能比较频繁地（每天演练）使用混沌工程。
图 1 混沌工程使用频率
2）混沌工程在企业内部的渗透率偏低：超过 3 成企业使用混沌工程的产品比例低于 25%，仅 8.68% 的企业内部应用混沌工程的占比超过 75%。混沌工程对企业内部的很多使用场景、产品都有较大可渗透空间。
图2. 公司中使用混沌工程的业务占比
3）混沌工程使用阶段较为初级：44.41% 的用户在研发 / 测试环境中开展演练，在预生产环境中开展混沌工程演练的占比也达到了 32.21%。较低的生产环境使用率体现了用户对混沌工程直接作用于生产环境的不自信。
图3. 开展混沌工程演练的环境
开发工具：混沌工程实践以国内开源工具为主，需求侧与供给侧侧重各有不同。
1）服务需求侧（甲方）更倾向于采用商业产品为辅助：33.04% 的服务需求侧倾向于采用成熟的商业产品作为辅助，以实现混沌工程快速落地、避开实施陷阱；其次才会考虑自研平台。
图4. 混沌工程使用工具分布-需求侧
2）服务供给侧（乙方）更倾向于采用自研平台为辅助：对于服务供给侧来讲，商业产品的吸引力（26.68%）小于自研平台（37.96%）及国外开源工具（29.07%）。
图5. 混沌工程使用工具分布-供给侧
故障类型：故障注入类型以基础资源故障为主。
1）故障注入类型聚焦于基础资源层面，应用层及容器关注度偏低：网络资源故障和计算资源故障是最通常采用的故障注入类型，而应用类和容器类故障注入的关注度相对较低。
图6. 故障注入类型分布
2）故障演练实施靶点主要为主机 / 虚机：与故障注入类型一致，用户最常采用的故障演练实施靶点为主机 / 虚机，较少将故障直接实施在应用上，这可能与部分应用故障有一定的技术实现门槛，需要与开发框配合实现有关。
图7. 混沌工程演练的实施对象/靶点
实施收益：提升可用性是实施混沌工程的最大收益
与前述分析结果保持一致，可见混沌工程有助于提升用户最关注的服务可用性。调查数据显示，高达 65% 使用过混沌工程的受访用户表示混沌工程可以“提升服务可用性”，显著高于其他收益项。
实施障碍：经验的缺乏及对风险的担忧，国内市场需要成熟、完善的混沌工程商业产品或咨询服务降低技术实施难度。
调查数据显示， 46.32% 的用户缺乏使用混沌工程的相关经验，45.29% 的用户表示担心“混沌工程可能会对生产环境带来某些风险” ；而对于刚接触混沌工程的用户来讲，“缺乏相关经验”是其深度采纳混沌工程最大的障碍；对于频繁使用混沌工程的用户来讲，对风险的担忧占上风；同时，随着混沌工程使用频率的提升，用户对衡量混沌工程效益的需求显著增长（图 10 橙色线）。
消除用户采纳混沌工程的顾虑，有以下建议：
1）向市场推出成熟的混沌工程产品或咨询服务，降低用户的使用门槛是尽快推广混沌工程的有效手段；
2）设计完备的系统稳定性度量体系、混沌实验故障分级机制可以量化混沌工程的实施效果，推动混沌工程精益化发展，提升混沌工程实施的投入产出比。
图9. 实施混沌工程的最大障碍
图10. 采用混沌工程的障碍在使用频率上的分布
前置条件：技术就绪是实施混沌工程的前置条件
产品技术层面的就绪包括：完善的监控体系、可量化的系统稳定性评估体系及系统已具备韧性基础。调查数据显示，65.59% 的用户认为具备完善的监控体系是混沌工程实施的首要前置条件，超 60% 的用户需要对混沌实验时故障注入后的影响有可量化的评估模型，而团队协作在用户的认知中重要性相对较低，48.09% 用户选择此项。
图11. 实施混沌工程的前置条件
概念认知：混沌工程概念不清晰，知识普及任重道远
调查数据显示，超过半数被访用户对混沌工程和演习的概念分辨不清，约 1/4 的用户认为两者没有区别，仅有约 1/5 的用户能明确表述出两者的区别。对被访用户的反馈信息加工、进行词频分析后，可以发现混沌工程更偏向于在生产环境中执行探索性测试，具有随机性，以发现系统中的隐藏问题；演习更偏向于有计划性地验证某一具体猜想。
图12. 混沌工程与演习是否有区别
第二部分【系统稳定性现状】
可用性：企业产品可用性仍有提升空间
1）调查数据显示，近 20% 的受访用户所负责的产品可用性低于 2 个 9，近半数产品的可用性能低于 3 个 9。这意味着 47.04% 的用户每个月要忍受高于 44 分钟（可用性 99.9%），甚至超过 7.3 小时（可用性 99%）的服务故障。
图15. 可用性现状
2）故障发生之后的解决情况也差强人意：仅不到一半的用户故障平均发现时长（MTTD）小于 1 小时；故障平均修复时长普遍超过 1 小时，超过 6 成故障修复时间（MTTR）高于 1 小时，甚至有约 20% 的服务故障修复时间超过 12 小时。
图 16. 故障平均发现时长（MTTD）
图17. 故障平均修复时长（MTTR）
可用性与混沌工程：混沌工程使用频率与产品可用性提升显著相关。
从未使用过混沌工程的受访者中，有近三成受访者产品可用性低于 99%，而随着混沌工程使用频率提升，在每天都会演练的受访者中，这一比例急剧缩减到 2.5%（见下图中蓝色模块），即随着混沌工程使用频率提升，低可用性的产品占比急剧萎缩；与此相对应的是，从未使用过混沌工程的受访者中，仅 25% 的产品可用性高于 99.99%，而随着混沌工程使用频率提升，在每天都会演练的受访者中，这一比例迅速增长至 65%（见下图中红色模块），即随着混沌工程使用频率提升，高可用性的产品占比迅速增长。
图 18. 产品可用性在不同混沌工程使用频率上的分布
可用性度量与提升：产品可用性度量维度及提升可用性的方法多样。
1）产品可用性度量维度多样：响应时间、可用率和错误率的选择人数明显较高，是度量产品可用性时最常使用的指标。有近 70% 的用户采用响应时间作为产品可用性度量标准之一，除此之外，可用率和错误率的选择人数也接近 60%。
图 19. 产品可用性度量维度
2）产品可用性的提升方式：备份、健康性检查、自动扩容、多中心双活模式、数据库复制集调查数据显示，48.72% 的用户会选择使用“备份”作为提升产品可用性的方法，48.43% 的用户会选择使用“健康性检查”，而自动扩容以 45.28% 的比例跻身产品可用性提升方法的第三位，多中心双活和数据库复制集分别以 43.9% 和 40.06% 的占比分列四、五位。相关人员可参考此数据以指导产品可用性提升建设规划。
图 20. 提高产品可用性的策略
3）应用上云是提升可用性的有效手段：从公司的云化程度来看，不同的云化程度对产品可用性的影响具有显著差异，云化程度越高的公司，产品可用性越高。上云比例低于 25% 的公司中，44.96% 的产品可用性低于 99%，仅 14.71% 的产品可用性高于 99.99%；而随着上云产品比例的提升至 75% 以上后，可用性高于 99.99% 的产品占比急速飙升至 49.23%，翻了两番之多。
图 21. 云化程度与服务可用性情况的交叉分析
重大事故：当前产品的稳定性相对较差，合理运用混沌工程能减少重大事故发生率。
1）可用性面临巨大威胁：调查数据显示，74.11% 的用户产品每月发生的重大事故少于 5 个，但每个月重大事故发生数量超过 5 个的产品占比达到 25.89%，这意味着约 1/4 的产品每年会发生至少 60 次重大事故，可用性面临巨大威胁。
图 22. 每个月重大事故（根据公司内部标准）的平均数量
2）重大事故来源分布：对于每个月重大事故数量小于 5 的公司来说，代码错误和网络问题是造成重大事故的主要原因；对于每个月发生 5~10 个重大事故的企业来说，非数据库引起的内部依赖问题引发了51.37%的故障，配置错误引发了43.72%的重大事故；对于每个月发生 10~20 个重大事故的企业来说，非数据库引起的内部依赖问题同样以 47.95% 的比例显著高于其他故障类型，配置错误以 41.1% 的比例位居第二。
线下调研结果提示：合理运用混沌工程能很好的规避或弱化以上问题。
图 23. 重大事故来源分布
图24. 重大事故与故障来源交叉分析
第三部分【发展建议】
一、关注企业 IT 架构现状，构建围绕业务的稳定性保障体系。面对日益复杂的 IT 系统架构以及逐步提升的用户期望，企业需要关注核心业务体系，建立稳定性优先的战略并依据科学、有效的混沌工程理念规划自身的稳定性保障体系，在积极采纳云原生、人工智能、大数据等技术的同时，优先考虑配套的稳定性系统搭建，在保障系统稳定的前提下，逐步实现业务向新架构的迁移。
二、重视技术迭代，打造以混沌工程为中心的系统稳定性保障体系。随着 IT 技术的更新，稳定性保障技术也随之迭代更新以解决新架构下面临的新问题。混沌工程通过引入随机和不可预知行为的受控实验来识别系统的弱点，有效提升软件系统稳定性。在此基础之上，配合使用可观测性平台、容量管理、全链路压测等工具或技术，组合搭建系统稳定性保障体系，全方位保障软件系统可用性。
三、构建稳定性优先的企业文化，借助合作伙伴生态加速混沌工程成熟周期。首先，企业和组织必须对新理念和技术持包容的心态，积极拥抱混沌工程理念及管理框架；其次，选择能够对混沌工程实验进行全生命周期支持的可信平台或工具，精细化管理混沌实验，逐步将混沌工程从测试环境推向生产环境；最后，企业应重点关注混沌工程实践效果度量，从而正确评估当前系统稳定性状态，缩短混沌工程成熟周期。
加入混沌工程实验，请联系wanghaiqing@caict.ac.cn
混沌工程实验室成员名单
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
