ACM通信

实践

DevOps指标

作者:妮可·福斯格伦，米克·克斯滕
美国ACM通信，2018年4月，第61卷第4期，44-48页
10.1145 / 3159169
评论

“软件正在吞噬世界。”
马克•安德森

“你无法管理你不衡量的东西。”
彼得•德鲁克

所有行业的组织都在拥抱软件，将其作为向客户交付价值的一种方式，我们也看到了软件驱动传统技术部门之外的创新和竞争力。

例如，银行不再以把金条藏在保险箱里而闻名:相反，金融行业的公司正在利用软件来争夺市场份额。银行正在使用创新的应用程序，让客户可以在几次滑动中完成大部分日常银行业务，从存入支票到在银行账户之间安全地转账。此外，银行本身可以通过多种方式改善服务，比如使用预测分析来检测欺诈交易。其他行业也在经历类似的变化:汽车现在是轮子上的计算机，甚至美国邮政服务也在进行大规模的DevOps转型。软件无处不在。

领导人必须拥抱这个新世界，否则就要退居二线。高德纳公司(Gartner Inc.)预测，到2020年，半数尚未改变团队能力的首席信息长(cio)将被逐出所在组织的领导团队。每一位优秀的领导者都知道，如果你不进行度量，你就无法改进它，因此度量软件开发过程和DevOps转换比以往任何时候都更加重要。

通过软件向业务交付价值需要过程和协调，通常跨越复杂系统的多个团队，并涉及开发和交付具有质量和弹性的软件。作为从业者和专业人士，我们知道软件开发和交付是一门越来越困难的艺术和实践，并且管理和改进任何过程或系统都需要洞察该系统。因此，度量对于创建一个有效的软件价值流是至关重要的。然而，精确测量并非易事。

测量DevOps。收集可以跨软件交付管道提供洞察的度量是困难的。数据必须是完整的、全面的和正确的，这样团队才能关联数据来驱动业务决策。对于许多组织来说，采用最新的最佳敏捷和DevOps工具使任务变得更加困难，因为组织内的多个记录保存系统在不断扩散。

跨组织软件交付数据的主要来源之一是年度DevOps状态报告https://devops-research.com/research.html）.²这个行业范围的调查提供了证据，证明软件交付在高绩效的技术驱动的组织中扮演着重要的角色。该报告概述了技术、过程和文化领域中有助于软件交付性能的关键能力，以及这些能力如何反过来促进关键结果，如员工福利、产品质量和组织性能。

在基于调查的研究的支持下，组织开始使用调查数据来衡量他们自己的DevOps的“准备程度”或“成熟度”。虽然这种类型的数据可以提供关于DevOps在团队和组织中可能扮演的潜在角色的有用视图，但危险在于，组织可能在不了解这种方法的局限性的情况下盲目应用调查结果。

另一方面，一些组织批评基于调查的数据批发，而是尝试单独使用系统数据来衡量或评估他们的DevOps准备程度或成熟度。这些基于存储在其存储库中的系统数据创建度量的组织，可能也不理解该方法的局限性。

通过理解这些限制，从业者和领导者可以更好地利用每种方法的好处。本文总结了度量软件价值流的两种独立但互补的方法，并分享了将两者合并的一些缺陷。这两种方法的定义如下:

• 调查数据。使用提供价值流整体和周期性视图的调查措施和技术。
• 系统数据。使用基于工具的数据，这些数据提供了价值流的连续视图，并且仅限于自动收集和关联的内容。

回到顶部

互补的方法

无论是系统数据还是调查数据都不能单独衡量现代软件交付管道的有效性。两者都是必需的。一种补充性的度量方法可以使组织对其开发和操作环境有一个更完整的了解，解决每种方法的关键差距，并为组织提供他们需要的信息，以便有竞争力地开发和交付软件。

作为一个类比，考虑一个制造商如何跟踪一个复杂的装配线的效率。在每个步骤上的仪器提供了关于每个阶段和跨端到端系统的流动速率和缺陷的数据。用装配线员工的调查数据来补充这一点，可以证明是非常有价值的，例如，发现一个新部署的协作机器人给员工带来的身体压力比机器人供应商承诺的要大。

