Anders Wallgren访谈：针对DevOps度量和文化的重要性

本文要点

• 对DevOps进行度量的重要性
• 将可见性融入整个部署流程的价值
• 它可能将部署周期时间减少几个数量级
• 它需要支持，安全文化使此类改进成为可能
• 开始使整个部署流程可见吧，然后优化整个流程，而不仅仅是其中的一部分

在2016年八月的敏捷大会上，Electric Cloud的技术总监Anders Wallgren演讲了在DevOps中正确度量的重要性。后来他与InfoQ交流了本次演讲和DevOps的总体状况。

InfoQ：请先向我们简单介绍一下Electric Cloud？

Anders： Electric Cloud提供DevOps自动化发布解决方案。我们和客户一起自动化他们的软件交付链，他们的软件流程。我们的方法是以端到端的视角去看事情实际上是如何运转的，我们从笔记本电脑到发布上线所追求的是什么。我们希望有一个头至尾的自动化链条，也正在打算把许多其他工具也涵盖进来，测试工具、构建工具、性能测试、安全性测试，等等。我们类似于管理和应对软件交付痛点的传送带和单一虚拟管理平台，这就是我们的定位。

InfoQ：请向我们谈谈关于你的演讲。

Anders ：我演讲了度量及其它们所承担的职责，特别是在DevOps中以及敏捷中。我喜欢把这些事放到一起来看，这使有些人感到不适。但所有这些是连续统一体，它们环环相扣。我认为DevOps状态报告其中一件很令人关注的事，Puppet Labs 和 Gene Kim在IT Revolution中每年会发布一次，事实表明，这是份非常严谨的统计数据，有某些行为和做事方式会实际影响到底线、客户满意度、员工满意度，所有之类的事。

在度量中有许多早已深入人心了，他们发现了一些非常令人关注的度量，它们与软件团队的成功高度相关。早在2014年的报告中，它们指出使用二元工件库（binary artifact repositories）的组织往往更不容易失败，恢复的平时时间也更低。作为一个组织，部署能力和成功之间有着非常密切的关联。

所以这次演讲是“让我们看些示例，看看组织是如何使用此类度量的”。我列出典型的软件流程，开发、持续集成、质量保证、运维，以及许多与这些阶段相关的度量，然后把我们从客户哪里收集到的一些信息以及他们是如何使用这些度量的予以分层。之后是他们取得的各类回报：削减周期时间或减少出错或减少由于出错带来的返工，等等。

而且有意思的是，DevOps状态报告在“针对高绩效组织的预测因子”方面探讨的数字与之非常契合。原来我们支持许多轶事证据，你所希望成立的事它恰恰表明的确如此。

InfoQ：那么这些重要的度量是什么？

Anders： 周期时间永远都是真正重要的度量。几年前我们对大约八百个人进行了调查，但这不是个很系统的调查，我们问开发人员和质保人员，“你每周要在等待上花费多少时间？”对于开发人员，答案是每周十二小时。对于质保人员，答案是每周二十小时，等着构建、等着环境、等着测试完成、等着部署完成，此时只能坐在那里看看新闻，这份成本非常昂贵。

所以周期时间永远都是一件相当重要的事，它对许多事会产生彻底的影响。我们所看到的事中我发现其中一件很令人关注，它在那份2016年报告中也有所涉及，那就是你不得不进行的返工都会对整个组织的生产力造成极大的影响，不论是那些由于安全性带来的返工还是由于缺陷导致的返工。低绩效团队花在规避安全问题上的时间是高绩效团队的两倍。这是一个非常夸张的比率。你也知道，如果你不在返工上浪费时间，就可以把时间用在做有价值的事上。

所以此类度量是：周期时间、前置时间、由于运行中断或部署期的问题所需的恢复平均时间，多长时间可以发现它、修复它、确保它不会再次发生。这些类型都非常非常值得度量。可能没有适合每个人的完美度量集，但这些都非常有价值，可能有非常普遍的适用范围。

