ACM通信

实践

在质量保证中采用Devops实践

由詹姆斯•罗氏
ACM通信，2013年11月，第56卷第11期，38-43页
10.1145/2524713.2524721
评论

在很长一段时间里，软件生命周期管理都是受控的。产品设计、开发和支持的持续时间是可以预测的，公司和他们的员工将财务、假期、手术和合并安排在产品发布的前后。当开发人员很忙时，质量保证(QA)就很容易了。当发行周期的编码部分接近尾声时，QA便接管了工作，同时支持也在增加。然后，当产品发布时，开发人员呼气、休息，并再次开始循环，而支持人员则过渡到忙于支持新产品。

从开发团队的角度来看，产品发布代表了一个可重复和公式化的闭环过程。除了可能需要开发人员专家关注的bug之外，一旦产品向客户提供，大多数员工就会被重新安排，专注于下一个版本。

在这个世界中，QA团队的职责主要是模仿客户的使用模式，尽量减少不愉快的意外发现。在瀑布模型中，QA团队的荣誉徽章是其预测、发现和交付可能导致用户问题的可重复场景的能力。

构建随机硬件配置，模拟令人困惑的网络环境，在底层平台架构中连接看似正交的因素，这些都是优秀QA工程师知识的方方面面。最优秀的工程师可以观察产品的设计，并预测可能出现的问题。对于独立的桌面软件，发布bug是非常昂贵的，因为修复涉及到服务发布，所以QA被给予了更多的时间和人员来验证一切都按照预期工作。

我还记得这个可预测变量和有限计划的时代结束的时候。事实上，我记得非常清楚。我当时在一家公司工作，该公司试图推出一个推翻ebay的个人对个人市场产品原型。我们花了几个月的时间从用户界面开始测试服务。发布的那天晚上，大楼里最大的会议室坐满了人，香槟装在纸板咖啡杯里，整个扩展团队都在期待着发布，最终喊着倒计时，“5,4,3,2,1 !”到处都是拥抱和敬酒，因为CEO使用新网站购买产品目录中我们开玩笑的愚蠢商品。然后有人拍了拍我的肩膀。电话是工程主管打来的，他的话很简单:“我们认为你应该和我们一起下楼。”

楼上，每个人都满怀期待地微笑着迎接我们产品的首次亮相。但是，在楼下一间小得多的房间里，门边的桌子都贴在墙上，没有一个人在笑。网站“运行”了，但考虑到它的流量太小，它运行得太热了。

当时是晚上7点左右我的工作主要是通过一个匆忙准备的shell脚本来生成流量，以维持服务上的负载。与此同时，6名工程师在一个屏幕上盯着滚动的日志和上下跳动的图表。在我们调整了负载均衡器之后，麻烦的曲线图开始向下指向，表明我们所面临的问题得到了缓解。整个房间的人都松了一口气。

那天晚上，楼上的派对在我离开办公室前几个小时就结束了。晚上11点半，我和我的狗狗清醒而疲惫地走回家，满足但焦虑地想知道第二天产品发布后的命运。

我们上了报纸的头版纽约时报第二天早上，我们得到了巨大的认可，但我当时的主要记忆是对软件产品来世的新发现的欣赏。

现在有哪些产品只存在于台式机上?从最后一次bug修复到向客户公开有多少产品周期是24小时?更重要的是，这将如何改变参与发布、维护和支持应用程序的人员和过程?

回到顶部

在墙上

我最近在网上看到了一个叫做“灾难女孩”的有趣表情包，无可否认，我可能是地球上最后一个遇到她的人。在照片的背景中，一所房子在冒烟，而邻居和消防员站在安全距离之外。在前景中，有一个带着谄媚微笑的年轻女孩，她大声地读着:“在开发中工作得很好。现在出现了操作问题。”⁵

我怀疑这不是一个新创造的笑话的部分原因是，对于大多数软件开发者来说，世界真的不再以那样的方式运行了。瀑布式开发曾经规定了从开发人员到QA再到运营的过程，现在的职责边界模糊，大多数工程师的技能集跨越多个学科。

捐助者之间的冲突现在最好平息下来。坏脾气的QA工程师在scrum团队中几乎没有立足之地。产品从原型发展而来。设计阶段已经被从开发到演示的更少周期、更民主的演变所取代。

