[转帖]中国混沌工程调查报告2021(观点摘要,调查背景和混沌工程应用现状)

中国,混沌,工程,调查报告,观点,摘要,调查,背景,应用,现状 · 浏览次数 : 0

小编点评

**1.调查背景** * 混沌工程使用普及率较低,未来有广阔增长空间。 * 用户中有超过 3 成从未使用过混沌工程,仅 3.94%左右的能频繁地(每天演练)使用混沌工程。 **2.混沌工程应用现状** * 混沌工程使用工具分布-需求侧:33.04%服务需求侧倾向于采用成熟的商业产品作为辅助,以实现混沌工程快速落地、避开实施陷阱。 * 混沌工程使用工具分布-供给侧故障注入类型聚焦于基础资源层面,应用层及容器关注度偏低。 **3.用户对混沌工程的影响** * 近 70%使用过混沌工程的受访用户表示混沌工程可以“提升服务可用性”,显著高于其他收益项。 **4.系统稳定性度量体系** * 混沌工程实施的最大收益是提升用户最关注的服务可用性。 **5.技术因素** * 完善的监控体系、可量化的系统稳定性评估体系及系统 已具备韧性基础。 *技术就绪是实施混沌工程的前置条件。 **6.结论** * 混沌工程更偏向于在生产环境中执行探索性测试,具有随机性,以发现系统中的隐藏问题;演习更偏向于有计划性地验证某一具体猜想。

正文

https://www.jianshu.com/p/9de94066ab46

 

随着分布式架构的普及以及云计算技术的成熟,国内企业应用云原生化推进业务系统的迭代速度越来越快,后端系统架构日趋复杂,服务间的依赖越来越多,调用的链路越来越长。宕机引发巨额损失、严重影响用户体验的新闻层出不穷,为了让云基础设施更好地适应复杂多变的运行环境,持续提供超大规模、超高稳定性的运行效能,一种新的软件思潮——“混沌工程学(Chaos  Engineering )”应运而生。混沌工程提供了一种端到端的稳定性测试理念与工具框架,通过主动引入故障来充分验证系统和应用的脆弱性,提前发现并解决问题,力求防患于未然,从而从根本上提高系统和应用的鲁棒性。

2020 年初,中国信通院开始组织专家进行混沌工程技术研究,提出应用混沌工程方法来验证企业软件系统的韧性架构。

2021 年 4 月 2 日,混沌工程项目研讨会议在京召开并发布《混沌工程平台能力要求》标准纲要,并在 2021 年 7 月于可信云大会上牵头成立国内首个混沌工程实验室,旨在探索混沌工程在国内各领域典型应用场景中的实践落地,联动云计算上下游企业来共同推进混沌工程概念快速普及。

为了了解我国混沌工程发展全貌,混沌工程实验室于 2021 年 9 月启动《中国混沌工程调查报告》问卷征集活动,此举有助于更深入探索我国云上软件系统稳定性现状、混沌工程使用情况、行业采纳度、技术成熟度及未来发展趋势,以期推动混沌工程在我国的概念普及,提升云上软件系统稳定性,促进软件质量发展。

本报告采用在线调查加线下访谈的方式,共回收有效问卷 1016 份、访谈企业 17 家。报告的第一部分介绍调查背景,第二部分介绍我国混沌工程当前使用情况,第三部分是混沌工程致力于提高的系统稳定性现状,第四部分聚焦混沌工程的发展建议。本报告以调查结果为基础,力争详实客观地反映混沌工程领域应用现状与痛点需求,为广大从业人员、专家学者和研究机构提供真实可信的数据参考。

本次报告的问卷发放、数据采集及文稿审核工作得到混沌工程实验室所有成员单位(见文末附录)及 InfoQ、中国云原生社区等单位或组织的大力支持,在此谨表示最衷心的感谢!同时也对接受混沌工程调查访问的用户朋友表示最诚挚的谢意!

观点摘要

1) 国内软件系统稳定性有较大可提升空间。