InfoQ：你可以举一些这些度量及其影响的示例吗？

Anders： 当然。我们与一些非常大型的组织合作过。我们的客户往往都是通用电气医疗集团 (GE Healthcare)或华为或高通或瞻博网络之类的，还有一些没那么大的，可能也就是在做一款某种类型移动应用的五六个人。几年前，华为决定关注我们特性交付的前置时间是什么？那么从我们准备好了决定去做某事起，到它完成需要多长时间？于是他们进行了研究，发现大约需要三十天，实际上，这还不算太糟。但他们决定把它降至七天。

如今，这驱动了整体的积极性。这驱动了降低持续集成周期时间的积极性，从十分钟降到了大约只需要一分钟；这驱动了他们降低产品构建的时间，从三百分钟降到了大约只需要一个小时；他们通过并行运行测试把测试时间削减到了四分之一，等等。

此外，也有一大批客户，惠普、高通以及一大批其他客户也都获得了巨大的回报，他们实现了自动化测试，不再需要那么多的人工测试了。降低周期时间有很多的影响，而且它还让你能运行更多的测试周期了，这将会提升质量，你将会发现更多的问题，从而减少返工以及在任务上的时间开销。

所以，所有此类令人关注的事都像它一样。我们有一些客户的安装测试时间很长，他们正在大幅削减这些时间。我们得到了一些这样的案例，瞻博网络把构建时间从二十小时降到了一小时。这非常显著，现在，你不用回家过几天回来后才发现已经出错了，只需要等一个小时就能知道结果了。

所以如果你们对略有宽松的日程并有些怠工的情况能够有所观察，就会发现自动化与手工传递之间的还有一些孤立的地方，在这些传递过程中浪费了很多的时间，发生了很多的错误。所以我们与客户做的是端到端的自动化，它帮助我们把工作变得更加紧凑了，使事情越来越多地提前了，空出了更多、更充分的测试周期。

我从其中一个客户FamilySearch那里听到了一个有意思的例子：他们的目标是减少交付时间，当他们开始持续交付之旅时，从代码完成到构建部署上线需要大约九十天。而现在他们只需要十分钟了，这简直颠覆了整个游戏。在给刚反馈过缺陷的客户打电话时，他们可以挂掉电话没多久就说“哦，现在再试试吧。”这时他们已经修复并发布了，显然，前提在于你能快速地修复它。而以他们为客户交付价值的能力来看，部署产品对于他们来说已经不再是问题了。

InfoQ：那么一个组织从九十天的部署周期缩短到十分钟需要做什么改变呢？

Anders： 要改变许多事。自动化是关键。我们需要让人们不再去做那些机器更擅长的事。作为一个生物，我们并不擅长在正确的时间在终端窗口输入正确的命令去重启正确的机器。

但另外还有文化。文化，工作文化即不能是惩罚式的也不能是官僚化的。关于一种文化，关于他们作为带来坏消息的信息传递者怎么去做的，你可以讲述很多的内容？他们已经行动了？他们选择了无视，或者他们得到了帮助？然后我们提出，“好，让我们马上处理这个问题尽快解决吧。”但在之后，让我们回溯并想清楚，“为什么我们没有尽早发现它？为什么这会在生产环境或验收测试环境出现？为什么没有在单元测试里发现它？”

所以文化应为 文化类型学 中更加无责和更具生产力的那种。文化类型与DevOps的成功和软件的成功有着很强的关联性。其中很多是精益管理方法，你需要去持续改进。如果总是打击告诉你需要去改进的人，是做不到持续改进的。坦白讲，我一直认为，保证正确是件非常难的事。没人喜欢被人动他自己的奶酪。要做这些事，我们就必须得去改变工作的方式，存乎运维和开发中的每个角落。

InfoQ：往上游推进怎么样？