在日常的对峙中，没有争论的对峙的论坛。运营工程师的神秘感也消失了。好莱坞曾经给人的印象是，在一屋子闪烁的屏幕上，用难以辨认的日志来推测产品的状态，而DevOps的文化已经消除了这些角色的许多魔力和咖啡因依赖。

一个令人耳目一新的结果是，该行业的专业知识和专业水平急剧上升。与此同时，强大的工程技术使团队能够自动化许多跟踪工作，而这些工作曾经需要24/7的人力系统监控人员，这提高了全球工程师的工作/生活平衡。对于每一个组，包括开发人员、质量保证和操作人员，他们的角色都发生了显著的变化，以突出现代软件架构模板的各个方面。

回到顶部

那么，到底是什么改变了呢?

回想20世纪90年代中期，大多数安装在机器上的东西都是通过软盘或CD-ROM媒体安装的。大部分软件很少与它自己的主机存储之外的任何资源交互，而与外部资源交互的软件是通过有限的企业产品阵列实现的。

开发到支持的指挥链如前所述。开发人员根据规范工作，“最低要求”文档是一组严格的约束。测试工作主要包括填充由每日安装驱动的硬件/特性配对矩阵，以及手动和自动测试的混合。自动化主要是为基准测试和耐受力收集性能指标。操作主要由客户支持技术人员负责，他们每天都与产品安装人员保持联系。可以这么说，不需要专门的操作工作，因为景观主要局限于每个用户的本地环境。

从这个时代到现在，瘦客户机与厚客户机之间的多次切换为应用程序产生了广泛的客户机容量。从厚的方面来说，游戏和数据管理软件需要非常强大的客户端，对现代环境中无数的网络选项提供强大的支持。瘦客户端充斥着基于浏览器的应用程序。连接厚/薄离群值的是大量的应用程序，其中本地处理环境通过网络与数据和异步处理配对。

这些新产品比早期“厚/瘦”权衡中讨论的任何东西都要精简得多，现在的数量也远远超过其他任何平台上的产品。随着移动平台处理能力的增长，厚/薄平衡有了自己的新光谱。移动设备是一个有趣的类别，因为应用程序受到屏幕尺寸和处理能力的限制，用户的期望比在桌面环境中运行的类似应用程序低得多。

当这种从孤立客户机的迁移成为常态时，软件开发团队中的角色就会同步迁移。不幸的是，对于许多人来说，这并不是一个明显的需求。软件墓地里充斥着管理人员对新网络环境反应不够迅速的产品。而那些真正适应了这种模式的公司则被迫将角色从传统的开发/QA/支持框架中移出，并组建更具协作性的团队，以构建具有无限功能寿命的容错系统。

瀑布现在变成了河流;开发和运营一起流动。当产品发布时，很少有升级或弃用功能的计划，支持是持续进行的。总体而言，该行业在适应这种新形势的期望方面做得很好。

最值得注意的是，工程工作现在为多个主人服务。过去关注的焦点是精确度，现在长寿和可伸缩性在产品需求讨论中占据同等地位。您的应用程序可能仍然会移动山脉，但现在它需要永远为地球上的每个人移动山脉。

传统上，QA负责风险定义和可维护性，而开发和运维人员(简称为DevOps)现在有了平等的角色，如果不是主导角色的话。现在，对功能的讨价还价涉及到超越个人电脑芯片组和媒体容量限制的可行性和可持续性。DevOps拥有组织内部和外部平台资源中系统容量和可扩展性的配置文件。

回到顶部

DevOps和开发，概念和误解

DevOps没有标准定义。关于这个话题的博客文章很多，但最好的结论是，这个术语的真正含义仍在变化。争论的一方确定了DevOps的具体工作描述，在一篇博客文章中有很好的总结:开发人员主要从事代码工作，运维人员主要从事系统工作，而DevOps是这两种技能的混合。⁶另一种观点并不是特别反对这个观点，而是认为DevOps并不是一项真正的工作(因为从本质上来说，你不会雇佣一个“DevOp”)，而是说DevOps的精神反映了现代软件开发和支持领域的一种新兴需求。^3.