调查数据显示,近 20%的受访用户所负责的产品可用性低于 2 个 9 (意味着用户每个月要忍受超过 7.3 小时的服务故障),超过 4 成产品的可用性低于 3 个 9(意味着用户每个月要忍受超过 44 分钟的服务故障)。故障发生之后的解决情况也差强人意:仅不到一半的故障平均发现时长(MTTD)小于 1 小时; 故障平均修复时长普遍超过 1 小时,超过 6 成故障修复时间(MTTR)高于 1 小时,甚至有约 20%的服务故障修复时间超过 12 小时。日益复杂的 IT 系统与快速迭代的软件交付为系统稳定性的保障带来诸多挑战和不确定性,国内软件系统稳定性仍有较大提升空间。

2) 混沌工程是提升产品可用性的有效手段,是建立稳定性优先战略的技术核心。

调查数据显示,随 着混沌工程使用频率提升,低可用性(可用性低于 99%)的产品占比急剧萎缩,高可用性(可用性高于 99.99%)的产品占比迅速增长。混沌工程通过在生产环境中执行探索性测试以发现系统中的隐藏问题,在软件系统稳定性维护上展现出巨大价值。其中,提升服务可用性及降低故障修复时间是两大主要收益。65%的受访者认为采用混沌工程提升了服务可用性,49.85%的受访者认为混沌工程帮助降低了 MTTR(数据详见图 14)。企业需要建立稳定性优先(Stability First)的战略,构建系统稳定性保障体系,稳步推进数字化转型进程。

3) 混沌工程应用当前成熟度偏低,市场需要成熟、完善的混沌工程商业产品及咨询服务。

超过3成企业仅在小范围使用混沌工程,仅 8.68%的企业较大规模地应用混沌工程,混沌工程在企业内部渗透率有待进一步提高(数据详见图 6);同时,近半数企业在研发、测试环境中使用混沌工程,仅不到 20%的企业在生产环境中开展混沌工程演练,混沌工程在内部使用的技术复杂度不够高。而阻碍用户大规模、深度使用混沌工程的主要障碍是:缺乏相关经验,担心故障注入为生产环境带来风险。未来,需面向市场推出成熟、可信的混沌工程产品或咨询服务,以提升混沌工程的技术认可度、降低用户使用门槛、消除使用顾虑,推动行业步入发展快车道。

4) 企业期待构建完整、可度量的系统稳定性保障体系。

线下访谈数据显示,业务系统开发人员面对日益复杂的技术架构,急需应用适配新型 IT 架构的稳定性保障工具、建设路径指引以及稳定性度量体系。受访用户普遍表示,合理借力合作伙伴或技术研究机构的技术支持和实践经验,可以很大程度规避新技术采纳过程中可能遇到的障碍,缩短技术成熟周期。

一、调查背景

(一)调查方法及样本

1、调查方法

本次调查采用在线调查加线下访谈的方式,共收集到有效问卷 1016 份,访谈企业 17 家。

2、样本描述

参与调查用户所在行业:包括软件及服务、银行/保险/金融服务、电信、能源、硬件/半导体及零售业。

 
图 1. 行业分布

参与调查用户所在企业的规模:共分为 1-100 人、101-500 人、501-1000 人以及 1000 人以上四档。

 
图 2. 企业规模

参与调查用户所在企业成立年限:共分为不足 1 年、2-10 年、11-25 年以及 25 年以上四档。

 
图 3. 企业成立年限

参与调查用户工作岗位分布如下:软件工程师及运维工程师占到半数以上。

 
图 4. 被调查用户工作岗位分布

(二)报告术语界定

混沌工程:在分布式系统上进行的有经验指导的受控实验,目的是观察系统行为、响应并发现系统缺陷,以建立对系统承受生 产环境中湍流条件的能力和信心。

产品可用性:产品可用性计算方法: ( 1-产品不可用时间/年度总时间) x100%。

MTTR:平均修复时间(Mean time to repair,MTTR),是描述产品由故障状态转为工作状态时修理时间的平均值。

MTTD:平均检测时间(Mean time to detect,MTTD),用于描述故障平均发现时长。

二、混沌工程应用现状

混沌工程使用普及率较低,未来有广阔增长空间。受访用户中有超过 3 成从未使用过混沌工程,仅 3.94%左右的能频繁地(每天演练)使用混沌工程,混沌工程的使用普及率较低,未来应用前景广阔。

 
图 5. 混沌工程使用频率

