CN115033415A - 一种基于fmea的混沌工程故障评估方法 - Google Patents

一种基于fmea的混沌工程故障评估方法 Download PDF

Info

Publication number
CN115033415A
CN115033415A CN202210708008.8A CN202210708008A CN115033415A CN 115033415 A CN115033415 A CN 115033415A CN 202210708008 A CN202210708008 A CN 202210708008A CN 115033415 A CN115033415 A CN 115033415A
Authority
CN
China
Prior art keywords
fault
fatality
faults
fmea
failure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210708008.8A
Other languages
English (en)
Other versions
CN115033415B (zh
Inventor
朱柯
杜昆鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Tongchuang Yongyi Technology Development Co ltd
Original Assignee
Beijing Tongchuang Yongyi Technology Development Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Tongchuang Yongyi Technology Development Co ltd filed Critical Beijing Tongchuang Yongyi Technology Development Co ltd
Priority to CN202210708008.8A priority Critical patent/CN115033415B/zh
Publication of CN115033415A publication Critical patent/CN115033415A/zh
Application granted granted Critical
Publication of CN115033415B publication Critical patent/CN115033415B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/80—Management or planning
    • Y02P90/82—Energy audits or management systems therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computer Hardware Design (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

本发明公开了一种基于FMEA的混沌工程故障评估方法，包括如下步骤，S1、通过可观测性发现被测试分布式系统的组件以及组件之间的关联关系；S2、基于发现的组件，结合故障专家库，确定组件所属的故障类型以及相应故障类型下包含的所有潜在的故障；S3、基于FMEA计算所有潜在的故障的致命度；S4、基于致命度计算结果，对致命度大的故障进行预防和改善。优点是：降低混沌测试门槛，不需要测试人员对应用和基础架构有深入的了解，就可以方便的进行混沌工程测试；同时减少不必要的故障测试，提高了测试效率。

Description

一种基于FMEA的混沌工程故障评估方法
技术领域
本发明涉及混沌工程故障评估技术领域，尤其涉及一种基于FMEA的混沌工程故障评估方法。
背景技术
混沌工程作为保障分布式系统稳定性的重要技术，已成为推动企业IT韧性系统建设的强大助力。目前，国内一些企业成功的落地了混沌工程，覆盖互联网、软件、银行、证券、通信、零售、能源等行业和领域。
由于分布式系统的复杂性，导致混沌工程需要测试的案例非常多，从200个，到2000个，再到1万个都有。我们可以把IT系统可能发生的所有故障的集合叫做故障空间。
企业的IT系统可能有上百种应用，每种应用都是由多个微服务组成的，微服务之间互相依赖，微服务又依赖中间件和底层的容器、虚拟机或者物理机。从简单的SaaS、PaaS和IaaS的分层模型来看，大企业最上面的SaaS有上百个，中间的PaaS成百上千个，下面的IaaS也是成百上千个。因此整个故障空间可能有上万甚至上十万的数量。所以采用复杂分布式IT系统带来的故障空间的膨胀。
分布式系统的故障空间这么大，要完全覆盖这么多故障基本上是不可能的，投入的时间和成本是巨大的。因此落地过程中最重要的是对各种可能的故障进行识别后，还要对每个故障进行评估。只有准确的对每个故障进行评价，才可以分清故障的重要程度并确定需要预防和改善的优先级，才能提出并采取对应的应对措施。
混沌工程在企业内部的渗透率偏低，使用阶段也比较初级。混沌工程在企业内部的渗透率偏低：超过3成企业使用混沌工程的产品比例低于25％，仅8.68％的企业内部应用混沌工程的占比超过75％。企业内部的很多使用场景、产品尚未采纳混沌工程，未来有较大渗透空间。大部分还不能做到完全自动化，需要人为地去设计测试案例，再执行案例，存在测试效率低下，耗费较大人力的问题。现在很多业务的版本迭代速度非常快，如果每发布一个版本，都要去跟进、做测试，会产生极高的人工成本。
发明内容
本发明的目的在于提供一种基于FMEA的混沌工程故障评估方法，从而解决现有技术中存在的前述问题。
为了实现上述目的，本发明采用的技术方案如下：
一种基于FMEA的混沌工程故障评估方法，包括如下步骤，
S1、通过可观测性发现被测试分布式系统的组件以及组件之间的关联关系；
S2、基于发现的组件，结合故障专家库，确定组件所属的故障类型以及相应故障类型下包含的所有潜在的故障；
S3、基于FMEA计算所有潜在的故障的致命度；
S4、基于致命度计算结果，对致命度大的故障进行预防和改善。
优选的，所述组件包括应用、应用平台、数据库和基础设施；所述故障类型包括应用故障、应用平台故障、数据库故障和基础设施故障。
优选的，基于FMEA计算故障的致命度的计算公式为，
故障致命度＝故障严重度*故障发生度
其中，故障致命度表示故障所造成的破坏程度；故障严重度表示故障发生后对业务功能和经济性所造成影响的严重程度；故障发生度表示故障发生的可能频度。
优选的，步骤S4具体为，对各个故障的致命度计算结果进行降序排序，对排序中致命度位于预设阈值之前的故障或排序靠前的预设百分比数量的故障进行预防和改善。
本发明的有益效果是：1、简化了测试人员手工操作，提升测试效率。没有自动化的方法，混沌工程一个故障演练下来至少是小时级以上的。有了自动化的方法，做混沌工程测试的效率大大提升。编排一个混沌工程测试，编排它的靶点、实验配置、观测指标，几乎可以做到分钟级。几分钟时间，就可以把整个测试编排出来，然后一边做测试一边观察效果，同时去发现问题、分析问题，大大缩短了测试时间。2、降低混沌测试门槛，不需要测试人员对应用和基础架构有深入的了解，就可以方便的进行混沌工程测试。
附图说明
图1是本发明实施例中评估方法的流程示意图；
图2是本发明实施例中某银行应用的架构示意图；
图3是本发明实施例中故障专家库的示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。
实施例一
本实施例中，提供了一种基于FMEA的混沌工程故障评估方法，包括如下步骤，
S1、通过可观测性发现被测试分布式系统的组件以及组件之间的关联关系；
可观测性是一个云原生架构的通用的技术。可观测性是从系统内部出发，基于白盒化的思路去监测系统内部的运行情况。其中架构感知能力(也叫链路追踪)就是发现组件之间的依赖关系，相关的产品有Zipkin、SkyWalking、Pinpoint等主流追踪系统。
所述组件包括应用、应用平台、数据库和基础设施；所述故障类型包括应用故障、应用平台故障、数据库故障和基础设施故障。
所述应用故障包括，服务宕机、进程停止、进程假死、java类异常、熔断、负载隔离、服务降级、流控、运营容灾切换等(仅列出了其中的一部分)；
所述应用平台故障包括，WAS故障、Tomcat故障、Zookeeper故障、Nginx故障、Kafka异常、Redis故障、配置中心故障、注册中心故障等(仅列出了其中的一部分)；
所述数据库故障包括，数据库满、数据库连接异常、高频访问、内存泄漏等(仅列出了其中的一部分)；
所述基础设施故障包括，网络中断、网络丢包、网络报损坏、DNS故障、内存占满、CPU抢占、磁盘高IO、宕机、K8s节点故障、服务器宕机、磁盘满、NAS磁盘无法访问、负载均衡故障等(仅列出了其中的一部分)。
S2、基于发现的组件，结合故障专家库，确定组件所属的故障类型以及相应故障类型下包含的所有潜在的故障；
S3、基于FMEA计算所有潜在的故障的致命度；
基于FMEA计算故障的致命度的计算公式为，
故障致命度＝故障严重度*故障发生度
其中，故障致命度表示故障所造成的破坏程度；故障严重度表示故障发生后对业务功能和经济性所造成影响的严重程度；故障发生度表示故障发生的可能频度。
故障严重度可以量化进行评价，具体见表1。
表1故障严重度
严重度等级 严重度
10 致命影响
8 重大影响
6 较大影响
4 轻微影响
2 影响极小
影响程度可以用故障发生造成的业务损失作为标准。比如致命影响是业务损失超过1000万，重大影响是业务损失在500万到1000万之间，较大影响是业务损失在100万到500万之间，轻微影响是业务损失在50万到100万之间，影响极小是业务损失小于50万。
故障发生度可以量化进行评价，具体见表2。
表2故障发生度
发生度等级 发生度
10 发生频度非常高
8 发生频度高
6 发生频度低
4 很少发生
2 几乎不发生
发生频率可以用发生一次的时间周期作为标准。比如发生频率非常高是每周发生1次。频度高是每个月发生1次。频度低是每个季度发生1次。很少发生是每年发生1次。几乎不发生是每5年发生一次。台风每年都会发生，就属于发生度等级为4。
S4、基于致命度计算结果，对致命度大的故障进行预防和改善。
步骤S4具体为，对各个故障的致命度计算结果进行降序排序，对排序中致命度位于预设阈值之前的故障或排序靠前的预设百分比数量的故障进行预防和改善。
致命度的数值越大，则该故障所造成的破坏越大，应对其进行预防和改善。算出各个故障的致命度以后，就可以对故障进行降序排序。通常情况下，排名前的故障引发的致命度占总致命度数值的80％以上，需针对前20％的关键少数故障采取预防和改善措施，效果较为明显。
实施例二
如图1所示，本实施例中，以某银行的一个应用(分布式系统)为例，该应用涉及A、B、C、D四个服务、数据库和kafka的基础IT组件。在没有自动化的情况下，混沌工程测试人员需要查阅资料了解该应用的服务架构、IT基础架构、服务之间的依赖关系等，然后对每一个服务和IT组件编写故障测试案例，最终执行测试。对测试人员的能力要求高，做一次完整的测试需要准备很长时间，限制了混沌工程的开展。
采用本发明方法即可解决上述问题，具体过程如下：
1、通过可观测性发现被测试对象的模块、组件、基础设施以及之间的关联关系
通过可观测性的架构感知能力，发现被测覆盖主机、网络、系统、设备、应用等对象，可观测性的好处是可以实时的获取应用的真实运行的状态，减少了测试人员查阅技术文档的工作。
如图2，自动发现被测试应用的微服务依赖关系。可以看到服务之间的调用关系：A服务调用B服务，B服务调用C服务，C服务调用D服务。也可以看到IT基础架构：该应用涉及四个应用容器，和数据库IP1，数据库IP2，数据库IP3，缓存服务器IP4。
2、通过应用自身架构自动匹配高可用故障专家库
根据发现的服务、设备等组件，结合故障专家库，生成对应的故障点上涉及的故障类型，形成故障测试案例。故障专家库是一个根据生产和经验设定的专家库，包含了不同应用和组件的可能发生的各种故障。故障专家库可以从历史事故中进行统计，也可以依赖有经验的运维专家来评定。故障经验库如图3所示。
参考故障专家库，对第1步中发现的服务和组件，自动形成每个服务和组件的故障测试案例如表3：
表3故障测试案例
Figure BDA0003706153420000061
结合表3，按照类型统计故障的数量：
(1)服务故障：A、B、C、D这四个服务每个服务可能发生9种故障，一共就是36种故障。
(2)数据库故障：IP1、IP2、IP3这三个数据库每个数据库可能发生4种故障，一共就是12种故障。
(3)Kafka故障：IP4这个kafka可能发生一种故障。
针对例子中的应用，一共存在49种可能的单一的故障。这么多故障如果都进行混沌工程，那么成本很高。因此，需要对众多的故障进行评估，找到最有价值的故障。
3、使用FMEA评估故障
FMEA为潜在故障模式影响分析，是一种广泛使用的事前预防的重要定性分析方法。它针对某一产品的组件或某个过程，列举和探究其可能存在的潜在故障模式，并确定各个故障模式所造成的影响，以便进行事前预防和应对。FMEA最重要的作用是分析通过对风险度进行计算，从而对故障风险进行了量化，并提供了评定故障等级的标准。根据风险度数值的大小，对所有故障进行降序排序，就能够确定故障应对的优先顺序，为合理应对系统的故障提供依据，从而引导有限的资源优先去应对排名较高的关键故障。
如何评价失效模式的影响大小、需要引入“致命度”这一概念。“致命度”是用来评估失效模式所造成的破坏的指标。FMEA分析可以量化各类失效模式的致命度，并对其进行降序排序。在预防和改善时，只需重点预防和改善致命度较高、排名较靠前的失效模式。
根据FMEA致命度的计算公式，对例子中的A服务和B服务的故障进行计算(其他类似)，如表4：
表4故障致命度计算及排序
Figure BDA0003706153420000071
可以看出A服务和B服务的故障类型是一样，但是每个故障的发生度和严重程度不一样，导致同样的故障所造成的的致命度是不一样的。对致命度排序后，选择排名前10％的故障，本文例子中的49个故障选取其中最关键的10个故障进行混沌工程，大幅减少了工作量。
4、自动化测试
将混沌工程的流程编排成自动化任务，每天进行测试，减少人工手动完成。通常把混沌工程和DevOps流水线集成起来，每发布一次版本都会自动调用混沌平台的固定测试任务去执行。这样的话，无论每次在何时何地发布版本，混沌工程测试都会被自动地引用执行，大大降低了我们测试的人力成本，提高了测试效率。
通过采用本发明公开的上述技术方案，得到了如下有益的效果：
本发明提供了一种基于FMEA的混沌工程故障评估方法，该方法简化了测试人员手工操作，提升测试效率。没有自动化的方法，混沌工程一个故障演练下来至少是小时级以上的。有了自动化的方法，做混沌工程测试的效率大大提升。编排一个混沌工程测试，编排它的靶点、实验配置、观测指标，几乎可以做到分钟级。几分钟时间，就可以把整个测试编排出来，然后一边做测试一边观察效果，同时去发现问题、分析问题，大大缩短了测试时间。该方法降低混沌测试门槛，不需要测试人员对应用和基础架构有深入的了解，就可以方便的进行混沌工程测试。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims (4)

1.一种基于FMEA的混沌工程故障评估方法，其特征在于：包括如下步骤，
S1、通过可观测性发现被测试分布式系统的组件以及组件之间的关联关系；
S2、基于发现的组件，结合故障专家库，确定组件所属的故障类型以及相应故障类型下包含的所有潜在的故障；
S3、基于FMEA计算所有潜在的故障的致命度；
S4、基于致命度计算结果，对致命度大的故障进行预防和改善。
2.根据权利要求1所述的基于FMEA的混沌工程故障评估方法，其特征在于：所述组件包括应用、应用平台、数据库和基础设施；所述故障类型包括应用故障、应用平台故障、数据库故障和基础设施故障。
3.根据权利要求2所述的基于FMEA的混沌工程故障评估方法，其特征在于：基于FMEA计算故障的致命度的计算公式为，
故障致命度＝故障严重度*故障发生度
其中，故障致命度表示故障所造成的破坏程度；故障严重度表示故障发生后对业务功能和经济性所造成影响的严重程度；故障发生度表示故障发生的可能频度。
4.根据权利要求3所述的基于FMEA的混沌工程故障评估方法，其特征在于：步骤S4具体为，对各个故障的致命度计算结果进行降序排序，对排序中致命度位于预设阈值之前的故障或排序靠前的预设百分比数量的故障进行预防和改善。
CN202210708008.8A 2022-06-21 2022-06-21 一种基于fmea的混沌工程故障评估方法 Active CN115033415B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210708008.8A CN115033415B (zh) 2022-06-21 2022-06-21 一种基于fmea的混沌工程故障评估方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210708008.8A CN115033415B (zh) 2022-06-21 2022-06-21 一种基于fmea的混沌工程故障评估方法

Publications (2)

Publication Number Publication Date
CN115033415A true CN115033415A (zh) 2022-09-09
CN115033415B CN115033415B (zh) 2023-04-18

Family

ID=83127185

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210708008.8A Active CN115033415B (zh) 2022-06-21 2022-06-21 一种基于fmea的混沌工程故障评估方法

Country Status (1)

Country Link
CN (1) CN115033415B (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000331091A (ja) * 1999-03-17 2000-11-30 Muto Consultant Jimusho:Kk 商品開発における新品質システム及び該新品質システムの評価と管理を行う方法
JP2007316753A (ja) * 2006-05-23 2007-12-06 Toshiba Corp リスク評価装置及びプログラム
US20160224444A1 (en) * 2012-09-24 2016-08-04 Nec Corporation Distributed system, server computer, distributed management server, and failure prevention method
US10684940B1 (en) * 2018-09-18 2020-06-16 Amazon Technologies, Inc. Microservice failure modeling and testing
CN113010393A (zh) * 2021-02-25 2021-06-22 北京四达时代软件技术股份有限公司 基于混沌工程的故障演练方法及装置
CN113032260A (zh) * 2021-03-23 2021-06-25 福建天泉教育科技有限公司 基于组件化分布式系统的故障注入仿真测试方法及系统
US20210263836A1 (en) * 2020-02-20 2021-08-26 Jpmorgan Chase Bank, N.A. Chaos engineering trials
CN113468051A (zh) * 2021-06-30 2021-10-01 北京百度网讯科技有限公司 一种混沌实验的确定方法、装置、电子设备和存储介质
CN113986638A (zh) * 2021-11-26 2022-01-28 中国银行股份有限公司 基于混沌工程的故障演练方法、系统、存储介质和电子设备
CN114113984A (zh) * 2021-11-29 2022-03-01 平安壹账通云科技(深圳)有限公司 基于混沌工程的故障演练方法、装置、终端设备及介质

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000331091A (ja) * 1999-03-17 2000-11-30 Muto Consultant Jimusho:Kk 商品開発における新品質システム及び該新品質システムの評価と管理を行う方法
JP2007316753A (ja) * 2006-05-23 2007-12-06 Toshiba Corp リスク評価装置及びプログラム
US20160224444A1 (en) * 2012-09-24 2016-08-04 Nec Corporation Distributed system, server computer, distributed management server, and failure prevention method
US10684940B1 (en) * 2018-09-18 2020-06-16 Amazon Technologies, Inc. Microservice failure modeling and testing
US20210263836A1 (en) * 2020-02-20 2021-08-26 Jpmorgan Chase Bank, N.A. Chaos engineering trials
CN113010393A (zh) * 2021-02-25 2021-06-22 北京四达时代软件技术股份有限公司 基于混沌工程的故障演练方法及装置
CN113032260A (zh) * 2021-03-23 2021-06-25 福建天泉教育科技有限公司 基于组件化分布式系统的故障注入仿真测试方法及系统
CN113468051A (zh) * 2021-06-30 2021-10-01 北京百度网讯科技有限公司 一种混沌实验的确定方法、装置、电子设备和存储介质
CN113986638A (zh) * 2021-11-26 2022-01-28 中国银行股份有限公司 基于混沌工程的故障演练方法、系统、存储介质和电子设备
CN114113984A (zh) * 2021-11-29 2022-03-01 平安壹账通云科技(深圳)有限公司 基于混沌工程的故障演练方法、装置、终端设备及介质

Also Published As

Publication number Publication date
CN115033415B (zh) 2023-04-18

Similar Documents

Publication Publication Date Title
Herzig et al. The art of testing less without sacrificing quality
Nguyen et al. Automated detection of performance regressions using statistical process control techniques
Gegick et al. Prioritizing software security fortification throughcode-level metrics
US6716652B1 (en) Method and system for adaptive sampling testing of assemblies
Boranbayev et al. Development of a software system to ensure the reliability and fault tolerance in information systems based on expert estimates
CN112532455B (zh) 一种异常根因定位方法及装置
CN115114064A (zh) 一种微服务故障分析方法、系统、设备及存储介质
CN115033415B (zh) 一种基于fmea的混沌工程故障评估方法
Ammar et al. Enhanced weighted method for test case prioritization in regression testing using unique priority value
CN111813872B (zh) 一种故障排查模型的生成方法、装置、设备
CN109034419A (zh) 应用大数据理论优化核电厂在役检查项目和频率的方法
Gegick et al. Toward non-security failures as a predictor of security faults and failures
Maiga et al. An empirical study on the handling of crash reports in a large software company: An experience report
CN113868035B (zh) 一种自动化ltp性能测试方法及装置
Hamouri et al. Predicting Bug Severity Using Machine Learning and Ensemble Learning Techniques
JP7466479B2 (ja) 業務改善支援装置、プログラムおよびプログラムを格納した記憶媒体
CN109033446A (zh) 腐蚀类型判别方法及装置
Oyetoyan et al. Criticality of defects in cyclic dependent components
Prasad et al. Predictive maintenance in forging industry
CN118051657B (zh) 一种数据专线故障定位用例库测试方法及系统
Chen et al. Big data system testing method based on chaos engineering
Munson et al. Estimating test effectiveness with dynamic complexity measurement
Børretzen et al. Investigating the software fault profile of industrial projects to determine process improvement areas: an empirical study
Bodsberg Comparative study of quantitative models for hardware, software and human reliability assessment
Gegick et al. Predictive models for identifying software components prone to failure during security attacks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant