配置windows错误恢复
windows错误恢复 时间:2021-02-28 阅读:()
软件学报ISSN1000-9825,CODENRUXUEWE-mail:jos@iscas.
ac.
cnJournalofSoftware,2015,26(6):12851305[doi:10.
13328/j.
cnki.
jos.
004823]http://www.
jos.
org.
cn中国科学院软件研究所版权所有.
Tel:+86-10-62562563软件配置错误诊断与修复技术研究陈伟1,黄翔2,乔晓强1,魏峻1,3,钟华1,31(中国科学院软件研究所软件工程技术研发中心,北京100190)2(中山大学信息科学与技术学院,广东广州510006)3(中国科学院软件研究所计算机科学国家重点实验室,北京100190)通讯作者:陈伟,E-mail:wchen@otcaix.
iscas.
ac.
cn摘要:软件的多样性、复杂性、灵活性和高度可定制性对系统的正确配置提出了挑战,配置错误已经成为影响应用服务质量的关键问题之一.
很多学者和研究机构致力于配置错误的检测、诊断和故障修复的相关技术和方法研究,以提高复杂应用系统的可用性和可靠性.
为系统了解软件配置错误相关的研究现状和进展,建立了一种多方面、多角度的分析框架对该领域的主要研究工作进行分类总结和分析评价,该分析框架覆盖了方法类型、方式和适用范围这3个方面的多个角度.
基于该分析框架的分析结果,总结了当前软件配置错误相关研究中存在的问题,并针对今后该领域的研究趋势进行了展望,对继续和深入研究具有一定的指导意义.
关键词:软件配置;故障诊断;错误修复中图法分类号:TP311中文引用格式:陈伟,黄翔,乔晓强,魏峻,钟华.
软件配置错误诊断与修复技术研究.
软件学报,2015,26(6):12851305.
http://www.
jos.
org.
cn/1000-9825/4823.
htm英文引用格式:ChenW,HuangX,QiaoXQ,WeiJ,ZhongH.
Researchonsoftwaremisconfigurationtroubleshooting.
RuanJianXueBao/JournalofSoftware,2015,26(6):12851305(inChinese).
http://www.
jos.
org.
cn/1000-9825/4823.
htmResearchonSoftwareMisconfigurationTroubleshootingCHENWei1,HUANGXiang2,QIAOXiao-Qiang1,WEIJun1,3,ZHONGHua1,31(TechnologyCenterofSoftwareEngineering,InstituteofSoftware,TheChineseAcademyofSciences,Beijing100190,China)2(SchoolofInformationScienceandTechnology,SunYat-SenUniversity,Guangzhou510006,China)3(KeyLaboratoryofComputerSciences,InstituteofSoftware,TheChineseAcademyofSciences,Beijing100190,China)Abstract:Softwareconfigurationhasbeenabigchallengeduetothediversity,complexity,flexibilityandcustomizabilityofasystem.
Configurationerrorhasbecomeadominantcauseleadingtosystemfailureandserviceoutage.
Toimprovesoftwareavailabilityandreliability,manyresearchersandinstitutionshavedevotedtheireffortsonsoftwaremisconfigurationtroubleshooting.
Thispaperfirstbuildsananalyticalframeworkwithestablishmentof3aspectsandmultipleperspectives,coveringthemethodtype,styleandapplicability.
Basedonthisframework,thepaperprovidesanoverviewofthestateofartofmisconfigurationtroubleshootingalongwithanalysisonthecurrentleadingmethodsofsoftwaremisconfigurationtroubleshooting.
Finally,thispapersummarizestheshortcomingsinthecurrentresearchandoutlinesthedevelopmentprospectsoffutureresearch.
Thispaperaimstoprovidesomeavailableinformationandbeneficialinsightforfutureresearches.
Keywords:softwareconfiguration;failurediagnose;errorfix配置(configuration)是软件系统不可或缺的组成部分,广泛存在于软件部署、升级以及迁移等应用场景中.
配置覆盖了软件系统及其环境的多个方面,包括配置文件、已安装的软件,甚至包括底层硬件环境.
广义上来讲,基金项目:国家自然科学基金(61402453);国家高技术研究发展计划(863)(2013AA041301);国家科技支撑计划(2013BAH05F03,2012BAH14B02)收稿时间:2014-05-13;修改时间:2015-01-05,2015-01-21;定稿时间:2015-02-061286JournalofSoftware软件学报Vol.
26,No.
6,June2015软件配置是指以用户需求和软件的功能、结构及主要特性等为依据,选择和确定相关硬件、软件和固件的型号、版本及数量,规划软件放置位置和关联关系,设置软件系统相关参数值等;狭义上的软件配置主要是指对软件系统配置参数取值的设置.
随着计算机技术和Internet的快速发展,软件系统在实现技术、应用模式和系统规模等方面发生了巨大变化,呈现网络化、协同化、普适化和服务化的趋势,软件应用的平台开放、动态、分布等特点也日益显著.
复杂应用(尤其是复杂网络应用)往往通过大量配置参数提高系统的可定制性,通过不同的配置参数取值获得期望的系统功能和性能特性.
软件配置往往决定了诸如数据存储位置、服务器端口绑定以及使用哪些模块和算法等多方面的问题,但是大量配置参数的存在及使用的灵活性为应用的正确配置带来极大困难[1],为系统后续运行的可靠性、可用性以及系统性能等带来极大挑战,具体表现如下:(1)配置错误已成为导致系统异常、服务失效甚至是系统崩溃的显著原因之一.
基于对3个商业互联网服务的研究,Oppenheimer等人[2]发现,50%以上的系统运维管理故障源于配置错误,并导致系统服务无法使用;Gray[3]的研究发现,42%的系统宕机与运维管理相关,其中,软件、硬件和环境错误分别占25%,18%和14%;还有相关研究发现,80%以上的网络故障也都是由于配置错误引起的[4].
(2)配置错误会带来灾难性后果,严重影响应用的服务质量,带来经济和声誉等方面的负面影响.
近年来,包括MicrosoftAzure[5],AmazonEC2[6]和Facebook[7]在内的很多复杂网络服务或应用系统都经历过配置错误导致的运行中断,使数百万用户受到影响.
2010年,Facebook的一个配置错误使多达500万用户在几个小时内无法访问其网站和服务[7];又如在2009年,由于DNS的配置错误,导致互联网的整个".
se"域在一个多小时内无法正常运行,使大约100万台主机受到影响[8].
本文首先给出软件配置错误定义,归纳总结了导致配置错误的主要原因,界定了软件配置错误诊断与修复的问题域,并对其相关研究领域进行了概述.
其次,从方法类型、特征和适用范围这3个方面的多个角度建立了配置错误诊断与修复方法的分析框架.
然后,简要介绍了该领域的研究现状和代表性工作,并基于分析框架对当前的研究工作进行分类总结和分析评价.
最后,本文分析总结了当前软件配置错误的诊断研究中存在的问题,并对未来研究趋势进行展望.
1概述软件配置错误(configurationerror或misconfiguration)定义为由于软件配置项的值设置错误而导致系统运行产生确定性(deterministic)故障,并产生相应的错误信息[9].
因此,配置错误可以认为是软件系统中存在的这样一类问题,即:软件代码本身正确,但是由于不正确的安装、配置或系统升级而导致软件系统无法按照预期正确运行[10].
导致软件配置错误的主要原因可以归纳为以下几点:(1)应用规模庞大且配置参数众多,需要大量的时间和精力进行配置方法的学习和参数用途的理解.
复杂应用常提供大量的配置参数项来满足用户对系统功能和性能相关特性的定制需求,增强系统的灵活性和可定制性.
大规模复杂应用往往由上层应用服务和下层的系统支撑软件组成,包括Hadoop[11],FreePastry[12],HBase[13]在内的系统软件均具有数量众多的配置项(例如,Hadoop具有超过400个配置项)[1].
随着云计算的发展和集群技术的运用,系统规模和参数配置项随着结点数量成倍增长.
(2)应用组件存在交互和相互依赖,导致配置参数间存在关联,给应用配置及其错误诊断带来困难.
复杂应用运行在多种/多层中间件平台上,分层架构使组件之间、容器之间以及组件与容器之间存在关联和依赖,也使应用及环境的配置参数间存在关联和约束,例如配置参数取值的一致性、依赖性、取值范围的相互制约等.
如果忽略这些关联和约束,将极易发生配置约束违背,产生系统运行故障.
(3)软件系统配置过程在一定程度上依赖于系统管理人员的知识和经验.
首先,用户使用和配置软件需要花费大量的时间和精力进行学习,研究数据证明,大部分参数配置错误发生在系统的初次使用和配置中[14,15],并且文档与系统的不一致使用户可能获取错误的指导信息[16,17];其次,人为操作导致的参数设置错误难以避免,其中包括拼写错误、语义错误等,长期以来,人工操作一直是导致互联网服务陈伟等:软件配置错误诊断与修复技术研究1287异常与不可用的显著因素之一[2],而其中一半以上的错误是由人为因素引起的[18,19].
(4)系统配置错误的辅助诊断能力直接影响诊断效率与准确性,配置错误修复主要依赖于已有经验和外部技术支持.
应用故障发生时经常抛出一个泛泛的错误提示,甚至没有任何提示,错误信息内容缺少可用的错误原因、系统状态和错误范围描述,无法从中获取有效的线索.
已有研究表明,仅仅只有7.
2%~15.
5%的配置问题能够给出较为清晰准确的信息提示来支持错误诊断[14].
在缺少有效提示信息的情况下,配置错误的定位和诊断花费的时间和精力随之成几倍甚至十几倍的增长.
软件配置错误诊断与修复(softwaremisconfigurationtroubleshooting,简称SMT)的对象是配置错误导致的系统故障和异常,目标是确保应用系统正确运行、保障其可靠性和可用性,核心内容包括配置错误的发现(detect)、诊断(diagnose)和修复(fix).
SMT相关的研究领域主要有自动配置和软件故障诊断.
自动配置方法的主要研究目标是实现配置的自动化执行,减少人工操作,从而降低配置出错几率.
当前,自动配置方法研究主要面向底层的网络设备,应对互联网大量的配置需求以及配置复杂度日益增长的趋势.
自动配置是互联网配置管理研究领域的一部分,按照流程,可以将自动配置分为配置自动生成[20,21]、配置验证[22,23]和配置自动实现[24].
清华大学的李福亮等人[25]对互联网自动配置领域的研究现状和代表工作进行了综述.
软件系统故障诊断方法的主要思想是:利用监测框架收集系统监测数据,在系统正常运行状态下建立状态模型,将监测到的系统状态与通过模型预测出的理想状态进行比较,把检测到的偏差作为可能的故障,据此定位问题出现的原因.
软件系统故障检测与诊断的常用方法包括基于规则和信号的方法[26]、基于行为模型的方法[27]、基于度量分析的方法[28]、基于性能模型的方法[29]等.
软件配置错误诊断与修复作为一个细分的研究领域,与上述两个领域既有关联又有区别:首先,与网络设备不同,软件系统复杂多样且配置错误难以避免,因此,软件配置错误诊断主要从如何发现、诊断和修复配置错误的角度来提高系统的可靠性与可用性;另一方面,配置错误是引起系统故障的因素之一,软件配置错误诊断在方法上与系统故障诊断存在相似性,不同的是,前者完全面向配置错误导致的系统故障和异常,更加具有针对性.
软件配置管理(softwareconfigurationmanagement,简称SCM)与SMT名称相近,但分属于不同的概念范畴,其问题域和研究内容上有根本性区别.
软件配置管理目的是协调软件开发使得混乱减到最小,是一种标识、组织和控制修改的技术.
SCM研究怎样在不同时刻标识软件系统的配置,以便系统化地控制配置的改变,以及在整个软件生命周期内维护配置的完整性和可追踪性,主要包括配置识别、变化控制、状态记录报告以及审计[30].
2配置错误诊断与修复技术分析框架SMT方法的目标系统、故障类型、采用的方法、具有的功能特征以及必须的前提条件和假设等方面各有特点,为了对SMT的研究现状进行分析、归纳与总结,本文从多个方面和角度建立了SMT的技术分析框架,如图1所示.
该框架以配置错误诊断与修复的过程为依据,分别从功能、基本方法、前提条件、目标系统和故障类型多个角度进行分析总结,覆盖了方法类型(type)、方法特征(feature)和适用范围(applicability)这3个方面.
Fig.
1SMTanalyticalframework图1SMT分析框架应用软件系统软件操作系统目标系统故障类型功能故障性能异常系统故障发现诊断修复功能代码测试用例配置约束知识库…条件程序分析统计学习对比重放技术…方法1288JournalofSoftware软件学报Vol.
26,No.
6,June20152.
1方法类型SMT从基本方法角度可以分为基于程序分析(programanalysisbased)的方法、基于统计学习(statisticsbased)的方法、基于重放技术(replaybased)的方法和基于对比(comparisonbased)的方法以及基于上述两种或多种方法的混合方法,分类如图2所示.
Fig.
2SMTclassification图2SMT方法分类2.
1.
1基于程序分析的方法(programanalysisbased)基于程序分析方法的核心思想是:将目标系统作为白盒(whitebox),采用与软件测试领域相似的技术手段,重点关注系统中与配置参数读写及操作相关的语句,通过数据流和控制流等信息流的分析,较为准确地获取配置参数影响的语句和执行路径,实现配置错误导致的系统异常检测与定位.
基于程序分析的SMT可以进一步分为基于静态程序分析(staticanalysisbased)的方法和基于动态程序分析(dynamicanalysisbased)的方法,如图2所示.
基于静态程序分析的方法主要对目标系统进行静态数据流分析,大多从配置参数读取位置为起始,获取并分析配置参数访问、使用和修改的相关语句,实现配置错误诊断.
动态程序分析方法通过对目标系统代码的植入和运行时监控来获取系统运行时的动态数据流和控制流信息,重点关注和分析配置参数项影响的系统执行路径.
2.
1.
2基于统计学习的方法(statisticsbased)基于统计学习的SMT将目标系统作为黑盒(blackbox),观察、收集系统行为(behavior)、状态(state)及与事件(event)相关的历史数据,再基于概率统计和机器学习等方法分析挖掘出目标系统的配置参数访问模式及设置规则.
当系统运行时发生故障,通过查看当前系统行为或状态违背的相关规则来实现配置错误的检测和诊断.
基于统计学习的方法无需目标系统的源码支持,也不需要理解系统的特定语义信息.
但是为了实现配置访问规则挖掘与异常事件检测的准确性,需要大量历史信息作为分析和挖掘的数据基础,适用于有配置数据集中存储管理和大量访问的应用场景.
对于使用频率低的配置参数及其配置行为,由于缺少数据的支持,难以挖掘出相应规则,导致此方法难以适用.
2.
1.
3基于重放技术的方法(replaybased)基于重放技术的方法本质上是将原先人工执行的反复试错的方法通过计算机的方式加以实现,提高故障诊断和修复的效率.
基于重放的配置错误诊断方法在沙箱环境(sandbox)[31]下不断尝试改变目标系统的配置参数设置,并观察系统行为的变化情况,最终实现错误修复.
沙箱环境起到很好的系统隔离作用,避免了对于其他系统可能带来的影响;同时,通过支持目标系统状态的回滚,降低改变原有正确配置参数带来的风险.
基于重放技术的方法需要对底层操作系统内核进行修改来构造沙箱环境,因此,该方法对系统运行环境具有定制需求,带来较大的工作量和限制;其次,基于重放的方法还需要一组测试用例来检验修改配置参数前后目标系统的变化.
方法类型白盒方法黑盒方法程序分析统计学习对比重放技术静态分析动态分析规则挖掘相似差异反复试错代码源代码字节码二进制数据信息领域知识测试用例已知错误参照基准陈伟等:软件配置错误诊断与修复技术研究12892.
1.
4基于对比的方法(comparisonbased)基于对比的方法通常以一组基准(baseline)、样本(sample)或已知故障(knownproblem)为依据,基准和样本记录了系统的状态[3234]、签名[35]和事件[36]等,已知故障则记录了发生的系统故障特征及其修复方法[37].
以基准和样本为依据时,方法将当前的系统状态、签名或行为与已有的基准进行对比,发现与其中相似基准或样本存在的差异,进而诊断出导致这些差异出现的配置错误;以已知故障为依据时,方法通过对比系统状态或行为找到与当前故障最为相似的已知故障,并将已知故障关联的配置错误作为可能导致当前系统故障的根本原因,同时,将已知故障对应的解决方法作为当前故障的推荐方法.
基于对比的方法同样采用的是黑盒策略,无需进行系统内部程序的分析和理解,但是需要为每个目标程序创建相应的样本库或已知故障库作为比较和分析的基准,在领域知识方面具有较高代价.
由于不同目标系统的样本库或已知故障库各不相同,因此缺少广泛的通用性.
该方法也主要适用于配置信息集中存储和管理的场景.
2.
1.
5混合方法程序分析、统计学习、重放技术和对比等方法在准确程度、执行效率以及额外开销等方面各有优劣,因此也有将上述多种方法结合在一起使用的SMT,用不同的方法分别解决其中的部分问题.
例如,基于程序分析技术进行可能的配置错误定位,基于统计分析来提高配置错误诊断的准确性.
混合方法融合了不同方法在错误定位和故障诊断方面的各自优势,但其局限性也来源于其中,需要充分考虑如何发挥方法的优势,并尽量限制或避免方法本身的局限性.
2.
2方法特征(feature)如图1所示,SMT包括了发现、诊断和修复等3个核心步骤,不同方法在侧重点和功能实现方面也有所不同.
除此之外,方法在基于的前提条件等方面也存在差异,因此本节将从方法的功能覆盖(function)、诊断方式(style)和方法局限性(limitation)这几个角度分别对当前的研究现状和代表性方法进行分析.
2.
2.
1功能覆盖配置错误检测主要解决如何发现错误的问题,回答"是否发生错误以及发生了什么错误(what)";配置错误诊断重点研究如何发现导致错误的根本原因(rootcause),回答"为什么发生错误(why)";配置错误修复技术解决如何修正配置错误的问题,回答"怎么修复错误(how)",三者之间紧密相关又有所区别.
当前,已有的SMT方法具有不同的侧重点,分别关注和解决上述3个方面中的某个或某些问题,具有不同的功能覆盖.
2.
2.
2诊断方式SMT可以分为系统运行前的主动检测和运行时的被动诊断.
系统运行时的被动诊断以运行时的系统行为异常现象为依据,进行错误原因的查找和修复.
该方式的优势在于具有针对性,能够准确、有效地排除系统故障;但其局限性在于对方法的效率具有较高要求,尤其是生产环境下,目标系统的故障诊断需要将对系统的影响降低到最小.
系统运行前的主动检测发生在系统运行前,通过约束发现和验证等方法主动进行系统配置检测,发现配置中存在的约束违背和错误.
该方式的优势在于无需考虑方法的执行效率、降低系统运行时发生异常的风险,但是该方法需要有配置约束和规则的支持.
2.
2.
3方法局限性已有SMT方法或多或少都限定了一些前提条件,使方法必须在满足这些条件限定的前提下才能够得以应用.
这些前提条件主要存在于以下几个方面:1)目标系统代码.
根据需要的系统代码类型,可细分为源代码[38]、字节码[3941]和二进制代码[10,42,43].
这一前提条件主要出现在基于程序分析的方法中;2)定制化的目标系统和运行环境.
为了能够准确获得目标系统运行时的一些细粒度的行为和状态信息,部分方法需要对目标系统进行植入[10,39,41,43],与之关联的是对目标系统代码(主要是二进制代码)的需求;另外,部分基于重放技术的方法需要对目标系统的运行环境进行定制[44],从而实现预测执行和系统回滚重放;1290JournalofSoftware软件学报Vol.
26,No.
6,June20153)其他领域知识和数据.
在这一方面,主要包括了测试用例[32,44]、基准数据[33,39,42]和历史数据库[3537]等.
2.
3适用范围(applicability)应用系统在系统类型、程序语言以及运行环境等方面存在差异配置错误,类型也多种多样,导致的系统故障现象也不尽相同.
因此,已有SMT存在对应的适用范围,本节从适用范围相关的目标系统类型、配置错误类型以及解决的系统故障类型等3个角度进行分析.
2.
3.
1目标系统类型(target)SMT的目标系统均具有配置参数众多、可配置灵活性强的特征,从适用的系统类型方面,可以细分为操作系统级软件(OS-level)、系统支撑软件(system-level)以及面向最终用户的应用系统(application-level).
2.
3.
2配置错误类型(errortype)软件应用的配置错误类型多种多样,包括配置参数取值错误、兼容性错误、组件放置位置错误等.
在配置参数取值错误方面,已有工作通常将配置参数项建模为key-value形式的名值对,这些配置项通常存储于文本文件、XML文件以及Windows的注册表中,配置参数取值错误还可以进一步细分为拼写错误、大小写错误、格式错误、取值范围错误、取值类型错误等.
除此之外,还有部分工作能够诊断或修复包括配置参数取值错误在内的多种类型错误.
2.
3.
3系统故障类型(systemfault)配置错误导致的系统故障具有不同的特征与表现,从大的方面可以分为功能异常和性能异常两类.
系统功能异常又可以根据故障的严重程度分为多种类型,包括:1)系统崩溃、抛出异常或错误信息.
此类系统故障具有明显的错误现象,而且系统往往无法继续运行;2)系统行为或输出结果不正确.
此类系统故障错误现象较为隐蔽,系统能够继续执行,但是其行为或输出错误;3)系统行为或输出与用户预期不符.
严格意义上来讲,系统在功能方面是正确的,多数是由于配置参数项的变化导致行为或输出与用户本身的需求存在差异.
3配置错误诊断与修复方法概述为尽可能保证本文综述的全面性,采用以下方法进行相关文献的检索与选取:1.
为保证能够反映最新的研究成果和研究动态,以2000年以后的研究成果为检索范围2.
选取了与配置相关(configuration,misconfiguration)、错误相关(error,bug,failure,fault,anomaly)以及诊断修复相关(troubleshooting,detection,diagnose/diagnosis,fix)的多个关键词,采用关键词组合的方式构成文献检索的检索词组;3.
基于学术搜索引擎(Googlescholar)进行文献检索.
对第2步中的关键词进行多种组合(如misconfigurationtroubleshooting),共使用10组检索词组.
为保证检索结果的相关性,本文采用基于相关性排序的方式对每次检索结果的前30条(top-30)记录进行人工的分析过滤和去重;4.
基于文献数据库的检索.
本文从多个文献数据库中(ACMDigitalLibrary,IEEEXploreDigitalLibrary)选择与SMT最为相关的领域会议/期刊作为检索范围,涉及软件工程(ICSE,FSE,ASE,ISSTA,ICSM,ISSRE,COMPSAC,TSE,TOSEM,etc.
)、系统软件与程序设计语言(OSDI,SOSP,OOPSLA,etc.
)和计算机系统(ASPLOS,USENIXATC,LISA,etc.
)等共计20多个会议/期刊.
对检索结果同样采用多组关键词组进行检索、识别和过滤去重;5.
为了尽可能找到检索词组以外的相关文献,本文对第3步、第4步检索得到的文献集合的相关工作、参考文献和研究团队逐一分析,找到与本文主题密切相关且在前两步中没有检索发现的相关成果;6.
综合以上第3步~第5步的结果构成本文的综述范围,共计相关文献34篇,其中,会议/期刊30篇,博士论文2篇,技术报告2篇,详细信息见表1.
陈伟等:软件配置错误诊断与修复技术研究1291Table1Literaturesearchlist表1文献检索结果列表会议/期刊名称相关结果IEEEInt'lConf.
onSoftwareEngineering(ICSE)5(Ref.
[1,39,41,45,46])IEEEInt'lConf.
onAutomatedSoftwareEngineering(ASE)1(Ref.
[9])Proc.
oftheACMSIGOPS/EuroSysEuropeanConf.
onComputerSystems(EuroSys)1(Ref.
[36])TheUSENIXSymp.
onOperatingSystemsDesignandImplementation(OSDI)4(Ref.
[10,32,34,43])Proc.
oftheACMSIGOPSSymp.
onOperatingSystemsPrinciples(SOSP)4(Ref.
[44,42,14,38])Proc.
oftheInt'lConf.
onArchitecturalSupportforProgrammingLanguagesandOperatingSystems(ASPLOS)2(Ref.
[47,48])TheUSENIXAnnualTechnicalConf.
(ATC)2(Ref.
[37,49])Proc.
oftheACMSIGSOFTInt'lSymp.
onSoftwareTestingandAnalysis(ISSTA)1(Ref.
[50])TheUSENIXLargeInstallationSystemAdministrationConf.
(LISA)3(Ref.
[35,33,51])IEEEInt'lSymp.
onSoftwareReliabilityEngineeringWorkshops(ISSREW)1(Ref.
[52])IEEEInt'lSymp.
onDependableSystemsandNetworksWithFTCSandDCC(DSN)1(Ref.
[53])IEEEAnnualInt'lComputers,SoftwareandApplicationsConf.
(COMPSAC)1(Ref.
[54])CompanionProce.
oftheInt'lConf.
onSoftwareEngineering(ICSECompanion)1(Ref.
[55])Int'lSymp.
onSoftwareReliabilityEngineering(ISSRE)1(Ref.
[56])IEEEInt'lConf.
onCloudComputing(CLOUD)1(Ref.
[57])TheUSENIXWorkshoponTacklingComputerSystemsProblemswithMachineLearningTechniques1(Ref.
[58])Ph.
D.
Thesis2(Ref.
[40,59])Technicalreport2(Ref.
[60,61])综上,本文能够较为全面地分析和综述当前SMT的主流、高水平研究成果,同时也较为充分地反映了本领域的最新研究现状、动态和进展,具有较强的时效性.
本文分析综述的研究成果来源于国内外多个研究团队与研究学者,其中包括了加州伯克利分校(UCBerkely)的Katz团队、密歇根大学(UniversityofMichigan)的Flinn团队、华盛顿大学(UniversityofWashington)的Ernst团队和圣地亚哥加州大学(UCSD)的Zhou团队等.
本节将按研究团体和机构分别对具有代表性的研究工作和成果进行简要介绍.
3.
1加州伯克利分校的研究工作加州大学伯克利分校Katz的团队[1,9,40,50]以开源的复杂系统软件(如ApacheHadoop)为研究对象,提出了基于程序分析的方法来减少软件配置错误.
Rabkin等人的工作主要针对名值对(key-value)类型配置参数项展开3个方面问题的研究,包括配置信息管理(documentingconfiguration)、配置错误调试(debuggingconfiguration)和改进系统日志配置(improvingloggerconfiguration),并设计实现了工具Conf_Analyzer[40].
在配置信息管理方面,针对开源软件存在系统实际配置与文档记录不一致的情况,Rabkin提出了一种基于静态程序分析的系统配置项识别方法[1],推断系统配置项的参数类型,提高系统文档关于配置信息的准确性.
方法首先基于实证研究提出了应用配置项分类,将配置项类型划分为数值型(numeric)、标识(identifier)、使用模式(mode)和其他(other)这4类,每一类又根据使用语义分为多个子类;其次,方法基于JChord[62]对Java程序字节码(bytecode)进行字段敏感(fieldsensitive)的静态分析,在找到配置项读取方法后,通过分析方法参数获取关联的配置参数项及名称,通过分析参数读取方法的返回值类型、参数处理相关的系统函数类型和相关参数比较操作信息推断出系统配置参数的取值类型.
该方法能够发现大部分的系统配置项,相比原有的系统文档,在配置参数项信息方面具有更好的准确性.
在配置错误调试和诊断方面,提出了一种基于静态数据流分析的检测方法[1,8].
首先,方法通过目标系统源代码(Javabytecode)的静态分析找到系统读写配置参数的关键语句;然后,方法基于数据流(dataflow)分析建立不同程序点与相关配置参数间的映射表.
当系统运行产生故障并抛出异常信息时,系统用户可以根据映射表以及抛出异常的代码行号实现关联配置项的快速定位.
在此基础上,文章还提出了故障上下文敏感(failure-context-sensitive,简称FCS)的分析方法,以系统日志信息和堆栈信息(stacktrace)为补充来提高分析的准确性和效率.
1292JournalofSoftware软件学报Vol.
26,No.
6,June20153.
2密歇根大学的研究工作密歇根大学Flinn研究团队基于动态分析发现输入配置参数与系统异常之间的因果关联关系(causality),通过提高配置错误诊断过程的自动化程度来实现配置错误诊断和修复[59].
该团队分别对配置错误引起的系统功能异常和性能异常问题进行研究,并实现了相应的系统工具SigConf[37],AutoBash[44],ConfAid[10]和X-ray[43].
SigConf[37]以已知的配置错误信息库为依据,通过粗粒度的因果关联分析(causalityanalysis)进行配置错误诊断.
配置错误信息库存储了已知的历史配置错误及其系统状态信息,对于当前配置错误导致的系统异常,SigConf通过与已知配置错误的系统状态对比找到相似的已知配置错误.
SigConf运行一组测试用例(predicates)[61],基于每个测试用例的执行路径记录对应的因果依赖,生成相应的签名(signature),而系统状态则是基于测试用例的执行结果和签名生成的.
SigConf的粗粒度因果关联分析主要体现在它记录了测试用例执行过程中所依赖的所有对象,包括文件、目录、类库等,而不细化到对象内部,如配置文件中的具体配置项等.
因此,SigConf具有执行代价小和效率高的优点,能够诊断多种类型的配置错误(如配置取值错误、类库不兼容等),但也由于粗粒度的分析策略,导致在准确度方面存在不足.
AutoBash[44]基于操作系统内核级的预测执行(speculativeexecution)来测试不同的配置操作给系统带来的影响.
AutoBash同样基于进程和文件粒度的因果关联分析进行错误诊断.
AutoBash以一组测试用例作为辅助,在不影响和改变其他系统的同时,尝试可能的配置错误修复方法,通过反复的尝试和回滚,找到能够解决当前系统故障的配置修复方法.
AutoBash将进程作为黑盒,认为进程的输出完全依赖于其输入数据,在同样粗粒度的分析基础上,AutoBash能够较为准确地定位存在故障的配置错误对象,但是难以进一步定位其内部的细粒度对象,例如ApacheHttpServer配置文件httpd.
conf内的某个特定配置参数项.
因此对于粗粒度对象中包括众多子项的场景,AutoBash的诊断效果有限.
ConfAid[10]针对目标系统采用白盒分析策略,通过细粒度的因果关联分析实现配置错误的诊断.
ConfAid对目标系统的二进制代码进行植入,深入进程内部,通过分析系统运行时的动态信息流来获取由数据和控制流引起的因果依赖.
ConfAid将动态分析的范围限定于从配置文件中读取数据的相关语句、变量和取值,一旦发现改变某个配置参数的取值能够引起系统控制流的变化并避免当前系统错误的发生,那么ConfAid将这一配置参数作为可能的错误项.
相比于前者,ConfAid主要针对配置文件中配置项取值错误进行诊断,具有较高的准确度;但是细粒度的分析和探针植入将引入较高的额外开销,降低系统运行效率.
与SigConf和ConfAid不同,X-ray[43]主要基于细粒度的因果关联分析实现对配置错误导致的系统性能异常诊断.
X-ray提出了基于性能摘要(performancesummarization)的配置错误诊断方法,首先为每个细粒度事件(如单个指令和系统调用等)确定对应的性能代价(performancecost),如响应时间、I/O资源使用率等;然后,基于动态信息流分析的方法找到导致每个事件执行的关联配置项(rootcause),并根据事件发生的概率将其对应的性能代价赋予对应的配置参数;对于每个配置项,通过汇总其关联的所有事件赋予的性能开销得到该配置项的总体性能代价,总体代价最高的配置项最有可能成为导致系统性能异常的根本原因.
3.
3圣地亚哥加州大学的研究工作圣地亚哥加州大学(UCSD)Zhou研究团队在应用配置错误的调研分析和错误诊断方面开展研究.
Yin[14]对多个商业和开源应用系统的配置错误进行了实证研究,是第一个针对配置错误相关特征研究和分析的工作.
该工作研究了546个真实的配置错误,其中,309个来源于一个商业化存储系统,另外237个错误来源于4个广泛使用的开源系统(CentOS,MySQL,ApacheHttpserver,OpenLDAP).
Yin主要从配置错误的类型、模式、原因、系统表现以及造成的影响等几个方面进行了实证研究,将配置错误的类型分为参数错误、兼容性错误、组件错误几大类.
该实证研究工作对配置参数错误导致的系统故障诊断与修复研究提供了丰富的论据和事实依据.
Yuan[49]以Windows环境下的应用为目标系统,研究Windows注册表中应用配置项的错误发现和检测方法.
Windows注册表中存在大量的应用配置信息,并且在运行时有频繁的注册表信息访问事件发生,配置数据的访陈伟等:软件配置错误诊断与修复技术研究1293问事件序列在一定程度上反映了应用系统的控制流信息,并能够提供程序运行时行为的上下文.
考虑到系统正常运行时对于注册表数据的访问行为通常是确定的、有规律的,Yuan提出了在线的配置错误检测方法,通过监控和记录注册表访事件序列分析和挖掘出注册表配置信息的访问规则,例如:在事件a,b,c之后应该确定性地发生事件d,即规则为abc→d.
当系统运行时监控到违反配置访问规则的事件发生时(例如,在事件a,b,c后发生了事件e而不是d),则认为当前事件可能导致配置错误产生并加以警告.
Yuan基于该方法设计实现了配置错误检测工具CODE,包括配置数据访问事件监控收集和访问规则分析两部分.
CODE以字典树(trie)表示事件序列,并基于Sequitur算法[63]进行规则的分析挖掘.
CODE基于系统外部事件分析,无需目标程序源码以及系统相关语义信息的支持,但其局限性在于必须能够提供大量的、频繁发生的配置访问事件来支持规则的分析挖掘,因此适用于具有配置数据集中存储管理和大量访问的应用场景,如Windows环境.
另一方面,CODE基于规则偏离分析解决配置错误的检测和诊断问题,即使在系统没有表现出明显的系统异常时,也能够在线发现潜在的配置错误,通过与已知规则的对比来提供错误解决依据.
Xu[38]从软件系统开发和设计的视角来看待配置错误问题,认为配置错误有时是由系统及配置本身相关的开发设计问题导致的,不应该完全归咎于用户的错误行为.
基于这一观点,Xu针对名值对类型的配置参数错误,基于静态程序数据流分析从配置参数的读取和使用模式中推断出参数配置约束,主要包括单个配置参数的类型约束(typeconstraint)、取值范围约束(valuerange)、涉及多配置参数的控制依赖(controldependency)和取值关联(valuecorrelation),以此为依据来辅助程序开发人员改进系统配置的设计,提高系统应对配置错误的能力.
SPEX是基于上述方法实现的配置约束推理工具,首先从目标系统源代码中识别出配置变量;然后,基于数据流分析获取与配置参数对应的每个程序变量,记录沿着数据流路径发现的所有属性约束.
在第2遍源码分析中,SPEX基于得到的每个配置参数的代码切片进行配置参数的约束推理.
以SPEX得到的目标系统参数约束集合为基础,Xu还实现了配置错误生成与测试工具SPEX-INJ.
SPEX-INJ生成违背约束的配置设置并注入目标系统,通过运行测试用例观察系统在异常发生时的反馈,以此来评价系统应对配置错误的能力,指导系统配置设置的改进.
SPEX将配置错误的诊断和修复工作提前到开发和设计阶段,更加具有主动性.
但是,基于静态分析的方法使得必须有目标系统源代码的支持;同时,SPEX目前主要应用于单个程序和系统的名值对类型配置参数,对于跨系统的配置间关联导致的约束无法适用.
Zhang[48]研究发现,软件配置项之间以及配置项与运行环境之间存在大量关联(correlation).
例如,配置项A指定某文件路径,而系统环境下该文件路径是否存在影响A取值的正确与否;又如,配置项A为某文件,而配置项B的取值表示文件的拥有者,则A与B间存在相互关联.
关联是导致配置错误的原因之一,由此,Zhang实现了基于配置关联的错误检测工具Encore[48].
Encore基于训练数据集(已有的系统配置)分析挖掘配置关联约束,将获取到的关联约束应用到待检测系统,实现配置错误的主动检测,其主要步骤包括:1)训练集数据处理(dataassembling).
根据配置项语义和取值特征进行配置项类型推断,根据配置项类型为其附加相应的环境信息.
例如,当前配置项为文件类型,则对应的环境属性可以包括用户(owner)、用户组(group)、权限(permission)等;2)预先定义一组约束模板(template)来描述配置项及环境信息间可能存在的二元关联关系.
例如,图3中的模板表达了用户名称类型的配置项B应该是文件类型配置项A的所有者,其中,A和B为模板中的占位符(placeholder);Fig.
3Exampleofconstrainttemplate图3关联约束模板示例3)基于模板集合,从训练集中选取满足模板的配置项并逐一进行实例化,产生针对目标系统的一组具体备选约束规则集合;Template:[AFilePath][BUserName]Rule:DataDiruser1294JournalofSoftware软件学报Vol.
26,No.
6,June20154)基于一组启发性规则过滤备选约束集合,提高约束规则的正确性;5)基于最终得到的约束规则对目标系统进行检测,对于出现约束违背的配置项产生警告.
除此之外,Encore还能够对单个配置项的拼写错误、取值类型错误以及取值错误进行检测.
Encore是基于统计分析和数据挖掘的配置错误主动检测方法,它只关注软件系统的配置项,但需要以训练数据集为基础,还需要提供预定义的约束模板;其次,Encore主要用于检测单个系统内部由于存在配置关联而导致的错误,没有考虑多个系统间存在关联的场景.
3.
4华盛顿大学的研究工作Zhang针对单个配置项取值错误导致的系统功能异常设计实现了工具ConfDiagnoser[39,46].
ConfDiagnoser将静态分析、动态分析和统计学习结合在一起,进行配置错误自动诊断.
在静态分析过程中,ConfDiagnoser采用基于程序薄片撷取(thinslicing)[64]的轻量级依赖关系分析方法识别每个配置项能够影响到的控制流分支判断语句.
然后,ConfDiagnoser有选择性地对目标系统源代码进行植入,获取被配置参数影响的判断语句运行时的行为作为执行概况(executionprofile).
ConfDiagnoser的故障诊断以预先建立的正确执行概况数据库为支撑,当系统运行时遇到可疑的配置错误时,ConfDiagnoser通过运行植入代码的系统进行错误重现,并从数据库中找到与当前错误相似的正确执行概况.
最后,基于统计分析的方法,ConfDiagnoser找到动态行为在正确和错误执行概况之间差别最大的那些判断语句,而与这些判定语句相关的配置则有可能是导致异常的根本原因.
在进一步的工作中,Zhang[41]发现:软件系统演化过程中,新版本软件的配置参数项会发生变化,并导致系统的某些行为或特征发生变化;用户升级新版本后,由于配置的使用和取值的变化,新版本系统的运行与用户的原有预期存在偏差.
尽管新版本系统本身正确,但从用户角度来说,与预期的偏差则难以接受.
为了保证系统演化后满足用户的预期目标,Zhang基于运行时植入监控、静态程序分析和运行轨迹对比的方法设计实现了配置诊断工具ConfSuggester,诊断并发现可能导致系统新老版本行为偏差的配置参数项,用户可以改变这些配置项的取值使系统行为符合其预期.
ConfSuggester的基本思想是:对于软件演化前后的新老版本系统,通过控制流的差异发现程序行为的差异;然后,基于程序行为差异的分析推理找到可能导致差异存在的配置项.
ConfSuggester通过3个步骤找到引起新旧版本系统行为偏差的配置项:首先,在两个版本的字节码中植入探针,监控目标是影响控制流变化的判定语句;其次,基于相同的输入和配置运行两个版本的系统,发现两个执行轨迹中的控制流差异;然后,基于一种轻量级的依赖关系静态分析技术,找到造成当前控制流差异的可能配置项集合;最后,通过基于权重的排序算法将可疑配置项的分级排序列表返回给用户,排序越靠前,可疑性越大.
与ConfDiagnoser不同的是,ConfSuggester诊断的配置问题更加宽泛,在诊断配置错误的同时,还能够找到导致系统行为违背用户预期的配置项.
3.
5微软研究机构的工作微软是较早进行SMT技术研究的机构之一,主要针对Windows环境下基于注册表的配置错误诊断问题展开研究,研究成果有Strider[33,51]、PeerPressure[34,60]、Snitch[58]和基于事件轨迹(eventtracebased)的诊断方法[36].
Strider[33]采用黑盒的、基于状态的配置错误诊断方法,将注册表的当前内容作为系统状态[51],采用状态差分(statediffing)的方法逐步缩小可能存在配置错误的搜索范围,最终实现可能的配置错误定位.
首先,Strider将异常时系统状态与本机的正确系统状态(或其他机器的正确系统状态)对比,得到状态差分集合;其次,Strider重新执行异常程序获取异常发生时涉及的注册表配置项集合;然后,Strider通过对两个集合执行交集操作进一步缩小可能导致系统异常的注册表配置项范围;最后,针对交集内的可疑配置参数项,Strider采用一系列启发性规则对其中的配置项进行排序,排序越靠前的配置项成为系统异常原因的可能性越大.
PeerPressure[34,60]相比于Strider有了进一步改进:基于统计学习的方法,通过对比运行同样应用的样本系统和当前故障系统的注册表项找到可疑的错误配置项集合;然后,基于贝叶斯统计方法对可疑的错误配置项进行概率计算及排序;最后,依据少数几个候选配置在正确样本系统中的取值,采用试错的方式进行修复.
文献[36]采用事件轨迹(eventtrace)表示系统行为,将当前发生故障的系统事件轨迹与已知的系统故障及陈伟等:软件配置错误诊断与修复技术研究1295解决方法的事件轨迹集合进行对比,找到与之相似的事件轨迹,从而进一步找到对应的已知系统故障及其修复方法.
该方法以WindowsXP环境下系统调用(systemcall)作为系统事件,通过监控和拦截系统调用获取事件信息.
方法的系统实现包括4个组成部分,其中,troubleshooter负责故障重现;tracer同时进行事件轨迹的记录并发送给classifier;classifier基于n元语法模型(n-grammodel)表示事件序列,并基于支持向量机(supportvectormachine,简称SVM)算法[65]进行事件序列中系统行为模式的识别,计算与已知问题库中(knownproblemDB)事件轨迹的相似度来找到可能相关的已知系统故障及修复方法.
Snitch[58]监控获取大量的应用配置参数及文件的读/写事件信息,然后,基于机器学习的方法建立应用错误与配置状态之间的二元决策树(binarydecisiontree),反映出错误信息与应用配置之间的关联.
应用运行再次发生错误,能够基于该决策树快速定位与错误相关的配置信息.
Snitch主要应用于Windows环境下存在频繁、大量配置读/写事件的场景,需要预先获取大量训练数据(应用配置读/写事件)建立二元决策树.
对于不同的应用系统,必须建立各自对应的决策树,同时,决策树的建立采用一种交互式的、需要人工指导的方式.
3.
6其他研究工作Choronus[32]在系统出现异常时首先定位发生异常的时间点,然后,通过对比该时间点前后的系统状态和配置参数的变化来找到可能引起系统故障的配置错误.
为了达到这一目标,Chronus基于虚拟化技术和一个定制的文件系统来找到引起系统无法正常运行的配置参数设置的改变.
ConfDebugger[52]是一个完全基于程序静态分析的轻量级配置错误诊断工具,仅仅依靠配置项信息、系统错误堆栈信息(failurestacktrace)以及目标系统的Java字节码来定位可能导致当前错误的配置项.
ConfDebugger首先基于正向静态分析和薄片撷取(thinslicing)技术找到每个配置项的程序读取语句以及该语句影响的语句集合;其次,基于错误堆栈信息找到出错的语句,并基于反向静态分析和薄片撷取技术找到当前错误语句关联的语句集合;最后,在两个语句集合的交集中查找相关联的配置项,那么该配置项或配置项集合则作为可能导致错误的所在.
Triage[42]支持在线的故障诊断,采用轻量级的重执行(replay)技术来支持程序运行时异常的重放,获取当时的环境与上下文信息.
Triage采用一种模仿人工调试过程的故障诊断协议进行故障原因分析,通过一组相似的输入和执行环境得到正确和错误的执行结果,并基于动态程序分析进行相似输入且执行结果不同的系统执行路径和数据流的分析,最终诊断出导致系统故障发生的根本原因.
Triage能够诊断多种类型的系统错误,包括配置错误导致的系统故障,并能够提供详细的诊断报告,包括故障信息、触发条件、相关代码和变量、错误扩散链以及可能的修复方法等.
文献[35]提出了一种基于程序行为的配置错误诊断方法,该方法通过监控系统运行轨迹来获得运行时系统调用(systemcall)、信号量、环境变量等行为信息,并将系统行为与状态合二为一建立系统签名(signature)作为正常运行的基准.
当系统运行出现异常时,通过对比异常行为与已有的系统签名来找到当前系统行为存在的偏差,从而分析可能导致系统异常的错误.
ECCFixer[45]是一个针对eCOS(embeddedconfigurableoperatingsystem)的配置错误修复工具,针对出现约束违背的系统配置项,自动产生满足需求的取值范围(rangefix).
ECCFixer基于Reiter[66]诊断理论,将配置参数取值问题映射为可满足问题(SAT)求解,从约束和配置集合中得到需要重新设置和修改的最小变量集合;然后,基于谓词逻辑将最小变量集合涉及的约束转化为等价的合取范式,并将每个子句作为一个最小的修复单元(fixunit);最后,在产生全局的修复取值范围时考虑了多个约束间的相互作用,为涉及的多个配置参数产生无冲突的取值范围集合.
ConfErr[53]是第一个模拟配置错误并进行目标系统注入和评估的工具.
ConfErr模拟用户在系统配置时人工操作可能造成的拼写错误、结构错误以及语义错误,将上述类型错误随机注入到目标系统对应的配置文件中,然后计算和评估系统配置错误的应对能力和表现,生成相应的分析和评估概况.
ConfErr同样可以用来作为目标系统应对配置错误能力的测试和评估基准,其生成的分析和评估概况可以作为系统改进的依据,也可以用于在相似的系统间进行容错能力的对比.
1296JournalofSoftware软件学报Vol.
26,No.
6,June2015Arshad[56]对JavaEE应用服务器的配置问题进行了特征研究,对开源应用服务器GlassFish和JBoss的281个配置问题,从4个维度进行分析,并基于分析结果设计实现了一个面向JavaEE的应用服务器配置错误注入及评估工具ConfInject.
ConfInject向应用服务器的XML配置文件进行基于字符串的配置项错误注入,并从4个方面对该错误导致应用服务器出现异常的情况进行分析,用以评价目标应用服务器应对配置参数错误的能力.
Meng[57]针对大规模分布式的、基于多层体系架构的网络应用系统提出了一种基于分析和比较的配置文件自动发现方法.
该方法把待分析的目标机器与一组基准镜像虚拟机进行比较,通过分析对比目标机器与镜像之间、镜像与镜像之间在文件方面发生的变化,总结提出了6种文件变化模式(changepatter,简称CP),并将属于6种CP的文件作为候选配置文件.
最后,该方法采用基于领域知识库(存储已有的配置文件发现语义规则)或人机交互的方式对选配置文件进行最终判断和认定.
文献[54]从系统错误报告(bugreport)的角度来判断当前系统错误是否由配置错误导致(configurationbugreportprediction).
该工作基于特征选择技术(featureselectiontechnique),如信息增益技术(informationgain)和卡法检验(Chi-square),从大量错误报告文本中选择紧密相关的特征术语(significantterm);然后,使用多种文本挖掘方法(如朴素贝叶斯、支持向量机、朴素贝叶斯多项式等)建立错误报告的分类统计模型(classifier);最后,给定一个错误报告,该模型能够判断出当前错误是否是配置错误相关的.
4软件配置错误诊断方法分析本节依据第2节提出的配置错误诊断方法分析框架对第3节概述的代表性工作进行分析,并对每个分析方面和角度中的各类工作进行统计.
4.
1方法类型分析所有代表性方法中,基于程序分析的方法、基于统计学习的方法和混合方法分别为5/18,4/18,5/18;此外,基于对比的方法和基于重放的方法分别占3/18和1/18(由于ECCFixer[45]仅针对配置修复问题,因此不在方法类型分析的统计范围内,详见表2).
4.
1.
1基于程序分析的方法基于程序分析的配置错误诊断方法可以进一步分为基于静态程序分析的方法和基于动态程序分析的方法.
基于静态程序分析的代表有Conf_Analyzer[40],ConfDebugger[52]和SPEX[38],而基于动态程序分析方法的工具有ConfAid[10]和X-ray[43].
Conf_Analyzer,ConfDebugger和SPEX分别对目标系统的字节码(bytecode)和源代码进行静态分析,而ConfAid和X-ray则基于系统的二进制代码(binarycode)进行植入、监控和分析.
程序分析的配置错误检测与诊断方法具有较高的准确率,但同时也带来了较高的额外开销.
为了提高执行效率,该类型的方法需要考虑路径覆盖和分析规模的问题,尽可能通过启发式规则降低分析复杂度.
基于程序分析方法的局限性还包括:1)程序语言相关性;2)编程风格和编程实践影响方法的有效性.
如果程序捕获所有异常,并抛出一个没有实质内容的泛泛的出错信息,那么该方法将难以进行相关配置参数项的定位.
4.
1.
2基于统计学习的方法CODE[49]从大量的、频繁的配置数据访问事件中分析挖掘出事件序列表示的配置访问模式和规则,通过发现违背规则的事件来检测配置错误.
文献[36]采用事件轨迹(eventtrace)表示系统行为,基于SVM识别事件序列中的系统行为模式.
Encore[48]从大量的训练数据集中分析挖掘出配置项间的关联约束.
Sintch[58]基于训练数据集建立二元决策树来辅助配置错误诊断.
基于统计学习的方法需要大量历史信息作为分析和挖掘的数据基础,例如,CODE和文献[36]均以Windows环境下的注册表信息作为配置参数实例,而Encore则从AmazonEC2中的公共镜像文件中获取训练数据.
4.
1.
3基于重放技术的方法代表性工作有AutoBash[44]和Triage[42]:AutoBash基于操作系统内核级的预测执行(speculativeexecution)来测试不同的配置操作变化给系统带来的影响;Triage采用轻量级的重执行技术来支持程序运行异常时的重陈伟等:软件配置错误诊断与修复技术研究1297放,获取当时的环境与上下文信息.
AutoBash对底层操作系统内核进行了定制构造沙箱环境,在Linux内核之上,实现了系统状态的回滚和与其他应用的隔离;其次,AutoBash和Triage还需要一组测试用例来检验修改配置参数前后目标系统的变化.
4.
1.
4基于对比的方法Strider[33]和PeerPresure[34]以本机正确系统状态以及样本机的系统状态为基准,通过错误系统状态与基准的状态差异对比进行诊断;Choronus[32]通过对比系统故障发生前后系统状态和配置参数的变化找到可能引起系统故障的配置错误;signature-based[35]方法对比异常行为与已有的系统签名来找到当前系统行为存在的偏差,分析可能导致系统异常的错误;SigConf[37]以已知的配置错误信息库为依据,通过与已知配置错误对应的系统状态对比找到相似的已知配置错误,实现配置错误的诊断.
4.
1.
5混合方法采用混合方法进行配置错误诊断的有ConfDiagnoser[39],ConfSuggester[41]和Triage[42]:ConfDiagnoser[39]综合采用了静态程序分析、动态程序分析和对比技术,通过静态分析识别每个配置项能够影响的控制分支判断语句,通过动态分析获取系统的执行概况,最后对比找到正确和错误执行概况之间差别最大的判断语句集合;ConfSuggester[41]同样基于静态、动态程序分析和运行轨迹对比发现系统演化过程中新老版本间配置的差异;Triage[42]基于重放技术获取系统故障时的环境与上下文信息,对输入相同但执行结果不同的多次系统执行进行动态程序分析,最终诊断出导致系统故障发生的根本原因.
如前所述,混合方法充分融合了不同方法的优势,对其局限性也兼而有之:ConfDiagnoser和ConfSuggester需要程序分析必须的源码支持,具有编程语言的针对性;其次,ConfDiagnoser还需要以正确执行概况的数据信息作为与当前系统故障行为进行对比的基准.
4.
2方法特征分析4.
2.
1功能覆盖分析现有方法的研究重点是配置错误诊断(12/19),而错误发现和修复各占2/19,还有部分工作覆盖了诊断与修复两个方面(3/19).
配置错误诊断方法含Conf_Analyzer[40],ConfAid[10],X-ray[43],SPEX[38],ConfDiagnoser[39],ConfSuggester[41],Strider[33],PeerPressure[34],Snitch[58],ConfDebugger[52]和Choronus[32]等.
上述研究成果的前提通常假设配置错误导致的系统异常是能够明显被观察到和发现的,例如抛出异常信息或崩溃[10,40]、系统执行错误[39]、输出信息与预期不符[41]和系统性能显著下降[43]等,因此,诊断出导致系统异常的根本原因成为修复系统故障的必要前提和核心问题,也使得配置错误诊断方法的研究成为最受关注的研究问题.
在明显的、可被观察的系统故障和异常之外还存在无法及时发现的系统错误,使得系统配置错误检测也成为研究问题之一.
CODE[49]是系统配置错误检测的代表性工作,能够通过在线的配置访问事件序列对比发现违背配置访问模式和规则事件的发生,从而在系统进行错误传播并表现出某些故障现象之前能够及时检测到错误的发生.
配置错误修复的研究目标是实现错误修复方法的自动生成,甚至是自动修复,进一步提高方法整体的自动化程度,降低对用户知识和经验的要求.
基于对比的方法通常能够在实现错误诊断的同时给出问题的解决方案,这是由于有对比基准或已知错误的解决方法作为参考,如SigConf[37],Signaturebased[35],Eventtracebased[36].
基于重放技术的方法则通过重放技术将系统错误调试和修复的过程自动化,达到错误修复的目标,代表性工作有AutoBash[44]和Triage[42].
ECCFixer[45]是一个专门以配置项取值错误修复为目标的工具,采用逻辑推理和约束求解的方法,为存在约束违背的系统配置项自动生成正确的取值范围.
4.
2.
2诊断方式分析从已有研究方法和成果来看,系统运行时的被动诊断为主要方式,在本文分析的19个代表性方法中,有16个采用的是故障发生后的诊断方式.
这些方法大多基于系统故障的现象、特征或者通过再次的错误执行重放(replay)或重执行(re-execution)来获取细粒度的、深层次的错误相关信息,从而有针对性地进行诊断和修复.
1298JournalofSoftware软件学报Vol.
26,No.
6,June2015相比于运行时的被动诊断,已有工作中采取主动的运行前诊断的方法主要有ECCFixer[45],SPEX[38]和Encore[48].
这些方法基于目标系统已有的配置约束[38]、程序分析推断出的配置约束[45]和基于统计学习得到的约束[48]为依据,采用约束验证的方法来主动检测和发现当前系统配置参数存在的约束违背.
ECCFixer还能够通过逻辑推理和约束求解的方法为存错误的配置参数项自动生成正确的取值范围.
4.
2.
3方法局限性分析本文分析的现有方法多数具有多个前提或局限性(8/19).
其中,需要系统代码并植入探针的方法占4/19,包括ConfAid[10],X-ray[43],ConfDiagnoser[39]和ConfSuggester[41],这些方法均通过对目标系统代码进行探针植入来获取系统运行时的动态信息.
需要系统代码并人工标记分析起始位置的方法占2/19,包括Conf_Analyzer[40]和SPEX[38],这些方法则需要通过人工标注的方法来限定程序静态分析的范围和起始位置,提高分析效率.
需要运行环境定制并提供测试用例的方法[44]和需要代码、监控植入以及领域知识支持的方法[39]各占1/19.
存在单个前提条件的方法中,需要领域知识和数据支持的方法占了8/19,包括SigConf[37],CODE[49],Strider[33],PeerPresure[34],Encore[48],Snitch[58]等,均是以领域知识和历史数据作为分析诊断的依据.
而仅需要系统代码[52]或测试用例支持[32]或已知配置约束[45]的方法则各占1/19.
4.
3适用范围分析4.
3.
1目标系统类型分析代表性方法主要以系统支撑软件为研究目标(12/19);其次是应用软件(6/19);以操作系统为目标系统的方法所占比例最小(1/19),主要以嵌入式可配置系统和Linux系统为对象.
ECCFixer[45]实现eCos配置错误的修复,eCos是一种嵌入式可配置实时操作系统,因此,其目标系统属于操作系统级软件.
当前,系统支撑软件越来越具有规模大和配置复杂的特征,例如Apachehttpserver,mysql,Hadoop等.
互联网应用、大数据和云计算等新技术的发展与应用,也使得这些系统支撑软件成为当前已有工作的主要研究对象,面向系统软件的配置诊断方法和工具有Conf_Analyzer[40],ConfAid[10],ConfDiagnoser[39]等.
CODE[49],Strider[33],PeerPresure[34],Eventtracebased[36],Snitch[58]以Windows环境下的应用软件作为目标系统,如InternetExplorer和Outlook等,这些应用以Windows的注册表作为配置设置和管理的基础,使得上述工作采取的方法能够获取丰富的配置相关数据作为配置错误检测、诊断和修复的依据.
4.
3.
2配置错误类型分析诊断名值对类型的配置参数取值错误方法占13/19,其他方法(6/19)则在配置错误类型方面没有明确限制.
基于程序分析的诊断方法主要围绕配置参数取值错误展开,该方法能够获得较为详细的配置项读取和使用信息等,代表性工作有Conf_Analyzer[40],ConfAid[10],X-ray[43],CODE[49],SPEX[38],Encore[48],ConfDiagnoser[39],ConfSuggester[41],Strider[33]和PeerPresure[34].
除此之外,还有部分工作能够诊断或修复多种类型的配置,这些工作主要采取的是基于对比[10,21]和基于重放[13,14]的方法,由于有已知故障及修复信息作为基准,使得基于对比方法的诊断和修复技术能够应付多种配置错误类型,而不是仅仅局限于配置参数的取值错误;基于重放技术的修复方法由于提高了调试过程的自动化程度,也能够修复多种类型的配置错误.
4.
3.
3系统故障类型分析当前已有方法主要是面向功能故障相关的配置错误诊断,占18/19,仅有少数工作诊断系统性能异常相关的配置错误(1/19).
代表性工作多数面向系统崩溃、抛出异常或错误信息的功能异常,如Conf_Analyzer[40],ConfAid[10],SPEX[38]等;ConfDiagnoser[39]以正确的执行概况为基准,使得系统行为即使没有明显的异常表现,在发生偏差时就能够得到诊断;ConfSuggester[41]以系统演化过程中配置参数变化导致的新老版本的行为应用场景,采用新老版本系统行为差异的对比方法,使导致系统功能与用户需求不符的这一类配置问题得以诊断.
当前,对于配置错误相关的系统性能异常诊断和修复的研究工作较少,代表性的工作主要有X-ray,它基于动态程序分析的方法获得程序执行语句的细粒度性能代价,然后,根据异常发生时汇总的所有语句的总体性能代价以及与配置项的关联度进行诊断.
陈伟等:软件配置错误诊断与修复技术研究12994.
4小结本节对国内外具有代表性SMT研究成果进行归纳,见表2.
从本文提出的分析框架的方法类型、方法特征以及适用范围这3个方面和多个角度对研究工作进行了总结,当前软件配置错误诊断与修复相关的研究成果呈现出以下特点:(1)从方法类型来看,较早的研究工作[33,34,36]主要通过建立系统表现出来的外部行为特征以及系统配置的关联来诊断和修复配置错误,但越来越多的工作[10,38,40]采用程序分析方法从系统内部获取细粒度的数据依赖和控制流信息,使配置错误的诊断和修复更为准确.
最新的研究工作[39,41]更趋向于采用多种方法相结合的混合方法,能够借助各种方法的优势,需要注意的是如何避免相应方法本身的一些局限性;(2)从方法特征来看,首先在功能覆盖方面,当前代表性的研究工作大多覆盖了配置错误诊断阶段,并将该问题作为研究的重点,同时,越来越多的工作[38,45]将关注点投向配置错误的自动修复方面,使错误修复更加自动化,降低对用户的知识与经验的依赖度;其次,在诊断方式上,当前研究成果主要采用的是一种运行时的被动诊断和修复方法,在错误发生时和发生后采用在线或者离线的方法完成配置错误的诊断和修复;在方法局限性方面,由前述分析可以看到,每种方法或多或少在系统代码、运行环境和其他数据知识方面存在一定的前提和假设,因此很多研究工作的重点之一也是如何消除或放宽这些前提条件,使方法在使用范围以及自动化程度等方面有所提高;(3)从适用范围来看,当前已有的研究工作主要面向大规模的网络应用支撑系统软件和特定的Windows环境下的客户应用,而解决的配置错误类型主要是具有key-value形式的配置项取值错误,而这类配置错误引起的系统异常和系统故障也主要是功能性异常.
Table2AnalysisofSMTmethods表2软件配置错误诊断与修复技术分析方法类型方法特征适用范围功能覆盖诊断方式局限性目标系统错误类型故障类型Conf_Analyzer[40]ADRC+ASKFSigConf[37,61]CD+FRKSAFAutoBash[44]RFRE+TSAFConfAid[10]ADRC+ISKFX-ray[43]ADRC+ISKPCODE[49]SERKAKFSPEX[38]ADPC+ASKFConfDiagnoser[39,46]A+CDRC+I+KSKFConfSuggester[41]A+CDRC+ISKFStrider[33,51]CDRKAKFPeerPressure[34,60]C+SDRKAKFSnitch[58]SDRKAKFEventtracebased[36]SD+FRKAAFChoronus[32]R+CDRTSAFConfDebugger[52]ADRCAKFTriage[42]R+AD+FRC+ISAFSignaturebased[35]CDRKSAFECCFixer[45]-FpROKFEncore[48]SEPKSKF方法类型:A—Programanalysisbased,S—Statisticsbased,C—Comparisonbased,R—Replaybased;功能覆盖:E—Exploring,D—Diagnosing,F—Fixing;诊断方式:R—Reactive,P—Proactive;局限性:C—Code,T—Testcase,E—Environmentcustomization,K—KnowledgeDB,I—Instrumentation,A—Annotation,R—Constraint;目标系统:O—Operatingsystem;S—Systemsoftware;A—Application;错误类型:K—Keyvalue,A—Any;故障类型:F—Functionalfault,P—Performancefault.
总结当前的研究工作,主要存在以下不足:1300JournalofSoftware软件学报Vol.
26,No.
6,June2015(1)目标系统主要是单个软件系统,忽略了构成应用的运行支撑环境以及构成复杂网络应用的不同组件和系统之间在配置参数上存在的隐式关联.
已有工作主要针对单个目标系统的配置问题进行研究[1],例如系统软件Hadoop、HBase和JavaEE应用服务器等.
实际应用中,复杂应用(尤其是复杂网络应用)是由操作系统、中间件、数据库以及异构组件构成的上层应用组成的,不同层次之间以及异构组件之间存在着依赖和交互,导致复杂网络应用的不同组成部分之间在配置参数方面同样会存在关联.
例如,复杂网络应用中,数据库访问组件中的数据源相关配置与底层数据库的相关配置之间就存在着关联关系.
在这种情况下,如果无法获取构成应用的组件及系统间配置参数的关联,那么在进行系统的配置或迁移时会导致配置参数设置和修改的遗漏,使得存在关联关系的配置参数发生相关约束和规则违背的情况,并最终导致系统故障的发生.
(2)已有研究成果主要采取的是一种系统异常发生时的被动诊断与修复策略,主动检测与修复相对薄弱.
被动的错误诊断与修复策略具有针对性,但是为了减少系统失效时间,对方法的效率和代价有较高要求.
加强系统运行前的、主动的配置错误检测力度,能够避免部分配置错误在运行时发生,降低系统由于配置错误导致运行异常和失效的几率.
因此,深入研究运行前的主动检测与修复机制是运行时诊断与修复的有效补充,通过覆盖运行前与运行时两个阶段来降低出错几率,保障系统可应用和提高服务质量.
(3)已有研究成果通常假设当前系统异常由且仅由一个配置参数项的错误导致,对于多个配置项错误导致的系统异常情况难以适用.
当前,已有的系统配置错误诊断方法通常假设导致当前系统故障的配置错误有且仅有一个,然而实际情况下,很多应用错误都是由少数几个参数的相互作用导致的.
例如,Kuhn和Reilly分析了Mozilla浏览器的错误报告记录,发现超过70%的错误是由某两个参数的相互作用触发的,超过90%的错误是由3个以内的参数互相作用而引发的[67].
因此,已有方法不适用于多配置错误的诊断与修复.
对于存在多个配置项错误的情况,基于程序分析的方法需要对配置参数项进行逐个分析,存在效率低下的问题;而基于对比的方法对于状态和现象高度相似的系统异常存在错误检测和诊断的困难.
同时,多配置参数错误导致的系统异常不会因为部分参数的修正而得到解决,而且有可能因为部分参数的修正导致系统异常现象发生变化,这都为基于程序分析的多配置项错误诊断带来了挑战.
(4)在方法适用范围方面,已有方法的目标配置错误类型和系统故障类型较为单一.
当前方法主要针对键值对(key-value)形式的配置参数取值错误,对于其他类型的配置错误(如兼容性错误、组件放置位置错误等)的研究涉及较少.
因此,对于其他类型配置错误的检测、诊断和故障修复技术研究,是对当前已有工作的有益补充,能够有效提高SMT的覆盖面和完整性.
在系统故障方面,当前方法主要解决配置错误导致的系统功能异常问题.
相比于系统性能异常,功能异常更加明确,且可能关联的参数配置项也较为固定.
而系统性能异常则往往是由于系统资源相关的参数配置项设置不合理导致的,异常现象本身具有隐蔽性和滞后性(通常是在一定的场景下才发生,例如系统的并发压力达到一定程度).
进一步的,导致系统性能异常的资源相关配置参数之间存在着相互的关联和制约,往往一个配置项的变化也会影响其他配置项的最佳设置值.
因此,对于系统性能异常相关的配置错误诊断与修复具有更大的难度.
也有相关工作[55]对当前SMT的实用性进行讨论.
通过对高可配置(highlyconfigurable)的一个商业化系统和两个开源系统进行定量分析,该工作认为,SMT的挑战存在于:1)复杂系统可以基于多种开发语言,因此,基于程序分析的SMT必须能够跨程序语言进行分析;2)系统存在很多修改配置的语句和方法需要从多个源头和位置进行配置追踪(tracing);3)仅仅基于系统出错时的持久化数据进行配置状态分析是不够的,需要结合运行时的内存数据与其他启发式规则来提高分析的准确性.
5研究展望通过当前软件配置错误检测、诊断与修复相关的研究热点和主要工作分析,本文认为,该领域的研究趋势和研究内容包括以下几个方面:陈伟等:软件配置错误诊断与修复技术研究1301(1)考虑参数关联和组件依赖的配置错误主动检测构成复杂网络应用的组件存在频繁交互和相互依赖,导致配置参数间产生隐式的复杂关联,给应用的配置及其错误诊断带来困难.
基于异构组件的复杂网络应用运行在多种/多层中间件平台上,分层架构使组件之间、容器之间以及组件与容器之间存在关联和依赖,也使应用及环境的配置参数之间存在隐式的复杂关联和约束,例如配置参数取值的一致性、依赖性、取值范围的相互制约等.
主动检测以配置中存在的不变性规则和约束为基础,配置约束具有隐式的特点,隐藏于配置参数的使用方式及其语义中.
因此,实现配置主动检测的难点和关键点在于发现应用配置参数关联及其蕴含的约束,并通过形式化的方法进行显示描述,实施自动化的配置约束验证.
(2)系统性能异常及可靠性、可用性等问题相关的配置错误诊断与修复在配置参数错误导致的系统性能异常诊断方面,配置参数与性能异常现象间的关联更为复杂,同时,很多情况下系统的运行时故障不是由单个配置参数引起的,而是由几个参数的相互作用导致[67],某一配置参数的取值变化可能导致其他参数的最佳取值范围也随之发生改变,很难通过程序分析进行诊断.
而基于历史数据的统计分析方法能够发现异常现象与配置参数之间以及两两配置参数之间潜在的关联性,是诊断性能异常的有效方法.
除配置错误引起的功能和性能异常外,还能导致系统可靠性及可用性等问题.
相比于功能和性能异常,此类问题对系统的影响等级较轻,且具有一定的主观性,因此,发现、诊断和修复配置错误引起的此类问题也具有更大的难度.
(3)配置错误修复技术研究很多情况下,一个系统错误的修复恰恰是新错误产生的直接原因[5],因此,配置错误修复必须确保不引入新的系统错误,其中的关键问题在于如何推断出错误配置项的正确取值或取值范围,以及如何确认当前修复方法的有效性,避免引入新的错误.
当前,已有工作采用程序分析[38]和约束求解[45]的方法在这一方面做出了探索和尝试,在基于程序分析的配置取值自动推断技术上,除了根据配置项的取值和使用信息来推断可能取值外,还应该分析该配置项与程序其他变量和执行路径的关联,并充分分析在该取值范围内程序的行为是否会发生改变,从而避免新错误的发生.
(4)应用配置错误辅助诊断能力提升的相关研究应用的错误提示信息缺少可能的错误原因、系统状态和错误范围等描述,使配置错误难以诊断,因此,提高系统的错误应对能力和辅助诊断能力十分关键.
当前,已有相关工作通过完善日志信息和异常信息提示的方法来提高系统对于错误信息的描述能力,从而辅助诊断[47].
在这一研究问题上,可以采取回溯(backtracking)的方法,从异常信息抛出位置逆向分析与之关联度高的配置参数集合以及相关的系统状态,并作为系统提示信息的输出内容加以完善.
(5)软件配置方法研究当前研究成果主要集中在如何被动的进行配置错误的检测、诊断和修复方面,忽视了如何从软件工程领域的视角出发,研究如何主动减少或避免配置错误的发生.
今后的研究工作可以从方法论以及建立规范机制的角度出发,研究软件本身的配置方法,如:针对不同的软件类型归纳总结出相应的软件配置方法模式以及从配置的功能和语义角度出发,对配置命名及取值类型等建立相应的规范机制.
6总结软件应用的多样性、复杂性、灵活性和高度可定制性对系统的正确配置提出了挑战,配置错误已经成为影响应用服务质量的关键问题之一.
很多学者和研究机构致力于配置错误的检测、诊断和故障修复相关的技术和方法的研究,以提高复杂应用系统的可用性和可靠性.
本文对软件配置错误诊断修复问题进行深入探讨.
文章分析了导致系统配置错误的多个因素;然后,从方法类型、方法特征和适用范围这3个方面和多个角度建立了一个SMT分析框架;接着,对研究现状进行概述,并基于该分析框架对代表性工作进行分类总结和分析评价;最后,本文总结了当前相关研究存在的不足,并对今后的研究趋势进行展望,对于今后该领域的继续和深入研究具有1302JournalofSoftware软件学报Vol.
26,No.
6,June2015指导意义.
References:[1]RabkinA,KatzR.
Staticextractionofprogramconfigurationoptions.
In:Proc.
ofthe33rdInt'lConf.
onSoftwareEngineering(ICSE).
2011.
[doi:10.
1145/1985793.
1985812][2]OppenheimerD,GanapathiA,PattersonDA.
WhydoInternetservicesfail,andwhatcanbedoneaboutitIn:Proc.
ofthe4thUSENIXSymp.
onInternetTechnologiesandSystems(USITS).
2003.
[3]GrayJ.
WhydocomputerstopandwhatcanbedoneaboutitTechnicalReport,85.
7,TandemCorp.
,1985.
[4]HaleB.
WhyeveryITpractitionershouldcareaboutnetworkchangeandconfigurationmanagement.
2012.
http://web.
swcdn.
net/creative/pdf/Wh-itepapers/Why_Every_IT_Practitioner_Should_Care_About_NCCM.
pdf[5]SverdlikY.
Microsoft:Misconfigurednetworkdeviceledtoazureoutage.
2012.
http://www.
datacenterdynamics.
com/focus/archive/2012/07/microsoft-misconfigured-network-device-led-azure-outage[6]AmazonWebServicesTeam.
SummaryoftheAmazonEC2andAmazonRDSservicedisruptionintheUSeastregion.
2011.
http://aws.
amazon.
com/message/65648[7]JohnsonR.
Moredetailsontoday'soutage.
http://www.
facebook.
com/notes/facebook-engineering/more-details-on-todays-outage/431441338919[8]CircleID.
Misconfigurationbringsdownentire.
SEdomaininSweden.
www.
circleid.
com/posts/misconfiguration_brings_down_entire_se_domain_in_sweden/[9]RabkinA,KatzR.
Precomputingpossibleconfigurationerrordiagnoses.
In:Proc.
ofthe26thIEEE/ACMInt'lConf.
onAutomatedSoftwareEngineering(ASE).
2011.
[doi:10.
1109/ASE.
2011.
6100053][10]AttariyanM,FlinnJ.
Automatingconfigurationtroubleshootingwithdynamicinformationflowanalysis.
In:Proc.
ofthe9thUSENIXConf.
onOperatingSystemsDesignandImplementation(OSDI).
2010.
[11]Hadoop.
http://hadoop.
apache.
org/[12]RowstronA,DruschelP.
Pastry:Scalable,decentralizedobjectlocation,androutingforlarge-scalepeer-to-peersystems.
In:Proc.
oftheIFIP/ACMInt'lConf.
onDistributedSystemsPlatforms(Middleware),2001.
[13]HBase.
http://hbase.
apache.
org/[14]YinZ,MaX,ZhengJ,ZhouY,BairavasundaramL,PasupathS.
Anempiricalstudyonconfigurationerrorsincommercialandopensourcesystems.
In:Proc.
ofthe23rdACMSymp.
onOperatingSystemsPrinciples(SOSP).
2011.
[doi:10.
1145/2043556.
2043572][15]EddyN.
HumanerrorcausedGoogleglitch.
2009.
http://www.
eweek.
com/c/a/Enterprise-Applications/Human-Error-Caused-Google-Glitch/[16]LevesqueM.
Fundamentalissueswithopensourcesoftwaredevelopment.
2005.
http://dlc.
dlib.
indiana.
edu/dlc/bitstream/handle/10535/3215/Fundamental_issues_with_open_source_software_development.
pdfsequence=1&isAllowed=y[17]SchreckD,DallmeierV,ZimmermannT.
Howdocumentationevolvesovertime.
In:Proc.
ofthe9thInt'lWorkshoponPrinciplesofSoftwareEvolution(IWPSE).
2007.
[doi:10.
1145/1294948.
1294952][18]NagarajaK,OliveiraF,BianchiniR,MartinRP,NguyenTD.
UnderstandinganddealingwithoperatormistakesinInternetservices.
In:Proc.
ofthe6thSymp.
onOperatingSystemsDesign&Implementation(OSDI).
2004.
[19]OliveiraF,NagarajaK,BachwaniR,BianchiniR,MartinRP,NguyenTD.
Understandingandvalidatingdatabasesystemadministration.
In:Proc.
oftheUSENIXAnnualTechnicalConf.
(ATC).
2006.
[20]BehmH,FeldmannA,MaennelO,ReiserC,VolkR.
Networkwideinter-domainroutingpolicies:Designandrealization.
In:Proc.
ofthe34thConf.
onNorthAmericanNetworkOperators'GroupMeeting.
2005.
[21]ChenX,MaoY,MaoZM,vanderMerweJ.
Declarativeconfigurationmanagementforcomplexanddynamicnetworks.
In:Proc.
ofthe6thInt'lConf.
onEmergingNetworkingExperimentsandTechnologies(CoNext).
2010.
6172.
[doi:10.
1145/1921168.
1921176][22]HuanL,DanO.
Remotenetworklabs:Anon-demandnetworkcloudforconfigurationtesting.
SIGCOMMComputerCommunicationReview,2010,40(1):8391.
[doi:10.
1145/1672308.
1672324]陈伟等:软件配置错误诊断与修复技术研究1303[23]Al-ShaerES,HamedHH.
Discoveryofpolicyanomaliesindistributedfirewalls.
In:Proc.
ofthe23rdAnnualJointConf.
oftheIEEEComputerandCommunicationsSocieties(INFOCOM).
2004.
26052616.
[doi:10.
1109/INFCOM.
2004.
1354680][24]EnckW,MoyerT,McDanielP,SenS,SebosP,SpoerelS,GreenbergA,SungYW,RaoS,AielloW.
Configurationmanagementatmassivescale:Systemdesignandexperience.
IEEEJournalonSelectedAreasinCommunications,2009,27(3):323335.
[doi:10.
1109/JSAC.
2009.
090408][25]LiFL,YangJH,WuJP,AnCQ,JiangN.
ResearchonInternetautomaticconfiguration.
RuanJianXueBao/JournalofSoftware,2014,25(1):118134(inChinesewithEnglishabstract).
http://www.
jos.
org.
cn/1000-9825/4458.
htm[26]ChenHF,JiangGF,YoshihiraK,SaxenaA.
Invariantsbasedfailurediagnosisindistributedcomputingsystems.
In:Proc.
ofthe29thIEEESymp.
onReliableDistributedSystems.
India,2010.
160166.
[doi:10.
1109/SRDS.
2010.
26][27]ChenHF,JiangGF,UngureanuC,YoshihiraK.
Failuredetectionandlocalizationincomponentbasedsystemsbyonlinetracking.
In:Proc.
ofthe11thACMSIGKDDInt'lConf.
onKnowledgeDiscoveryinDataMining.
Chicago,2005.
750755.
[doi:10.
1145/1081870.
1081968][28]BodicP,FriedmanG,BiewaldL,LevineH,CandeaG,PatelK,TolleG,HuiJ,FoxA,JordanMI,PattersonD.
Combiningvisualizationandstatisticalanalysistoimproveoperatorconfidenceandefficiencyforfailuredetectionandlocalization.
In:Proc.
ofthe2ndInt'lConf.
onAutonomicComputing.
2005.
89100.
[doi:10.
1109/ICAC.
2005.
18][29]CherkasovaL,OzonatK,MiN,SymonsJ,SmirniE.
Automatedanomalydetectionandperformancemodelingofenterpriseapplications.
ACMTrans.
onComputerSystems,2009,27(3):132.
[doi:10.
1145/1629087.
1629089][30]ZhangL,XieB,MeiH,ShaoWZ,YangFQ.
Studyofcomponent-basedsoftwareconfigurationmanagementtechnologies.
ActaElectronicaSinica,2001,29(2):13(inChinesewithEnglishabstract).
[31]Sandbox.
http://en.
wikipedia.
org/wiki/Sandbox_(computer_security)[32]WhitakerA,CoxRS,GribbleSD.
Configurationdebuggingassearch:Findingtheneedleinthehaystack.
In:Proc.
ofthe6thUSENIXConf.
onOperatingSystemsDesignandImplementation(OSDI).
2004.
[33]WangYM,VerbowskiC,DunaganJ,ChenY,WangHJ,YuanC,ZhangZ.
STRIDER:Ablack-box,state-basedapproachtochangeandconfigurationmanagementandsupport.
In:Proc.
ofthe17thLargeInstallationSystemsAdministrationConf.
(LISA).
2003.
[doi:10.
1016/j.
scico.
2003.
12.
009][34]WangHJ,PlattJC,ChenY,ZhangR,WangYM.
AutomaticmisconfigurationtroubleshootingwithPeerPressure.
In:Proc.
ofthe6thUSENIXConf.
onOperatingSystemsDesignandImplementation(OSDI).
2004.
[35]DingXN,HuangH,RuanYP,ShaikhA,ZhangXD.
Automaticsoftwarefaultdiagnosisbyexploitingapplicationsignatures.
In:Proc.
ofthe22ndLargeInstallationSystemsAdministrationConf.
(LISA).
2008.
[36]YuanC,LaoN,WenJR,LiJ,ZhangZ,WangYM,MaWY.
Automatedknownproblemdiagnosiswitheventtraces.
In:Proc.
ofthe1stACMSIGOPS/EuroSysEuropeanConf.
onComputerSystems(EuroSys).
2006.
[doi:10.
1145/1217935.
1217972][37]AttariyanM,FlinnJ.
Usingcausalitytodiagnoseconfigurationbugs.
In:Proc.
ofthe2008USENIXAnnualTechnicalConf.
(ATC).
Boston,2008.
[38]XuTY,ZhangJQ,HuangP,ZhengJ,ShengTW,YuanD,ZhouYY,PasupathyS.
Donotblameusersformisconfigurations.
In:Proc.
ofthe24thACMSymp.
onOperatingSystemsPrinciples(SOSP).
2013.
[doi:10.
1145/2517349.
2522727][39]ZhangS,ErnstMD.
Automateddiagnosisofsoftwareconfigurationerrors.
In:Proc.
ofthe35thInt'lConf.
onSoftwareEngineering(ICSE).
2013.
[doi:10.
1109/ICSE.
2013.
6606577][40]RabkinA.
Usingprogramanalysistoreducemisconfigurationinopensourcesystemssoftware[Ph.
D.
Thesis].
Berkeley:UniversityofCalifornia,2012.
[41]ZhangS,ErnstMD.
WhichconfigurationoptionshouldIchangeIn:Proc.
ofthe36thInt'lConf.
onSoftwareEngineering(ICSE).
2014.
[doi:10.
1145/2568225.
2568251][42]TucekJ,LuS,HuangC,XanthosS,ZhouYY.
Triage:Diagnosingproductionrunfailuresattheuser'ssite.
In:Proc.
ofthe21stACMSymp.
onOperatingSystemsPrinciples(SOSP).
2007.
[doi:10.
1145/1294261.
1294275][43]AttariyanM,ChowM,FlinnJ.
X-Ray:Automatingroot-causediagnosisofperformanceanomaliesinproductionsoftware.
In:Proc.
ofthe10thUSENIXSymp.
onOperatingSystemsDesignandImplementation(OSDI).
Hollywood,2012.
1304JournalofSoftware软件学报Vol.
26,No.
6,June2015[44]SuYY,AttariyanM,FlinnJ.
AutoBash:Improvingconfigurationmanagementwithoperatingsystemcausalityanalysis.
In:Proc.
ofthe21stACMSymp.
onOperatingSystemsPrinciples(SOSP).
2007.
[doi:10.
1145/1294261.
1294284][45]XiongY,HubauxA,SheS,CzarneckiK.
Generatingrangefixesforsoftwareconfiguration.
In:Proc.
ofthe34thInt'lConf.
onSoftwareEngineering(ICSE).
2012.
[doi:10.
1109/ICSE.
2012.
6227206][46]ZhangS.
ConfDiagnoser:AnautomatedconfigurationerrordiagnosistoolforJavasoftware.
In:Proc.
ofthe35thInt'lConf.
onSoftwareEngineering(ICSE).
2013.
[doi:10.
1109/ICSE.
2013.
6606737][47]YuanD,ZhengJ,ParkS,ZhouYY,SavageS.
Improvingsoftwarediagnosabilityvialogenhancement.
In:Proc.
ofthe16thInt'lConf.
onArchitectureSupportforProgrammingLanguageandOperatingSystems(ASPLOS).
2011.
[doi:10.
1145/1950365.
1950369][48]ZhangJQ,RenganarayanaL,ZhangXL,GeNY,BalaV,XuTY,ZhouYY.
EnCore:Exploitingsystemenvironmentandcorrelationinformationformisconfigurationdetection.
In:Proc.
ofthe19thInt'lConf.
onArchitectureSupportforProgrammingLanguageandOperatingSystems(ASPLOS).
2014.
[doi:10.
1145/2541940.
2541983][49]YuanD,XieXL,PanigrahyR,YangJF,VerbowskiC,KumarA.
Context-Basedonlineconfiguration-errordetection.
In:Proc.
ofthe2011USENIXAnnualTechnicalConf.
(ATC).
Portland,2011.
313326.
[50]RabkinA,KatzR.
Usingstaticanalysistodiagnoseconfigurationerrors.
In:Proc.
ofthe11thInt'lSymp.
onSoftwareTestingandAnalysis(ISSTA).
2011.
[51]LaoN,WenJR,MaWY,WangYM.
Combininghighlevelsymptomdescriptionsandlowlevelstateinformationforconfigurationfaultdiagnosis.
In:Proc.
ofthe18thLargeInstallationSystemsAdministrationConf.
(LISA).
2004.
[52]DongZ,GhanavatiM,AndrzejakA.
Automateddiagnosisofsoftwaremisconfigurationsbasedonstaticanalysis.
In:Proc.
ofthe2013IEEEInt'lSymp.
onSoftwareReliabilityEngineeringWorkshops(ISSREW).
2013.
[doi:10.
1109/ISSREW.
2013.
6688897][53]KellerL,UpadhyayaP,CandeaG.
ConfErr:Atoolforassessingresiliencetohumanconfigurationerrors.
In:Proc.
oftheIEEEInt'lConf.
onDependableSystemsandNetworkswithFTCSandDCC(DSN).
2008.
[doi:10.
1109/DSN.
2008.
4630084][54]XiaX,LoD,QiuW,WangX.
Automatedconfigurationbugreportpredictionusingtextmining.
In:Proc.
oftheIEEE38thAnnualComputerSoftwareandApplicationsConf.
(COMPSAC).
2014.
[doi:10.
1109/COMPSAC.
2014.
17][55]JinD,QuX,CohenMB,RobinsonB.
Configurationseverywhere:implicationsfortestinganddebugginginpractice.
In:CompanionProc.
ofthe36thInt'lConf.
onSoftwareEngineering(ICSECompanion).
2014.
[doi:10.
1145/2591062.
2591191][56]ArshadFA,KrauseRJ,BagchiS.
CharacterizingconfigurationproblemsinJavaEEapplicationservers:AnempiricalstudywithGlassFishandJBoss.
In:Proc.
oftheIEEE24thInt'lSymp.
onSoftwareReliabilityEngineering(ISSRE).
2013.
[doi:10.
1109/ISSRE.
2013.
6698919][57]MengFJ,ZhuoXJ.
Agenericframeworkforapplicationconfigurationdiscoverywithpluggableknowledge.
In:Proc.
oftheIEEE6thInt'lConf.
onCloudComputing(CLOUD).
2013.
[doi:10.
1109/CLOUD.
2013.
16][58]MickensJ,Szummer,NarayananD.
Snitch:Interactivedecisiontreesfortroubleshootingmisconfigurations.
In:Proc.
ofthe2ndUSENIXWorkshoponTacklingComputerSystemsProblemswithMachineLearningTechniques(SYSML).
2007.
[59]AttariyanM.
Improvingsoftwareconfigurationtroubleshootingwithcausalityanalysis[Ph.
D.
Thesis].
UniversityofMichigan,2012.
[60]WangHJ,PlattJ,ChenY,ZhangR,WangYM.
PeerPressure:Astatisticalmethodforautomaticmisconfigurationtroubleshooting.
TechnicalReport,MSR-TR-2003-80,2003.
http://research.
microsoft.
com/en-us/um/people/helenw/papers/msr-tr-03-80.
pdf0sr=ar[61]SuYY,FlinnJ.
Automaticallygeneratingpredicatesandsolutionsforconfigurationtroubleshooting.
TechnicalReport,2007.
http://citeseerx.
ist.
psu.
edu.
sci-hub.
org/viewdoc/downloaddoi=10.
1.
1.
148.
7963&rep=rep1&type=pdf[62]NaikM.
JChord.
http://jchord.
googlecode.
com[63]Nevill-ManningCG,WittenIH.
Identifyinghierarchicalstructureinsequences:Alinear-timealgorithm.
JournalofArtificialIntelligenceResearch,1997.
6782.
[64]SridharanM,FinkSJ,BodikR.
Thinslicing.
In:Proc.
oftheACMSIGPLAN2007Conf.
onProgrammingLanguageDesignandImplementation(PLDI).
2007.
[65]ChangCC,LinCJ.
LIBSVM:Alibraryforsupportvectormachines.
ACMTrans.
onIntelligentSystemsandTechnology(TIST),2011,2(3):27.
[doi:10.
1145/1961189.
1961199]陈伟等:软件配置错误诊断与修复技术研究1305[66]ReiterR.
Atheoryofdiagnosisfromfirstprinciples.
ArtificialIntelligence,1987,32(1):5795.
[doi:10.
1016/0004-3702(87)90062-2][67]KuhnDR,ReillyMJ.
Aninvestigationoftheapplicabilityofdesignofexperimentstosoftwaretesting.
In:Proc.
oftheAnnualNASA/IEEESoftwareEngineeringWorkshop(SEW).
LosAlamitos:IEEEPress,2002.
9195.
[doi:10.
1109/SEW.
2002.
1199454]附中文参考文献:[25]李福亮,杨家海,吴建平,安常青,姜宁.
互联网自动配置研究.
软件学报,2014,25(1):118134.
http://www.
jos.
org.
cn/1000-9825/4458.
htm[30]张路,谢冰,梅宏,邵维忠,杨芙清.
基于构件的软件配置管理技术研究.
电子学报,2001,29(2):13.
陈伟(1980-),男,江西高安人,博士,高级工程师,CCF会员,主要研究领域为网络分布式计算,软件工程.
魏峻(1970-),男,博士,研究员,博士生导师,CCF高级会员,主要研究领域为网络分布式计算,软件工程.
黄翔(1982-),男,博士,主要研究领域为网络分布计算,大数据.
钟华(1971-),男,博士,研究员,博士生导师,CCF高级会员,主要研究领域为网络分布式计算,软件工程.
乔晓强(1977-),男,博士,副研究员,CCF会员,主要研究领域为网络分布计算,服务计算,软件工程.
ac.
cnJournalofSoftware,2015,26(6):12851305[doi:10.
13328/j.
cnki.
jos.
004823]http://www.
jos.
org.
cn中国科学院软件研究所版权所有.
Tel:+86-10-62562563软件配置错误诊断与修复技术研究陈伟1,黄翔2,乔晓强1,魏峻1,3,钟华1,31(中国科学院软件研究所软件工程技术研发中心,北京100190)2(中山大学信息科学与技术学院,广东广州510006)3(中国科学院软件研究所计算机科学国家重点实验室,北京100190)通讯作者:陈伟,E-mail:wchen@otcaix.
iscas.
ac.
cn摘要:软件的多样性、复杂性、灵活性和高度可定制性对系统的正确配置提出了挑战,配置错误已经成为影响应用服务质量的关键问题之一.
很多学者和研究机构致力于配置错误的检测、诊断和故障修复的相关技术和方法研究,以提高复杂应用系统的可用性和可靠性.
为系统了解软件配置错误相关的研究现状和进展,建立了一种多方面、多角度的分析框架对该领域的主要研究工作进行分类总结和分析评价,该分析框架覆盖了方法类型、方式和适用范围这3个方面的多个角度.
基于该分析框架的分析结果,总结了当前软件配置错误相关研究中存在的问题,并针对今后该领域的研究趋势进行了展望,对继续和深入研究具有一定的指导意义.
关键词:软件配置;故障诊断;错误修复中图法分类号:TP311中文引用格式:陈伟,黄翔,乔晓强,魏峻,钟华.
软件配置错误诊断与修复技术研究.
软件学报,2015,26(6):12851305.
http://www.
jos.
org.
cn/1000-9825/4823.
htm英文引用格式:ChenW,HuangX,QiaoXQ,WeiJ,ZhongH.
Researchonsoftwaremisconfigurationtroubleshooting.
RuanJianXueBao/JournalofSoftware,2015,26(6):12851305(inChinese).
http://www.
jos.
org.
cn/1000-9825/4823.
htmResearchonSoftwareMisconfigurationTroubleshootingCHENWei1,HUANGXiang2,QIAOXiao-Qiang1,WEIJun1,3,ZHONGHua1,31(TechnologyCenterofSoftwareEngineering,InstituteofSoftware,TheChineseAcademyofSciences,Beijing100190,China)2(SchoolofInformationScienceandTechnology,SunYat-SenUniversity,Guangzhou510006,China)3(KeyLaboratoryofComputerSciences,InstituteofSoftware,TheChineseAcademyofSciences,Beijing100190,China)Abstract:Softwareconfigurationhasbeenabigchallengeduetothediversity,complexity,flexibilityandcustomizabilityofasystem.
Configurationerrorhasbecomeadominantcauseleadingtosystemfailureandserviceoutage.
Toimprovesoftwareavailabilityandreliability,manyresearchersandinstitutionshavedevotedtheireffortsonsoftwaremisconfigurationtroubleshooting.
Thispaperfirstbuildsananalyticalframeworkwithestablishmentof3aspectsandmultipleperspectives,coveringthemethodtype,styleandapplicability.
Basedonthisframework,thepaperprovidesanoverviewofthestateofartofmisconfigurationtroubleshootingalongwithanalysisonthecurrentleadingmethodsofsoftwaremisconfigurationtroubleshooting.
Finally,thispapersummarizestheshortcomingsinthecurrentresearchandoutlinesthedevelopmentprospectsoffutureresearch.
Thispaperaimstoprovidesomeavailableinformationandbeneficialinsightforfutureresearches.
Keywords:softwareconfiguration;failurediagnose;errorfix配置(configuration)是软件系统不可或缺的组成部分,广泛存在于软件部署、升级以及迁移等应用场景中.
配置覆盖了软件系统及其环境的多个方面,包括配置文件、已安装的软件,甚至包括底层硬件环境.
广义上来讲,基金项目:国家自然科学基金(61402453);国家高技术研究发展计划(863)(2013AA041301);国家科技支撑计划(2013BAH05F03,2012BAH14B02)收稿时间:2014-05-13;修改时间:2015-01-05,2015-01-21;定稿时间:2015-02-061286JournalofSoftware软件学报Vol.
26,No.
6,June2015软件配置是指以用户需求和软件的功能、结构及主要特性等为依据,选择和确定相关硬件、软件和固件的型号、版本及数量,规划软件放置位置和关联关系,设置软件系统相关参数值等;狭义上的软件配置主要是指对软件系统配置参数取值的设置.
随着计算机技术和Internet的快速发展,软件系统在实现技术、应用模式和系统规模等方面发生了巨大变化,呈现网络化、协同化、普适化和服务化的趋势,软件应用的平台开放、动态、分布等特点也日益显著.
复杂应用(尤其是复杂网络应用)往往通过大量配置参数提高系统的可定制性,通过不同的配置参数取值获得期望的系统功能和性能特性.
软件配置往往决定了诸如数据存储位置、服务器端口绑定以及使用哪些模块和算法等多方面的问题,但是大量配置参数的存在及使用的灵活性为应用的正确配置带来极大困难[1],为系统后续运行的可靠性、可用性以及系统性能等带来极大挑战,具体表现如下:(1)配置错误已成为导致系统异常、服务失效甚至是系统崩溃的显著原因之一.
基于对3个商业互联网服务的研究,Oppenheimer等人[2]发现,50%以上的系统运维管理故障源于配置错误,并导致系统服务无法使用;Gray[3]的研究发现,42%的系统宕机与运维管理相关,其中,软件、硬件和环境错误分别占25%,18%和14%;还有相关研究发现,80%以上的网络故障也都是由于配置错误引起的[4].
(2)配置错误会带来灾难性后果,严重影响应用的服务质量,带来经济和声誉等方面的负面影响.
近年来,包括MicrosoftAzure[5],AmazonEC2[6]和Facebook[7]在内的很多复杂网络服务或应用系统都经历过配置错误导致的运行中断,使数百万用户受到影响.
2010年,Facebook的一个配置错误使多达500万用户在几个小时内无法访问其网站和服务[7];又如在2009年,由于DNS的配置错误,导致互联网的整个".
se"域在一个多小时内无法正常运行,使大约100万台主机受到影响[8].
本文首先给出软件配置错误定义,归纳总结了导致配置错误的主要原因,界定了软件配置错误诊断与修复的问题域,并对其相关研究领域进行了概述.
其次,从方法类型、特征和适用范围这3个方面的多个角度建立了配置错误诊断与修复方法的分析框架.
然后,简要介绍了该领域的研究现状和代表性工作,并基于分析框架对当前的研究工作进行分类总结和分析评价.
最后,本文分析总结了当前软件配置错误的诊断研究中存在的问题,并对未来研究趋势进行展望.
1概述软件配置错误(configurationerror或misconfiguration)定义为由于软件配置项的值设置错误而导致系统运行产生确定性(deterministic)故障,并产生相应的错误信息[9].
因此,配置错误可以认为是软件系统中存在的这样一类问题,即:软件代码本身正确,但是由于不正确的安装、配置或系统升级而导致软件系统无法按照预期正确运行[10].
导致软件配置错误的主要原因可以归纳为以下几点:(1)应用规模庞大且配置参数众多,需要大量的时间和精力进行配置方法的学习和参数用途的理解.
复杂应用常提供大量的配置参数项来满足用户对系统功能和性能相关特性的定制需求,增强系统的灵活性和可定制性.
大规模复杂应用往往由上层应用服务和下层的系统支撑软件组成,包括Hadoop[11],FreePastry[12],HBase[13]在内的系统软件均具有数量众多的配置项(例如,Hadoop具有超过400个配置项)[1].
随着云计算的发展和集群技术的运用,系统规模和参数配置项随着结点数量成倍增长.
(2)应用组件存在交互和相互依赖,导致配置参数间存在关联,给应用配置及其错误诊断带来困难.
复杂应用运行在多种/多层中间件平台上,分层架构使组件之间、容器之间以及组件与容器之间存在关联和依赖,也使应用及环境的配置参数间存在关联和约束,例如配置参数取值的一致性、依赖性、取值范围的相互制约等.
如果忽略这些关联和约束,将极易发生配置约束违背,产生系统运行故障.
(3)软件系统配置过程在一定程度上依赖于系统管理人员的知识和经验.
首先,用户使用和配置软件需要花费大量的时间和精力进行学习,研究数据证明,大部分参数配置错误发生在系统的初次使用和配置中[14,15],并且文档与系统的不一致使用户可能获取错误的指导信息[16,17];其次,人为操作导致的参数设置错误难以避免,其中包括拼写错误、语义错误等,长期以来,人工操作一直是导致互联网服务陈伟等:软件配置错误诊断与修复技术研究1287异常与不可用的显著因素之一[2],而其中一半以上的错误是由人为因素引起的[18,19].
(4)系统配置错误的辅助诊断能力直接影响诊断效率与准确性,配置错误修复主要依赖于已有经验和外部技术支持.
应用故障发生时经常抛出一个泛泛的错误提示,甚至没有任何提示,错误信息内容缺少可用的错误原因、系统状态和错误范围描述,无法从中获取有效的线索.
已有研究表明,仅仅只有7.
2%~15.
5%的配置问题能够给出较为清晰准确的信息提示来支持错误诊断[14].
在缺少有效提示信息的情况下,配置错误的定位和诊断花费的时间和精力随之成几倍甚至十几倍的增长.
软件配置错误诊断与修复(softwaremisconfigurationtroubleshooting,简称SMT)的对象是配置错误导致的系统故障和异常,目标是确保应用系统正确运行、保障其可靠性和可用性,核心内容包括配置错误的发现(detect)、诊断(diagnose)和修复(fix).
SMT相关的研究领域主要有自动配置和软件故障诊断.
自动配置方法的主要研究目标是实现配置的自动化执行,减少人工操作,从而降低配置出错几率.
当前,自动配置方法研究主要面向底层的网络设备,应对互联网大量的配置需求以及配置复杂度日益增长的趋势.
自动配置是互联网配置管理研究领域的一部分,按照流程,可以将自动配置分为配置自动生成[20,21]、配置验证[22,23]和配置自动实现[24].
清华大学的李福亮等人[25]对互联网自动配置领域的研究现状和代表工作进行了综述.
软件系统故障诊断方法的主要思想是:利用监测框架收集系统监测数据,在系统正常运行状态下建立状态模型,将监测到的系统状态与通过模型预测出的理想状态进行比较,把检测到的偏差作为可能的故障,据此定位问题出现的原因.
软件系统故障检测与诊断的常用方法包括基于规则和信号的方法[26]、基于行为模型的方法[27]、基于度量分析的方法[28]、基于性能模型的方法[29]等.
软件配置错误诊断与修复作为一个细分的研究领域,与上述两个领域既有关联又有区别:首先,与网络设备不同,软件系统复杂多样且配置错误难以避免,因此,软件配置错误诊断主要从如何发现、诊断和修复配置错误的角度来提高系统的可靠性与可用性;另一方面,配置错误是引起系统故障的因素之一,软件配置错误诊断在方法上与系统故障诊断存在相似性,不同的是,前者完全面向配置错误导致的系统故障和异常,更加具有针对性.
软件配置管理(softwareconfigurationmanagement,简称SCM)与SMT名称相近,但分属于不同的概念范畴,其问题域和研究内容上有根本性区别.
软件配置管理目的是协调软件开发使得混乱减到最小,是一种标识、组织和控制修改的技术.
SCM研究怎样在不同时刻标识软件系统的配置,以便系统化地控制配置的改变,以及在整个软件生命周期内维护配置的完整性和可追踪性,主要包括配置识别、变化控制、状态记录报告以及审计[30].
2配置错误诊断与修复技术分析框架SMT方法的目标系统、故障类型、采用的方法、具有的功能特征以及必须的前提条件和假设等方面各有特点,为了对SMT的研究现状进行分析、归纳与总结,本文从多个方面和角度建立了SMT的技术分析框架,如图1所示.
该框架以配置错误诊断与修复的过程为依据,分别从功能、基本方法、前提条件、目标系统和故障类型多个角度进行分析总结,覆盖了方法类型(type)、方法特征(feature)和适用范围(applicability)这3个方面.
Fig.
1SMTanalyticalframework图1SMT分析框架应用软件系统软件操作系统目标系统故障类型功能故障性能异常系统故障发现诊断修复功能代码测试用例配置约束知识库…条件程序分析统计学习对比重放技术…方法1288JournalofSoftware软件学报Vol.
26,No.
6,June20152.
1方法类型SMT从基本方法角度可以分为基于程序分析(programanalysisbased)的方法、基于统计学习(statisticsbased)的方法、基于重放技术(replaybased)的方法和基于对比(comparisonbased)的方法以及基于上述两种或多种方法的混合方法,分类如图2所示.
Fig.
2SMTclassification图2SMT方法分类2.
1.
1基于程序分析的方法(programanalysisbased)基于程序分析方法的核心思想是:将目标系统作为白盒(whitebox),采用与软件测试领域相似的技术手段,重点关注系统中与配置参数读写及操作相关的语句,通过数据流和控制流等信息流的分析,较为准确地获取配置参数影响的语句和执行路径,实现配置错误导致的系统异常检测与定位.
基于程序分析的SMT可以进一步分为基于静态程序分析(staticanalysisbased)的方法和基于动态程序分析(dynamicanalysisbased)的方法,如图2所示.
基于静态程序分析的方法主要对目标系统进行静态数据流分析,大多从配置参数读取位置为起始,获取并分析配置参数访问、使用和修改的相关语句,实现配置错误诊断.
动态程序分析方法通过对目标系统代码的植入和运行时监控来获取系统运行时的动态数据流和控制流信息,重点关注和分析配置参数项影响的系统执行路径.
2.
1.
2基于统计学习的方法(statisticsbased)基于统计学习的SMT将目标系统作为黑盒(blackbox),观察、收集系统行为(behavior)、状态(state)及与事件(event)相关的历史数据,再基于概率统计和机器学习等方法分析挖掘出目标系统的配置参数访问模式及设置规则.
当系统运行时发生故障,通过查看当前系统行为或状态违背的相关规则来实现配置错误的检测和诊断.
基于统计学习的方法无需目标系统的源码支持,也不需要理解系统的特定语义信息.
但是为了实现配置访问规则挖掘与异常事件检测的准确性,需要大量历史信息作为分析和挖掘的数据基础,适用于有配置数据集中存储管理和大量访问的应用场景.
对于使用频率低的配置参数及其配置行为,由于缺少数据的支持,难以挖掘出相应规则,导致此方法难以适用.
2.
1.
3基于重放技术的方法(replaybased)基于重放技术的方法本质上是将原先人工执行的反复试错的方法通过计算机的方式加以实现,提高故障诊断和修复的效率.
基于重放的配置错误诊断方法在沙箱环境(sandbox)[31]下不断尝试改变目标系统的配置参数设置,并观察系统行为的变化情况,最终实现错误修复.
沙箱环境起到很好的系统隔离作用,避免了对于其他系统可能带来的影响;同时,通过支持目标系统状态的回滚,降低改变原有正确配置参数带来的风险.
基于重放技术的方法需要对底层操作系统内核进行修改来构造沙箱环境,因此,该方法对系统运行环境具有定制需求,带来较大的工作量和限制;其次,基于重放的方法还需要一组测试用例来检验修改配置参数前后目标系统的变化.
方法类型白盒方法黑盒方法程序分析统计学习对比重放技术静态分析动态分析规则挖掘相似差异反复试错代码源代码字节码二进制数据信息领域知识测试用例已知错误参照基准陈伟等:软件配置错误诊断与修复技术研究12892.
1.
4基于对比的方法(comparisonbased)基于对比的方法通常以一组基准(baseline)、样本(sample)或已知故障(knownproblem)为依据,基准和样本记录了系统的状态[3234]、签名[35]和事件[36]等,已知故障则记录了发生的系统故障特征及其修复方法[37].
以基准和样本为依据时,方法将当前的系统状态、签名或行为与已有的基准进行对比,发现与其中相似基准或样本存在的差异,进而诊断出导致这些差异出现的配置错误;以已知故障为依据时,方法通过对比系统状态或行为找到与当前故障最为相似的已知故障,并将已知故障关联的配置错误作为可能导致当前系统故障的根本原因,同时,将已知故障对应的解决方法作为当前故障的推荐方法.
基于对比的方法同样采用的是黑盒策略,无需进行系统内部程序的分析和理解,但是需要为每个目标程序创建相应的样本库或已知故障库作为比较和分析的基准,在领域知识方面具有较高代价.
由于不同目标系统的样本库或已知故障库各不相同,因此缺少广泛的通用性.
该方法也主要适用于配置信息集中存储和管理的场景.
2.
1.
5混合方法程序分析、统计学习、重放技术和对比等方法在准确程度、执行效率以及额外开销等方面各有优劣,因此也有将上述多种方法结合在一起使用的SMT,用不同的方法分别解决其中的部分问题.
例如,基于程序分析技术进行可能的配置错误定位,基于统计分析来提高配置错误诊断的准确性.
混合方法融合了不同方法在错误定位和故障诊断方面的各自优势,但其局限性也来源于其中,需要充分考虑如何发挥方法的优势,并尽量限制或避免方法本身的局限性.
2.
2方法特征(feature)如图1所示,SMT包括了发现、诊断和修复等3个核心步骤,不同方法在侧重点和功能实现方面也有所不同.
除此之外,方法在基于的前提条件等方面也存在差异,因此本节将从方法的功能覆盖(function)、诊断方式(style)和方法局限性(limitation)这几个角度分别对当前的研究现状和代表性方法进行分析.
2.
2.
1功能覆盖配置错误检测主要解决如何发现错误的问题,回答"是否发生错误以及发生了什么错误(what)";配置错误诊断重点研究如何发现导致错误的根本原因(rootcause),回答"为什么发生错误(why)";配置错误修复技术解决如何修正配置错误的问题,回答"怎么修复错误(how)",三者之间紧密相关又有所区别.
当前,已有的SMT方法具有不同的侧重点,分别关注和解决上述3个方面中的某个或某些问题,具有不同的功能覆盖.
2.
2.
2诊断方式SMT可以分为系统运行前的主动检测和运行时的被动诊断.
系统运行时的被动诊断以运行时的系统行为异常现象为依据,进行错误原因的查找和修复.
该方式的优势在于具有针对性,能够准确、有效地排除系统故障;但其局限性在于对方法的效率具有较高要求,尤其是生产环境下,目标系统的故障诊断需要将对系统的影响降低到最小.
系统运行前的主动检测发生在系统运行前,通过约束发现和验证等方法主动进行系统配置检测,发现配置中存在的约束违背和错误.
该方式的优势在于无需考虑方法的执行效率、降低系统运行时发生异常的风险,但是该方法需要有配置约束和规则的支持.
2.
2.
3方法局限性已有SMT方法或多或少都限定了一些前提条件,使方法必须在满足这些条件限定的前提下才能够得以应用.
这些前提条件主要存在于以下几个方面:1)目标系统代码.
根据需要的系统代码类型,可细分为源代码[38]、字节码[3941]和二进制代码[10,42,43].
这一前提条件主要出现在基于程序分析的方法中;2)定制化的目标系统和运行环境.
为了能够准确获得目标系统运行时的一些细粒度的行为和状态信息,部分方法需要对目标系统进行植入[10,39,41,43],与之关联的是对目标系统代码(主要是二进制代码)的需求;另外,部分基于重放技术的方法需要对目标系统的运行环境进行定制[44],从而实现预测执行和系统回滚重放;1290JournalofSoftware软件学报Vol.
26,No.
6,June20153)其他领域知识和数据.
在这一方面,主要包括了测试用例[32,44]、基准数据[33,39,42]和历史数据库[3537]等.
2.
3适用范围(applicability)应用系统在系统类型、程序语言以及运行环境等方面存在差异配置错误,类型也多种多样,导致的系统故障现象也不尽相同.
因此,已有SMT存在对应的适用范围,本节从适用范围相关的目标系统类型、配置错误类型以及解决的系统故障类型等3个角度进行分析.
2.
3.
1目标系统类型(target)SMT的目标系统均具有配置参数众多、可配置灵活性强的特征,从适用的系统类型方面,可以细分为操作系统级软件(OS-level)、系统支撑软件(system-level)以及面向最终用户的应用系统(application-level).
2.
3.
2配置错误类型(errortype)软件应用的配置错误类型多种多样,包括配置参数取值错误、兼容性错误、组件放置位置错误等.
在配置参数取值错误方面,已有工作通常将配置参数项建模为key-value形式的名值对,这些配置项通常存储于文本文件、XML文件以及Windows的注册表中,配置参数取值错误还可以进一步细分为拼写错误、大小写错误、格式错误、取值范围错误、取值类型错误等.
除此之外,还有部分工作能够诊断或修复包括配置参数取值错误在内的多种类型错误.
2.
3.
3系统故障类型(systemfault)配置错误导致的系统故障具有不同的特征与表现,从大的方面可以分为功能异常和性能异常两类.
系统功能异常又可以根据故障的严重程度分为多种类型,包括:1)系统崩溃、抛出异常或错误信息.
此类系统故障具有明显的错误现象,而且系统往往无法继续运行;2)系统行为或输出结果不正确.
此类系统故障错误现象较为隐蔽,系统能够继续执行,但是其行为或输出错误;3)系统行为或输出与用户预期不符.
严格意义上来讲,系统在功能方面是正确的,多数是由于配置参数项的变化导致行为或输出与用户本身的需求存在差异.
3配置错误诊断与修复方法概述为尽可能保证本文综述的全面性,采用以下方法进行相关文献的检索与选取:1.
为保证能够反映最新的研究成果和研究动态,以2000年以后的研究成果为检索范围2.
选取了与配置相关(configuration,misconfiguration)、错误相关(error,bug,failure,fault,anomaly)以及诊断修复相关(troubleshooting,detection,diagnose/diagnosis,fix)的多个关键词,采用关键词组合的方式构成文献检索的检索词组;3.
基于学术搜索引擎(Googlescholar)进行文献检索.
对第2步中的关键词进行多种组合(如misconfigurationtroubleshooting),共使用10组检索词组.
为保证检索结果的相关性,本文采用基于相关性排序的方式对每次检索结果的前30条(top-30)记录进行人工的分析过滤和去重;4.
基于文献数据库的检索.
本文从多个文献数据库中(ACMDigitalLibrary,IEEEXploreDigitalLibrary)选择与SMT最为相关的领域会议/期刊作为检索范围,涉及软件工程(ICSE,FSE,ASE,ISSTA,ICSM,ISSRE,COMPSAC,TSE,TOSEM,etc.
)、系统软件与程序设计语言(OSDI,SOSP,OOPSLA,etc.
)和计算机系统(ASPLOS,USENIXATC,LISA,etc.
)等共计20多个会议/期刊.
对检索结果同样采用多组关键词组进行检索、识别和过滤去重;5.
为了尽可能找到检索词组以外的相关文献,本文对第3步、第4步检索得到的文献集合的相关工作、参考文献和研究团队逐一分析,找到与本文主题密切相关且在前两步中没有检索发现的相关成果;6.
综合以上第3步~第5步的结果构成本文的综述范围,共计相关文献34篇,其中,会议/期刊30篇,博士论文2篇,技术报告2篇,详细信息见表1.
陈伟等:软件配置错误诊断与修复技术研究1291Table1Literaturesearchlist表1文献检索结果列表会议/期刊名称相关结果IEEEInt'lConf.
onSoftwareEngineering(ICSE)5(Ref.
[1,39,41,45,46])IEEEInt'lConf.
onAutomatedSoftwareEngineering(ASE)1(Ref.
[9])Proc.
oftheACMSIGOPS/EuroSysEuropeanConf.
onComputerSystems(EuroSys)1(Ref.
[36])TheUSENIXSymp.
onOperatingSystemsDesignandImplementation(OSDI)4(Ref.
[10,32,34,43])Proc.
oftheACMSIGOPSSymp.
onOperatingSystemsPrinciples(SOSP)4(Ref.
[44,42,14,38])Proc.
oftheInt'lConf.
onArchitecturalSupportforProgrammingLanguagesandOperatingSystems(ASPLOS)2(Ref.
[47,48])TheUSENIXAnnualTechnicalConf.
(ATC)2(Ref.
[37,49])Proc.
oftheACMSIGSOFTInt'lSymp.
onSoftwareTestingandAnalysis(ISSTA)1(Ref.
[50])TheUSENIXLargeInstallationSystemAdministrationConf.
(LISA)3(Ref.
[35,33,51])IEEEInt'lSymp.
onSoftwareReliabilityEngineeringWorkshops(ISSREW)1(Ref.
[52])IEEEInt'lSymp.
onDependableSystemsandNetworksWithFTCSandDCC(DSN)1(Ref.
[53])IEEEAnnualInt'lComputers,SoftwareandApplicationsConf.
(COMPSAC)1(Ref.
[54])CompanionProce.
oftheInt'lConf.
onSoftwareEngineering(ICSECompanion)1(Ref.
[55])Int'lSymp.
onSoftwareReliabilityEngineering(ISSRE)1(Ref.
[56])IEEEInt'lConf.
onCloudComputing(CLOUD)1(Ref.
[57])TheUSENIXWorkshoponTacklingComputerSystemsProblemswithMachineLearningTechniques1(Ref.
[58])Ph.
D.
Thesis2(Ref.
[40,59])Technicalreport2(Ref.
[60,61])综上,本文能够较为全面地分析和综述当前SMT的主流、高水平研究成果,同时也较为充分地反映了本领域的最新研究现状、动态和进展,具有较强的时效性.
本文分析综述的研究成果来源于国内外多个研究团队与研究学者,其中包括了加州伯克利分校(UCBerkely)的Katz团队、密歇根大学(UniversityofMichigan)的Flinn团队、华盛顿大学(UniversityofWashington)的Ernst团队和圣地亚哥加州大学(UCSD)的Zhou团队等.
本节将按研究团体和机构分别对具有代表性的研究工作和成果进行简要介绍.
3.
1加州伯克利分校的研究工作加州大学伯克利分校Katz的团队[1,9,40,50]以开源的复杂系统软件(如ApacheHadoop)为研究对象,提出了基于程序分析的方法来减少软件配置错误.
Rabkin等人的工作主要针对名值对(key-value)类型配置参数项展开3个方面问题的研究,包括配置信息管理(documentingconfiguration)、配置错误调试(debuggingconfiguration)和改进系统日志配置(improvingloggerconfiguration),并设计实现了工具Conf_Analyzer[40].
在配置信息管理方面,针对开源软件存在系统实际配置与文档记录不一致的情况,Rabkin提出了一种基于静态程序分析的系统配置项识别方法[1],推断系统配置项的参数类型,提高系统文档关于配置信息的准确性.
方法首先基于实证研究提出了应用配置项分类,将配置项类型划分为数值型(numeric)、标识(identifier)、使用模式(mode)和其他(other)这4类,每一类又根据使用语义分为多个子类;其次,方法基于JChord[62]对Java程序字节码(bytecode)进行字段敏感(fieldsensitive)的静态分析,在找到配置项读取方法后,通过分析方法参数获取关联的配置参数项及名称,通过分析参数读取方法的返回值类型、参数处理相关的系统函数类型和相关参数比较操作信息推断出系统配置参数的取值类型.
该方法能够发现大部分的系统配置项,相比原有的系统文档,在配置参数项信息方面具有更好的准确性.
在配置错误调试和诊断方面,提出了一种基于静态数据流分析的检测方法[1,8].
首先,方法通过目标系统源代码(Javabytecode)的静态分析找到系统读写配置参数的关键语句;然后,方法基于数据流(dataflow)分析建立不同程序点与相关配置参数间的映射表.
当系统运行产生故障并抛出异常信息时,系统用户可以根据映射表以及抛出异常的代码行号实现关联配置项的快速定位.
在此基础上,文章还提出了故障上下文敏感(failure-context-sensitive,简称FCS)的分析方法,以系统日志信息和堆栈信息(stacktrace)为补充来提高分析的准确性和效率.
1292JournalofSoftware软件学报Vol.
26,No.
6,June20153.
2密歇根大学的研究工作密歇根大学Flinn研究团队基于动态分析发现输入配置参数与系统异常之间的因果关联关系(causality),通过提高配置错误诊断过程的自动化程度来实现配置错误诊断和修复[59].
该团队分别对配置错误引起的系统功能异常和性能异常问题进行研究,并实现了相应的系统工具SigConf[37],AutoBash[44],ConfAid[10]和X-ray[43].
SigConf[37]以已知的配置错误信息库为依据,通过粗粒度的因果关联分析(causalityanalysis)进行配置错误诊断.
配置错误信息库存储了已知的历史配置错误及其系统状态信息,对于当前配置错误导致的系统异常,SigConf通过与已知配置错误的系统状态对比找到相似的已知配置错误.
SigConf运行一组测试用例(predicates)[61],基于每个测试用例的执行路径记录对应的因果依赖,生成相应的签名(signature),而系统状态则是基于测试用例的执行结果和签名生成的.
SigConf的粗粒度因果关联分析主要体现在它记录了测试用例执行过程中所依赖的所有对象,包括文件、目录、类库等,而不细化到对象内部,如配置文件中的具体配置项等.
因此,SigConf具有执行代价小和效率高的优点,能够诊断多种类型的配置错误(如配置取值错误、类库不兼容等),但也由于粗粒度的分析策略,导致在准确度方面存在不足.
AutoBash[44]基于操作系统内核级的预测执行(speculativeexecution)来测试不同的配置操作给系统带来的影响.
AutoBash同样基于进程和文件粒度的因果关联分析进行错误诊断.
AutoBash以一组测试用例作为辅助,在不影响和改变其他系统的同时,尝试可能的配置错误修复方法,通过反复的尝试和回滚,找到能够解决当前系统故障的配置修复方法.
AutoBash将进程作为黑盒,认为进程的输出完全依赖于其输入数据,在同样粗粒度的分析基础上,AutoBash能够较为准确地定位存在故障的配置错误对象,但是难以进一步定位其内部的细粒度对象,例如ApacheHttpServer配置文件httpd.
conf内的某个特定配置参数项.
因此对于粗粒度对象中包括众多子项的场景,AutoBash的诊断效果有限.
ConfAid[10]针对目标系统采用白盒分析策略,通过细粒度的因果关联分析实现配置错误的诊断.
ConfAid对目标系统的二进制代码进行植入,深入进程内部,通过分析系统运行时的动态信息流来获取由数据和控制流引起的因果依赖.
ConfAid将动态分析的范围限定于从配置文件中读取数据的相关语句、变量和取值,一旦发现改变某个配置参数的取值能够引起系统控制流的变化并避免当前系统错误的发生,那么ConfAid将这一配置参数作为可能的错误项.
相比于前者,ConfAid主要针对配置文件中配置项取值错误进行诊断,具有较高的准确度;但是细粒度的分析和探针植入将引入较高的额外开销,降低系统运行效率.
与SigConf和ConfAid不同,X-ray[43]主要基于细粒度的因果关联分析实现对配置错误导致的系统性能异常诊断.
X-ray提出了基于性能摘要(performancesummarization)的配置错误诊断方法,首先为每个细粒度事件(如单个指令和系统调用等)确定对应的性能代价(performancecost),如响应时间、I/O资源使用率等;然后,基于动态信息流分析的方法找到导致每个事件执行的关联配置项(rootcause),并根据事件发生的概率将其对应的性能代价赋予对应的配置参数;对于每个配置项,通过汇总其关联的所有事件赋予的性能开销得到该配置项的总体性能代价,总体代价最高的配置项最有可能成为导致系统性能异常的根本原因.
3.
3圣地亚哥加州大学的研究工作圣地亚哥加州大学(UCSD)Zhou研究团队在应用配置错误的调研分析和错误诊断方面开展研究.
Yin[14]对多个商业和开源应用系统的配置错误进行了实证研究,是第一个针对配置错误相关特征研究和分析的工作.
该工作研究了546个真实的配置错误,其中,309个来源于一个商业化存储系统,另外237个错误来源于4个广泛使用的开源系统(CentOS,MySQL,ApacheHttpserver,OpenLDAP).
Yin主要从配置错误的类型、模式、原因、系统表现以及造成的影响等几个方面进行了实证研究,将配置错误的类型分为参数错误、兼容性错误、组件错误几大类.
该实证研究工作对配置参数错误导致的系统故障诊断与修复研究提供了丰富的论据和事实依据.
Yuan[49]以Windows环境下的应用为目标系统,研究Windows注册表中应用配置项的错误发现和检测方法.
Windows注册表中存在大量的应用配置信息,并且在运行时有频繁的注册表信息访问事件发生,配置数据的访陈伟等:软件配置错误诊断与修复技术研究1293问事件序列在一定程度上反映了应用系统的控制流信息,并能够提供程序运行时行为的上下文.
考虑到系统正常运行时对于注册表数据的访问行为通常是确定的、有规律的,Yuan提出了在线的配置错误检测方法,通过监控和记录注册表访事件序列分析和挖掘出注册表配置信息的访问规则,例如:在事件a,b,c之后应该确定性地发生事件d,即规则为abc→d.
当系统运行时监控到违反配置访问规则的事件发生时(例如,在事件a,b,c后发生了事件e而不是d),则认为当前事件可能导致配置错误产生并加以警告.
Yuan基于该方法设计实现了配置错误检测工具CODE,包括配置数据访问事件监控收集和访问规则分析两部分.
CODE以字典树(trie)表示事件序列,并基于Sequitur算法[63]进行规则的分析挖掘.
CODE基于系统外部事件分析,无需目标程序源码以及系统相关语义信息的支持,但其局限性在于必须能够提供大量的、频繁发生的配置访问事件来支持规则的分析挖掘,因此适用于具有配置数据集中存储管理和大量访问的应用场景,如Windows环境.
另一方面,CODE基于规则偏离分析解决配置错误的检测和诊断问题,即使在系统没有表现出明显的系统异常时,也能够在线发现潜在的配置错误,通过与已知规则的对比来提供错误解决依据.
Xu[38]从软件系统开发和设计的视角来看待配置错误问题,认为配置错误有时是由系统及配置本身相关的开发设计问题导致的,不应该完全归咎于用户的错误行为.
基于这一观点,Xu针对名值对类型的配置参数错误,基于静态程序数据流分析从配置参数的读取和使用模式中推断出参数配置约束,主要包括单个配置参数的类型约束(typeconstraint)、取值范围约束(valuerange)、涉及多配置参数的控制依赖(controldependency)和取值关联(valuecorrelation),以此为依据来辅助程序开发人员改进系统配置的设计,提高系统应对配置错误的能力.
SPEX是基于上述方法实现的配置约束推理工具,首先从目标系统源代码中识别出配置变量;然后,基于数据流分析获取与配置参数对应的每个程序变量,记录沿着数据流路径发现的所有属性约束.
在第2遍源码分析中,SPEX基于得到的每个配置参数的代码切片进行配置参数的约束推理.
以SPEX得到的目标系统参数约束集合为基础,Xu还实现了配置错误生成与测试工具SPEX-INJ.
SPEX-INJ生成违背约束的配置设置并注入目标系统,通过运行测试用例观察系统在异常发生时的反馈,以此来评价系统应对配置错误的能力,指导系统配置设置的改进.
SPEX将配置错误的诊断和修复工作提前到开发和设计阶段,更加具有主动性.
但是,基于静态分析的方法使得必须有目标系统源代码的支持;同时,SPEX目前主要应用于单个程序和系统的名值对类型配置参数,对于跨系统的配置间关联导致的约束无法适用.
Zhang[48]研究发现,软件配置项之间以及配置项与运行环境之间存在大量关联(correlation).
例如,配置项A指定某文件路径,而系统环境下该文件路径是否存在影响A取值的正确与否;又如,配置项A为某文件,而配置项B的取值表示文件的拥有者,则A与B间存在相互关联.
关联是导致配置错误的原因之一,由此,Zhang实现了基于配置关联的错误检测工具Encore[48].
Encore基于训练数据集(已有的系统配置)分析挖掘配置关联约束,将获取到的关联约束应用到待检测系统,实现配置错误的主动检测,其主要步骤包括:1)训练集数据处理(dataassembling).
根据配置项语义和取值特征进行配置项类型推断,根据配置项类型为其附加相应的环境信息.
例如,当前配置项为文件类型,则对应的环境属性可以包括用户(owner)、用户组(group)、权限(permission)等;2)预先定义一组约束模板(template)来描述配置项及环境信息间可能存在的二元关联关系.
例如,图3中的模板表达了用户名称类型的配置项B应该是文件类型配置项A的所有者,其中,A和B为模板中的占位符(placeholder);Fig.
3Exampleofconstrainttemplate图3关联约束模板示例3)基于模板集合,从训练集中选取满足模板的配置项并逐一进行实例化,产生针对目标系统的一组具体备选约束规则集合;Template:[AFilePath][BUserName]Rule:DataDiruser1294JournalofSoftware软件学报Vol.
26,No.
6,June20154)基于一组启发性规则过滤备选约束集合,提高约束规则的正确性;5)基于最终得到的约束规则对目标系统进行检测,对于出现约束违背的配置项产生警告.
除此之外,Encore还能够对单个配置项的拼写错误、取值类型错误以及取值错误进行检测.
Encore是基于统计分析和数据挖掘的配置错误主动检测方法,它只关注软件系统的配置项,但需要以训练数据集为基础,还需要提供预定义的约束模板;其次,Encore主要用于检测单个系统内部由于存在配置关联而导致的错误,没有考虑多个系统间存在关联的场景.
3.
4华盛顿大学的研究工作Zhang针对单个配置项取值错误导致的系统功能异常设计实现了工具ConfDiagnoser[39,46].
ConfDiagnoser将静态分析、动态分析和统计学习结合在一起,进行配置错误自动诊断.
在静态分析过程中,ConfDiagnoser采用基于程序薄片撷取(thinslicing)[64]的轻量级依赖关系分析方法识别每个配置项能够影响到的控制流分支判断语句.
然后,ConfDiagnoser有选择性地对目标系统源代码进行植入,获取被配置参数影响的判断语句运行时的行为作为执行概况(executionprofile).
ConfDiagnoser的故障诊断以预先建立的正确执行概况数据库为支撑,当系统运行时遇到可疑的配置错误时,ConfDiagnoser通过运行植入代码的系统进行错误重现,并从数据库中找到与当前错误相似的正确执行概况.
最后,基于统计分析的方法,ConfDiagnoser找到动态行为在正确和错误执行概况之间差别最大的那些判断语句,而与这些判定语句相关的配置则有可能是导致异常的根本原因.
在进一步的工作中,Zhang[41]发现:软件系统演化过程中,新版本软件的配置参数项会发生变化,并导致系统的某些行为或特征发生变化;用户升级新版本后,由于配置的使用和取值的变化,新版本系统的运行与用户的原有预期存在偏差.
尽管新版本系统本身正确,但从用户角度来说,与预期的偏差则难以接受.
为了保证系统演化后满足用户的预期目标,Zhang基于运行时植入监控、静态程序分析和运行轨迹对比的方法设计实现了配置诊断工具ConfSuggester,诊断并发现可能导致系统新老版本行为偏差的配置参数项,用户可以改变这些配置项的取值使系统行为符合其预期.
ConfSuggester的基本思想是:对于软件演化前后的新老版本系统,通过控制流的差异发现程序行为的差异;然后,基于程序行为差异的分析推理找到可能导致差异存在的配置项.
ConfSuggester通过3个步骤找到引起新旧版本系统行为偏差的配置项:首先,在两个版本的字节码中植入探针,监控目标是影响控制流变化的判定语句;其次,基于相同的输入和配置运行两个版本的系统,发现两个执行轨迹中的控制流差异;然后,基于一种轻量级的依赖关系静态分析技术,找到造成当前控制流差异的可能配置项集合;最后,通过基于权重的排序算法将可疑配置项的分级排序列表返回给用户,排序越靠前,可疑性越大.
与ConfDiagnoser不同的是,ConfSuggester诊断的配置问题更加宽泛,在诊断配置错误的同时,还能够找到导致系统行为违背用户预期的配置项.
3.
5微软研究机构的工作微软是较早进行SMT技术研究的机构之一,主要针对Windows环境下基于注册表的配置错误诊断问题展开研究,研究成果有Strider[33,51]、PeerPressure[34,60]、Snitch[58]和基于事件轨迹(eventtracebased)的诊断方法[36].
Strider[33]采用黑盒的、基于状态的配置错误诊断方法,将注册表的当前内容作为系统状态[51],采用状态差分(statediffing)的方法逐步缩小可能存在配置错误的搜索范围,最终实现可能的配置错误定位.
首先,Strider将异常时系统状态与本机的正确系统状态(或其他机器的正确系统状态)对比,得到状态差分集合;其次,Strider重新执行异常程序获取异常发生时涉及的注册表配置项集合;然后,Strider通过对两个集合执行交集操作进一步缩小可能导致系统异常的注册表配置项范围;最后,针对交集内的可疑配置参数项,Strider采用一系列启发性规则对其中的配置项进行排序,排序越靠前的配置项成为系统异常原因的可能性越大.
PeerPressure[34,60]相比于Strider有了进一步改进:基于统计学习的方法,通过对比运行同样应用的样本系统和当前故障系统的注册表项找到可疑的错误配置项集合;然后,基于贝叶斯统计方法对可疑的错误配置项进行概率计算及排序;最后,依据少数几个候选配置在正确样本系统中的取值,采用试错的方式进行修复.
文献[36]采用事件轨迹(eventtrace)表示系统行为,将当前发生故障的系统事件轨迹与已知的系统故障及陈伟等:软件配置错误诊断与修复技术研究1295解决方法的事件轨迹集合进行对比,找到与之相似的事件轨迹,从而进一步找到对应的已知系统故障及其修复方法.
该方法以WindowsXP环境下系统调用(systemcall)作为系统事件,通过监控和拦截系统调用获取事件信息.
方法的系统实现包括4个组成部分,其中,troubleshooter负责故障重现;tracer同时进行事件轨迹的记录并发送给classifier;classifier基于n元语法模型(n-grammodel)表示事件序列,并基于支持向量机(supportvectormachine,简称SVM)算法[65]进行事件序列中系统行为模式的识别,计算与已知问题库中(knownproblemDB)事件轨迹的相似度来找到可能相关的已知系统故障及修复方法.
Snitch[58]监控获取大量的应用配置参数及文件的读/写事件信息,然后,基于机器学习的方法建立应用错误与配置状态之间的二元决策树(binarydecisiontree),反映出错误信息与应用配置之间的关联.
应用运行再次发生错误,能够基于该决策树快速定位与错误相关的配置信息.
Snitch主要应用于Windows环境下存在频繁、大量配置读/写事件的场景,需要预先获取大量训练数据(应用配置读/写事件)建立二元决策树.
对于不同的应用系统,必须建立各自对应的决策树,同时,决策树的建立采用一种交互式的、需要人工指导的方式.
3.
6其他研究工作Choronus[32]在系统出现异常时首先定位发生异常的时间点,然后,通过对比该时间点前后的系统状态和配置参数的变化来找到可能引起系统故障的配置错误.
为了达到这一目标,Chronus基于虚拟化技术和一个定制的文件系统来找到引起系统无法正常运行的配置参数设置的改变.
ConfDebugger[52]是一个完全基于程序静态分析的轻量级配置错误诊断工具,仅仅依靠配置项信息、系统错误堆栈信息(failurestacktrace)以及目标系统的Java字节码来定位可能导致当前错误的配置项.
ConfDebugger首先基于正向静态分析和薄片撷取(thinslicing)技术找到每个配置项的程序读取语句以及该语句影响的语句集合;其次,基于错误堆栈信息找到出错的语句,并基于反向静态分析和薄片撷取技术找到当前错误语句关联的语句集合;最后,在两个语句集合的交集中查找相关联的配置项,那么该配置项或配置项集合则作为可能导致错误的所在.
Triage[42]支持在线的故障诊断,采用轻量级的重执行(replay)技术来支持程序运行时异常的重放,获取当时的环境与上下文信息.
Triage采用一种模仿人工调试过程的故障诊断协议进行故障原因分析,通过一组相似的输入和执行环境得到正确和错误的执行结果,并基于动态程序分析进行相似输入且执行结果不同的系统执行路径和数据流的分析,最终诊断出导致系统故障发生的根本原因.
Triage能够诊断多种类型的系统错误,包括配置错误导致的系统故障,并能够提供详细的诊断报告,包括故障信息、触发条件、相关代码和变量、错误扩散链以及可能的修复方法等.
文献[35]提出了一种基于程序行为的配置错误诊断方法,该方法通过监控系统运行轨迹来获得运行时系统调用(systemcall)、信号量、环境变量等行为信息,并将系统行为与状态合二为一建立系统签名(signature)作为正常运行的基准.
当系统运行出现异常时,通过对比异常行为与已有的系统签名来找到当前系统行为存在的偏差,从而分析可能导致系统异常的错误.
ECCFixer[45]是一个针对eCOS(embeddedconfigurableoperatingsystem)的配置错误修复工具,针对出现约束违背的系统配置项,自动产生满足需求的取值范围(rangefix).
ECCFixer基于Reiter[66]诊断理论,将配置参数取值问题映射为可满足问题(SAT)求解,从约束和配置集合中得到需要重新设置和修改的最小变量集合;然后,基于谓词逻辑将最小变量集合涉及的约束转化为等价的合取范式,并将每个子句作为一个最小的修复单元(fixunit);最后,在产生全局的修复取值范围时考虑了多个约束间的相互作用,为涉及的多个配置参数产生无冲突的取值范围集合.
ConfErr[53]是第一个模拟配置错误并进行目标系统注入和评估的工具.
ConfErr模拟用户在系统配置时人工操作可能造成的拼写错误、结构错误以及语义错误,将上述类型错误随机注入到目标系统对应的配置文件中,然后计算和评估系统配置错误的应对能力和表现,生成相应的分析和评估概况.
ConfErr同样可以用来作为目标系统应对配置错误能力的测试和评估基准,其生成的分析和评估概况可以作为系统改进的依据,也可以用于在相似的系统间进行容错能力的对比.
1296JournalofSoftware软件学报Vol.
26,No.
6,June2015Arshad[56]对JavaEE应用服务器的配置问题进行了特征研究,对开源应用服务器GlassFish和JBoss的281个配置问题,从4个维度进行分析,并基于分析结果设计实现了一个面向JavaEE的应用服务器配置错误注入及评估工具ConfInject.
ConfInject向应用服务器的XML配置文件进行基于字符串的配置项错误注入,并从4个方面对该错误导致应用服务器出现异常的情况进行分析,用以评价目标应用服务器应对配置参数错误的能力.
Meng[57]针对大规模分布式的、基于多层体系架构的网络应用系统提出了一种基于分析和比较的配置文件自动发现方法.
该方法把待分析的目标机器与一组基准镜像虚拟机进行比较,通过分析对比目标机器与镜像之间、镜像与镜像之间在文件方面发生的变化,总结提出了6种文件变化模式(changepatter,简称CP),并将属于6种CP的文件作为候选配置文件.
最后,该方法采用基于领域知识库(存储已有的配置文件发现语义规则)或人机交互的方式对选配置文件进行最终判断和认定.
文献[54]从系统错误报告(bugreport)的角度来判断当前系统错误是否由配置错误导致(configurationbugreportprediction).
该工作基于特征选择技术(featureselectiontechnique),如信息增益技术(informationgain)和卡法检验(Chi-square),从大量错误报告文本中选择紧密相关的特征术语(significantterm);然后,使用多种文本挖掘方法(如朴素贝叶斯、支持向量机、朴素贝叶斯多项式等)建立错误报告的分类统计模型(classifier);最后,给定一个错误报告,该模型能够判断出当前错误是否是配置错误相关的.
4软件配置错误诊断方法分析本节依据第2节提出的配置错误诊断方法分析框架对第3节概述的代表性工作进行分析,并对每个分析方面和角度中的各类工作进行统计.
4.
1方法类型分析所有代表性方法中,基于程序分析的方法、基于统计学习的方法和混合方法分别为5/18,4/18,5/18;此外,基于对比的方法和基于重放的方法分别占3/18和1/18(由于ECCFixer[45]仅针对配置修复问题,因此不在方法类型分析的统计范围内,详见表2).
4.
1.
1基于程序分析的方法基于程序分析的配置错误诊断方法可以进一步分为基于静态程序分析的方法和基于动态程序分析的方法.
基于静态程序分析的代表有Conf_Analyzer[40],ConfDebugger[52]和SPEX[38],而基于动态程序分析方法的工具有ConfAid[10]和X-ray[43].
Conf_Analyzer,ConfDebugger和SPEX分别对目标系统的字节码(bytecode)和源代码进行静态分析,而ConfAid和X-ray则基于系统的二进制代码(binarycode)进行植入、监控和分析.
程序分析的配置错误检测与诊断方法具有较高的准确率,但同时也带来了较高的额外开销.
为了提高执行效率,该类型的方法需要考虑路径覆盖和分析规模的问题,尽可能通过启发式规则降低分析复杂度.
基于程序分析方法的局限性还包括:1)程序语言相关性;2)编程风格和编程实践影响方法的有效性.
如果程序捕获所有异常,并抛出一个没有实质内容的泛泛的出错信息,那么该方法将难以进行相关配置参数项的定位.
4.
1.
2基于统计学习的方法CODE[49]从大量的、频繁的配置数据访问事件中分析挖掘出事件序列表示的配置访问模式和规则,通过发现违背规则的事件来检测配置错误.
文献[36]采用事件轨迹(eventtrace)表示系统行为,基于SVM识别事件序列中的系统行为模式.
Encore[48]从大量的训练数据集中分析挖掘出配置项间的关联约束.
Sintch[58]基于训练数据集建立二元决策树来辅助配置错误诊断.
基于统计学习的方法需要大量历史信息作为分析和挖掘的数据基础,例如,CODE和文献[36]均以Windows环境下的注册表信息作为配置参数实例,而Encore则从AmazonEC2中的公共镜像文件中获取训练数据.
4.
1.
3基于重放技术的方法代表性工作有AutoBash[44]和Triage[42]:AutoBash基于操作系统内核级的预测执行(speculativeexecution)来测试不同的配置操作变化给系统带来的影响;Triage采用轻量级的重执行技术来支持程序运行异常时的重陈伟等:软件配置错误诊断与修复技术研究1297放,获取当时的环境与上下文信息.
AutoBash对底层操作系统内核进行了定制构造沙箱环境,在Linux内核之上,实现了系统状态的回滚和与其他应用的隔离;其次,AutoBash和Triage还需要一组测试用例来检验修改配置参数前后目标系统的变化.
4.
1.
4基于对比的方法Strider[33]和PeerPresure[34]以本机正确系统状态以及样本机的系统状态为基准,通过错误系统状态与基准的状态差异对比进行诊断;Choronus[32]通过对比系统故障发生前后系统状态和配置参数的变化找到可能引起系统故障的配置错误;signature-based[35]方法对比异常行为与已有的系统签名来找到当前系统行为存在的偏差,分析可能导致系统异常的错误;SigConf[37]以已知的配置错误信息库为依据,通过与已知配置错误对应的系统状态对比找到相似的已知配置错误,实现配置错误的诊断.
4.
1.
5混合方法采用混合方法进行配置错误诊断的有ConfDiagnoser[39],ConfSuggester[41]和Triage[42]:ConfDiagnoser[39]综合采用了静态程序分析、动态程序分析和对比技术,通过静态分析识别每个配置项能够影响的控制分支判断语句,通过动态分析获取系统的执行概况,最后对比找到正确和错误执行概况之间差别最大的判断语句集合;ConfSuggester[41]同样基于静态、动态程序分析和运行轨迹对比发现系统演化过程中新老版本间配置的差异;Triage[42]基于重放技术获取系统故障时的环境与上下文信息,对输入相同但执行结果不同的多次系统执行进行动态程序分析,最终诊断出导致系统故障发生的根本原因.
如前所述,混合方法充分融合了不同方法的优势,对其局限性也兼而有之:ConfDiagnoser和ConfSuggester需要程序分析必须的源码支持,具有编程语言的针对性;其次,ConfDiagnoser还需要以正确执行概况的数据信息作为与当前系统故障行为进行对比的基准.
4.
2方法特征分析4.
2.
1功能覆盖分析现有方法的研究重点是配置错误诊断(12/19),而错误发现和修复各占2/19,还有部分工作覆盖了诊断与修复两个方面(3/19).
配置错误诊断方法含Conf_Analyzer[40],ConfAid[10],X-ray[43],SPEX[38],ConfDiagnoser[39],ConfSuggester[41],Strider[33],PeerPressure[34],Snitch[58],ConfDebugger[52]和Choronus[32]等.
上述研究成果的前提通常假设配置错误导致的系统异常是能够明显被观察到和发现的,例如抛出异常信息或崩溃[10,40]、系统执行错误[39]、输出信息与预期不符[41]和系统性能显著下降[43]等,因此,诊断出导致系统异常的根本原因成为修复系统故障的必要前提和核心问题,也使得配置错误诊断方法的研究成为最受关注的研究问题.
在明显的、可被观察的系统故障和异常之外还存在无法及时发现的系统错误,使得系统配置错误检测也成为研究问题之一.
CODE[49]是系统配置错误检测的代表性工作,能够通过在线的配置访问事件序列对比发现违背配置访问模式和规则事件的发生,从而在系统进行错误传播并表现出某些故障现象之前能够及时检测到错误的发生.
配置错误修复的研究目标是实现错误修复方法的自动生成,甚至是自动修复,进一步提高方法整体的自动化程度,降低对用户知识和经验的要求.
基于对比的方法通常能够在实现错误诊断的同时给出问题的解决方案,这是由于有对比基准或已知错误的解决方法作为参考,如SigConf[37],Signaturebased[35],Eventtracebased[36].
基于重放技术的方法则通过重放技术将系统错误调试和修复的过程自动化,达到错误修复的目标,代表性工作有AutoBash[44]和Triage[42].
ECCFixer[45]是一个专门以配置项取值错误修复为目标的工具,采用逻辑推理和约束求解的方法,为存在约束违背的系统配置项自动生成正确的取值范围.
4.
2.
2诊断方式分析从已有研究方法和成果来看,系统运行时的被动诊断为主要方式,在本文分析的19个代表性方法中,有16个采用的是故障发生后的诊断方式.
这些方法大多基于系统故障的现象、特征或者通过再次的错误执行重放(replay)或重执行(re-execution)来获取细粒度的、深层次的错误相关信息,从而有针对性地进行诊断和修复.
1298JournalofSoftware软件学报Vol.
26,No.
6,June2015相比于运行时的被动诊断,已有工作中采取主动的运行前诊断的方法主要有ECCFixer[45],SPEX[38]和Encore[48].
这些方法基于目标系统已有的配置约束[38]、程序分析推断出的配置约束[45]和基于统计学习得到的约束[48]为依据,采用约束验证的方法来主动检测和发现当前系统配置参数存在的约束违背.
ECCFixer还能够通过逻辑推理和约束求解的方法为存错误的配置参数项自动生成正确的取值范围.
4.
2.
3方法局限性分析本文分析的现有方法多数具有多个前提或局限性(8/19).
其中,需要系统代码并植入探针的方法占4/19,包括ConfAid[10],X-ray[43],ConfDiagnoser[39]和ConfSuggester[41],这些方法均通过对目标系统代码进行探针植入来获取系统运行时的动态信息.
需要系统代码并人工标记分析起始位置的方法占2/19,包括Conf_Analyzer[40]和SPEX[38],这些方法则需要通过人工标注的方法来限定程序静态分析的范围和起始位置,提高分析效率.
需要运行环境定制并提供测试用例的方法[44]和需要代码、监控植入以及领域知识支持的方法[39]各占1/19.
存在单个前提条件的方法中,需要领域知识和数据支持的方法占了8/19,包括SigConf[37],CODE[49],Strider[33],PeerPresure[34],Encore[48],Snitch[58]等,均是以领域知识和历史数据作为分析诊断的依据.
而仅需要系统代码[52]或测试用例支持[32]或已知配置约束[45]的方法则各占1/19.
4.
3适用范围分析4.
3.
1目标系统类型分析代表性方法主要以系统支撑软件为研究目标(12/19);其次是应用软件(6/19);以操作系统为目标系统的方法所占比例最小(1/19),主要以嵌入式可配置系统和Linux系统为对象.
ECCFixer[45]实现eCos配置错误的修复,eCos是一种嵌入式可配置实时操作系统,因此,其目标系统属于操作系统级软件.
当前,系统支撑软件越来越具有规模大和配置复杂的特征,例如Apachehttpserver,mysql,Hadoop等.
互联网应用、大数据和云计算等新技术的发展与应用,也使得这些系统支撑软件成为当前已有工作的主要研究对象,面向系统软件的配置诊断方法和工具有Conf_Analyzer[40],ConfAid[10],ConfDiagnoser[39]等.
CODE[49],Strider[33],PeerPresure[34],Eventtracebased[36],Snitch[58]以Windows环境下的应用软件作为目标系统,如InternetExplorer和Outlook等,这些应用以Windows的注册表作为配置设置和管理的基础,使得上述工作采取的方法能够获取丰富的配置相关数据作为配置错误检测、诊断和修复的依据.
4.
3.
2配置错误类型分析诊断名值对类型的配置参数取值错误方法占13/19,其他方法(6/19)则在配置错误类型方面没有明确限制.
基于程序分析的诊断方法主要围绕配置参数取值错误展开,该方法能够获得较为详细的配置项读取和使用信息等,代表性工作有Conf_Analyzer[40],ConfAid[10],X-ray[43],CODE[49],SPEX[38],Encore[48],ConfDiagnoser[39],ConfSuggester[41],Strider[33]和PeerPresure[34].
除此之外,还有部分工作能够诊断或修复多种类型的配置,这些工作主要采取的是基于对比[10,21]和基于重放[13,14]的方法,由于有已知故障及修复信息作为基准,使得基于对比方法的诊断和修复技术能够应付多种配置错误类型,而不是仅仅局限于配置参数的取值错误;基于重放技术的修复方法由于提高了调试过程的自动化程度,也能够修复多种类型的配置错误.
4.
3.
3系统故障类型分析当前已有方法主要是面向功能故障相关的配置错误诊断,占18/19,仅有少数工作诊断系统性能异常相关的配置错误(1/19).
代表性工作多数面向系统崩溃、抛出异常或错误信息的功能异常,如Conf_Analyzer[40],ConfAid[10],SPEX[38]等;ConfDiagnoser[39]以正确的执行概况为基准,使得系统行为即使没有明显的异常表现,在发生偏差时就能够得到诊断;ConfSuggester[41]以系统演化过程中配置参数变化导致的新老版本的行为应用场景,采用新老版本系统行为差异的对比方法,使导致系统功能与用户需求不符的这一类配置问题得以诊断.
当前,对于配置错误相关的系统性能异常诊断和修复的研究工作较少,代表性的工作主要有X-ray,它基于动态程序分析的方法获得程序执行语句的细粒度性能代价,然后,根据异常发生时汇总的所有语句的总体性能代价以及与配置项的关联度进行诊断.
陈伟等:软件配置错误诊断与修复技术研究12994.
4小结本节对国内外具有代表性SMT研究成果进行归纳,见表2.
从本文提出的分析框架的方法类型、方法特征以及适用范围这3个方面和多个角度对研究工作进行了总结,当前软件配置错误诊断与修复相关的研究成果呈现出以下特点:(1)从方法类型来看,较早的研究工作[33,34,36]主要通过建立系统表现出来的外部行为特征以及系统配置的关联来诊断和修复配置错误,但越来越多的工作[10,38,40]采用程序分析方法从系统内部获取细粒度的数据依赖和控制流信息,使配置错误的诊断和修复更为准确.
最新的研究工作[39,41]更趋向于采用多种方法相结合的混合方法,能够借助各种方法的优势,需要注意的是如何避免相应方法本身的一些局限性;(2)从方法特征来看,首先在功能覆盖方面,当前代表性的研究工作大多覆盖了配置错误诊断阶段,并将该问题作为研究的重点,同时,越来越多的工作[38,45]将关注点投向配置错误的自动修复方面,使错误修复更加自动化,降低对用户的知识与经验的依赖度;其次,在诊断方式上,当前研究成果主要采用的是一种运行时的被动诊断和修复方法,在错误发生时和发生后采用在线或者离线的方法完成配置错误的诊断和修复;在方法局限性方面,由前述分析可以看到,每种方法或多或少在系统代码、运行环境和其他数据知识方面存在一定的前提和假设,因此很多研究工作的重点之一也是如何消除或放宽这些前提条件,使方法在使用范围以及自动化程度等方面有所提高;(3)从适用范围来看,当前已有的研究工作主要面向大规模的网络应用支撑系统软件和特定的Windows环境下的客户应用,而解决的配置错误类型主要是具有key-value形式的配置项取值错误,而这类配置错误引起的系统异常和系统故障也主要是功能性异常.
Table2AnalysisofSMTmethods表2软件配置错误诊断与修复技术分析方法类型方法特征适用范围功能覆盖诊断方式局限性目标系统错误类型故障类型Conf_Analyzer[40]ADRC+ASKFSigConf[37,61]CD+FRKSAFAutoBash[44]RFRE+TSAFConfAid[10]ADRC+ISKFX-ray[43]ADRC+ISKPCODE[49]SERKAKFSPEX[38]ADPC+ASKFConfDiagnoser[39,46]A+CDRC+I+KSKFConfSuggester[41]A+CDRC+ISKFStrider[33,51]CDRKAKFPeerPressure[34,60]C+SDRKAKFSnitch[58]SDRKAKFEventtracebased[36]SD+FRKAAFChoronus[32]R+CDRTSAFConfDebugger[52]ADRCAKFTriage[42]R+AD+FRC+ISAFSignaturebased[35]CDRKSAFECCFixer[45]-FpROKFEncore[48]SEPKSKF方法类型:A—Programanalysisbased,S—Statisticsbased,C—Comparisonbased,R—Replaybased;功能覆盖:E—Exploring,D—Diagnosing,F—Fixing;诊断方式:R—Reactive,P—Proactive;局限性:C—Code,T—Testcase,E—Environmentcustomization,K—KnowledgeDB,I—Instrumentation,A—Annotation,R—Constraint;目标系统:O—Operatingsystem;S—Systemsoftware;A—Application;错误类型:K—Keyvalue,A—Any;故障类型:F—Functionalfault,P—Performancefault.
总结当前的研究工作,主要存在以下不足:1300JournalofSoftware软件学报Vol.
26,No.
6,June2015(1)目标系统主要是单个软件系统,忽略了构成应用的运行支撑环境以及构成复杂网络应用的不同组件和系统之间在配置参数上存在的隐式关联.
已有工作主要针对单个目标系统的配置问题进行研究[1],例如系统软件Hadoop、HBase和JavaEE应用服务器等.
实际应用中,复杂应用(尤其是复杂网络应用)是由操作系统、中间件、数据库以及异构组件构成的上层应用组成的,不同层次之间以及异构组件之间存在着依赖和交互,导致复杂网络应用的不同组成部分之间在配置参数方面同样会存在关联.
例如,复杂网络应用中,数据库访问组件中的数据源相关配置与底层数据库的相关配置之间就存在着关联关系.
在这种情况下,如果无法获取构成应用的组件及系统间配置参数的关联,那么在进行系统的配置或迁移时会导致配置参数设置和修改的遗漏,使得存在关联关系的配置参数发生相关约束和规则违背的情况,并最终导致系统故障的发生.
(2)已有研究成果主要采取的是一种系统异常发生时的被动诊断与修复策略,主动检测与修复相对薄弱.
被动的错误诊断与修复策略具有针对性,但是为了减少系统失效时间,对方法的效率和代价有较高要求.
加强系统运行前的、主动的配置错误检测力度,能够避免部分配置错误在运行时发生,降低系统由于配置错误导致运行异常和失效的几率.
因此,深入研究运行前的主动检测与修复机制是运行时诊断与修复的有效补充,通过覆盖运行前与运行时两个阶段来降低出错几率,保障系统可应用和提高服务质量.
(3)已有研究成果通常假设当前系统异常由且仅由一个配置参数项的错误导致,对于多个配置项错误导致的系统异常情况难以适用.
当前,已有的系统配置错误诊断方法通常假设导致当前系统故障的配置错误有且仅有一个,然而实际情况下,很多应用错误都是由少数几个参数的相互作用导致的.
例如,Kuhn和Reilly分析了Mozilla浏览器的错误报告记录,发现超过70%的错误是由某两个参数的相互作用触发的,超过90%的错误是由3个以内的参数互相作用而引发的[67].
因此,已有方法不适用于多配置错误的诊断与修复.
对于存在多个配置项错误的情况,基于程序分析的方法需要对配置参数项进行逐个分析,存在效率低下的问题;而基于对比的方法对于状态和现象高度相似的系统异常存在错误检测和诊断的困难.
同时,多配置参数错误导致的系统异常不会因为部分参数的修正而得到解决,而且有可能因为部分参数的修正导致系统异常现象发生变化,这都为基于程序分析的多配置项错误诊断带来了挑战.
(4)在方法适用范围方面,已有方法的目标配置错误类型和系统故障类型较为单一.
当前方法主要针对键值对(key-value)形式的配置参数取值错误,对于其他类型的配置错误(如兼容性错误、组件放置位置错误等)的研究涉及较少.
因此,对于其他类型配置错误的检测、诊断和故障修复技术研究,是对当前已有工作的有益补充,能够有效提高SMT的覆盖面和完整性.
在系统故障方面,当前方法主要解决配置错误导致的系统功能异常问题.
相比于系统性能异常,功能异常更加明确,且可能关联的参数配置项也较为固定.
而系统性能异常则往往是由于系统资源相关的参数配置项设置不合理导致的,异常现象本身具有隐蔽性和滞后性(通常是在一定的场景下才发生,例如系统的并发压力达到一定程度).
进一步的,导致系统性能异常的资源相关配置参数之间存在着相互的关联和制约,往往一个配置项的变化也会影响其他配置项的最佳设置值.
因此,对于系统性能异常相关的配置错误诊断与修复具有更大的难度.
也有相关工作[55]对当前SMT的实用性进行讨论.
通过对高可配置(highlyconfigurable)的一个商业化系统和两个开源系统进行定量分析,该工作认为,SMT的挑战存在于:1)复杂系统可以基于多种开发语言,因此,基于程序分析的SMT必须能够跨程序语言进行分析;2)系统存在很多修改配置的语句和方法需要从多个源头和位置进行配置追踪(tracing);3)仅仅基于系统出错时的持久化数据进行配置状态分析是不够的,需要结合运行时的内存数据与其他启发式规则来提高分析的准确性.
5研究展望通过当前软件配置错误检测、诊断与修复相关的研究热点和主要工作分析,本文认为,该领域的研究趋势和研究内容包括以下几个方面:陈伟等:软件配置错误诊断与修复技术研究1301(1)考虑参数关联和组件依赖的配置错误主动检测构成复杂网络应用的组件存在频繁交互和相互依赖,导致配置参数间产生隐式的复杂关联,给应用的配置及其错误诊断带来困难.
基于异构组件的复杂网络应用运行在多种/多层中间件平台上,分层架构使组件之间、容器之间以及组件与容器之间存在关联和依赖,也使应用及环境的配置参数之间存在隐式的复杂关联和约束,例如配置参数取值的一致性、依赖性、取值范围的相互制约等.
主动检测以配置中存在的不变性规则和约束为基础,配置约束具有隐式的特点,隐藏于配置参数的使用方式及其语义中.
因此,实现配置主动检测的难点和关键点在于发现应用配置参数关联及其蕴含的约束,并通过形式化的方法进行显示描述,实施自动化的配置约束验证.
(2)系统性能异常及可靠性、可用性等问题相关的配置错误诊断与修复在配置参数错误导致的系统性能异常诊断方面,配置参数与性能异常现象间的关联更为复杂,同时,很多情况下系统的运行时故障不是由单个配置参数引起的,而是由几个参数的相互作用导致[67],某一配置参数的取值变化可能导致其他参数的最佳取值范围也随之发生改变,很难通过程序分析进行诊断.
而基于历史数据的统计分析方法能够发现异常现象与配置参数之间以及两两配置参数之间潜在的关联性,是诊断性能异常的有效方法.
除配置错误引起的功能和性能异常外,还能导致系统可靠性及可用性等问题.
相比于功能和性能异常,此类问题对系统的影响等级较轻,且具有一定的主观性,因此,发现、诊断和修复配置错误引起的此类问题也具有更大的难度.
(3)配置错误修复技术研究很多情况下,一个系统错误的修复恰恰是新错误产生的直接原因[5],因此,配置错误修复必须确保不引入新的系统错误,其中的关键问题在于如何推断出错误配置项的正确取值或取值范围,以及如何确认当前修复方法的有效性,避免引入新的错误.
当前,已有工作采用程序分析[38]和约束求解[45]的方法在这一方面做出了探索和尝试,在基于程序分析的配置取值自动推断技术上,除了根据配置项的取值和使用信息来推断可能取值外,还应该分析该配置项与程序其他变量和执行路径的关联,并充分分析在该取值范围内程序的行为是否会发生改变,从而避免新错误的发生.
(4)应用配置错误辅助诊断能力提升的相关研究应用的错误提示信息缺少可能的错误原因、系统状态和错误范围等描述,使配置错误难以诊断,因此,提高系统的错误应对能力和辅助诊断能力十分关键.
当前,已有相关工作通过完善日志信息和异常信息提示的方法来提高系统对于错误信息的描述能力,从而辅助诊断[47].
在这一研究问题上,可以采取回溯(backtracking)的方法,从异常信息抛出位置逆向分析与之关联度高的配置参数集合以及相关的系统状态,并作为系统提示信息的输出内容加以完善.
(5)软件配置方法研究当前研究成果主要集中在如何被动的进行配置错误的检测、诊断和修复方面,忽视了如何从软件工程领域的视角出发,研究如何主动减少或避免配置错误的发生.
今后的研究工作可以从方法论以及建立规范机制的角度出发,研究软件本身的配置方法,如:针对不同的软件类型归纳总结出相应的软件配置方法模式以及从配置的功能和语义角度出发,对配置命名及取值类型等建立相应的规范机制.
6总结软件应用的多样性、复杂性、灵活性和高度可定制性对系统的正确配置提出了挑战,配置错误已经成为影响应用服务质量的关键问题之一.
很多学者和研究机构致力于配置错误的检测、诊断和故障修复相关的技术和方法的研究,以提高复杂应用系统的可用性和可靠性.
本文对软件配置错误诊断修复问题进行深入探讨.
文章分析了导致系统配置错误的多个因素;然后,从方法类型、方法特征和适用范围这3个方面和多个角度建立了一个SMT分析框架;接着,对研究现状进行概述,并基于该分析框架对代表性工作进行分类总结和分析评价;最后,本文总结了当前相关研究存在的不足,并对今后的研究趋势进行展望,对于今后该领域的继续和深入研究具有1302JournalofSoftware软件学报Vol.
26,No.
6,June2015指导意义.
References:[1]RabkinA,KatzR.
Staticextractionofprogramconfigurationoptions.
In:Proc.
ofthe33rdInt'lConf.
onSoftwareEngineering(ICSE).
2011.
[doi:10.
1145/1985793.
1985812][2]OppenheimerD,GanapathiA,PattersonDA.
WhydoInternetservicesfail,andwhatcanbedoneaboutitIn:Proc.
ofthe4thUSENIXSymp.
onInternetTechnologiesandSystems(USITS).
2003.
[3]GrayJ.
WhydocomputerstopandwhatcanbedoneaboutitTechnicalReport,85.
7,TandemCorp.
,1985.
[4]HaleB.
WhyeveryITpractitionershouldcareaboutnetworkchangeandconfigurationmanagement.
2012.
http://web.
swcdn.
net/creative/pdf/Wh-itepapers/Why_Every_IT_Practitioner_Should_Care_About_NCCM.
pdf[5]SverdlikY.
Microsoft:Misconfigurednetworkdeviceledtoazureoutage.
2012.
http://www.
datacenterdynamics.
com/focus/archive/2012/07/microsoft-misconfigured-network-device-led-azure-outage[6]AmazonWebServicesTeam.
SummaryoftheAmazonEC2andAmazonRDSservicedisruptionintheUSeastregion.
2011.
http://aws.
amazon.
com/message/65648[7]JohnsonR.
Moredetailsontoday'soutage.
http://www.
facebook.
com/notes/facebook-engineering/more-details-on-todays-outage/431441338919[8]CircleID.
Misconfigurationbringsdownentire.
SEdomaininSweden.
www.
circleid.
com/posts/misconfiguration_brings_down_entire_se_domain_in_sweden/[9]RabkinA,KatzR.
Precomputingpossibleconfigurationerrordiagnoses.
In:Proc.
ofthe26thIEEE/ACMInt'lConf.
onAutomatedSoftwareEngineering(ASE).
2011.
[doi:10.
1109/ASE.
2011.
6100053][10]AttariyanM,FlinnJ.
Automatingconfigurationtroubleshootingwithdynamicinformationflowanalysis.
In:Proc.
ofthe9thUSENIXConf.
onOperatingSystemsDesignandImplementation(OSDI).
2010.
[11]Hadoop.
http://hadoop.
apache.
org/[12]RowstronA,DruschelP.
Pastry:Scalable,decentralizedobjectlocation,androutingforlarge-scalepeer-to-peersystems.
In:Proc.
oftheIFIP/ACMInt'lConf.
onDistributedSystemsPlatforms(Middleware),2001.
[13]HBase.
http://hbase.
apache.
org/[14]YinZ,MaX,ZhengJ,ZhouY,BairavasundaramL,PasupathS.
Anempiricalstudyonconfigurationerrorsincommercialandopensourcesystems.
In:Proc.
ofthe23rdACMSymp.
onOperatingSystemsPrinciples(SOSP).
2011.
[doi:10.
1145/2043556.
2043572][15]EddyN.
HumanerrorcausedGoogleglitch.
2009.
http://www.
eweek.
com/c/a/Enterprise-Applications/Human-Error-Caused-Google-Glitch/[16]LevesqueM.
Fundamentalissueswithopensourcesoftwaredevelopment.
2005.
http://dlc.
dlib.
indiana.
edu/dlc/bitstream/handle/10535/3215/Fundamental_issues_with_open_source_software_development.
pdfsequence=1&isAllowed=y[17]SchreckD,DallmeierV,ZimmermannT.
Howdocumentationevolvesovertime.
In:Proc.
ofthe9thInt'lWorkshoponPrinciplesofSoftwareEvolution(IWPSE).
2007.
[doi:10.
1145/1294948.
1294952][18]NagarajaK,OliveiraF,BianchiniR,MartinRP,NguyenTD.
UnderstandinganddealingwithoperatormistakesinInternetservices.
In:Proc.
ofthe6thSymp.
onOperatingSystemsDesign&Implementation(OSDI).
2004.
[19]OliveiraF,NagarajaK,BachwaniR,BianchiniR,MartinRP,NguyenTD.
Understandingandvalidatingdatabasesystemadministration.
In:Proc.
oftheUSENIXAnnualTechnicalConf.
(ATC).
2006.
[20]BehmH,FeldmannA,MaennelO,ReiserC,VolkR.
Networkwideinter-domainroutingpolicies:Designandrealization.
In:Proc.
ofthe34thConf.
onNorthAmericanNetworkOperators'GroupMeeting.
2005.
[21]ChenX,MaoY,MaoZM,vanderMerweJ.
Declarativeconfigurationmanagementforcomplexanddynamicnetworks.
In:Proc.
ofthe6thInt'lConf.
onEmergingNetworkingExperimentsandTechnologies(CoNext).
2010.
6172.
[doi:10.
1145/1921168.
1921176][22]HuanL,DanO.
Remotenetworklabs:Anon-demandnetworkcloudforconfigurationtesting.
SIGCOMMComputerCommunicationReview,2010,40(1):8391.
[doi:10.
1145/1672308.
1672324]陈伟等:软件配置错误诊断与修复技术研究1303[23]Al-ShaerES,HamedHH.
Discoveryofpolicyanomaliesindistributedfirewalls.
In:Proc.
ofthe23rdAnnualJointConf.
oftheIEEEComputerandCommunicationsSocieties(INFOCOM).
2004.
26052616.
[doi:10.
1109/INFCOM.
2004.
1354680][24]EnckW,MoyerT,McDanielP,SenS,SebosP,SpoerelS,GreenbergA,SungYW,RaoS,AielloW.
Configurationmanagementatmassivescale:Systemdesignandexperience.
IEEEJournalonSelectedAreasinCommunications,2009,27(3):323335.
[doi:10.
1109/JSAC.
2009.
090408][25]LiFL,YangJH,WuJP,AnCQ,JiangN.
ResearchonInternetautomaticconfiguration.
RuanJianXueBao/JournalofSoftware,2014,25(1):118134(inChinesewithEnglishabstract).
http://www.
jos.
org.
cn/1000-9825/4458.
htm[26]ChenHF,JiangGF,YoshihiraK,SaxenaA.
Invariantsbasedfailurediagnosisindistributedcomputingsystems.
In:Proc.
ofthe29thIEEESymp.
onReliableDistributedSystems.
India,2010.
160166.
[doi:10.
1109/SRDS.
2010.
26][27]ChenHF,JiangGF,UngureanuC,YoshihiraK.
Failuredetectionandlocalizationincomponentbasedsystemsbyonlinetracking.
In:Proc.
ofthe11thACMSIGKDDInt'lConf.
onKnowledgeDiscoveryinDataMining.
Chicago,2005.
750755.
[doi:10.
1145/1081870.
1081968][28]BodicP,FriedmanG,BiewaldL,LevineH,CandeaG,PatelK,TolleG,HuiJ,FoxA,JordanMI,PattersonD.
Combiningvisualizationandstatisticalanalysistoimproveoperatorconfidenceandefficiencyforfailuredetectionandlocalization.
In:Proc.
ofthe2ndInt'lConf.
onAutonomicComputing.
2005.
89100.
[doi:10.
1109/ICAC.
2005.
18][29]CherkasovaL,OzonatK,MiN,SymonsJ,SmirniE.
Automatedanomalydetectionandperformancemodelingofenterpriseapplications.
ACMTrans.
onComputerSystems,2009,27(3):132.
[doi:10.
1145/1629087.
1629089][30]ZhangL,XieB,MeiH,ShaoWZ,YangFQ.
Studyofcomponent-basedsoftwareconfigurationmanagementtechnologies.
ActaElectronicaSinica,2001,29(2):13(inChinesewithEnglishabstract).
[31]Sandbox.
http://en.
wikipedia.
org/wiki/Sandbox_(computer_security)[32]WhitakerA,CoxRS,GribbleSD.
Configurationdebuggingassearch:Findingtheneedleinthehaystack.
In:Proc.
ofthe6thUSENIXConf.
onOperatingSystemsDesignandImplementation(OSDI).
2004.
[33]WangYM,VerbowskiC,DunaganJ,ChenY,WangHJ,YuanC,ZhangZ.
STRIDER:Ablack-box,state-basedapproachtochangeandconfigurationmanagementandsupport.
In:Proc.
ofthe17thLargeInstallationSystemsAdministrationConf.
(LISA).
2003.
[doi:10.
1016/j.
scico.
2003.
12.
009][34]WangHJ,PlattJC,ChenY,ZhangR,WangYM.
AutomaticmisconfigurationtroubleshootingwithPeerPressure.
In:Proc.
ofthe6thUSENIXConf.
onOperatingSystemsDesignandImplementation(OSDI).
2004.
[35]DingXN,HuangH,RuanYP,ShaikhA,ZhangXD.
Automaticsoftwarefaultdiagnosisbyexploitingapplicationsignatures.
In:Proc.
ofthe22ndLargeInstallationSystemsAdministrationConf.
(LISA).
2008.
[36]YuanC,LaoN,WenJR,LiJ,ZhangZ,WangYM,MaWY.
Automatedknownproblemdiagnosiswitheventtraces.
In:Proc.
ofthe1stACMSIGOPS/EuroSysEuropeanConf.
onComputerSystems(EuroSys).
2006.
[doi:10.
1145/1217935.
1217972][37]AttariyanM,FlinnJ.
Usingcausalitytodiagnoseconfigurationbugs.
In:Proc.
ofthe2008USENIXAnnualTechnicalConf.
(ATC).
Boston,2008.
[38]XuTY,ZhangJQ,HuangP,ZhengJ,ShengTW,YuanD,ZhouYY,PasupathyS.
Donotblameusersformisconfigurations.
In:Proc.
ofthe24thACMSymp.
onOperatingSystemsPrinciples(SOSP).
2013.
[doi:10.
1145/2517349.
2522727][39]ZhangS,ErnstMD.
Automateddiagnosisofsoftwareconfigurationerrors.
In:Proc.
ofthe35thInt'lConf.
onSoftwareEngineering(ICSE).
2013.
[doi:10.
1109/ICSE.
2013.
6606577][40]RabkinA.
Usingprogramanalysistoreducemisconfigurationinopensourcesystemssoftware[Ph.
D.
Thesis].
Berkeley:UniversityofCalifornia,2012.
[41]ZhangS,ErnstMD.
WhichconfigurationoptionshouldIchangeIn:Proc.
ofthe36thInt'lConf.
onSoftwareEngineering(ICSE).
2014.
[doi:10.
1145/2568225.
2568251][42]TucekJ,LuS,HuangC,XanthosS,ZhouYY.
Triage:Diagnosingproductionrunfailuresattheuser'ssite.
In:Proc.
ofthe21stACMSymp.
onOperatingSystemsPrinciples(SOSP).
2007.
[doi:10.
1145/1294261.
1294275][43]AttariyanM,ChowM,FlinnJ.
X-Ray:Automatingroot-causediagnosisofperformanceanomaliesinproductionsoftware.
In:Proc.
ofthe10thUSENIXSymp.
onOperatingSystemsDesignandImplementation(OSDI).
Hollywood,2012.
1304JournalofSoftware软件学报Vol.
26,No.
6,June2015[44]SuYY,AttariyanM,FlinnJ.
AutoBash:Improvingconfigurationmanagementwithoperatingsystemcausalityanalysis.
In:Proc.
ofthe21stACMSymp.
onOperatingSystemsPrinciples(SOSP).
2007.
[doi:10.
1145/1294261.
1294284][45]XiongY,HubauxA,SheS,CzarneckiK.
Generatingrangefixesforsoftwareconfiguration.
In:Proc.
ofthe34thInt'lConf.
onSoftwareEngineering(ICSE).
2012.
[doi:10.
1109/ICSE.
2012.
6227206][46]ZhangS.
ConfDiagnoser:AnautomatedconfigurationerrordiagnosistoolforJavasoftware.
In:Proc.
ofthe35thInt'lConf.
onSoftwareEngineering(ICSE).
2013.
[doi:10.
1109/ICSE.
2013.
6606737][47]YuanD,ZhengJ,ParkS,ZhouYY,SavageS.
Improvingsoftwarediagnosabilityvialogenhancement.
In:Proc.
ofthe16thInt'lConf.
onArchitectureSupportforProgrammingLanguageandOperatingSystems(ASPLOS).
2011.
[doi:10.
1145/1950365.
1950369][48]ZhangJQ,RenganarayanaL,ZhangXL,GeNY,BalaV,XuTY,ZhouYY.
EnCore:Exploitingsystemenvironmentandcorrelationinformationformisconfigurationdetection.
In:Proc.
ofthe19thInt'lConf.
onArchitectureSupportforProgrammingLanguageandOperatingSystems(ASPLOS).
2014.
[doi:10.
1145/2541940.
2541983][49]YuanD,XieXL,PanigrahyR,YangJF,VerbowskiC,KumarA.
Context-Basedonlineconfiguration-errordetection.
In:Proc.
ofthe2011USENIXAnnualTechnicalConf.
(ATC).
Portland,2011.
313326.
[50]RabkinA,KatzR.
Usingstaticanalysistodiagnoseconfigurationerrors.
In:Proc.
ofthe11thInt'lSymp.
onSoftwareTestingandAnalysis(ISSTA).
2011.
[51]LaoN,WenJR,MaWY,WangYM.
Combininghighlevelsymptomdescriptionsandlowlevelstateinformationforconfigurationfaultdiagnosis.
In:Proc.
ofthe18thLargeInstallationSystemsAdministrationConf.
(LISA).
2004.
[52]DongZ,GhanavatiM,AndrzejakA.
Automateddiagnosisofsoftwaremisconfigurationsbasedonstaticanalysis.
In:Proc.
ofthe2013IEEEInt'lSymp.
onSoftwareReliabilityEngineeringWorkshops(ISSREW).
2013.
[doi:10.
1109/ISSREW.
2013.
6688897][53]KellerL,UpadhyayaP,CandeaG.
ConfErr:Atoolforassessingresiliencetohumanconfigurationerrors.
In:Proc.
oftheIEEEInt'lConf.
onDependableSystemsandNetworkswithFTCSandDCC(DSN).
2008.
[doi:10.
1109/DSN.
2008.
4630084][54]XiaX,LoD,QiuW,WangX.
Automatedconfigurationbugreportpredictionusingtextmining.
In:Proc.
oftheIEEE38thAnnualComputerSoftwareandApplicationsConf.
(COMPSAC).
2014.
[doi:10.
1109/COMPSAC.
2014.
17][55]JinD,QuX,CohenMB,RobinsonB.
Configurationseverywhere:implicationsfortestinganddebugginginpractice.
In:CompanionProc.
ofthe36thInt'lConf.
onSoftwareEngineering(ICSECompanion).
2014.
[doi:10.
1145/2591062.
2591191][56]ArshadFA,KrauseRJ,BagchiS.
CharacterizingconfigurationproblemsinJavaEEapplicationservers:AnempiricalstudywithGlassFishandJBoss.
In:Proc.
oftheIEEE24thInt'lSymp.
onSoftwareReliabilityEngineering(ISSRE).
2013.
[doi:10.
1109/ISSRE.
2013.
6698919][57]MengFJ,ZhuoXJ.
Agenericframeworkforapplicationconfigurationdiscoverywithpluggableknowledge.
In:Proc.
oftheIEEE6thInt'lConf.
onCloudComputing(CLOUD).
2013.
[doi:10.
1109/CLOUD.
2013.
16][58]MickensJ,Szummer,NarayananD.
Snitch:Interactivedecisiontreesfortroubleshootingmisconfigurations.
In:Proc.
ofthe2ndUSENIXWorkshoponTacklingComputerSystemsProblemswithMachineLearningTechniques(SYSML).
2007.
[59]AttariyanM.
Improvingsoftwareconfigurationtroubleshootingwithcausalityanalysis[Ph.
D.
Thesis].
UniversityofMichigan,2012.
[60]WangHJ,PlattJ,ChenY,ZhangR,WangYM.
PeerPressure:Astatisticalmethodforautomaticmisconfigurationtroubleshooting.
TechnicalReport,MSR-TR-2003-80,2003.
http://research.
microsoft.
com/en-us/um/people/helenw/papers/msr-tr-03-80.
pdf0sr=ar[61]SuYY,FlinnJ.
Automaticallygeneratingpredicatesandsolutionsforconfigurationtroubleshooting.
TechnicalReport,2007.
http://citeseerx.
ist.
psu.
edu.
sci-hub.
org/viewdoc/downloaddoi=10.
1.
1.
148.
7963&rep=rep1&type=pdf[62]NaikM.
JChord.
http://jchord.
googlecode.
com[63]Nevill-ManningCG,WittenIH.
Identifyinghierarchicalstructureinsequences:Alinear-timealgorithm.
JournalofArtificialIntelligenceResearch,1997.
6782.
[64]SridharanM,FinkSJ,BodikR.
Thinslicing.
In:Proc.
oftheACMSIGPLAN2007Conf.
onProgrammingLanguageDesignandImplementation(PLDI).
2007.
[65]ChangCC,LinCJ.
LIBSVM:Alibraryforsupportvectormachines.
ACMTrans.
onIntelligentSystemsandTechnology(TIST),2011,2(3):27.
[doi:10.
1145/1961189.
1961199]陈伟等:软件配置错误诊断与修复技术研究1305[66]ReiterR.
Atheoryofdiagnosisfromfirstprinciples.
ArtificialIntelligence,1987,32(1):5795.
[doi:10.
1016/0004-3702(87)90062-2][67]KuhnDR,ReillyMJ.
Aninvestigationoftheapplicabilityofdesignofexperimentstosoftwaretesting.
In:Proc.
oftheAnnualNASA/IEEESoftwareEngineeringWorkshop(SEW).
LosAlamitos:IEEEPress,2002.
9195.
[doi:10.
1109/SEW.
2002.
1199454]附中文参考文献:[25]李福亮,杨家海,吴建平,安常青,姜宁.
互联网自动配置研究.
软件学报,2014,25(1):118134.
http://www.
jos.
org.
cn/1000-9825/4458.
htm[30]张路,谢冰,梅宏,邵维忠,杨芙清.
基于构件的软件配置管理技术研究.
电子学报,2001,29(2):13.
陈伟(1980-),男,江西高安人,博士,高级工程师,CCF会员,主要研究领域为网络分布式计算,软件工程.
魏峻(1970-),男,博士,研究员,博士生导师,CCF高级会员,主要研究领域为网络分布式计算,软件工程.
黄翔(1982-),男,博士,主要研究领域为网络分布计算,大数据.
钟华(1971-),男,博士,研究员,博士生导师,CCF高级会员,主要研究领域为网络分布式计算,软件工程.
乔晓强(1977-),男,博士,副研究员,CCF会员,主要研究领域为网络分布计算,服务计算,软件工程.
- 配置windows错误恢复相关文档
- 笔记本windows错误恢复
- 扫描仪windows错误恢复
- 指示灯windows错误恢复
- 招标文件项目编号:MSCG2020049-2
- 考生windows错误恢复
- 备份windows错误恢复
Hostiger 16G大内存特价VPS：伊斯坦布尔机房，1核50G SSD硬盘200Mbps带宽不限流量$59/年
国外主机测评昨天接到Hostigger（现Hostiger）商家邮件推送，称其又推出了一款特价大内存VPS，机房位于土耳其的亚欧交界城市伊斯坦布尔，核50G SSD硬盘200Mbps带宽不限月流量只要$59/年。 最近一次分享的促销信息还是5月底，当时商家推出的是同机房同配置的大内存VPS，价格是$59.99/年，不过内存只有10G，虽然同样是大内存，但想必这次商家给出16G，价格却是$59/年，...
ZJI：香港物理服务器,2*E5-2630L/32G/480G SSD/30Mbps/2IP/香港BGP,月付520元
zji怎么样?zji是一家老牌国人主机商家，公司开办在香港，这个平台主要销售独立服务器业务，和hostkvm是同一样，两个平台销售的产品类别不一平，商家的技术非常不错，机器非常稳定。昨天收到商家的优惠推送，目前针对香港邦联四型推出了65折优惠BGP线路服务器，性价比非常不错，有需要香港独立服务器的朋友可以入手，非常适合做站。zji优惠码：月付/年付优惠码：zji 物理服务器/VDS/虚拟主机空间订...
Vultr VPS新增第18个数据中心 瑞典斯德哥尔摩欧洲VPS主机机房
前几天还在和做外贸业务的网友聊着有哪些欧洲机房的云服务器、VPS商家值得选择的。其中介绍他选择的还是我们熟悉的Vultr VPS服务商，拥有比较多达到17个数据中心，这不今天在登录VULTR商家的时候看到消息又新增一个新的机房。这算是第18个数据中心，也是欧洲VPS主机，地区是瑞典斯德哥尔摩。如果我们有需要欧洲机房的朋友现在就可以看到开通的机房中有可以选择瑞典机房。目前欧洲已经有五个机房可以选择，...
windows错误恢复为你推荐
-
印章制作传统印章怎么做邮箱群发如何在电子邮箱中实现群发邮件？微信如何建群微信建群怎么建办公协同软件协同企业办公的软件有哪些？滚动代码来回滚动代码怎么升级ios6苹果IOS5怎么升级IOS6版本mate8价格华为麦特八多少价格商标注册查询官网商标注册查询官方网站?iphone6上市时间苹果6什么时候在中国大陆上市什么是云平台什么是云系统？