一段时间以来，这个问题在社区中一直存在分歧。那些自豪地自称为“DevOps”的工程师显然与那些认为不存在“DevOps”的人并不一致，但成千上万的招聘信息专门寻找“DevOps工程师”，这证明了许多知名公司的人认为这个术语描述了一个特定的角色。其他业内人士认为这个术语描述了开发、测试、发布、支持和度量收集的新标准。在这篇文章中，我不偏袒任何一方，而是使用DevOps描述新标准，而不是具体的职位。

根据我的经验，我观察到DevOps的概念来自许多相同的行业力量，这些力量使QA工程师的工作描述更接近开发人员。一个人对应用程序的代码和平台了解得越多，他在构建和修复应用程序方面就会做得越好。DevOps，无论是在由运维工程师负责开发任务的情况下，还是在开发人员从事运维领域工作的情况下，都是在努力拉近这两个学科之间的距离。

这种软件开发和支持的合并是由于需要更好的工具集来检测和度量网络系统中的问题而产生的。数百家(如果不是数千家的话)不同的公司为共同的任务创建了自己的解决方案，然后这些解决方案的构建、扩展和维护变得乏味乏味。不久以前，出现了许多产品，它们为开发组织提供了解决常见需求的方法，如问题诊断、部署管理、任务自动化和过程标准化。这样，发展组织，无论大小，都可以巩固专门用于建立这种机制的资源。

这种新的基础设施的最大好处是能够量化开发和支持工作的各个方面。在没有不确定性的情况下，开发过程可以用图形来描述，这些图形可以将数据完美地传达给真正的开发人员，以及非技术项目和产品所有者。这对团队来说是一个巨大的价值，从前面提到的社区内的争论中可以清楚地看出:软件开发肯定存在一个前devops和后devops时代。

在整个艺术形式中，DevOps的影响使效率和过程变得更加清晰。不过，在一些特定的领域，DevOps浪潮已经完全和永久地改善了产品开发和所有权，这尤其要感谢对度量和过程标准化的更清晰关注。

回到顶部

流程标准化

行业正再次整合其平台选项，系统管理正变得越来越标准化，因为行业局外人为Chef、Splunk和Jenkins等流行产品构建垫片。少数经过时间考验的产品体现了DevOps工具包的锤子和螺丝刀，它们是如此普遍，以至于管理员级别的经验是许多工作描述的一部分。虽然在基础设施使用这些产品作为系统基石的小公司中，这似乎并不新鲜或奇怪，但拥有多个团队分别开发和部署的大公司发现，这种标准化是强制自行开发解决方案、允许不受约束的独立性或介于两者之间的任何事情的一种有价值的替代方案。

对于许多公司来说，这个标准化净化了发布和支持过程。许多组织的流程都是围绕固定的对象发展的。桌面软件实际上只能在CD/DVD制造商和出版商周围发布，但现在他们有了在线应用程序市场标准来制定指导方针。同样，对正常运行时间要求很高的在线产品与数据中心服务提供商签订了昂贵的维护合同。现在，有了把这项工作内部化的能力，我们就能更好地理解这个过程，而对那些负责发布新产品的人来说，就不会那么麻烦了。

---

在一些特定的领域，DevOps浪潮已经完全和永久地改善了产品开发和所有权，这尤其要感谢对度量和过程标准化的更尖锐的关注。

---

对任何软件组织的开发、部署和支持过程的真正验证是持续部署的概念，这实际上是在不通知客户甚至不关心软件升级的情况下协调所有三个任务。持续部署需要开发组织实现足够的质量，这样在源代码控制提交和发布之间的短路径上就不会遗漏任何一块石头。这意味着部署必须是无法被用户发现的，其中一些用户将在会话过程中更改软件版本。这也意味着，在这种秘密的发布过程中，对遇到的任何问题的响应都是积极主动的和即时的。

DevOps的定义出现在Dmitriy Samovskiy 2010年的一篇博文中⁸将工作描述的一个方面命名为“生产中的QA”。毫无疑问，这引起了许多业内人士的愤怒，但考虑到这如何有助于为软件行业中的每个人定义一个新标准，这使它成为一个有价值的要点，否则就会引起争议。再次强调，DevOps文化最宝贵的贡献体现在软件支持角色上，在整个产品生命周期中嵌入相关文化将有价值的改进推回到应用程序的设计阶段。