在出现较高的不良率、较低的员工调查分数甚至是诉讼之前捕获这些信息是非常宝贵的。在本例中，调查数据为系统数据提供了领先指标，或者提供了系统数据可能根本不透露的见解。尽管装配线制造在度量标准和数据收集方面非常成熟，但在如何度量软件交付方面却严重缺乏行业共识。这意味着这种做法仍处于初级阶段。(请注意，这可能与这些领域本身的相对成熟有关:制造学科已经存在了很长时间，所以那些研究和测量它的人有几十年的时间来完善他们的手艺;相比之下，软件工程是一个相对年轻的领域，使得它的度量研究远远不够成熟。)因此，对于组织来说，理解他们可以和不能用哪种方法度量什么，以及他们必须采取什么步骤来获得对软件交付价值流的可见性是至关重要的。

利用作者在收集调查和系统数据方面的几十年的研究和经验，通过与数十个全球组织的数百名专家的深入讨论确认，这些组织将软件价值流度量作为其数字转换的关键部分，本文概述了理解您开发和交付软件的能力所需的度量。

回到顶部

现在就开始建立基线

为什么系统数据和调查数据都应该用来度量定义软件交付过程的价值流，这有几个原因。最重要的一点是，大多数组织似乎对他们的软件交付实践几乎没有可见性或可靠的度量。

一个组织越早开始测量，基线就越早建立起来，可以用来测量相对改进。对于小型组织来说，将系统度量作为初始基线是很容易的。例如，一个20人的初创公司可以只用Jira这样的问题跟踪器来测量MTTR(平均修复时间)。然而，一个大型组织将需要包括服务台和潜在的其他计划系统，以便识别基线，并且可能没有实现提供跨系统可见性的工具。我们建议立即开始基线收集，对于许多组织来说，这将意味着在努力捕获和关联系统数据的同时收集调查数据。

在缺乏完整的系统度量的情况下，全面的调查可以相对快速地提供系统的整体视图(例如，在几周内)。与此相比，基于系统的指标提供了系统的完全可见性。获取端到端系统数据可能是一个漫长的过程，因为您首先必须跨系统部署度量解决方案，然后确保跨系统集成到位，以便能够正确地关联数据。现代价值流度量使这变得更容易，但对于许多组织来说，这是一个多年的项目。

虽然尽早开始以获得系统数据的好处是很重要的，但部署调查数据提供了几乎直接的价值和基线信息来源。这对于将当前和未来的调查数据作为基线，以及一旦调查就位后将其与系统数据进行比较都是有价值的。因此，在继续构建基于系统的度量的同时，最好现在就用调查度量获取系统基线。

一旦你完全掌握了基于系统的指标，会发生什么?您可以继续使用基于调查的度量来增强和捕获特别适合于调查方法的附加数据。

---

领导人必须拥抱这个新世界，否则就要退居二线。高德纳公司(Gartner Inc.)预测，到2020年，半数尚未改变团队能力的首席信息长(cio)将被逐出所在组织的领导团队。

---

仍然有一些对软件交付很重要的度量，例如基于调查的度量，这些度量将会得到，而基于系统的度量可能会错过。此外，拥有两种类型的度量为三角测量提供了机会:如果您的调查度量提供的数据与来自您的系统的数据有很大的不同，这可能会突出系统中的差距。

有些人可能会说这样的差距只是“人们说谎”的区域，但如果所有与系统密切合作的人都在说谎，您可能会想要将他们的经验视为一个真正的数据点。如果您的工程师始终报告构建时间长，而系统数据报告的构建时间短，这可能是API中的配置错误吗?或者，基于系统的度量只捕获了数据的一部分?如果不始终从使用您的系统的专业人员那里收集见解，您将错过看到全貌的机会。本文的其余部分将概述每种度量类型的优缺点。

回到顶部

基于系统的指标

基于系统的度量通常是指来自组成端到端软件交付价值流的各种记录系统的数据。该数据的重要方面包括:

• 完整性。从特定的记录系统(如敏捷工具)捕获的数据是否完整到足以提供项目目标的可见性、度量和报告?例如，如果展示更快的上市时间是目标，那么是否捕获了足够多的历史数据来得出新产品和功能交付速度的趋势线?
• 全面性。是否在所有记录系统中捕获了足够的数据?例如，为了测量客户请求的上市时间，您可能需要来自客户/支持跟踪系统、路线图/需求系统、敏捷工具和部署工具链的数据。
• 的正确性。数据之间是否有足够的相关性?例如，如果一个支持票据和一个缺陷实际上是相同的项目，但是存在于两个不同的系统中，这两个系统是否应该以一种方式进行集成，以表明它们是相同的项目，或者您是否在这个场景中冒重复计算缺陷的风险?