Anders： 开发人员，质量的缔造者。我认为最重要的指标之一是你打算花多少时间返工，以及花多少时间在下游去处理本应在上游发现的问题，这意味着每个开发人员应该去写单元测试，还是应该通过回归测试或者性能测试或者安全性测试来发现。所有这些事我们过去经常按阶段的方式去做。你也了解，我们会把软件先做出来，然后提升质量，然后提升性能，然后提升安全性，然后交付使用。

InfoQ：只是我们在这中间经常有所遗漏。

Anders： 好吧，是的，的确如此。但是现在，大家经常会说，“看，我们要有自己的持续集成系统了。我们必须确保事情不会被彻底搞坏，我们打算最小化这件事的工作量。”但另一方面，我们在持续集成之后有后续的阶段去做类似于用户验收测试、性能和其他之类很花时间的事，也许，因为你想要快速反馈给开发人员所以会在持续集成周期内去做这些事。但这些事必须针对每一块要发布的代码。它必须通过自动化来执行。你必须收集好所有的数据。

为避免陷入逆境，一旦软件推出就必须把所有事都做到位，特别我们现在正在开始进入到物联网领域，所有个人数据都是可以获取到的，包括心率及诸如此类安全性、隐私的数据。所有这些事都很重要，而不是可有可无的，它们是特性，它们是最基本的首要特性，你需要按此规格去对待它们。我觉得行业正在开始采用这种更好的做法了。我们尚未精通此道，但正在越做越好。现在令人可耻的问题已经足够公开了，没有人想成为这样的公司。

InfoQ：看起来甚至进一步要倒退到需求来源之处了，我们如何确保构建了正确的东西？

Anders： 我认为敏捷真的很有帮助，这很明显。我的意思不是说敏捷已经解决了这个问题，因为它仍然是个棘手的问题。但我觉得关注周期时间能有很大的帮助。你可以先给客户更多的原型，可以用它们做更多的试验，更多地展示打算做的是什么，以及使他们更多地参与进来。

所以，坦率地说，我认为敏捷是这场方法论之战的最大赢家。那么现在，如果我还这么说可能就不太适当了，因为现在DevOps和持续交付是最后一英里的探索了。很明显，敏捷宣言所说的“我们在乎的是整体”是绝对没错的。从实用的角度来看，我觉得我必须更少关注开发和质保，而更关注产品所有权，更少地关注如何交付它，我觉得这可能是十年前最大痛点之所在了。所以我们关注它，现在我们正在试图想清楚如何为客户探索这最后一英里，无论是在亚马逊封装为一体的固件，还是在网页端或其他你采用的方式。

InfoQ：除文化之外，其他的一些障碍是什么？

Anders： 其中有这么一件，我不清楚是否该称其为障碍，也许是个挑战，还是让我换一种方式来说吧，当我讨论这些事时，得到的最常见问题是：“好吧，但我从哪里开始呢？”因为这是件大事。我觉得人们如今已经认识到这一点了，而早前的时候会出现类似的说法：“好的，有些人上了一课，然后我们将要变成敏捷了或者将要变成DevOps了，我们本周五将停止再做瀑布，到下周一早晨，我们就是Scrum或者就是DevOps了。 ”

这种方式行不通。它是逐渐转变的。可能文化不得不发生改变，可能工具不得不发生改变，可能技术和流程不得不发生改变。我们鼓励我们的客户去做的其中一件事是，先弄明白你们在谱系中的位置，因为公司A必定会与其公司B面临同样的挑战。

我们鼓励我们的客户做的另一件事是，坐下来想清楚从笔记本电脑到发布上线的流程看起来是什么样子的。从一名开发人员检入一段对于客户来说是有价值的代码之后，你们会做些什么工作？特别是在大型组织中，特别是在具有分布式团队的组织中，以及所有此类情况，未必每个人脑中对此都有映像，这是极为常见的一种情况。实际上，我们经常听到这样的说法，“哈，你想知道吗？鲍勃知道，我们去问问他。”所以我们把鲍勃请到屋里，讨论时他会说，“不不不，我们做得根本就不是这些。我们做的是那些。顺便说一下，如果你们这么做，将对我们有一定帮助。”