回到顶部

将软件开发度量转移到DevOps世界

现代软件领域中最有利于创建者的方面是设计时瘦客户机解决方案和厚客户机解决方案的可用性。一旦考虑到数据传输的成本，大多数客户端(现在包括大多数移动设备)上的处理能力与服务器端处理能力相当。DevOps使实现这一承诺成为可能。当客户端上的一个功能的复杂性使它接近被排斥时，承认这种权衡是必要的。此外，准确地描述互让关系是交付成功的产品与交付成为行业其余部分笑料的产品之间的区别。

这引出了DevOps的一个有趣的方面，我们现在终于超越了QA工程师的见解总是与有问题的数据相结合的问题。此时DevOps拥有服务器端数据，因为负载、容量和可伸缩性已经成为容易推导的数字。

当主要处理客户端代码时，客户端排列的可变性和缺乏准确的行为度量使QA输入远远不够客观和可验证。例如，许多QA讨论的开头都是，“我们有客户抱怨这个功能在他们的手机上运行得很慢。”简单的后续问题包括，“这些手机上还运行什么?”，“它们运行的是Wi-Fi、3G还是4G?”，“这是某个手机的问题吗?”，然后继续往下问。一个消息灵通的DevOps工程师会说，“我们的产品现在使用了我们10,000个活跃订阅者的40%的容量，所以如果我们不能在现在到下一个版本之间将实例的数量翻倍，我们就不能接受更多的特性或更多的客户。”没有人会去猜测这样一个数据驱动的DevOps裁决，而QA工程师传统上无法支持他们的论点，除非做更多的研究。在某种程度上，DevOps在定义和解决客户端/服务应用程序领域的问题方面更容易一些。与此同时，QA在描述应用程序生态系统中的问题时提供同样级别的有效性是一项艰巨的责任。

已经强调通过客户端应用程序指标交付大量实际体验。许多应用程序建议用户在安装时允许崩溃报告。基于浏览器的应用程序能够跟踪用户与应用程序的每次交互的几乎每个方面，移动设备也提供类似的线索。客户端越薄，应用程序崩溃时丢失的数据就越多。如果没有明确的许可，大多数浏览器和所有移动操作系统都会阻止对评估应用程序崩溃原因所必需的数据的访问。

---

当主要处理客户端代码时，客户端排列的可变性和缺乏准确的行为度量使QA输入远远不够客观和可验证。

---

具有讽刺意味的是，QA的客户端数据来源是以应用程序的吞吐量为代价的。从运行应用程序的客户端收集数据的方法当然有很多，但减少数据量和交付频率会对客户端的性能和服务的可用性产生负面影响。同样，基于浏览器的应用和运行在移动平台上的应用受到的影响最为严重。安装到操作系统上的应用程序可以运行哨兵进程，这些进程定期发出数据，不管目标应用程序是否处于活动状态，基于浏览器的应用程序将失去作为客户机的所有标识，除非它们处于活动状态。所以，这对QA工程师来说的确是一个令人沮丧的情况。创新不断地改善客户端数据的情况，但数据数量和对应用程序的影响之间的权衡永远不会消失。

也许最能体现技术水平的是在移动平台领域争夺客户的产品数量。在iOS领域，苹果为iTunes App Store中出售的所有应用程序提供原生崩溃日志报告。⁴正如刚才所描述的，用户需要在安装时选择加入，将这些数据提供给应用程序所有者，因此不像第三方提供者那样提供那么多的数据。在第三方领域，供应商确实在激增。⁷这些产品提供了各种特性，每个产品都附带了一个受devops启发的基于图形的用户界面，用于跟踪日常频率、堆栈跟踪弱点，并提供对承载异常的客户机的全局精确定位。

对于运行在Android上的应用程序，原生平台之外的产品也大量涌现。原生Android SDK提供了比原生iOS更好的报告平台，²包括报告崩溃事件，以及已捕获和未捕获的异常。扩展使这些报告的集成更容易，¹主要针对那些使用谷歌基础设施的人。基本上，在iOS领域使用最多的产品也可以在Android平台上使用。这些产品可能对拥有多平台产品的应用程序开发人员最有吸引力。

回到顶部