回到顶部

系统数据优势

• 精度。只有系统生成的数据才能准确地显示分钟、秒和毫秒的响应时间。
• 连续的可见性。系统生成的数据特别适合连续/流数据和实时报告。您可以将它指向数据存储并收集所有内容，以便稍后进行有针对性的分析。
• 粒度。来自系统的数据可以提供非常细粒度的数据，允许您报告子系统和组件。这对于识别趋势和瓶颈是有用的，但是需要额外的努力来创建整个系统的更高层次的图像。数据越细，就需要更多的工作来描绘完整的图像。
• 可伸缩性。一旦实现了集成和可见性基础设施，就可以指向所有系统。这意味着解决方案可以从单个项目的可见性扩展到包含大量数据的数十个或数百个项目。

打个比方:建房子的时候，承包商可以用混凝土做地基;墙壁用木材/钉子/螺丝/干墙;电线和管道;外墙用砖;油漆/地毯完成;再加上厨房和浴室的任何材料。为了跟踪和监视进度，您可以内置监视来跟踪建筑的每个部分，并在房屋建造时安装它。一旦安装，这个基础设施(特定数据)的每一部分都可以以亚秒级的间隔(精度)持续提供报告和度量(连续数据)。然后，你可以将这些数据进行组合和关联(音量和比例)，以创建一幅关于你家里正在发生的事情的全景图。

回到顶部

系统数据挑战

• 捕获系统外部的行为。这可能是基于系统的数据中最重要但最容易被忽视的限制。一个例子是版本控制:你的系统只能告诉你里面有什么。正在做的工作有多少不被签入版本控制系统?常见的罪魁祸首包括系统配置和数据库配置脚本。
• 获得一个整体的视角。最终，系统级数据可以提供系统的相对完整的视图，但这需要完整的工具，以及跨度量的相关性和报告和可视化技术中的成熟度，以便团队能够理解系统状态。这是一项艰巨的任务，特别是在没有适当的工具和基础设施的情况下。此外，整体的观点应该包括过程的人的方面，例如部署和软件冲刺的难度，这对于理解工作的可持续性是很重要的。
• 捕捉系统中的漂移。如果系统堆栈的任何部分发生了变化，而数据收集器没有更新，则系统视图将不准确。请注意，这不是一流数据报告解决方案的特征，但它发生在一些商业系统和许多自行开发的解决方案中，因此这是值得注意的一个条件。
• 文化或感性的衡量。如果你想衡量文化的方方面面，这些都是感性的，应该通过调查来衡量。此外，来自系统数据库(如HR系统)的任何度量通常都不能很好地表示您试图收集的数据，并且将是滞后的指标。也就是说，他们只有在事情发生之后(比如某人离开了一个团队或组织)才能够衡量它。相反，调查方法可以让您及时测量对文化的感知，以便根据信息采取行动。

基于系统的度量是有用的，但是它们不能描绘出软件交付工作中正在发生的事情的完整图像。因此，强烈建议您使用补充的调查度量来增强您的度量。

回到顶部

基于调查的指标

基于调查的指标通常指的是来自调查的关于系统和人员(如文化)的数据。理想情况下，这些调查被发送给系统本身的工作人员以及对软件开发和交付系统非常熟悉的人员，也就是执行者。团队最好避免调查管理层和高管，因为正如Forrester最近的一项研究显示的那样，高管往往会高估组织的成熟度。^3.

该数据的重要方面包括:

• 凝聚力。基于调查的数据特别擅长提供系统的完整和整体视图。这是因为它可以捕获有关系统、流程和文化的信息。定期测量你的身体系统:每4到6个月。
• 的正确性。调查设计和测量是一门很好理解的学科，可以用来提供关于系统和文化的良好数据和见解。通过使用精心设计的调查，以及经过严格开发和测试的统计上有效和可靠的调查问题，组织可以对他们的调查数据有信心。

回到顶部

调查数据优势