所以不妨把每个人都聚到屋里（理想情况是在同一时间），然后实际绘制出流程是什么样的。这么做的其中一个好处是，你现在可以看到并弄清细节都在哪里了。因为当我们像烟囱一样封闭起来时往往就会像盲人摸象一般，每个人只是关心他们看到的那一小部分。

如果我是名构建工程师，我想更快速地构建。如果我是名质保工程师，我想更快速地测试。但你最大的问题是什么？是否由于未在测试中发现的缺陷而导致了返工的问题？它是否导致运营停机？它是不可靠的部署吗？你正在做的局部优化说起来根本不会在本质上对你有所帮助，除非你清楚这些，肯经常在不会带来任何进展的地方花很多时间。

所以我们总是鼓励我们的客户坐下来看清楚、想明白，至少一次。现在，我们鼓励他们为其建模并将其编入产品法典，然后依此执行。那么你可以与自己的产品一起演进你的流程，流程实际上应该稍微迁就一下产品。我用一个类比，我们回到都还在使用桌面软件的时候，我们那时在构建安装程序。我们的部署脚本就是当时我们的安装程序、部署流程，不是吗？我们给运维的就是这些安装程序。

然后我们犯了许多人使用安装程序时同样的错误，那就是“把它交给新人，由他来做。”即使这本是件非常棘手的事情，而不是那些你随便可以交给毫无经验的人去办的事。实际上，你是想要交给最擅长这方面的人的。我们如何自动化DevOps流程？我们如何持续交付？这些事不应该抛给毫无经验的人。因为它很难而且很重要，所以你想让最优秀的人把它办好。

InfoQ：在 Electric Cloud 产品套件中有什么新内容？

Anders： 我们已经发布了Electric Flow的新版本。在其上的通栏标题是，我们现在基本上可以一键完成大规模环境的滚动部署了。所以我们现在有建模的能力，并在每个环境基础上说，“当你部署此类环境时，我希望你去做这一类分阶段的展开。我希望你在这一层上、这一层的机器上做这么多事，或做一定比重的工作，然后我希望你对这些进行测试或验证。然后我们可以部署到50%并执行其他的测试，直至最终完成所有部署。”所以你可以相当轻松，即可以用我们的特定领域语言，也可以在用户界面里拟订大规模环境的滚动部署。

我们从客户那里听到，我们的客户之中有一个是《财富》20强银行。他们的数据中心中有6000个应用，有144000个终端。所以这么大的规模，同样也存在一个棘手的问题，那就是怎么不会踩到其他人的脚？所以除了所有这些应用、所有这些组件的完整依赖关系视图外，发布计划和环境日程和预约也是我们具有的另一部分功能。

所以你可以说，“好的，我们打算试试这个服务了。谁使用这三个应用？好吧，我们打算在本周五做。我们需要接触这些环境。让我们把它们预约出来，确保没有其他人部署它们。”通过这么做，我的意思是我们可以适当避免大家部署那些未经预约的环境，或其他要进行管制的事。我认为其中最有意思的是，显然这件事已经存在很长时间了。但它通常是定制的、脚本化的，客户员工自己编写的或具有此能力的该领域的独角兽（译注：表示它是高贵、高傲、不易接近的）。所以现在，我们要把它变成马，而不仅是独角兽，能够更现成地完成这些事，看到它的出现委实是件令人兴奋和开心的事。

关于访谈者

Anders Wallgren 是Electric Cloud的技术总监。Anders具有超过二十五年资深的商业软件设计和构建经验。之前，Anders在Aceva、Archistra、Impresse、Macromedia (MACR)、Common Ground Software 和 Verity (VRTY)担任过行政和管理岗位。Anders持有麻省理工学院的学士学位。

查看英文原文： Anders Wallgren of Electric Cloud on Metrics for DevOps and the Importance of Culture