部分问题在于工程是一门科学，所以你无法改进无法衡量的东西。，衡量任何形式的“转型”都非常困难。更棘手的是，尽管名为 DevOps，但它实际上更侧重于优化运维，而非开发者体验。

衡量开发者的生产力并非易事。尽管新闻媒体热衷于报道DORA 指标、SPACE 框架和去年的DevEx 指标，但似乎只有微软和谷歌等少数公司真正使用了类似的指标，而大多数此类研究的起源也是一些知名公司，如Netflix、Spotify、LinkedIn、Atlassian和GitHub等。

那些身处更传统的企业（突然发现自己也变成了科技公司），感觉自己还没有看到漫长的 DevOps 隧道尽头的曙光。

当然，大型科技公司成为炒作周期中的早期采用者并不罕见，但 DORA 指标今年已经 10 岁了——无论我们这些评论家觉得它们多么有趣，它们似乎并没有被广泛采用。

是什么阻碍了这些传统企业成为DevOps精英企业？我们采访了Uplevel的产品副总裁Christina Forney，了解究竟是什么阻碍了它们。

过去十年，Forney一直在产品和工程之间摇摆不定，始终致力于开发面向开发人员的效率工具。最近五年，她专注于与企业客户密切合作，亲眼目睹了他们在DevOps方面的投入，但回报却微乎其微。

她表示，大多数组织都陷入了“痛苦三角”的困境。这是Uplevel对衡量员工健康三个关键要素的命名：

• 员工健康——我们是否在以可持续的方式开展工作？

• 承诺——我们的计划是否有效，我们的承诺是否履行？

• 交付——我们是否高效地交付了高质量的解决方案？

“这三件事，做其中一两件很容易，但要三件事都做好就非常难了，”Forney说，“因为你虽然可以保证质量，但你的团队会筋疲力尽。或者你的团队很高兴你履行了承诺，但这需要很长时间，所以质量就下降了。”

保持两个物体的平衡很容易，但凳子需要三条腿才能站立。

疼痛三角模型，由 Uplevel 提供

值得注意的是，阻碍企业发展的并非是对DevOps目标缺乏理解。毕竟，有一个价值数百万美元的咨询行业致力于确保DevOps得到充分解释。正如Forney所说：

“我们知道需要加快发布速度，我们知道需要倾听客户反馈，我们知道想要创造商业价值，我们知道应该进行客户调研，我们知道应该更频繁地发布产品、收集反馈、缩短开发周期、降低拉取请求的复杂性，并进入高效工作流程，我们知道每天都应该吃沙拉，并非每个人都喜欢每天吃沙拉……所以即使你知道某件事是正确的，也不意味着我们就会真的去做。”

只是在这些传统组织的复杂环境下，DevOps 并不是万能的灵丹妙药。

大约15年前，有人将其称为DevOps转型，让人联想到少女巫师萨布丽娜旋转换装的场景（暗示转型将快速、轻松、无痛）。然而，尽管企业聘请了数千名DevOps顾问和教练，投入了数百万美元，大多数传统企业仍然感觉不到“转型”，他们真正感受到的只是试图将圆钉硬塞进方孔中时的挫败感。

“我看到科技领先型公司和正在经历转型期的公司之间的鸿沟越来越大，”Forney说道。她以科技巨头Meta、Alphabet、亚马逊和谷歌为例，继续说道：“这些科技领先型公司引领着潮流，最佳实践措施也是建立在它们的基础之上的。”

但对于科技界所谓的“传统型企业”来说，情况则截然不同。例如银行业和汽车行业，它们最初在软件开发方面并未取得成功，但近年来已发展成为完全依赖于软件开发和利用的公司。

“这些大型组织说，‘我们想要进行重大转型’，他们聘请了那些在谷歌等公司有过类似经历的高管和领导者。他们把这些人招进来，却仍然一事无成，”她继续说道，“这导致转型需要年复一年、年复一年、年复一年地进行。”

虽然规模较小的组织可以更加“敏捷”，并且能够相对轻松地完成这些所谓的“转型”，例如云迁移和打破孤岛以实现跨组织协作，但这些老牌组织仍在苦苦挣扎——尽管 DevOps 已经流行了 10 年。

这种惰性究竟源于何处？Forney认为，这是技术债务和根深蒂固的传统文化共同作用的结果。“就像如果你很久不做伸展运动，突然想起来做，你不可能马上就能摸到脚趾一样，”她说。“这需要时间。而且你会发现领导层更迭频繁，尤其是在那些以文书工作、官僚主义和繁文缛节著称的低效组织中。”

她回忆起一位财富100强客户时说：“这位领导非常沮丧地表示，‘我一直在努力，但什么都做不成’”，尽管他之前在其他地方成功转型过。所以他们知道DevOps的潜力，也知道全面采用DevOps能带来多大的好处，但他们就是无法在这些监管严格的、拥有50年甚至100年历史的公司里成功实施DevOps。

有人认为，过去 18 个月大型科技公司的裁员对于这些传统企业来说，可能是一个吸引科技人才的大好机会，但是，大型科技公司的视角可能并不适合驾驭这些企业。

部分原因是，这些较为传统的企业被大型科技公司的开发者生产力指标所吸引，但他们的人员、流程以及通常的遗留技术并不适合这些少数几个衡量标准。

根据Forney的计算，在最顶尖的组织中，开发人员高达 70% 的时间都花在编写和测试代码上，其余时间则充斥着会议和工作切换。但她解释说，当你仔细审视这高达 70% 的时间时，你还必须考虑他们有多少时间仅仅用于“维持系统运转”、处理客户支持或待命，而“他们又有多少时间真正用于创造新价值”。她指出，这部分时间就像一个“不断缩小的空间”。

