故障注入注定要成为软件专业人士的必备技能

日期:2016-12-23作者:Fred Churchville

故障注入   云服务   

【TechTarget中国原创】

在给简历列技能的时候,软件测试者和工程师也许要考虑一件事,那就是越来越多的公司正在寻找一种新型的软件专家。他们要找的不仅仅是能够在出现问题时修补系统漏洞和崩溃服务的人,他们还在寻找愿意花时间去故意攻击这些服务和系统的人。

有意制造事端,导致服务和软件崩溃或者失灵,这个叫做故障注入。这是一种QA范式,微软的两位软件工程师认为,这个东西可以缓解现代软件部署和管理相关的风险,尤其是与云端应用和服务相关的风险,通过受控的方式帮助工程师观察和找到这些失效情况的补丁,而不是在意外情况下第一时间去处理它们。

云是如何把事情搞复杂的

尽管云改善了企业迅速发布高质量、高能力应用的能力,但专家警告说要小心这些应用汇变得太复杂,难以进行人工测试。

软件变得越来越复杂,据Netflix的工程经理Casey Rosenthal说,以至于整个流程无法在心中建模,日益给QA造成了负担。实际上,公司的软件系统也许是“黑箱”,甚至连负责开发它们的软件工程师都弄不清楚。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

技术手册>更多

  • 智能BPM与业务流程工具

    Gartner认为iBPM要比运营型智能平台更优秀,表现在以下几个方面:iBPM套件提供更好的工作流,适配性案例管理以及结构化流程协调能力。

  • 云BPM新常态解析

    云端业务流程管理已经不再是什么新鲜事,更不再是什么可怕的方法来管理重要的业务流程。现在,它已经普遍被认为是一种新常态。组织已经从这一技术中获益,使它来更有效地访问和管理企业信息。

  • 企业IT集成指南

    随着云技术的不断采用,现代企业都面临着重大的集成问题。现在已经不再是把企业内部的数据和应用简单地缝合在一起,企业IT现在面临着整合着外部与内部信息的难题。

  • API开发与管理大作战

    2014将会是API管理方法新旧PK的一年,据Delyn Simons说,她领导了Mashery开发者的外展团队。应用编程接口(API)的主流化和私有化在新的一年也将掀起波澜,她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。

【TechTarget中国原创】

在给简历列技能的时候,软件测试者和工程师也许要考虑一件事,那就是越来越多的公司正在寻找一种新型的软件专家。他们要找的不仅仅是能够在出现问题时修补系统漏洞和崩溃服务的人,他们还在寻找愿意花时间去故意攻击这些服务和系统的人。

有意制造事端,导致服务和软件崩溃或者失灵,这个叫做故障注入。这是一种QA范式,微软的两位软件工程师认为,这个东西可以缓解现代软件部署和管理相关的风险,尤其是与云端应用和服务相关的风险,通过受控的方式帮助工程师观察和找到这些失效情况的补丁,而不是在意外情况下第一时间去处理它们。

云是如何把事情搞复杂的

尽管云改善了企业迅速发布高质量、高能力应用的能力,但专家警告说要小心这些应用汇变得太复杂,难以进行人工测试。

软件变得越来越复杂,据Netflix的工程经理Casey Rosenthal说,以至于整个流程无法在心中建模,日益给QA造成了负担。实际上,公司的软件系统也许是“黑箱”,甚至连负责开发它们的软件工程师都弄不清楚。

“我认为这整个行业正在转移到这样一个领域,在那里系统变得越来越复杂,” Rosenthal说:“复杂到即便是对于开发某些系统的软件工程师来说,这些系统本身也变成了黑箱。比方说你无法对深度学习算法进行反思,没办法以任何有意义的方式进行。”

除了这种复杂性以外,还有就是软件部署的速度很快。据微软的软件工程师Michalis Zervos说,部署日益加快的节奏意味着组织需要找到测试以外的办法来验证这些服务在生产下如预期行事。

微软首席软件工程经理兼服务弹性团队领导Dmitri Klementiev对此表示同意,他说软件开发和交付给客户软件的速率使得进行及时进行软件的完整测试变得太过困难。实际上,他并不认为任何服务开发者在交付前有时间彻底测试完所有的软件。

Rosenthal指出,这个问题的一大部分在于,事实上当服务中断之后,往往是处在最不方便的时候——也即是说,在半夜。

“没人想在凌晨3点接到电话说系统罢工了,因为其中一个服务器突然消失或者停止响应了,”他说。

Zervos指出,这不仅给开发者造成不便,而且一个疲惫的头脑还会导致糟糕决策——从而使得后果甚至更加糟糕。

注入故障

整个行业都需要一种新的办法来处理日益增加的复杂性,Klementiev说。处理的办法之一是采用Zervos和Klementiev所谓的“故障注入”。