混沌工程在企业内部的渗透率偏低,使用阶段也比较初级。

混沌工程在企业内部的渗透率偏低:超过 3 成企业使用混沌工程的产品比例低于 25%,仅 8.68%的企业内部应用混沌工程的占比超过 75%。混沌工程对企业内部的很多使用场景、产品都有较大可渗透空间。

混沌工程使用阶段较为初级:调查数据显示,仅不到 20%的用户在生产环境中开展混沌工程演练,44.41%的用户在研发/测试环境中开展演练,在预生产环境中开展混沌工程演练的占比也达到了 32.21%。较低的生产环境使用率体现了用户缺乏混沌工程直接作用于生产环境的信心。

 

混沌工程实践以国内开源工具为主。国内开源工具(如 ChaosBlade、ChaosMesh)是市场首选,但服务需求侧(甲方) 更倾向于采用商业产品为辅,而服务侧给方(乙方)倾向于内部自研为辅。调查数据显示,33.04%的服务需求侧倾向于采用成熟的商业产品作为辅助,以实现混沌工程快速落地、避开实施陷阱;而对于服务供给侧来讲,商业产品的吸引力(26.68%)小于自研平台(37.96%)及国外开源工具(29.07%)。

 
图 8. 混沌工程使用工具分布-需求侧

 

 
图 9. 混沌工程使用工具分布-供给侧

故障注入类型聚焦于基础资源层面,应用层及容器关注度偏低。网络资源故障和计算资源故障是最通常采用的故障注入类型,而应用类和容器类故障注入的关注度相对较低。

与故障注入类型一致,用户最常采用的故障演练实施靶点为主机/虚机,较少将故障直接实施在应用上,这可能与部分应用故障有一定的技术实现门槛,需要与开发框配合实现有关。

 
图 10. 故障注入类型分布

 

 
图 11. 混沌工程演练的实施对象/靶点

提升可用性是实施混沌工程的最大收益。与前述分析结果保持一致,可见混沌工程有助于提升用户最关注的服务可用性。

数据显示,近 70%使用过混沌工程的受访用户表示混沌工程可以“提升服务可用性”,显著高于其他收益项,如图 12。

 
图 12. 实施混沌工程的收益

用户实施混沌工程的主要障碍为经验的缺乏、对风险的担忧,国内市场需要成熟、完善的混沌工程商业产品或咨询服务降低技术实施难度。46.32%的用户缺乏使用混沌工程的相关经验,45.29%的用户表示担心“混沌工程可能会对生产环境带来某些风险”。而对于刚接触混沌工程的用户(偶尔使用混沌工程的用户)来讲,“缺乏相关经验”是其深度采纳混沌工程最大的障碍(见图 14);对于频繁使用混沌工程的用户来讲,对风险的担忧占上风(图 14 红色线);同时,随着混沌工程使用频率的提升,用户对衡量混沌工程效益的需求显著增长(图 14 橙色线)。

消除用户采纳混沌工程的顾虑,向市场推出成熟的混沌工程产品或咨询服务,降低用户的使用门槛是尽快推广普及混沌工程的有效手段;同时完备的系统稳定性度量体系、混沌实验故障分级机制可以量化混沌工程的实施效果,推动混沌工程精益化发展,提升混沌工程实施的投入产出比。

 
图 13. 实施混沌工程的最大障碍

 

 
图 14. 混沌工程的使用频率与采用混沌工程的障碍交叉分析

混沌工程概念不清晰,知识普及任重道远。超过半数被访用户对混沌工程和演习的概念分辨不清,约 1/4 的用户认为两者没有区别,仅有约 1/5 的用户能明确表述出两者的区别。对被访用户的反馈信息加工分析后(图 16 和图 17),可以发现混沌工程更偏向于在生产环境中执行探索性测试,具有随机性,以发现系统中的隐藏问题;演习更偏向于有计划性地验证某一具体猜想。

 
图 15. 混沌工程与演习是否有区别

 

 

