一种基于云平台历史故障数据的故障注入方法
阅读：173发布：2023-03-08
专利汇可以提供一种基于云平台历史故障数据的故障注入方法专利检索，专利查询，专利分析的服务。并且一种基于 云 平台历史故障数据的故障注入方法。技术领域：本 发明 涉及计算机 软件 测试领域中的一种验证云平台可靠性的故障注入测试方法。本发明能够有效利用已有历史故障数据指导云平台故障注入测试。现代云服务提供商大多都会内部维护一个自己的故障模式库，与此同时开源的故障日志也有很多，但是如何将这些已有的故障数据应用于云平台的可靠性检测是一个问题，解决好该问题能够极大地节约云服务提供商所花费的测试成本。我们提取了云平台故障模式的特征，分析了多故障的组合形式，并利用 覆盖 表生成方法得到待测组件相应的待注入故障模式序列，并利用故障特征约减待注入故障模式序列，以达到节省测试成本的目的。，下面是一种基于云平台历史故障数据的故障注入方法专利的具体信息内容。
一种基于云平台历史故障数据的故障注入方法
技术领域
背景技术
[0002] 云平台为企业应用及Web服务提供了一种具有革命性意义的新模式，越来越多的互联网企业将自己的产品及服务部署于云平台之上，云平台的可靠性直接影响着这些应用服务的稳定性，然而由于云平台规模庞大、结构复杂，想要做到其软硬件设备设施完全可靠是不现实的。
[0003] 故障注入测试是验证云平台可靠性的重要手段之一。故障注入测试，即人为地向云平台中注入若干故障，若云平台依然能够正常工作，则可以认为云平台具有较好的容错性，其可靠性较高，若不能正常工作，则该云平台容错能力不足，可靠性欠佳。
[0004] 故障注入测试中有两个主体：待注入的故障和目标组件。其中，大多数云平台故障模式分析的工作是基于系统日志或故障报告的。Jia Tong等人[1]基于开源云平台日志数据，分析其中由Bug引发的故障特征，提出了一个自动化的方法，能够从日志数据中精确地找出由Bug引发的故障.Peter Garraghan等人[2]通过分析谷歌Cloud trace工具的日志，分别研究了工作量及服务器中故障及修复时间的相关特征。Chen X等人[3]通过分析谷歌云集群工作记录和其中故障的特征，分别提出了工作和任务故障的统计特征，并将它们与关键调度约束、节点操作、人为因素联系起来；此外，关于故障注入测试框架及工具的研究也有很多。例如：由于线下测试有许多故障场景难以被覆盖，故而产生了故障演习：与其等待故障发生，不如演习故障发生的场景[4]。在此基础上，HS Gunawi等人[5]提出了FaaS，一种提供在线演习的新型云服务。在可靠性测试中，随机测试通常是一种行之有效的测试方法，Netflix工程师基于Chaos Engineering[6]提出了 Chaos Monkey，模拟类似猴子随意点击的思路，是一种基于随机思想的云平台故障注入测试。
[0005] 我们可以发现，目前关于云平台故障模式分析以及云平台故障注入测试工具或框架的研究工作十分丰富，然而却鲜有工作将两者结合起来，即通过分析研究故障模式来指导故障注入测试。本发明主要的工作是通过分析历史宕机事故报告中的故障模式、提出基于历史的故障组合方法，使得历史故障数据能够被充分利用，有效地为故障注入测试做贡献，此外，本发明找出了多故障交互作用对云平台产生影响时的一般组合形式。
发明内容
[0006] 发明目的
[0007] 本发明的目的是要提供一种新的云平台可靠性检测方法，通过对历史故障数据的分析，使我们能够充分利用历史数据信息指导云平台故障注入测试。
[0008] 详细描述
[0010] 1)ID：我们给每个故障模式一个身份编号，用数字来代表该故障模式。
[0011] 2)Component：该特征用来描述故障模式是在云平台的哪个组件上发生的，可作为后续组合算法中的输入参数之一。由于我们收集的故障模式主要集中在云平台的基础设施层，因此参考云平台的分层结构，该特征的取值主要是云平台基础设施层的硬件设备，如服务器、路由器等。
[0012] 3)Fix：该特征用来描述故障的修复方法，该特征可与impact特征共同应用于在组合算法的结果约减。我们分析了云平台事故报告对故障的处理过程，并提取出了一些常见的修复故障的方法如下：
[0013] a)ADDRESOURCES：即引起故障的原因可能是计算资源、存储资源、网络资源短缺，因此修复方法是增加相应的资源。
[0014] b)FIXHW：即引起该故障的原因可能是硬件问题，因此修复方法是修复硬件。
[0015] c)FIXSW：即引起该故障的原因可能是软件问题，因此修复方法是修复软件。
[0016] d)FIXCONFIG：即引起该故障的原因可能是配置问题，因此修复方法是修复配置文件。
[0017] e)RESTART：有些故障的修复可能需要重启受影响的组件。
[0018] f)RESTOREDATA：通过数据转存或数据重定向等手段修复故障。
[0019] g)ROLLBACKSW：通过回滚操作修复故障。
[0020] h)UNKNOWN：以及一些未知的修复操作，适用于人为引起的故障。
[0021] 4)Root cause：该特征用来描述云平台事故的根本原因。我们将云平台事故报告中关于事故发生的原因做了归纳总结，提取出其中与云平台可靠性相关的根因，并以我们收集的事故报告为样本库，统计了每个根因发生的比例，利用该比例可以对组合算法中的待注入故障序列结果进行优先级的排序，确保经常发生的故障会在第一时间被检测出来。
[0022] a)Upgrade：所占比例为16％。在云平台维护过程中，软硬件的升级更新可能会对系统产生意料之外的影响。通过研究相关案例我们发现，某一组件或功能的升级故障，可能会影响到其周边组件或相关功能，进而引发严重的故障，甚至导致云平台宕机事故。
[0023] b)Network：所占比例为15％。网络设施是云平台提供服务的基础，网络设施一旦出现问题可能会导致严重的后果。
[0024] c)Config：所占比例为10％。错误的配置有时同样会引发云平台故障。在云平台的维护、升级、改造过程中，由于相关人员的疏忽导致系统配置不当，可能会导致严重的后果，除了相关人员的疏忽之外，软件当中的bug等也可能影响相应的配置，导致故障的发生。
[0025] d)Load：所占比例为9％。云平台所提供的服务都是在一定负载范围内的，而为了节省资源，云平台也不会刻意设计超出自身使用预期的负载能力，因此，异常的过高的负载可能会导致严重的事故。
[0026] e)Power：所占比例为6％。云平台中成千上万的硬件设备需要稳定可靠的、高负载量的电力系统。
[0028] g)Server：所占比例为3％。服务器在云平台中扮演多种角色，不同类型的服务器负责不同的任务，共同实现云平台的功能。
[0029] h)Hardware：所占比例为1％。硬件原因引起的故障是云平台基础设施层最常见的故障原因之一。
[0030] i)Unkown：有些事故报告并没有明确提及导致该事故发生的原因，我们将它们归为Unknown。
[0031] 5)Impact：该特征用来描述该发生故障后对云平台产生的影响。根据云平台事故报告中的描述，我们将故障对云平台的影响分为以下几类：
[0032] a)FULLOUTAGE：表明该故障会对云平台造成极为严重的影响，导致组件或云平台宕机。
[0033] b)OPFAIL：表明该故障会使某次关键操作无效化。
[0034] c)PERFORMANCE：表明该故障会使云平台某硬件设备的性能下降。
[0035] d)LOSS：表明该故障会导致数据丢失，包括服务器、存储器以及网络链路中的数据。
[0036] e)STALE：表明该故障会导致数据过期、不一致等后果。
[0037] f)SECURITY：表明该故障会为平台带来安全上的问题。
[0038] 6)AftID：该特征表明在故障ID为AftID的故障发生之后该故障才会发生。常见的故障场景如满足因果关系的两个故障，存在故障发生的先后顺序。
[0039] 7)nAftID：该特征表明在故障ID为nAftID的故障发生之后该故障绝不会发生。常见的故障场景如服务器发生宕机故障，那么关于该服务器的其它故障就不会发生。
[0040] 此外，我们还发现多个故障之间可能存在的组合关系，可指导我们进行多故障组合注入。我们将其分类如下：
[0041] 1.顺序发生
[0042] 顺序发生是指在某次事故当中，引发此次事故的若干个故障是按一定顺序依次发生的，多个故障之间存在一定的关系，这种关系可能是：
[0043] 1)多个故障之间存在因果关系，由前一个故障导致了后一个故障。
[0044] 2)在前一个故障恢复的过程中产生了新的故障。
[0045] 2.组合发生
[0046] 组合发生是指在某次事故中，引发此次事故的若干个故障必须同时发生，可以分为以下两种情况：
[0047] 1)某一组件和其容错组件同时发生故障。
[0048] 2)某两个故障A、B同时发生，且A、B之间有依赖关系(A所在组件能否正确运行需要依赖于B 所在组件)。
[0049] 第二步，我们利用云平台拓扑结构图，选出最大注入故障数mf个目标组件对集合 A＝{(A11，A12......A1mf)...(Ai1，Ai2......Aimf)}，其中mf表示一次注入任务所允许向待测系统中注入的故障数量的最大值，A表示目标组件，i表示第i个组件对，其中共有mf个目标组件。
[0050] 第三步，我们为上一阶段中每一个组件分别选取出可以注入的故障模式集合。假设待测组件为Ai，通过对故障模式数据库的遍历，我们可以从故障模式库中选取所有满足条件“Component＝Ai”的故障模式加入该组件相应的故障模式集合Bi＝{(bi1，bi2......bin)}，其中Bi表示第i个组件相对应的故障模式集合，bij表示第i个组件的故障模式集合中的第j个故障模式。
[0051] 第四步，我们根据待测组件集合A和相应的故障模式集合B，利用组合测试当中的覆盖表生成算法，生成mf维覆盖表，作为待注入的故障序列。具体来说，我们将待测组件集合A＝{A1，A2......An(n≤N)}，每个组件相应的故障模式集合B＝{B1，B2......Bn}作为输入，集合A可以看作是待测软件的参数，而集合B 可以看作是每个参数对应的取值，应用组合测试覆盖表生成方法最终得到关于云平台组件集合与待注入故障模式集合的覆盖表，即待注入故障序列集合。
[0052] 得到该覆盖表之后，我们可以根据根因的统计信息对每条待注入故障序列进行排序。即提取出每条待注入故障序列中每个故障模式的根因，将这些根因发生的概率相加得到该条待注入故障序列发生的概率，概率越高意味着该待注入故障序列中的故障越容易发生，可以优先进行注入以期望在最短时间内发现最多的问题。
[0053] 最后，我们对结果进行约减。通过对云平台历史数据的分析，我们总结出了以下几种策略以约减组合空间。
[0054] 1.根据故障模式标签中的“AftID”可确定约束类型1：
[0055] 假设组件A1中的故障模式b1，拥有标签“AftID”，且其值为b2，那么：
[0056] 1)若此时存在组件A2，其恰好有故障模式b2，那么需要保证b2先被注入，再注入b1，不符合这种顺序的待注入故障序列可以被约减。
[0057] 2)若所有的组件均没有故障模式b2，则组件A1中含有b1的待注入故障模式序列可以被约减。
[0058] 该策略伪代码如下：
[0059]
[0060] 适用场景：该约束类型大多发生在故障及其容错路径之间，能够约减一部分容错路径(包括故障监控 /检测系统、故障恢复机制)上的故障与其它不相关故障之间的组合。
[0061] 例如：公共电源故障和不间断供电系统之间就存在这种关系。不间断供电系统是公共电源的容错系统，当公共电源系统正常时，向不间断供电系统中注入故障是无意义的，因此一些不相关的故障(比如路由器的故障，磁盘的故障等等)与不间断供电系统故障相组合就可以被约减。
[0062] 2.根据故障模式标签中的“nAftID”可确定约束类型2：
[0063] 假设组件A1中的故障模式b1，拥有标签“nAftID”，且其值为b2，那么：
[0064] 若此时存在组件A2，其恰好有故障模式b2，组件A1的故障模式b1不能在b2之后被注入；
[0065] 该策略伪代码如下：
[0066]
[0067] 适用场景：该约束类型大多发生在一些特殊场景下。
[0068] 场景1：某些故障(如断电、过载、驱动损坏、升级故障等等)会导致路由器crash(即该故障的标签 Impacts＝＝FULLOUTAGE)，那么此时再注入1)该路由器本身的故障(即Component＝＝该路由器id)、 2)其它组件与该路由器在数据交互时的故障(如某服务器给该路由器发送的数据包丢失等故障)，是无意义的。
[0069] 场景2：某些故障会导致组件的某些关键操作(如登录、支付、搜索)失效(即该故障的标签Impacts＝＝ OPFAIL)，那么此时再注入与该操作有关的故障(如登录之后修改信息时的故障)是无意义的。
[0070] 3.在同一个组件中，若两个故障产生的影响相同、修复方法也相同，那么可以把这两个故障归为一类。即针对故障模式集合Bi中的任意两个故障模式bj.Fix＝＝bk.Fix&&bj.Impact＝＝bk.Impact，则bj与bk可归为同一类故障。
[0071] 该策略伪代码如下：
[0072]
[0073] 约束类型1与约束类型2适用于得到待注入故障序列的覆盖表之后，对该表进行约减，减少待注入故障序列，而对故障模式数量的约减方法适用于在故障模式选取阶段为各个组件选取故障模式之后对每个组件对应的故障模式库进行约减。附图说明
[0074] 图1是一个简单的Oracle云平台典型物理架构，我们将其作为实例验证对象。该Oracle云平台典型物理架构主要包括以下9种基础设施：光纤收发器、防火墙、VPN服务器、云平台管理服务器、云软件管理服务器、云计算物理服务器、千兆以太网交换机、光纤交换机、存储设备。图中的连线表示数据通路，长虚线表示按广度优先选择组件的路径，短虚线表示按深度优先选择组件的路径。
具体实施方式
[0075] 我们选择以一个简单的Oracle云平台典型物理架构(图1)作为实例验证对象。该Oracle云平台典型物理架构主要包括以下9种基础设施：光纤收发器、防火墙、VPN服务器、云平台管理服务器、云软件管理服务器、云计算物理服务器、千兆以太网交换机、光纤交换机、存储设备。在本实例中我们故障注入的对象即为这9种基础设施组件。
[0076] 我们分别为上述9种基础设施组件选择若干故障模式。如表1所示，表中前两列分别表示故障模式所属的组件与ID，第三列表示该故障模式的名称，后三列分别表示该故障模式的修复方法、根因和对系统产生的影响。
[0077] 表1故障模式
[0078]
[0079]
[0080] 我们取组件两两之间进行组合，每次分别向相应的两个组件中各注入一个故障，即最大注入故障数 mf＝2，分别使用深度优先(图1中短虚线路径)、广度优先(图1中长虚线路径)、全组合选择策略，得到相应的组件集合，并将组件看作参数，对应组件的故障模式看作该参数的取值，应用基于历史的故障组合方法，分别得到每个组件集合相应的2维待注入故障序列集合。
[0081]
[0082]
[0083] 附表5
[0084]
[0085] 附表6
[0086]
[0087] 附表7
[0088]
[0089] 附表8
[0090]
[0091] 得到待注入故障序列集合之后，我们依据“在同一个组件中，若两个故障产生的影响相同、修复方法也相同，那么可以把这两个故障归为一类”这一策略逐条判断待注入故障序列是否能够被约减。例如在以光纤收发器与防火墙为目标组件的故障序列集合中，由于光纤收发器中的故障“光纤收发器两端不能通信”和“光纤收发器宕机”两者对系统造成的影响相同(光纤收发器完全无法工作)、修复方法相同(重启光纤收发器)，因此可以将这两个故障归为同一类，在与防火墙中的故障相组合时可以约减其中的3条故障序列。以深度优先策略为例，我们在上一步得到的故障模式序列中找出所有可以被该策略约减的故障序列，共计12条故障序列(附表中标粗的故障序列)。
[0092] 参考文献
[0093] [1]Jia T，Li Y，Tang H，et al.An Approach to Pinpointing Bug-Induced Failure in Logs of Open Cloud Platforms[C]//IEEE，International Conference on Cloud Computing.IEEE，2016：294-302.
[0094] [2]Peter Garraghan and Paul Townend and Jie Xu，”An Empirical Failure-Analysis of a Large-Scale Cloud Computing Environment，”IEEE 15th International Conference symposium on High-Assurance Systems Engineering，pages 113-120，Miami，USA，January9-11，2014.
[0095] [3]Chen X，Lu C D，Pattabiraman K.Failure Analysis of Jobs in Compute Clouds：A Google Cluster Case Study[C]//IEEE，International Symposium on Software Reliability Engineering.IEEE，2014：341-346.
[0096] [4]Leesatapornwongsa T，Gunawi H S.The Case for Drill-Ready Cloud Computing[C]//the ACM Symposium.ACM，2014：1-8.
[0097] [5]Gunawi H s，Do T，Hellerstein J M，et al.Failure as a Service (FaaS)：A Cloud Service for Large-Scale，Online Failure Drills[J].2011.
[0098] [6]Basiri A，Behnam N，Rooij R D，et al.Chaos Engineering[J].IEEE Software，2016，33(3)：35-41。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种基于水上钢管桩基础的暴露试验平台 | 2021-06-08 | 0 |
| 基于电商平台的礼物赠送方法和装置 | 2020-10-31 | 1 |
| 基于GISDK平台对TransCAD进行二次开发系统 | 2020-11-25 | 3 |
| 一种基于Android平台的入侵检测系统 | 2020-12-13 | 1 |
| 基础软件平台的质量评估方法 | 2021-01-01 | 1 |
| 基于Revit平台的结构件构造方法和装置 | 2020-08-14 | 4 |
| 一种基于IOT平台的垃圾桶管理系统 | 2021-03-08 | 5 |
| 一种基于IFC的输变电工程三维数字化管理平台 | 2022-07-23 | 2 |
| 基于云平台的3D打印制造系统及其实现方法 | 2021-10-16 | 4 |
| 基于业务系统的交管设施运维平台 | 2020-09-03 | 1 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
基台热门专利
QQ群二维码
意见反馈
意见反馈