与 Alison Polton-Simon 的问答：DevOpsDays 新西兰大会上的演讲“重要的度量”

Alison Polton-Simon 是 ThoughtWorks 的一名软件工程师，曾任 GoCD Analytics 团队成员，在团队中她所参与的工作有助于开发人员、运维人员和业务利益相关人员做出更智能的、数据驱动的决策。

Polton-Simon 将于十月在 DevOpsDays 新西兰大会上做演讲，题目是“重要的度量”（Metrics That Matter）。她将在演讲中分享自己对一些用于企业间的关键度量的看法，这些度量已被证明对于帮助企业理解并改进持续交付过程是更为有效的。

InfoQ 采访了 Polton-Simon，一窥她当前感兴趣的领域，以及她认为应该得以测量的度量。

InfoQ:您能向我们介绍一下您当前在 DevOps 领域的角色，以及您所感兴趣的方面吗？

Alison Polton-Simon:当前我在 ThoughtWorks 工作，任软件工程师和全球软件顾问。我在过去的五个月中所参与的团队工作，是将一家应用性能监控企业迁移到新的构建架构上。对于从头开始设计一个新系统而言，将已有的单体代码库和构建系统移植到一系列更为独立的仓储中，业已成为一个很大的机会，优点在于我们已经理解了其中的大多数更为复杂的潜在边缘案例。

从技术和实践看，我很高兴看到向架构即代码发展的趋势。在我当前工作的项目上，团队已经使用 DSL 配置了我们所有的流水线，这使得我们可以获取更为传统的软件开发中所具有的可读性和可重用性的优点。我们也对大部分的构建代理做了容器化，这确保了更可靠的构建环境，并简化了开发人员设置与构建服务器一致的本地测试环境。

鉴于我们的客户就是和我们日复一日一起一起工作的开发人员，所以我可以直接了解更改的影响情况，这是非常有益的。

InfoQ:您将在 DevOpsDays 新西兰大会上以“重要的度量”为题目做演讲。您能向我们预先透露一下报告的内容吗，以及您是如何选取特定的度量集的？

Polton-Simon：在做当前的项目之前，我曾帮助一家投资企业使用 ThoughtWork 的 GoCD 持续交付服务器。我们当时的目标是为团队开发一种可深入地洞察如何改进自身构建和交付过程的分析服务。考虑到这是一次绿地（Greenfiled）投资，我们在一开始，是通过与一定范围内的持续交付参与者和顾问交谈，了解他们认为对于理解自身过程有价值的度量。我要做的演讲，综合了我们这些会谈中谈及的共同话题和陷阱。

InfoQ: 我们应该观察哪些类型的度量？

Polton-Simon：软件开发的主要目标应是可靠地交付价值给客户。无论所处的角色，每个人都有对日常过程中一些低效事情感到沮丧的经历。

对于开发人员，这通常是提交和成功构建之间的长循环时间。

对于处于 DevOps 角色的个体，挑战可能会出现在部署应用中。我们所选择的度量，例如循环时间、平均恢复时间等，量化了这些痛苦点，使得团队可以追踪并理解自身的成长过程。

InfoQ: 度量采集团队的本地场景将在何种程度上影响这些度量的价值？

Polton-Simon：在选取度量时，我们瞄准的是那些解决软件开发中全局关注问题的度量，并且对于每个团队成员应该是感觉相关的。但这并非说团队的本地场景是完全无关的。

对于本地场景会影响度量值，一个最为显著方式就是，度量是否是在一种对度量的有效性缺乏信心的环境中采集的，或者是在一种个体或小组采集并分析度量的环境中采集的。

对于一个认为度量是个人相关的团队，或者一个对企业的领导具有信心的团队，它们确认为不可或缺的度量，在另一个团队看来可能是无关紧要的，甚至是有毒的。

这里给出一个经典的例子。有的团队认为交付速度是个人相关的，该度量可在每次回顾时反映出团队是如何增加交付速度的。而有一些团队认为这一度量是无用的，只是会膨胀对团队自身的估计，并营造出一种速度增加的表象。

考虑到由度量驱动的方法在消除系统恐惧和激发游戏上的潜力，一个新项目在早期阶段，最重要的是投入精力构建信任和共同使命。

InfoQ:如何使通常是自顶向下的传统 KPI 和企业层面的度量适用于您所描述的场景？

Polton-Simon：构建团队层面的度量，应该看齐企业的目标和 KPI。在企业中具有冲突度量的个体，将会发现自身受到由激烈竞争所导致的紧张氛围所困扰。企业 KPI 应为企业的优先事宜提供高层的指引，而团队层面的指示可用于驱动日常工作。

InfoQ: 在优化本地和企业有效性上，您是否看到其它一些围绕交付和其他业务度量的协作例子？

Polton-Simon：作为顾问，我们工作的关键通常在于如何对齐本地和企业度量。我们发现了一个能成功识别改进本地和企业有效性机会的方法，就是让一些团队一起工作，并将他们各自的工作路径映射到生产环境。

