中国混沌工程调查报告 (2022年) 混沌工程实验室2023年3月 版权声明 本报告版权归混沌工程实验室所有,受法律保护。如需转载、摘抄或通过其他方式使用本报告内容,须注明“来源:混沌工程实验室”,违者必究。 前言 混沌工程作为主动挖掘复杂系统稳定性缺陷的方法,其应用价值已得到广泛认可并逐步获得更多领域用户的青睐。中国信通院于2020年初关注混沌工程并推进相关研究,在2021年7月于可信云大会上牵头成立国内首个混沌工程实验室,旨在以混沌工程为抓手,探索系统稳定性保障技术在国内各领域典型应用场景中的实施路径,集合行业内领头企业的专业力量,开展技术研究,推进标准体系建设,提高产业发展向心力和发展质量,进而为我国数字经济的持续、稳定发展提供基础的技术保障。 2021年,中国信通院混沌工程实验室发布了国内首个针对混沌工程应用情况的《中国混沌工程调查报告(2021)》,一年以来,混沌工程实验室持续跟踪国内混沌工程应用现状及所面临的挑战,更进一步地,实验室今年关注了可观测性、全链路压测及容灾技术的应用情况,凸显综合运用系统稳定性保障技术的重要性,推动系统稳定性保障技术在我国的概念普及,提升软件系统安全、稳定、持续运营水平,促进软件高质量发展。 本报告采用在线调查加线下访谈的方式,共回收有效问卷1270份,访谈企业13家。本报告第一部分介绍调查背景,第二部分介绍我国系统稳定性现状,包括整体情况及稳定性保障关键技术应用情况,第三部分是混沌工程的应用现状,第四部分提供了企业发展建议,供市场各方参考。报告以调查结果为基础,力争详实客观地反映系统稳定性保障领域应用现状与痛点需求,为广大从业人员、专家学者和研究机构提供真实可信的数据参考。 本次报告的问卷发放、数据采集及文稿审核工作得到混沌工程实验室成员单位(见文末附录)及云上软件工程社区、QECon组委会、软件质量报道、InfoQ、开源中国、QAPark、极狐GitLab、华为开发者联盟、HeapDump性能社区、测试窝等单位和组织的大力支持,在此谨表示最衷心的感谢!同时也对接受混沌工程调查访问的用户朋友表示最诚挚的谢意! 编制说明 本调查问卷及报告自2022年9月启动编制,在问题设计、问卷投放、报告起草、征求意见和修订完善等五个重要阶 段,均面向软件系统稳定性领域的技术提供方、产品服务方、行业应用方开展了深度访谈、意见征集等工作,参与问卷及报告编制的单位和个人说明如下: 参编单位:中国信息通信研究院、阿里云计算有限公司、百度网讯科技有限公司、中泰证券股份有限公司、中国农业银行、科来网络技术股份有限公司、腾讯云计算(北京)有限责任公司、华为云计算技术有限公司、云杉网络科技有限公司、北京必示科技有限公司、招商银行、东软集团股份有限公司、花瓣云科技有限公司、北京同创永益科技发展有限公司、极狐创新 (北京)信息技术有限公司、中移(杭州)信息技术有限公司、建信金融科技有限责任公司、招商基金管理有限公司、中电金信软件有限公司、四川省农村信用社联合社、天翼云科技有限公司、思特沃克软件技术(北京)有限公司、中债金科信息技术有限公司、南京争锋信息科技有限公司。 参编专家:郑立、王海清、李修莹、周洋、肖长军、郑焱、刘运鑫、苗永辉、黄钰䶮、胡皓、张明利、张永启、刘浩、张洁玉、肖晶、张亚祥、郭伟杰、王洋、廖荣、姜英伟、陈佃晓、崔传敏、潘微服、鹿骏、刘波、崔杰、郭旭东、李飞、张月、曹立、金永哲、胡文、左坚、金一、郑晖、耿宜龙、金永哲。 目录 前言3 编制说明4 目录5 观点摘要6 一、调查背景8 (一)调查方法及样本8 1、调查方法8 2、样本描述8 (二)报告术语界定11 二、软件系统稳定性现状12 (一)软件系统稳定性整体现状12 (二)稳定性保障技术应用情况15 1、容灾能力15 2、可观测能力17 3、全链路压力测试能力20 三、混沌工程应用现状20 四、发展建议30 编后语31 附录32 观点摘要 国内软件稳定安全运行水平仍有较大可提升空间,系统稳定性保障技术市场增长动能强劲。调查数据显示,约15%的受访用户所负责的软件产品可用性低于2个9,近半数产品的可用性能低于3个9。这意味着47.08%的用户每个月要忍受高于44分钟(可用性99.9%),甚至约15%的用户每个月要忍受超过7.3小时(可用性99%)的服务故障。故障发生之后的解决情况也差强人意:仅有不到一半的故障平均发现时长(MTTD)小于1小时;近一半的用户需要花费1小时以上才能发现故障,这反映了软件产品及其运行环境的观测能力不足,故障修复时长则普遍超过1小时,甚至有约20%的服务故障修复时间超过12小时,这反映了应急处理能力与灾难恢复能力的不足。系统自身稳定安全运行水平较大的可提升空间及终端用户对系统故障更低的容忍度,为稳定性保障相关技术市场提供了持续发展的动能。 混沌工程与软件系统稳定运行强相关,其价值得到持续认可。混沌工程使用频率与产品可用性提升显著相关,随着混沌工程使用频率提升,高可用性的产品占比增长迅速,此数据规律与去年保持高度一致,用户对软件系统高可用性的追求将持续促进系统稳定性保障技术繁荣发展。同时,约68.21%的企业对提升系统可用性的结论表示认可、有46.92%的企业降低了应用服务的MTTR,有42.31%的企业验证了服务应急预案的有效性,有42.05%的企业降低了应用服务的MTTD。此外,还有41.52%企业通过混沌工程发现了应用服务的bug。混沌工程的价值得到市场普遍且持续的认可,团队能看到采纳混沌工程所带来的益处。伴随对混沌工程质疑的下降及实践经验的丰富,61.79%的受访用户有明确规划且具备可操作性,说明混沌工程已经被组织的认可,开展规模化落地。 混沌工程技术关注度及认知度呈增长态势,但用户缺乏并亟需最佳实践(包括平台建设及场景梳理)指导。在政府、企业等参与者的大力促进下,系统稳定性保障理念得以快速推广,使得混沌工程采纳程度进一步提升,“从未使用”(下降3.75%)及“偶尔使用”(下降3.55%)的用户占比下降,由此可见,其对于业务与技术的价值得到认可,更多从业人员认识到混沌工程的价值并开始尝试拓展混沌工程技术的应用与实践。同时,实验场景梳理(60.77%)及平台能力建设(58.97%)是企业的工作重点,但是建设经验匮乏(43.91%)及对实施风险(36.56%)的担忧阻碍了组织内混沌工程成熟度加深,市场需关注用户对成熟、完善的商业化产品及混沌工程实验场景设计和编排能力的需求。 “稳定性优先”战略定位需要增强,用户需关注稳定性保障体系构建。频繁的版本更新带来软件稳定性的担忧,要保证高质量的交付,就要更多体系化地综合应用混沌工程、可观测性建设以及全链路压测,在部署之前建立对软件的信心。同时配合稳定安全运行机制和良好的容灾恢复能力提升整体稳 定保障水平。据调查数据显示,受访用户对相关技术的使用深度普遍偏低,仅40.57%受访用户可以应对机房级故障,而能应对区域级故障的用户占比则不足3成;多数用户仍无法区分可观测性与传统监控之间的区别。 一、调查背景 (一)调查方法及样本 1、调查方法 本次调查采用在线调查加线下访谈的方式,共收集到有效问卷1270份,访谈企业13家。 2、样本描述 参与调查用户所在行业:包括软件及云服务、金融、互联网、电信、能源、硬件/半导体及零售业等。 图1.受访者所在行业分布 数据来源:中国信通院混沌工程实验室 参与调查用户角色:甲方用户多于乙方供应商。 图2.企业类型分布 数据来源:中国信通院混沌工程实验室 参与调查用户所在企业情况:人员规模在千人以上的企业超过50%,近5成企业成立时间超过10年。 图3.企业成立时间 数据来源:中国信通院混沌工程实验室 图4.企业人员规模 数据来源:中国信通院混沌工程实验室 参与调查用户工作职位:超过3成受访者来自研发部门,19.37%的受访者来自运维部门,18.2%的受访者是测试工程师,还有12.19%的受访者是经理、总监以上的技术线管理人员。 图5.被调查用户工作岗位分布 数据来源:中国信通院混沌工程实验室 (二)报告术语界定 混沌工程:混沌工程是一门通过设计并执行一系列实验,帮助发现信息系统技术架构(设计、架构、代码、运维等)与运营流程方面的隐藏风险与薄弱环节,从而全面提升信息系统韧性,使得系统达到既定可靠性的学科。 应用多活:指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统,所有机房内的应用同时对外提供服务的技术。 可观测性:在信息系统中,可观测性指的是通过系统的外部输出来度量系统内部运行状态的能力。MTTR:平均修复时间(Meantimetorepair,MTTR),用于描述产品由故障状态转为工作状态时修理时间的平均值。 MTBF:平均无故障时间(MeanTimeBetweenFailure,MTBF),它反映了产品的时间质量,用于描述产品在规定时间内保持功能的一种能力。 MTTD:平均检测时间(Meantimetodetect,MTTD),用于描述故障平均发现时长。 产品可用性:产品可用性=MTBF/(MTBF+MTBF+MTTR)。 业务连续性:业务连续性是一种组织能力,在中断期间,组织以预先确定的能力在可接受时间范围内持续交付产品和服务的能力。1 RPO:数据恢复点目标RPO(RecoveryPointObjective),主要指的是业务系统所能容忍的数据丢失量,用来衡量容灾备份技术。 1ISO22301:20193.3和ISO22300:20213.1.19 二、软件系统稳定性现状 (一)软件系统稳定性整体现状 以混沌工程为代表的系统稳定性保障技术市场增长动能强劲。 软件系统可用性仍有较大可提升空间。调查数据显示(图6),约15%的受访用户所负责的软件产品可用性低于2个9,近半数产品的可用性能低于3个9。这意味着47.08%的用户每个月要忍受高于44分钟 (可用性99.9%),甚至超过7.3小时(可用性99%)的服务故障。 故障发现及故障修复能力有较大提升空间。调查数据显示,近一半的用户需要花费1小时以上才能发现 故障,这反映了软件产品及其运行环境的观测能力不足。约六成用户的故障修复时间超过1小时,甚至有约 20%的服务故障修复时间超过12小时,这反映了其故障恢复能力有待提升。故障发现及恢复能力不足将直接降低研发运营侧体验,较差的应急处置能力将直接降低终端用户体验,最终都将降低终端用户对产品的认可度。 图6.受访用户公司产品可用性分布图7.故障发现与故障修复平均时长分布 数据来源:中国信通院混沌工程实验室数据来源:中国信通院混沌工程实验室 混沌工程实施频率与产品可用性之间的正相关性得到持续的验证。混沌工程实施频率与产品可用性提升显著相关,随着混沌工程使用频率提升,高可用性的产品占比呈现显著上升趋势(如图8),此规律与去年保持高度一致,混沌工程实施频率与软件产品可用性之间的正相关性得到持续验证,用户对软件系统高可用性的追求也将刺激混沌工程技术持续发展。 图8.产品可用性在不同混沌工程使用频率上的分布 数据来源:中国信通院混沌工程实验室 代码错误、网络问题、配置错误、内部依赖仍是引发重大事故的主要原因。结合线下调研数据了解到,合理运用多种稳定性保障技术手段能很好的规避或弱化以上问题。引发重大事故的来源与去年保持高度一致,但是“人工误操作”今年和去年都占较大比例,提示稳定安全运行机制及稳定性保障文化普及的重要性。 图9.重大事故来源分布 数据来源:中国信通院混沌工程实验室 按需部署有隐忧,系统稳定性存风险:需要依赖混沌工程、可观测性、全链路压测等技术建立对软件可靠性的信心。受访者中约14%能按需部署(部署间隔平均为几小时),与DORA发布的《2022DevOps现状调查报告2》中数值(16%)接近。按需部署则意味着更频繁、不定时地代码迭代,因此可能带来更多稳定性风险,导致软件交付的整体质量下降。在高频部署的情况下,组织