她发现，尤其是在那些尚未完全迁移到云端，也尚未彻底从瀑布式开发转向敏捷开发的老牌企业中，开发人员常常把精力放在错误的工作上。或者，他们为了快速解决问题，在技术债务的基础上构建权宜之计，而不是着眼于长远发展进行修复。

“我们看到很多组织花费大量时间进行规划，并认为这些是组织中的首要任务，但实际上情况如何呢？开发人员真的把他们预期的大部分时间都花在了这些事情上吗？”Forney说，“通常情况下，你会发现他们只把整个组织投入到这些最重要事情上的时间占到了5%左右。”

该估算来自 Uplevel 自己的工具，该工具从不同的来源提取数据，并试图模拟时间在整个组织中实际是如何花费的。

“当你开始把整个工程组织视为一台引擎时，你就开始构建工程系统了，”Forney解释说，这反过来又能让你专注于解决最大的整体工程瓶颈。只有系统思维才能改善DevOps的成果。

虽然看似流行的 DORA 指标和 SPACE 框架也是在团队及以上级别进行衡量的，但它们在更传统的企业领域并没有得到广泛采用。

“SPACE最大的挑战之一在于它的定义不够清晰明确，”Forney说道。SPACE框架提出了25项开发者生产力指标，作为衡量各种社会技术因素的起点，但它更侧重于如何围绕这些指标构建情境，而不是具体应该使用哪些指标。“因此，它留下了一个宽泛的开放式方向：你应该衡量这个领域的某些方面，但要自己去摸索最适合你的方法。尤其是在大型组织中，人们往往不清楚应该衡量什么。”

正如我们之前在对谷歌的 Nathen Harvey 和 Michelle Irvine 的采访中讨论的那样，DORA 指标不止4个，而是有 50 个左右，但每个人都只关注核心的四个指标：部署频率、变更提前期、变更失败率和交付失败恢复时间（以前称为平均恢复时间，或 MTTR）。

“你需要衡量的指标远不止四个，”Forney说，这样你才能“了解平衡员工健康或确保开发人员有足够的深度工作时间的情况”。

她特别强调了以信息流动和信任为基础，构建积极主动的组织文化的重要性。事实上，《2023 年 DevOps 现状报告》将积极主动的组织文化列为核心能力，因为该报告发现，拥有积极主动组织文化的团队绩效提升了 30%，生产力和工作满意度也显著提高，开发人员的职业倦怠感则有所降低。

当然，尤其是在等级森严、传统化的行业中，培养这种程度的沟通并衡量其发展更具挑战性。传统组织的系统思维往往依赖于繁琐的官僚程序、大量的对话以及人为设置的障碍。

DORA 和 SPACE 难以推广的一个原因是，即使在这些大型科技公司中，他们对 DevOps 成功的定义和衡量方式也各不相同。

DX开发者体验平台首席执行官Abi Noda分享了针对17家公司（均为科技公司）开发者生产力指标的最新研究成果。其中绝大多数公司都没有使用DORA或SPACE等工具。他写道：“每家公司都有自己量身定制的方法来衡量其工程团队的效率。”

17 家科技公司（Amplitude、Atlassian、Chime、DoorDash、Etsy、GoodRX、Google、Intercom、Lattice、LinkedIn、Microsoft、Notion、Peloton、Postman、Spotify、Stripe、Uber）的开发者生产力指标飞涨

DX 提供了对 17 家不同科技公司工程领导层的采访结果

如果已经证明没有任何单一指标可以衡量开发人员的生产力，那么人们又该如何衡量 DevOps 呢？

Forney 表示，会检查工程组织层面的元数据，其中不包含任何个人或团队的隐私或特定信息，这些元数据来自多个来源，包括：

• 工作日历

• Slack消息

• 代码提交

• JIRA和其他项目跟踪工具

• 事件响应工具和值班安排

• CI/CD 系统

• 同步沟通，例如会议

她尤其发现，实时对话通常是绕过官僚主义的一种方式。

“你需要准确衡量时间是如何被利用的。然后，你需要将这些数据运用到你的规划和业务决策中，”福尼解释说。“这将有助于在整个工程组织内达成共识，使工程领导者能够根据实际情况做出决策。”

她解释说，如今企业都在自上而下地制定目标，但尤其是在这些传统企业中，“工程团队的大部分时间都花在维持系统正常运行或处理客户支持问题上。诸如此类的事情，只是为了让整个系统运转起来，但实际上并没有为企业创造价值。”

这一切最终都回归到DevOps的初衷：实现业务与工程的协同一致。

平台工程在2023年的迅猛发展，部分原因在于它为业务部门提供了一种了解工程成本中心（这个中心通常晦涩难懂，但成本却很高）运作情况的途径。

了解这种沟通流程，以及阻碍干扰的因素，——是开启自动化DevOps评估之旅的良好开端。但工程师调查是另一个重要的信息来源：还有谁比他们更了解造成瓶颈和破坏工作流程状态的最主要原因呢？

这些还应包括开展启发性的文化对话，以了解：“我们的协作方式是否真正有助于我们解决客户问题？” Forney 表示，通过将这种感受与数据相结合，可以开始激发开发人员在实际解决真实问题时所感受到的那种兴奋感：

“有一些已知的模式和行为，如果你开始衡量这些模式和行为，并尝试帮助平衡我们工程组织的‘痛苦三角’，你就可以开始影响整个组织内正确的对话。”