• 准确性。当正确收集时，调查数据可以提供对系统、流程和文化的准确洞察。例如，您可以通过询问团队以自动或手动方式完成关键任务的频率来度量系统功能。当设计正确时，这提供了一个快速和准确的度量，可以用于基线和指导改进工作。
• 对系统的整体看法。调查特别擅长捕捉系统的整体图像，因为应答者提供的答案综合了与自动化、过程和文化相关的数据。
• 用系统数据进行三角测量。调查数据提供了系统的另一种视图，允许您在存在两种截然不同的视图时识别问题或错误。当这种情况发生时，不要自动忽略您的调查度量:经常会出现这样的情况:配置或系统行为的更改改变了系统数据的收集方式，而调查度量仍然是正确的，只有这两个度量中的增量才会引起对底层系统更改的注意。
• 捕获系统外部的行为。在讨论系统数据时，使用版本控制作为仅从系统收集的不完整数据的示例。通过使用调查，您可以更全面地了解系统内部和系统周围正在发生的情况。例如，是否存在绕过版本控制的情况?
• 与系统相关的文化或感性措施。调查数据可以让我们深入了解做工作:组织文化、工作满意度和倦怠是工作节奏可持续性和雇佣/保留的重要领先指标。研究表明，良好的组织文化推动软件交付和组织绩效，²而工作满意度会推动收入增长。¹所有技术经理和执行人员都应该优先考虑主动(通过调查数据)而不仅仅是被动地(通过人力资源数据库中的人员流动指标)监测这些数据。

让我们回到房子的类比。在使用系统数据时，您可以从正在报告的系统的每个部分获得详细信息。当通过调查问题询问人们时，这种程度的细节是不可能的(或不现实的)，但您可以非常快速和容易地获得对您的系统或其组件正在做什么的整体理解。例如，你可以可靠地确定房子是否处于良好的状态:任何人都可以报告房子是否着火，房间是否脏或有烟，或者事件是否造成了损害。收集这些数据比测量、关联和综合成百上千个数据点所需的时间要快得多。如果您的调查和系统测量不一致，您就有充分的理由开始调试系统。

回到顶部

调查数据的挑战

• 精度。虽然您可以查询实践者的大致内容，但是您不应该依赖他们获得详细或特定的信息。当您询问部署频率时，您的调查选项增加了日志规模:人们通常可以告诉您他们是按需部署软件、每周部署、每月部署、每季度部署还是每年部署。这些频率很容易通过基于系统的度量来确认(当可用时，尽管这是从系统中获得的一个重要的度量，因为它需要沿着部署管道从多个系统获得数据)。
• 数据的连续性。让人们频繁地填写调查是很累人的，调查疲劳是一个真正的问题。最好是通过调查来限制大数据收集的频率，比如每六个月左右。
• 体积。您收集的数据量与您收集数据的频率有关。经验告诉我们，调查应该保持在2025分钟(或更短)，以最大化参与和完成率。但也有明显的例外:亚马逊著名的开发人员调查是每年进行一次，花了大约一个小时才能完成，但工程师们对结果非常感兴趣并投入了精力，所以他们花了时间来完成调查。
• 紧张环境下的措施。如果管理层明确表示诚实是不安全的，或者结果会被用来惩罚团队，那么任何调查回应都是可疑的。引用已故的w·爱德华兹·戴明(W. Edwards Deming)的话:“每当存在恐惧时，你就会得到错误的数据。”但是，公平地说，基于系统的度量在不安全和可怕的环境中同样是可疑的，甚至可能更多。为什么?因为它只需要一个拥有根访问权限的人将一个无赖的度量放入系统中，而在同行评审或变更批准委员会(CAB)中疲惫的人就会错过它(正如我们这些看过cult经典电影《办公空间》的人可以证明的那样)。相反，要想使调查结果发生偏差，需要数人、数十人、数百人的参与。

回到顶部

结论

软件正在推动所有行业和世界各地组织的价值。为了帮助更快地交付价值、质量和可持续性，企业正在进行DevOps转型。为了帮助引导这些困难的转变，领导者必须理解技术过程。

这个过程可以通过一个好的度量程序来阐明，它允许团队成员、领导者和执行者理解技术和过程工作，计划计划，并跟踪进展，这样组织就可以向关键涉众演示投资的价值。基于系统的度量和基于调查的度量都有固有的局限性，但是通过在一个互补的度量程序中利用这两种类型的度量，组织可以更好地了解他们的软件交付价值链和DevOps转换工作。

相关文章
在queue.acm.org

在质量保证中采用DevOps实践
詹姆斯罗氏
http://queue.acm.org/detail.cfm?id=2540984

工程师统计数据
海因里希·哈特曼
http://queue.acm.org/detail.cfm?id=2903468

响应型企业:拥抱黑客方式
埃里克·梅杰和维克拉姆·卡普尔
http://queue.acm.org/detail.cfm?id=2685692

回到顶部

回到顶部

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

---

没有找到条目