软中国混沌工程调查报告2021(软件系统稳定性现状和发展建议)

转载自混沌工程实验室

三、软件系统稳定性现状

企业产品可用性仍有提升空间。调查数据显示（图 19），近 20%的受访用户所负责的产品可用性低于 2 个 9，近半数产品的可用性能低于 3 个 9。这意味着 47.04%的用户每个月要忍受高于 44 分钟（可用性 99.9%） ，甚至超过 7.3 小时（可用性99%）的服务故障。

图 19. 调查用户公司产品可用性

混沌工程使用频率与产品可用性提升显著相关。从未使用过混沌工程的受访者中，有近三成受访者产品可用性低于 99%，而随着混沌工程使用频率提升，在每天都会演练的受访者中，这一比例急剧缩减到 2.5%（见图 20 中蓝色模块），即随着混沌工程使用频率提升，低可用性的产品占比急剧萎缩；与此相对应的是，从未使用过混沌工程的受访者中，仅 25%的产品可用性高于 99.99% ，而随着混沌工程使用频率提升，在每天都会演练的受访者中，这一比例迅速增长至 65%（见图 20 中红色模块），即随着混沌工程使用频率提升，高可用性的产品占比迅速增长。

图 20. 产品可用性在不同混沌工程使用频率上的分布

产品可用性度量维度多样，响应时间、可用率和错误率的选择人数明显较高，是度量产品可用性时最常使用的指标。调查数据显示（图 21），有近 70%的用户采用响应时间作为产品可用性度量标准之一，除此之外，可用率和错误率的选择人数也接近 60%。

图 21. 产品可用性度量维度

MTTD 及 MTTR 时长有较大提升空间。调查数据显示，仅不到一半的用户故障平均发现时长（MTTD）小于 1 小时，而超过 50%的产品故障需要 1 小时以上才能被探测到；与此同时，故障平均修复时长（MTTR）普遍超过 1 小时，超过 6 成故障修复时间高于 1 小时，甚至有约 20%的服务故障修复时间超过 12 小时。漫长的故障探测及修复时间是良好用户体验的巨大阻碍。但故障修复后，半数以上的公司会进行事故复盘且及时向公司内外利益相关方分享脱敏后的复盘报告（图 24），透明度较高。

备份、健康性检查、自动扩容、多中心双活模式、数据库复制集是最常使用的提升产品可用性的方法。调查数据显示（图 25），48.72%的用户会选择使用“备份”作为提升产品可用性的方法，48.43%的用户会选择使用“健康性检查”，而自动扩容以 45.28%的比例跻身产品可用性提升方法的第三位，多中心双活和数据库复制集分别以 43.9%和  40.06%的占比分列四、五位。这 5 项的响应率和普及率明显较其他选项高。相关人员可参考此数据以指导产品可用性提升建设规划。

从公司的云化程度来看，不同的云化程度对产品可用性的影响具有显著差异，云化程度越高的公司，产品可用性越高。调查数据显示（图 26），上云比例低于 25%的公司中，44.96%的产品可用性低于 99%，仅 14.71%的产品可用性高于 99.99%；而随着上云产品比例的提升至 75%以上后，可用性高于 99.99%的产品占比急速飙升至 49.23%，翻了两番之多。应用上云也是提升可用性的有效手段。

云化程度与服务可用性情况的交叉分析

健康性检查是监控产品可用性最主要的技术手段。调查数据显示（图 27），69.19%的用户使用健康性检查作为监控产品可用性最主要的技术手段，而真实用户监控和服务侧响应两种技术也分别贡献了近 60%的普及率。

图 27. 监控服务可用性的工具分布

当前产品的稳定性相对较差，月事故率差强人意，仍有 25.89%的服务每个月发生超过 5 个严重性事故。调查数据显示（图 28 ），74.11%的产品每月发生的重大事故少于 5 个，但每个月重大事故发生数量超过 5 个的产品占比达到 25.89%，这意味着约 1/4 的产品每年会发生至少 60 次严重性事故，用户体验面临巨大威胁。

图 28. 每个月重大事故（根据公司内部标准）的平均数量

代码错误、网络问题、配置错误、内部依赖是引发重大事故的主要原因，合理运用混沌工程能很好的规避或弱化以上问题。

对于每个月重大事故数量小于 5 的公司来说（图 30），代码错误和网络问题是造成重大事故的主要原因；对于每个月发生 5~10 个重大事故的企业来说，非数据库引起的内部依赖问题引发了 51.37%的故障，配置错误引发了 43.72%的重大事故； 对于每个月发生10~20个重大事故的企业来说，非数据库引起的内部依赖问题同样以47.95%的比例显著高于其他故障类型， 配置错误以 41.1%的比例位居第二。

线下调研结果提示：合理运用混沌工程能很好的规避或弱化以上问题。

图 29. 重大事故来源分布

图 30. 重大事故与故障来源交叉分析

超过半数系统每周都会发布新功能，产品功能迭代较频繁。调查数据显示（图 31），有 20.08%的产品两次部署间隔为几 小时，新功能发布时间间隔在几天的比例为 35.82%，而新功能发布间隔为几个月及以上的占比仅为 10%左右。

四、发展建议

越来越多的企业与机构在数字化转型过程中拥抱云计算、大数据、人工智能等新兴技术，但其在带来战略业务价值的同时， 也引入了更多的不确定性与技术挑战，如企业 IT 架构复杂度迅速拉升、系统之间调用链增长、依赖关系错综复杂等问题。混 沌工程作为维持、提升系统稳定性的新思想，成为解决系统稳定性问题的一方良药。然而，当下系统管理人员对其建设方法、 实施路径存在很多盲区，尤其对主动向生产系统注入故障有诸多顾虑。

因此，混沌工程实验室指出，正在调研或已经开始尝试使用云计算、大数据等技术进行数字化转型的企业与组织机构，首 先需要建立稳定性优先（Stability First）的战略，通过渐进和务实的整体规划，以体系化的方式有效构建企业系统稳定性保障能力；其次要借助合作伙伴的技术深度、生态系统广度以及相关行业实践的专业度，保障信息系统的持续迭代和创新，不畏惧不确定性挑战，真正将新技术的巨大潜能稳定地释放给系统用户。具体建议：

一、关注企业 IT 架构现状，构建围绕业务的稳定性保障体系。面对日益复杂的 IT 系统架构以及逐步提升的用户期望，企业需要关注核心业务体系，并依据科学、有效的混沌工程理念规划自身的稳定性保障体系，在积极采纳云原生、人工智能、大数据等技术的同时，优先考虑配套的稳定性系统搭建，在保障系统稳定的前提下，逐步实现业务向新架构的迁移。

二、重视技术迭代，打造以混沌工程为中心的系统稳定性保障体系。随着 IT 技术的更新，稳定性保障技术也随之迭代更 新以解决新架构下面临的新问题。混沌工程通过引入随机和不可预知行为的受控实验来识别系统的弱点，有效提升软件系统稳定性。在此基础之上，配合使用可观测性平台、容量管理、全链路压测等工具或技术，组合搭建系统稳定性保障体系，全方位保障软件系统可用性。

三、构建稳定性优先的企业文化，借助合作伙伴生态加速混沌工程成熟周期。首先，企业和组织必须对新理念和技术持包 容的心态，积极拥抱混沌工程理念及管理框架；其次，选择能够对混沌工程实验进行全生命周期支持的可信平台或工具，精细 化管理混沌实验，逐步将混沌工程从测试环境推向生产环境；最后，企业应重点关注混沌工程实践效果度量，从而正确评估当 前系统稳定性状态，缩短混沌工程成熟周期。