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

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

故障注入   云服务   

【TechTarget中国原创】

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

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

云是如何把事情搞复杂的

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

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

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

SOA开发>更多

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

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

  • 容器与微服务要“联姻” 你对它们够了解吗?

    在虚拟化和云计算领域,容器大概是发展最快、最广为令人兴奋的技术了,微服务则紧随其后。如果把这两大技术结合起来会碰撞出怎样的火花呢?

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • HTML5促进企业移动化服务走向极致

    在企业困扰于传统移动化方式过于复杂时, HTML5凭借其天然的跨平台特性,乘势而起并逐渐得到企业的关注。可是,由于HMTL5标准建立时间不长,展示性能及稳定性更是需要和浏览器有一个良好的兼容,除此之外企业更是缺乏实际应用经验,所以基于HTML5技术的企业级服务市场还处于一片初创状态。

相关推荐

  • 外包SaaS和云服务的五个关键因素

    在采用任何服务之前,IT部门都需要仔细考量很多注意事项。云和SaaS产品没什么特别的。但是在企业评估云和SaaS时,最需要特别注意的考量因素是什么呢?

  • 云服务如何驱动BPM厂商?

    尽管有预测称BPM即将消失,但是它却一直处于增长势头。推动BPM供应商发展的主要动力之一就是云服务。

  • 云服务扩展移动性能测试工具

    无法衡量的东西也是无法管理的。听起来足够简单,但移动应用性能测试市场的现实却远没有那么直截了当。

  • iCloud开发框架:未来将让所有人受益

    在今年WWDC大会上,苹果发布了新的“限时免费”开发框架CloudKit,它能够让应用软件开发商接入苹果iCloud云服务,让他们更为轻松地将云服务整合到移动应用软件中。

技术手册>更多

  • 2012年SOA最佳技巧集 TOP 10

    转眼之间,我们已经走过了战战兢兢的2012年,传说中世界末日并未如期而至,我们还是迎来的2013年的曙光。在迎接崭新的一年之始,2012年的一些大事迹应该还在你的脑中存留。同样的,TechTarget SOA在陪伴读者走过的2012中,有哪些是技巧、工具的类的文章给您带去的帮助呢。本文带你走进SOA 2012年的TOP 10最佳技巧集。

  • SOA基础

    面向服务结构的主要目的,就是要将业务与信息技术有效的结合,并使二者更加的有效。SOA将为创建二者共存互惠的局面搭建桥梁,这二者也是以往最为强大和有价值的,而且,SOA也是业务和IT更好的结合之后的业务需求。

  • 解围应用集成困境指南

    集成是个很老的话题,很多时候在谈及新技术的时候,我们会避而不谈,但集成问题却一直贯穿在企业之中。应用集成就是建立一个统一的综合应用,也即将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中,并使它们就像一个整体一样,进行业务处理和信息共享。要实现这样的效果并不简单,在这本手册中,我们会为您拨开一些迷雾,更好的解决应用集成所面临的问题。

  • 银行SOA应用案例简报

    本世纪初,全球金融崩溃后,曾听到花旗银行企业架构部高级VP讲假如他或者其他金融巨头的IT系统架构师能够最终在企业内推行SOA的话,这场金融危机将不会发生。因为SOA的应用能够很容易地对即将发生的金融风险进行预警。但可惜的是,企业的各个部门并不愿意在应用SOA方面花费太多的精力。时过境迁,现在面对全球经济的快速发展,很多银行已经开始了SOA之行并从中开始获益,下面我们就来看看这些内容。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【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指出,这还不仅仅只是学习技巧的事情。相反,在云端的软件开发方面,它要求接受新的哲学。正如他所述,业界需要一个新的学科,一个能成为云服务文化一部分的学科。