据Zervos说,故障注入是这样一种办法,通过它软件工程师、开发者或者测试人员可以模拟经常在跟云服务这样的东西配合时发生的错误的效果,比如迫使资源压力的增加或者网络中断的发生。故障注入必定并没有规定的办法——只是把系统推到极限,有时候到破坏点的程度,只是为了看看会发生什么,从而确定作为团队要作何响应。

新颖创意还是被废弃的概念?

Michalis Zervos和 Dmitri Klementiev都是微软的软件工程师,据两位的说法,故障注入背后的想法并不新鲜。几乎在10年前微软自己就已经进行过被认为是故障注入变种的做法。

“比方说,当微软和其他公司有传统封装软件的时候,在代码中进行故障注入……会迫使代码抛出错误,迫使代码返回错误值,这时候再来看看应用的其他部分会如何表现,” Zervos说。

Klementiev同意,故障注入已经存在了很长一段时间,但云端软件交付的性质已经改变了这种思想形态。在过去,软件交付的周期一般都是1、2年,所以在测试产品和处理bug时,时间是站在他们这边的。

“我们可以用来测试的时间很多,是云环境下不能比的……我们可以推迟交付知道我们修补好所有发现并认可的bug,” Klementiev说:“而现在交付云软件时,我们可能每天都要交付。”

Zervos和Klementiev同意,鉴于这些交付周期已经加快,故障注入可以帮助填补仅仅执行单元测试等传统技术无法满足要求所造成的鸿沟。然而,Zervos指出,这些测试并不总能为服务依赖性而不仅仅是代码以及对整个系统的影响提供洞察。

Zervos说:“比方说如果我们希望测试,如果我的CPU压力上升的时候大家都在点我的服务,使得CPU使用率达到了90%的话,我的这个登录服务,一项鉴权服务会发生什么呢?……尝试任何那些传统办法几乎都是不可能的。”

Zervos补充说,故障注入可以跟所谓的“压力测试”这种测试方法相比较——制造更多流量或者从外部给服务制造更多的压力。但即便这类测试也不能提供故障注入可提供的那类信息,包括看看在特定情况下依赖性是如何体现的。

错误注入最有用的方面之一是,你可以看到一个bug或者一次崩溃的结果,你还可以在它们真正发生之前确定好的行动步骤,Klementiev说。这些崩溃必定是要发生的,而这个可以让工程师更快发现问题,然后在受控的方式下处置它们。

Zervos指出,这可能也会涉及到软件相关的错误,比如像OutOfMemoryException这样非预期的例外或者错误代码的出现。错误注入使得开发者和工程师看到其余代码,以及任何的依赖服务因为该事件会如何表现。

“比方说,你试图跟SQL服务器对话时,一些数据包丢失了,或者连接很慢,”Zervos说:“错误注入很容易就能测试这些。”

反对错误注入的理由  

然而,Zervos和Klementiev说,采用这种办法并不是免费搭车,执行故障注入的时候尤其如此。许多开发者根本就不能或者不想花时间去学习一种新的测试方式。这个问题使得理解如何对故障注入进行自动化,以及如何让组织的相关人执行这一流程尽可能的方便变得非常关键。

Zervos说,另一个问题是他发现许多工程师质疑鼓励以真实客户流量往生产环境注入故障的做法,这是可以理解的。为了应对这个,最好是先在测试环境下慢慢树立起对你执行故障注入能力的信心。然后,当信心足够大时,开始在生产环境下执行故障注入。

然而,Klementiev说,即便测试者、开发者或者工程师对自己在生产环境下进行故障注入的能力信心够足了,他们也仍然需要得到公司领导层的完全支持才行,因为基本上这种做法是搞破坏。这是很大的文化变革,但领导买账仍然非常关键。

“如果他们不在现在承担一点点风险的话,到后面可能公司要付出的代价就要高得多,” Klementiev说。

Zervos和Klementiev指出,对于预算、客户群以及开发或测试团队有限的小公司来说,这个也许不是简单的事情。然而,Klementiev提出,即便他们不能正式进行故障注入,也有临时方案可以做。

“我认为任何人都可以做的最简单的故障注入是过去把电源给拔了,” Klementiev说:“只需要跑到数据中心然后把它给关了。或者关掉一机架的机器。我知道有很多公司就是这么做的。”

开发者和测试者在一条船上吗?

Klementiev和Zervos同意,这种类型的测试仍然有待得到行业认可。然而,据Zervos说,这种做法的方向是积极的,并且他相信软件工程的本质绝对可以让这种做法得到认可。

“我认为它们意识到往弹性和故障注入投入的好处,近期许多公司都会需要故障注入测试,”他说:“过去2年,你会看到越来越多的企业把资源和努力投入到这一领域。对我来说,这是一个信号,标志着故障注入测试在云服务世界正在变得越来越大。”

Klementiev指出,这还不仅仅只是学习技巧的事情。相反,在云端的软件开发方面,它要求接受新的哲学。正如他所述,业界需要一个新的学科,一个能成为云服务文化一部分的学科。