在此操作中，我们将过程中的各个步骤标注上处理时间、等待时间和痛点等信息。通过强调这三个部分，团队可以识别自身的本地增长区域（例如，片状或长时间运行测试等问题），以及可改进企业有效性的领域（由于对各自期望的错误理解，缺乏跨团队协作可导致大量的重做工作）。

进而，团队和企业可识别他们的最大痛点，并找出在各个企业层面上解决这些痛点的行动。这一操作有利于推进在企业间分享理解，并授权团队去解决自身的首要关注。

InfoQ: 成功的度量是更为主观和定性的，例如客户幸福度或体验。您对此有何建议？

Polton-Simon：对于这一类度量的处理，我认为存在两种附加方法。一种是使用传统的方法，例如 Net Promoter Score 。这是一直以来长期在业务中使用的方法，让用户去评定他们会在何种程度上向朋友推荐指定的产品或服务。

另一个方法使用了稍偏离传统的测量方法，可能也是更定性的方法，去了解企业的性能。关键在于，如何量身打造第二种方法以适合企业的价值。

Zappos 是我记忆深刻的一个离奇案例。它标榜提供优秀的客户服务，并为服务于客户的最大利益而提供长时间的支持电话。一个广为报道的案例就是，它的一个客户服务代表花费近 11 小时的电话时间与一个客户交流，为客户提供购买帮助，期间还讨论了假期和儿时经历。它的原则就是，不断超越，为客户留下深刻印象。

追踪这样的新颖度量，有助于强化那些使你在竞争者中脱颖而出的东西。

InfoQ: 就测量和审核过程激发 DevOps 文化的协作方面，您是否可以分享一些好的案例？

Polton-Simon：对于任何一家企业，如何创立文化改进都是最大的挑战之一，但协作通常可在团队鉴别测量度量的过程中增进。

我在工作中曾面对这样的一家企业，该企业中的团队很少交流，大量的回归测试套件（需要运行 14 小时）是不可靠的，并且一些测试总是失败。雇员习惯于忽略测试的输出，他们放弃了对流水线过程一路绿灯的希望。

为解决这些技术和文化上的问题，ThoughtWorks 团队开展了为期三天的研讨会，意在鉴别要改进的最高优先级领域，并为团队提供了可与他人分享过程和痛点的机会。

下一步，团队选取他们可立即做的更改，解决他们所发现的挑战。这些过程还为跨团队协作提供了机会，使得团队可以选取一系列高层次的度量，并发现可跨越团队界限的改进领域。

随后的数月中，测试已经一路绿灯，从提交到部署更改的时间也已从 18 天改进为 10 天。我们还看到，团队增进了构建流水线状态的兴趣，并在团队间具有更多的交流，这使得团队在失败真正发生时，可以恢复到健康状态。团队继续发现那些可以取得进展以降低从提交到部署时间的新领域。

这就是说，度量并非银子弹，也非万能药。协作和文化上的真正改进，需要很长的时间，并需要大量的投资和努力。

InfoQ: 对于那些处于这一旅程的早期阶段并想要着手测量度量的人，您有哪些建议？

Polton-Simon：我会鼓励这些对测量过程有兴趣的人去采取协作和迭代的方法。

通常在开始一个新项目时，我们在一开始时会让团队将交付代码过程从提交映射到生产环境。在此过程中，我们会询问所有的痛点和摩擦领域。对于一些团队，最大的痛苦会很早进入，表现为片状的构建和不可靠的流水线。对于另一些团队，问题会以长时间运行集成测试的形式，或是频繁失败部署的形式，在过程的稍后阶段出现。

一旦团队已经列出自身的痛点，我们将从中推选出一个感觉上最为紧迫的，确定一个量化该痛点的方法，进而给出一些可能会改进该痛点的快速试验。

我会鼓励那些想要测量这些度量的团队去采取类似的过程。我也会鼓励他们对习惯于迭代的方式。如果我们选取的度量在数个 Sprint 后看上去不再相关，重复上述过程，并尝试一些新的度量。

当持续改进是为解决最大痛点而量身打造时，或是被真正地采纳时，它无疑会最具影响。

InfoQ: 对于 DevOpsDays 新西兰大会，您最期待的是什么？

Polton-Simon： 我十分期待能参与 DevOpsDays 新西兰社区，并从中学习。DevOpsDays 是一个能从具有相似想法的参与者中学习的很好机会，并且大家能比较在不同技术栈、行业和企业的成长阶段中解决类似问题的方法。我参加了上一次在科罗拉多州丹佛市举行的 DevOpsDays，印象深刻的是激动人心的演讲和感觉很好的社区，我确信这次大会也将会取得同样的成功。就个人而言，我也非常期待能游览奥克兰市，这是我首次来新西兰。

DevOpsDayz 新西兰大会将于 10 月 3 日至 4 日期间在奥克兰市举行。大会期间，Alison Polton-Simon 等多位国际和本地演讲者将就文化和技术话题展开分享。

查看英文原文： Q&A with Alison Polton-Simon on Her 'Metrics That Matter’ Talk for DevOpsDays NZ