QA和DevOps在哪里融合?

在分析了QA和DevOps可用的技术之后，比较仍然需要详细说明，在开发周期的工程阶段，如何以DevOps时代的运维工程师可用的有效性和洞察力来捕获客户体验。

QA的影响力体现在日程安排、对设计决策的反馈、对bug的优先级排序，以及在不考虑开放bug的情况下发布的决定中，收敛程度很大程度上是风险评估的功能。长期以来，工程师们一直能够利用从生产中收集的应用程序参数，将严重程度投射到已发现的漏洞上。然而，当致力于新功能或当一个新设计最终迫使用户进入一些全新的工作流程时，任务就不那么容易了。

测试的时间表必须从过时的瀑布模型转移到一个承认测试和发布模拟重要性的模型。这是显而易见的，它构成了软件开发理想的陈词滥调。受DevOps文化影响而引入的新概念促进了对客户端场景的程序化分析。对客户端场景的主动分析的扩展应该从本质上自动化用户可能(也许更重要的是)可能遇到的各种用例路径。与那些影响用户使用模式之外的问题相比，那些更接近用户关键路径的问题显然会被分级为更高的严重性。普通评估和通过DevOps透镜进行的相同分析之间的区别在于数据的存在。使用数据显然必须是严重性评估的基础。

评估设计决策需要专家洞察所有指导。DevOps文化的一个特点是拥有对整个系统的工作知识，能够基于对整个应用程序的完整知识进行概要分析和预测问题评估。从QA的角度来看，这种洞察力使人们相信关于精确度、性能和交付设计决策的建议结果的可能性的问题。开发人员的洞察力在很大程度上就足够了，但DevOps美学要求以不能被质疑或猜测的指标形式表示信息。

确定bug修复的优先级可以对软件发布产生决定或破坏的影响。在发布之前强制修复bug是另一种责任。在开发周期的特定窗口中修复bug将为更多有趣的测试提供机会。显然，在任何可能的情况下解除测试阻塞是非常重要的，但是在开发团队中，关于bug修复正式开始的时间经常发生冲突。这就是优先级必须高于计划的地方。

当测试被阻塞时，测试目标就会受到影响。重要的是要使测试目标成为一种不可移动的力量，并使用度量标准来定义两个相反的力量何时可能发生碰撞。要确保发行版的运行状况，测试必须在一定天数内成功。如果严重的bug阻碍了测试，那么发布可以也应该推迟。Bug优先级是必须的，以确保有足够的工作量来保证一个可接受的和成功的发布。

发布决定的底线是真正的底线，软件应用程序的普及和使用将定义它的价值。无论这是否推动了一项工作的财务或流行的成功，它无疑是验证器。

发布决策必须始终承认已知的面向客户的问题的存在，QA经常负责评估发布的准备情况。总会有很多争论，但数据应该为自己说话。这是子弹击中骨头获得应用程序所有权的地方。这些数据应该确定客户会看到什么、何时看到以及多久看到一次。“Sign Up”中的模糊bug与“Login”中的模糊bug有很大不同，因为后者是每个会话的前兆。仅在濒死操作系统中出现的问题可能会限制曝光，但也会增加支持成本。QA的目标应该是适当地呈现可行的数据，并在发布后记录问题。

无论将DevOps视为团队中的一个特定角色还是一种文化，对工程和量化指标的关注使团队能够进行预测和权衡，从而增强产品架构师和管理层的能力。在某种程度上，这是一个成熟的软件开发过程已经到来了很长一段时间。

在没有大量数据帮助可预测验证结果的情况下，没有任何其他科学和其他工业努力能够做出决策。在DevOps将系统管理技能集与开发工作联系起来的地方，将同样的基础转移向上转移到质量工程工作中，可以帮助团队对产品的开发和发布做出更明智的决定。

相关文章
在queue.acm.org

Antifragile组织
阿里尔Tseitlin
http://queue.acm.org/detail.cfm?id=2499552

在QA工具的沙漠中漫步
特里Coatta
http://queue.acm.org/detail.cfm?id=1046955

质量保证:远远超过测试
斯图亚特·费尔德曼
http://queue.acm.org/detail.cfm?id=1046943

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2013 ACM, Inc.

---

没有发现记录