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

日期: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云服务,让他们更为轻松地将云服务整合到移动应用软件中。

技术手册>更多

  • SOA之云开发技术手册

    十年前,面向服务架构突然出现在IT舞台上,而且许多公司已经在SOA应用上进行了大量的投资。现在云计算在IT舞台上更是独领风骚。SOA之于云,云之于SOA的意义又是怎样的。很明显,云计算的成功取决于它能够给现有的SOA实现增加价值的能力。而SOA的使用也促进了云开发。

  • SOA治理

    治理不同于管理。治理规划需要制定什么决策,而管理是制定和实施决策的过程。治理重在建立决策,而管理重在贯彻执行决策。

  • SOA安全

    安全对于许多的IT部门来说都是一个重要的问题之一,但是SOA安全问题完全是在另一个新的纬度上了。对于SOA为一个机构所带来的许多的好处,例如具有在许多不同的提供者和供应商的情况下混合和匹配服务。

  • ActiveMQ实践入门指南

    ActiveMQ是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。下面我们将分四部分来介绍ActiveMQ的相关内容。

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