技术就绪是实施混沌工程的前置条件,产品技术层面的就绪包括:完善的监控体系、可量化的系统稳定性评估体系及系统 已具备韧性基础。调查数据显示(图 18),65.59%的用户认为具备完善的监控体系是混沌工程实施的首要前置条件,超 60%的用户需要对混沌实验时故障注入后的影响有可量化的评估模型,而团队协作在用户的认知中重要性相对较低,48.09%用户选择此项。

 

 

与[转帖]中国混沌工程调查报告2021(观点摘要,调查背景和混沌工程应用现状)相似的内容:

[转帖]中国混沌工程调查报告2021(观点摘要,调查背景和混沌工程应用现状)

https://www.jianshu.com/p/9de94066ab46 随着分布式架构的普及以及云计算技术的成熟,国内企业应用云原生化推进业务系统的迭代速度越来越快,后端系统架构日趋复杂,服务间的依赖越来越多,调用的链路越来越长。宕机引发巨额损失、严重影响用户体验的新闻层出不穷,为了让云基础设

[转帖]全局负载均衡方案

https://www.cnblogs.com/charlieroro/p/15822238.html 本文经验更适用于混合云场景,公有云一般直接使用供应商提供的LB即可。 简介 当在多云(可能是混合云)中使用Kubernetes或Openshift部署应用时,需要考虑到如何跨集群分发应用流量。为了

[转帖]TiDB修改配置参数

https://www.jianshu.com/p/2ecdb4642579 在TiDB 中,“修改配置参数”似乎是个不精准的说法,它实际包含了以下内容: 修改 TiDB 的系统变量 修改集群配置- tiup 修改集群配置- set config 在线修改集群配置 总结 TiDB的配置修改比较混乱,

[转帖]TiDB修改配置参数

https://www.jianshu.com/p/2ecdb4642579 在TiDB 中,“修改配置参数”似乎是个不精准的说法,它实际包含了以下内容: 修改 TiDB 的系统变量 修改集群配置- tiup 修改集群配置- set config 在线修改集群配置 总结 TiDB的配置修改比较混乱,

[转帖]TiDB修改配置参数

https://www.jianshu.com/p/2ecdb4642579 在TiDB 中,“修改配置参数”似乎是个不精准的说法,它实际包含了以下内容: 修改 TiDB 的系统变量 修改集群配置- tiup 修改集群配置- set config 在线修改集群配置 总结 TiDB的配置修改比较混乱,

[转帖]TiDB修改配置参数

https://www.jianshu.com/p/2ecdb4642579 在TiDB 中,“修改配置参数”似乎是个不精准的说法,它实际包含了以下内容: 修改 TiDB 的系统变量 修改集群配置- tiup 修改集群配置- set config 在线修改集群配置 总结 TiDB的配置修改比较混乱,

[转帖]Sql Server - 文件和文件组体系结构

摘自 http://msdn.microsoft.com/zh-cn/library/ms179316(SQL.105).aspx SQL Server 将数据库映射为一组操作系统文件。数据和日志信息绝不会混合在同一个文件中,而且一个文件只由一个数据库使用。文件组是命名的文件集合,用于帮助数据布局和

[转帖]共识、线性一致性与顺序一致性

https://segmentfault.com/a/1190000022248118 etcd 是线性一致性读,而 zk 却是顺序一致性读,再加上各种共识、强弱一致的名词,看的时候总会混淆,这篇文档就列举下分布式系统中的那些"一致性名词",引用了很多其他的文章,不过会多出一些例子来帮助理解。 什么

[转帖]SpringBoot配置SSL 坑点总结【密码验证失败、连接不安全】

文章目录 前言1.证书绑定问题2.证书和密码不匹配3.yaml配置文件问题3.1 解密类型和证书类型是相关的3.2 配置文件参数混淆 后记 前言 在SpringBoot服务中配置ssl,无非就是下载证书设置一下配置文件的问题,这里主要记录我在配置的过程中遇到的坑点。 如果是新手上道的话建议结合其他的

[转帖]数据存储四种常见方式

常见的数据存储方式有四种:在线存储、近线存储、脱机存储和站外保护。 不同的存储方式提供不同的获取便利性、安全性和成本开销等级。 在大多数场景中,四种存储方式被混合使用以达到最有效的存储策略。 来看一看这四种数据存储方式各自的含义: 1. 在线存储 (Online storage): 有时也称为二级存