PDF在质量保证中采用 DevOps 实践
融合软件开发的艺术与科学
James Roche
在很长一段时间里，软件生命周期管理都是一项受控的活动。产品设计、开发和支持的持续时间是可预测的，公司及其员工可以围绕产品发布安排财务、假期、手术和合并。当开发人员忙碌时，QA（质量保证）部门相对轻松。当发布周期的编码部分接近尾声时，QA 接管工作，同时支持部门开始增加人手。然后，当产品发布时，开发人员松了一口气，休息一下，然后重新开始循环，而支持人员则忙于支持新产品。
从开发团队的角度来看，产品发布代表了一个可重复且公式化的闭环流程。除了可能需要开发人员专家关注的错误之外，大多数员工在产品提供给客户后，都会被重新分配到下一个版本的开发工作中。
在这个世界里，QA 团队的职责主要包括模仿客户的使用模式，并最大限度地减少令人不快的意外的发现。在瀑布模型中，QA 团队的荣誉勋章是其预测、发现和提供可重现场景的能力，这些场景可能会给用户带来问题。
构建随机硬件配置、模拟令人困惑的网络环境以及连接底层平台架构中看似正交的因素，都是优秀 QA 工程师知识的各个方面。最优秀的工程师可以查看产品设计并预测可能出现问题的地方。对于独立的桌面软件，发布错误的代价非常高昂，因为修复需要服务发布，因此 QA 部门获得了更多的时间和人员来验证一切是否按预期工作。
我记得这个可预测的变量和有限的时间表时代结束的时候。事实上，我记得非常清楚。我当时在一家公司工作，试图推出一款旨在颠覆 eBay 的个人对个人市场产品的原型。我们花了几个月的时间从用户界面向下测试该服务。在盛大发布之夜，大楼里最大的会议室挤满了人，纸板咖啡杯里盛着香槟，整个扩展团队都期待着发布，最终高呼倒计时：“5、4、3、2、1！” 当 CEO 使用新网站购买我们在产品目录中开玩笑的傻乎乎的物品时，拥抱和祝酒声此起彼伏。然后有人拍了拍我的肩膀。是工程主管，他的话很简单：“我们认为你应该和我们一起下楼。”
楼上，每个人都面带微笑，期待着我们产品的首次亮相。但是，在楼下一个小得多的房间里，沿着墙壁摆满了临时办公桌，没有人面带笑容。网站“可以工作”，但考虑到微小的流量，它的运行温度过高。
当时大约是太平洋时间晚上 7:00，距离计划于第二天早上向全球发布的公告只有几个小时了。我的工作主要是通过一个匆忙准备的 shell 脚本来生成流量，从而维持服务的负载。与此同时，六名工程师围在一台屏幕前，屏幕上滚动着日志，图表上下跳动。在我们调整了负载均衡器之后，那些令人头疼的图表线开始向下，标志着我们面临的问题得到了缓解。整个房间都谨慎地松了一口气。
楼上的派对在我那天晚上离开办公室前几个小时就结束了。晚上 11:30，我和我的狗一起清醒而疲惫地走回家，感到满意但又焦虑地想知道第二天宣布后的产品命运。
第二天早上，我们登上了《纽约时报》的头版，这对我们来说是巨大的认可，但我对那个时期的主要记忆是对软件产品的售后有了新的认识。
现在还有多少产品只在桌面上运行？有多少产品周期甚至在最后一个错误修复和暴露给客户之间只有 24 小时？更重要的是，这如何改变发布、维护和支持应用程序的人员和流程？
隔墙相望
我最近偶然看到一个有趣的在线表情包，叫做“灾难女孩”，老实说，我可能是地球上最后一个遇到它的人。在照片的背景中，一所房子正在冒烟，邻居和消防员站在安全的距离之外。在前景中，有一个年轻女孩带着沾沾自喜的笑容，以及响亮的文字，写着“在开发环境中运行良好。现在是运维问题了。”5
我怀疑这不是一个新笑话的部分原因是，对于大多数软件创作者来说，世界真的不再那样运作了。曾经瀑布式开发规定了从开发人员到 QA 再到运维的交接过程，但现在的职责界限模糊，大多数工程师的技能组合跨越多个学科。
贡献者之间的冲突现在最好被消除。脾气暴躁的 QA 工程师在 Scrum 团队中几乎没有立足之地。产品从原型成长而来。设计阶段已被从开发到演示的非周期性、民主的演变所取代。
在每日站立会议中，没有争论不休的论坛。运维工程师的神秘感也消失了。曾经在好莱坞电影中，那些夜间无所不知的人在一个满是闪烁屏幕和难以理解的日志的房间里推断产品的状态，而 DevOps 文化已经消除了这些角色的大部分魔力和咖啡因依赖性。
一个令人耳目一新的结果是行业内部专业知识和专业精神的急剧上升。与此同时，工程技术实力使团队能够自动化许多曾经需要人类系统监视器 24/7 值班的跟踪工作，这改善了全球工程师的工作与生活平衡。对于每个团队——包括开发人员、质量保证和运维——他们的角色都发生了重大变化，以突出现代软件架构模板的各个方面。
那么，究竟发生了什么变化？
回想一下 20 世纪 90 年代中期，当时安装在机器上的大部分东西都是通过软盘或 CD-ROM 光盘提供的。大多数软件很少与自身主机存储之外的任何资源交互，而与外部资源交互的软件则通过有限的企业产品阵列进行交互。
开发到支持的指挥链与之前定义的一样。开发人员根据规范工作，“最低要求”文档是一组严格的约束。测试工作主要包括填充硬件/功能配对矩阵，每天安装一次，以及手动和自动化测试的组合。自动化主要用于收集性能指标，以进行基准测试和压力承受能力测试。运维在很大程度上是客户支持技术人员的责任，他们与安装产品的客户有日常接触。可以说，没有必要进行专门的运维工作，因为环境在很大程度上仅限于每个用户的本地环境。
在这个时代与现在之间，瘦客户端和胖客户端之间的无数次翻转已经为应用程序产生了广泛的客户端容量。在胖客户端方面，游戏和数据管理软件需要非常强大的客户端，并对现代环境中无数的网络选项提供强大的支持。瘦客户端的末端填充着基于浏览器的应用程序。弥合胖客户端和瘦客户端之间空间的是大量的应用程序，这些应用程序将本地处理环境与网络上的数据和异步处理配对。
这些新产品比早期的胖/瘦权衡中讨论的任何产品都要苗条得多，并且现在在任何其他平台上都远远超过了它们。随着移动平台处理能力的增长，胖/瘦平衡本身也具有新的范围。移动设备是一个有趣的类别，因为应用程序既受到屏幕尺寸和处理能力的限制，用户的期望也远低于在桌面环境中运行的类似应用程序。
当这种远离孤立客户端的迁移成为常态时，软件开发团队内部的角色也随之同步变化。不幸的是，对于许多人来说，这不是一个立即显而易见的要求。软件墓地里堆满了那些管理层未能对新联网环境做出足够快反应的产品。那些适应了环境的产品被迫将角色从传统的开发/QA/支持框架中移出，并建立在构建具有功能无限寿命的容错系统方面更具协作性的团队。
瀑布现在变成了一条河流；开发和运维融为一体。当产品发布时，很少有升级或弃用功能的计划，支持是持续进行的。行业通常在适应这种新环境的期望方面做得很好。
最值得注意的是，现在的工程努力服务于多个主人。以前的重点纯粹是精度，而现在，在产品需求讨论中，寿命和可扩展性与精度具有同等重要的地位。您的应用程序可能仍然可以移山填海，但现在它需要永远为地球上的每个人移山填海。
传统上，QA 部门负责风险定义和可维护性，而开发和运维人员（简称 DevOps）现在也扮演着同等重要甚至更重要的角色。现在，讨价还价的功能不仅要考虑 PC 芯片组和媒体容量的限制，还要考虑可行性和可持续性。DevOps 负责系统容量和可扩展性，这受限于组织内部和外部的平台资源。
DevOps 与开发、概念和误解
DevOps 没有标准的定义。关于该主题的博客文章比比皆是，但能得出的最佳结论是，关于该术语的实际含义，沙子仍在移动。争论的一方确定了 DevOps 的具体职位描述，一篇博客文章很好地总结了这一点，该文章指出，开发人员主要从事代码工作，运维人员主要从事系统工作，而 DevOps 是这两种技能组合的混合。6 另一方并不明确反对这种观点，但认为 DevOps 实际上不是一个职位（因为你不会直接聘请“DevOp”），而是 DevOps 的精神表明了现代软件开发和支持环境中新兴的需求。3
这个问题已经困扰社区一段时间了。那些自豪地将自己描述为 DevOps 的工程师显然与那些认为根本不存在 DevOps 这种事物的人不在同一个频道上，但是成千上万个专门寻找“DevOps 工程师”的公开招聘职位证明，许多知名公司的人认为该术语描述了一个特定的角色。行业中的其他人认为，该术语描述了开发、测试、发布、支持和指标收集的新标准。我不站队，但在本文中，我将使用DevOps 来描述新标准，而不是特定的职位。
根据我的经验，我观察到 DevOps 概念的出现与许多行业力量相同，这些行业力量使 QA 工程师的职位描述更接近于开发人员。一个人对应用程序的代码和平台了解得越多，就越能更好地构建和修复该应用程序。DevOps，无论是在运维工程师承担开发任务的情况下，还是在开发人员在运维领域工作的情况下，都是为了拉近这两个学科之间的距离。
软件开发和支持的这种融合是随着对更好的工具集的需求而出现的，以检测和衡量网络系统中的问题。成百上千家不同的公司为常见任务创建了自研解决方案，然后这些解决方案变得繁琐，难以构建、扩展和维护。不久前，许多产品开始面市，这些产品为开发组织提供了一种解决常见需求的方法，例如问题诊断、部署管理、任务自动化和流程标准化。通过这种方式，无论大小，开发组织都可以整合致力于构建此类机制的资源。
这种新基础设施的最大好处是能够量化开发和支持工作的各个方面。在没有不确定性的情况下，可以使用数字来描述开发过程，这些数字可以完美地将数据传达给埋头苦干的开发人员以及非技术性的项目和产品负责人。这对团队来说是一个巨大的价值，并且从社区内上述辩论中可以清楚地看到一件事：软件开发绝对存在 DevOps 前时代和 DevOps 后时代。
在整个领域，DevOps 的影响使效率和流程具有了视角。但是，在某些特定领域，DevOps 浪潮完全且永久地改善了产品开发和所有权，这特别归功于对指标和流程标准化的更敏锐的关注。
流程标准化
行业再次整合其平台选项，并且系统管理正变得越来越标准化，因为行业异类为 Chef、Splunk 和 Jenkins 等流行产品构建了垫片。DevOps 工具包的锤子和螺丝刀所体现的少数经过时间考验的产品非常普遍，以至于具备这些产品的管理员级别经验已成为许多职位描述的一部分。虽然这在基础设施使用这些产品作为系统开发基石的小公司中可能看起来并不新鲜或奇怪，但拥有多个团队分别开发和部署的大公司发现这种标准化是强制使用自研解决方案、允许自由放任的独立性或介于两者之间的任何事物的有价值的替代方案。
对于许多公司来说，这种标准化净化了发布和支持流程。许多组织围绕不动对象发展其流程。过去，桌面软件实际上只能围绕 CD/DVD 制造商和出版商发布，但现在他们有了在线应用市场标准来设定指导方针。同样，对正常运行时间有严格要求的在线产品导致了与数据中心服务提供商签订了昂贵的维护合同。现在，有了将这项工作内部化的能力，人们对流程有了更好的理解，并且对于那些负责发布新产品的人来说，减少了跳舞的环节。
任何软件组织的开发、部署和支持流程的真正验证是持续部署的概念——实际上，它是将所有三项任务协调到客户不会被通知，甚至不关心软件升级的程度。持续部署要求开发组织实现足够的质量，以便在源代码控制提交和发布之间的短路径中不遗余力。这意味着部署必须对用户不可察觉，其中一些用户将在会话中软件版本被偷偷更换。这也意味着对在此类秘密发布过程中遇到的任何问题的响应都是积极主动且立即的。
Dmitriy Samovskiy 在 2010 年的一篇博客文章8 中对 DevOps 的定义将工作描述的一个方面命名为“生产环境中的 QA”。这无疑会激怒行业中的许多人，但思考一下这如何帮助为软件行业的每个人定义新标准，使其成为一篇有争议的文章中一个有价值的要点。同样，在 DevOps 文化的最有价值的贡献在软件支持角色中浮出水面的程度上，将相关的文化嵌入到整个产品生命周期中会将有价值的改进一直推回到应用程序的设计阶段。
将软件开发指标转移到 DevOps 世界
现代软件环境中对创建者最有利的方面是在设计时同时提供瘦客户端和胖客户端解决方案。一旦考虑到数据传输成本，大多数客户端（现在包括大多数移动设备）的处理能力与服务器端处理能力相当。DevOps 使实现承诺成为可能。当客户端功能的复杂性使其接近排除时，承认这种权衡是必要的。此外，准确描述权衡取舍是交付成功产品和交付成为行业笑柄的产品之间的区别。
这引出了 DevOps 的一个有趣方面，即我们现在终于超越了 QA 工程师的见解始终与可疑数据相关联的阶段。在这一点上，DevOps 拥有服务器端数字，因为负载、容量和可扩展性已成为易于推导的数字。
当主要处理客户端代码时，客户端排列组合的可变性和缺乏准确的行为度量使得 QA 输入的客观性和可验证性大大降低。例如，许多 QA 讨论都以“我们有客户抱怨这个功能在他们的手机上运行缓慢”开头。简单的后续问题包括，“那些手机上还在运行什么？”“他们是在 Wi-Fi、3G 还是 4G 上运行？”以及“这是一个特定手机的问题吗？”，然后从那里继续。一位消息灵通的 DevOps 工程师可以说：“我们的产品现在使用了我们 10,000 名活跃订阅者 40% 的容量，因此，如果我们不能在现在到下一次发布之间将实例数量翻倍，我们就无法承担更多功能或更多客户。” 没有人会质疑这种数据驱动的 DevOps 裁决，而 QA 工程师传统上无法在不做更多研究的情况下支持他们的论点。在某种程度上，DevOps 人员现在在定义和解决客户端/服务应用程序环境中的问题方面的工作更容易了。与此同时，QA 在描述应用程序生态系统中的问题时，要提供相同水平的有效性，这是一项艰巨的责任。
已经非常重视通过客户端应用程序指标来提供大部分实际体验。崩溃报告是许多应用程序在安装时建议用户允许的功能。基于浏览器的应用程序能够跟踪用户与应用程序交互的几乎每个方面，移动设备也提供了类似的蛛丝马迹。客户端越瘦，应用程序崩溃时丢失的数据就越多。在没有明确许可的情况下，大多数浏览器和所有移动操作系统都阻止访问评估应用程序崩溃原因所需的数据。
具有讽刺意味的是，QA 的客户端数据是以应用程序吞吐量为代价的。当然，有很多方法可以从运行应用程序的客户端收集数据，但是减少数据量和交付频率会对客户端的性能和服务的可用性产生负面影响。同样，基于浏览器的应用程序和在移动平台上运行的应用程序受到的影响最严重。虽然安装到操作系统的应用程序可以运行 sentinel 进程，无论目标应用程序是否处于活动状态，这些进程都会定期发出数据，但基于浏览器的应用程序除非处于活动状态，否则会失去作为客户端的所有标识。因此，是的，这对 QA 工程师来说是一种令人沮丧的情况。创新不断改善客户端数据的情况，但是数据量和对应用程序的影响之间的权衡永远不会消失。
也许对现有技术的最佳代表是在移动平台领域争夺客户的产品数量。在 iOS 环境中，Apple 向 iTunes App Store 中销售的所有应用程序提供其原生崩溃日志报告。4 正如刚刚描述的那样，用户需要在安装时选择加入以向应用程序所有者提供此数据，因此提供的数据不如第三方提供商提供的数据多。在第三方领域，提供商真正激增。7 这些产品提供各种专业功能，并且每个产品都带有受 DevOps 启发的基于图形的用户界面，以跟踪每日频率、堆栈跟踪薄弱点，并为全球精确定位异常客户端提供支持。
对于在 Android 上运行的应用程序，在原生平台之外也有类似的产品激增。原生 Android SDK 提供了比原生 iOS 中看到的更好的报告场所，2 包括崩溃事件以及捕获和未捕获异常的报告。扩展使这些报告的集成更容易，1 主要针对那些坚持使用 Google 基础设施的人。一般来说，在 iOS 中使用最多的产品也可在 Android 平台上使用。这些产品可能对提供多平台应用程序的应用程序开发人员最具吸引力。
QA 和 DevOps 在哪里融合？
在分析了 QA 和 DevOps 可用的技术之后，比较仍然需要详细说明在开发周期的工程阶段，如何以 DevOps 时代的运维工程师可用的有效性和洞察力来捕获客户端体验。
QA 的影响体现在进度安排、对设计决策的反馈、错误的优先级排序以及尽管存在未解决的错误仍决定发布，融合程度在很大程度上取决于风险评估。使用从生产环境中收集的应用程序指标，工程师长期以来一直能够预测已发现错误的严重性。但是，当处理新功能或新设计迫使用户进入全新的工作流程时，这项任务就不那么容易了。
测试的进度安排必须从过时的瀑布模型转变为承认测试和发布模拟重要性的模型。这是显而易见的，它构成了软件开发理想的陈词滥调。但是，DevOps 文化提倡对客户端场景进行程序化分析。扩展对客户端场景的主动分析本质上应该自动化用户可能遇到，也许更重要的是，很可能遇到的各种用例路径。与超出此使用模式的用户相比，发现的更接近典型用户的关键路径的问题显然将被视为更严重的问题。常见评估与通过 DevOps 镜头进行的相同分析之间的区别在于数据的存在。使用数据显然必须是严重性评估的基础。
评估设计决策需要对所有指导进行专家洞察。DevOps 文化的一个标志是对整个系统的工作知识，以及基于对整个应用程序环境的了解来分析和做出预测性问题评估的能力。从 QA 的角度来看，这种洞察力为关于精度、性能以及交付设计决策的预期结果的可能性问题提供了可信度。这是开发人员的洞察力在很大程度上就足够的地方，但 DevOps 美学要求以无法质疑或反驳的指标形式呈现信息。
确定错误修复的优先级对软件发布具有成败的影响。在发布之前强制修复错误是不同的责任。在开发周期的特定窗口中修复错误为更多更有趣的测试打开了机会。尽可能解除测试障碍显然非常重要，但是开发团队内部经常就错误修复何时正式开始存在冲突。这就是优先级必须凌驾于进度安排之上的地方。
当测试被阻止时，测试目标会受到损害。重要的是将测试目标作为绝对优先事项，并使用指标来定义当两个相互冲突的目标发生冲突时该怎么做。为了确保发布的健康状况，测试必须在一定的天数内成功。如果关键错误阻碍了测试，则可以并且应该延迟发布。需要错误优先级来确保完成足够的工作以保证可接受的——并且成功的——发布。
发布决策的底线确实是底线，而软件应用程序的受欢迎程度和使用情况将定义其价值。无论这是否推动了努力的财务或受欢迎程度的成功，它都毫无疑问是验证者。
发布决策必须始终承认已知客户面临的问题的存在，并且 QA 经常负责评估发布的就绪状态。总会有很多争论，但数据应该说明一切。这就是应用程序所有权的关键所在。数据应识别客户将看到什么、何时看到以及看到频率。 “注册”中的一个晦涩的错误与“登录”中的一个晦涩的错误大不相同，因为后者是每个会话的先决条件。仅在垂死的操作系统中看到的问题可能会限制暴露，但也可能增加支持成本。QA 在这里的目标应该是适当地呈现数据，并记录问题以供发布后跟踪。
无论是将 DevOps 视为团队中的特定角色还是作为一种文化，对工程和量化指标的关注都使团队能够做出授权产品架构师和管理层的预测和权衡。在某种程度上，这是软件开发过程的成熟，这种成熟已经期待已久。
没有其他科学和很少有其他工业努力会在没有大量数据来帮助可预测地验证结果的情况下做出决策。在 DevOps 将系统管理技能与开发工作联系起来的地方，将这种联系向上移动到质量工程工作中，有助于团队就产品的开发和发布做出更明智的决策。
参考文献
1. Acra; http://acra.ch/。
2. Google Analytics。2013 年。崩溃和异常—Android SDK； https://developers.google.com/analytics/devguides/collection/android/v2/exceptions。
3. Jones，R.。2012 年。如何聘请 DevOps。Gun.io； http://gun.io/blog/how-to-hire-devops/。
4. Mac 开发人员库； https://developer.apple.com/library/mac/navigation/。
5. 表情包生成器； http://memegenerator.net/instance/22605665。
6. Mueller，E.。2010 年。什么是 DevOp？The Agile Admin； http://theagileadmin.com/2010/10/08/whats-a-devop/。
7. Rocchi，C.。2013 年。iOS 崩溃报告工具概述，第 1 部分。Ray Wenderlich； http://www.raywenderlich.com/33669/overview-of-ios-crash-reporting-tools-part-1。
8. Samovskiy，D.。2010 年。DevOps 的兴起； http://www.somic.org/2010/03/02/the-rise-of-devops/。
喜欢它，讨厌它？请告诉我们
James Roche 是一位软件开发人员和工程经理，专注于测试框架。他的工作涵盖了 16 年的著名项目，包括亚马逊的零售平台、亚马逊网络服务；Adobe InDesign；和 Adobe 的数字出版套件。他正在为一个 Adobe 的原型项目做出贡献，期待在 2013 年底附近发布。
© 2013 1542-7730/13/0900 $10.00
最初发表于 Queue vol. 11, no. 9—
在 数字图书馆 中评论本文
更多相关文章
Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，它确保应用程序能够以一致、可预测且经济高效的方式交付所需的业务功能，而不会损害可用性、性能和可维护性等核心方面。本文介绍了一组企业可以应用的核心原则和工程方法，以帮助他们驾驭复杂的企业可靠性环境并交付高度可靠且经济高效的应用程序。
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着时间的推移，MongoDB 变得越来越功能丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。三年前，MongDB 将自研的 JavaScript fuzzer 添加到其工具包中，它现在是我们最多产的错误查找工具，在两个发布周期中负责检测到近 200 个错误。这些错误跨越了 MongoDB 组件的范围，从分片到存储引擎，症状从死锁到数据不一致不等。fuzzer 作为 CI（持续集成）系统的一部分运行，在 CI 系统中，它经常捕获新提交代码中的错误。
Robert V. Binder, Bruno Legeard, Anne Kramer - 基于模型的测试：它处于什么位置？
您可能听说过 MBT（基于模型的测试），但像许多没有使用过 MBT 的软件工程专业人士一样，您可能对其他人使用这种测试设计方法的经验感到好奇。从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是 2012 年类似调查的后续调查，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括 2013 年高级自动化测试用户会议上分发的一些问题。一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数据。
Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化 QA 测试：由事件驱动
对于数百万游戏极客来说，在 Electronic Arts 担任 QA（质量保证）测试员的职位一定像是一份梦想的工作。但从公司的角度来看，与 QA 相关的开销可能看起来非常可怕，尤其是在大型多人在线游戏时代。
© 保留所有权利。