DevOps推出已经15年了。但对于更传统的企业，他们的DevOps转型为何看似没完没了？
译自 Can Enterprise DevOps Ever Measure Up？，作者 Jennifer Riggins。
我们踏上称为DevOps的征程已有15年多。然而，许多组织在转型过程中似乎陷入僵局，比以往面临更多阻力。
部分问题在于，工程是一门科学，因此无法改进未能测量之物。对任何“转型”的测量本就困难重重。更为复杂的是，尽管名为DevOps，但它更专注于运营优化，而非开发者体验。Jennifer Riggins 是一位讲述技术文化故事的作家、记者、撰稿人和活动及播客主持人，她帮助分享技术文化碰撞的故事，并译介我们正在构建的技术的影响。
开发者生产力的测量并不简单。尽管媒体喜报DORA指标、SPACE框架与去年的DevEx指标，但实际应用类似工具的公司寥寥无几——微软与谷歌——大多数研究的发源地——以及Netflix、Spotify、领英、Atlassian与GitHub等大品牌。
这些传统企业也突然发现自己成了科技公司，却感到没有看到漫长DevOps隧道尽头的曙光。
当然，在炒作周期中，科技巨头作为早期采用者并不罕见。但DORA指标已经10岁了——无论评论员多么感兴趣，它们的采用范围似乎都不广。
是什么阻碍这些传统组织成为DevOps精英？我们与Uplevel产品副总裁Christina Forney对话，探讨真正的绊脚石。
在过去的10年里，Forney在产品和工程之间来回切换，一直致力于为开发者开发生产力工具。 在过去的5年里，她与企业客户密切合作，亲身见证了这种投入却看不到DevOps的回报。
她说，大多数组织都陷入了“痛苦三角”。这是Uplevel对三个关键人员健康组成部分测量的命名:
- 人员健康 - 我们的工作是否可持续？
- 承诺 - 我们是否有效地计划并兑现承诺？
- 交付 - 我们是否高效地交付优质解决方案？
“在这三件事中做好一两件非常容易。做好全部三件非常困难，”Forney说，“因为你可以按质交付完成承诺，但会拖垮你的团队。或者你的团队对你完成承诺很满意，但这需要非常非常长的时间，所以质量在受损。”
平衡两者相对简单，但三角支架需要三条腿才能站立。
痛苦三角，图片由Uplevel提供。
值得注意的是，阻碍企业转型的不是对DevOps目标的认识不足。毕竟，咨询行业投入了数百万美元来确保它得到解释。正如Forney所说:
“我们知道我们需要更快地交付。我们知道我们需要听取客户反馈。我们知道我们想要交付业务价值。我们知道我们应该进行客户研究。我们知道我们应该更频繁地发布和获取反馈，并且周期更短，降低拉取请求的复杂度，进入流式工作状态。但是我们也应该每天吃沙拉。并不是每个人都喜欢每天吃沙拉。仅仅因为你知道某事为真并不意味着这就是我们的实际行为方式。”
就DevOps来说，在这些传统组织面临的复杂环境中，它并非魔法治疗药。
大约15年前，有人决定将其称为DevOps转型，唤起了魔法少女萨布丽娜变装的画面——暗示它会快速、轻松又无痛。然而，尽管聘请了成千上万的DevOps顾问和教练，投入了数百万美元，大多数传统企业距离感觉“转型”却仍没有更近一步。他们真正感受到的只是在试图将圆钉塞进他们的方孔中时的无尽挫折。
“我看到越来越大的鸿沟在科技进步的公司和正在转型的公司之间，”Forney说。她指着 Meta、Alphabet、亚马逊(Amazon)和谷歌(Google)等科技巨头继续说道:“你有这些科技先进的公司引领潮流，最佳实践就是建立在他们的基础之上的。”
但是对于科技圈称为“传统组织”的完全不同。这些组织像是银行和汽车行业，起初并不擅长构建软件，但最近已经进化成完全依赖利用和构建软件的公司。
“这些大型组织在说，‘我们想要进行这些大规模的转型’，于是他们聘请了在谷歌有过类似经历的高管和领导者。他们进入公司后仍然事不成。”她继续说道，这导致“转型需要数年乃至更久的时间。”
而较小的组织可以更“敏捷”，并可以相对轻松地完成这些所谓的“转型”，如云迁移和打破孤岛实现跨组织协作。但这些老牌组织10年后仍在挣扎——就在DevOps曾经很酷的10年后。
是什么导致了这种惯性？Forney将其归因于技术债务和传统文化结构的组合。“就像如果你长时间不伸展身体，然后起床想试试，你不会立刻就能碰到脚趾，”她说。“这需要时间。你会看到许多领导层的流失。特别是在这些以文书工作、官僚主义和法规为特征的缓慢组织中。”
她反思一个财富100强客户时说:“这位领导者表达了极大的沮丧，我在努力，但没有任何成果”，尽管在其他地方曾成功转型过。所以他们知道潜力以及当DevOps被全面接纳时可以多好，但他们就是无法在这些存在高度监管、有50至100年历史的公司中使其奏效。
一些人认为过去18个月大型科技公司裁员可以成为这些传统组织吸引科技人才的大好机会，但同样，大型科技公司的视角可能不具备导航这些企业的能力。
部分问题在于，这些更传统的企业吸收了大型科技公司的开发者生产力指标，但他们的人员、流程以及通常的遗留技术不适合这几项测量。
在Forney看来，在顶尖组织中，开发者花费长达70%的时间编写和测试代码，其余时间用于开会和切换上下文。但当你检视这个异常高的70%时，她解释道，你然后不得不考虑他们花了多少时间仅仅是“保持系统运行”，或处理客户支持，或处于待命状态，相对于“他们花了多少时间创造新的价值”。她说这变成了一个“不断缩小的空间桶”。
尤其是在那些还没有完全迁移到云端、还没有完全从瀑布开发转向敏捷开发的老牌组织，她发现开发者经常关注错误的工作。或者他们在技术债务之上构建快速获胜的变通方法，而不是基于长期视角进行修复。
“我们看到组织花费大量时间进行计划，认为这些是组织的首要任务，但实际上发生了什么？开发人员是否真的花费了你预期的大部分时间来做这些事情？” Forney说，“大多数情况下，你会看到他们花费了全组织级别努力的5%时间来做这些最重要的事情。”
这种估计来自Uplevel自己的工具，它从各种来源拉取数据，并试图对组织范围内的时间实际花费进行建模。
“当你开始把整个工程组织看作是一个引擎，你就开始对工程系统进行工程化”，Forney解释说，这反过来让你能够关注整体工程的最大瓶颈。只有系统思维才能改进DevOps结果。
虽然看似流行的DORA指标和SPACE框架也是在团队层面及以上进行测量，但它们在更传统的企业场景中根本没有广泛采用。
“对于SPACE框架，最大挑战之一在于它不够精准和明确定义，”Forney表示。SPACE框架提出了25项开发者生产力指标，作为衡量各种社会技术因素的起点，但更注重如何为这些测量创造情境，而非应使用哪些指标。“因此，它给出了一个宽泛的开放方向，即应在此领域进行测量，但要弄清什么最适合你。特别是在大型组织中，人们不太清楚应测量什么。”
而且，正如我们之前采访谷歌的Nathen Harvey和Michelle Irvine时讨论过的，DORA指标远不止4项——更像50项，但每个人都执着于核心4项:部署频率、变更引导时间、变更失败率和故障交付恢复时间(此前称为平均恢复时间，即MTTR)。
“你需要测量的指标远不止4项，”Forney表示，这些指标让你“看到平衡人员健康或确保开发者有足够深度工作时间的叙事”。
她特别指出需要生成式组织文化——该文化植根于信息流动和信任。事实上，2023年DevOps状态报告在发现拥有生成式文化的团队表现提升30%的同时，生产力和工作满意度也大幅提高，开发者职业倦怠降低后，将生成式文化作为核心能力加入其中。
当然，尤其在典型的等级制传统部门，培养这种程度的沟通，然后衡量其增长变得更具挑战性。传统组织的系统思维通常依赖大量官僚主义和许多对话以及刻意的障碍。
DORA和SPACE难以采用的一个原因是，即使在这些大型科技公司，它们也都在以不同的方式定义和衡量DevOps的成功。
上个月，DX开发者体验平台的CEO Abi Noda分享了对17家公司开发者生产力指标的最新研究结果，所有这些公司最初都是作为科技公司设立的。绝大多数也没有使用DORA或SPACE。他写道:“每家公司都有自己量身定制的方法来衡量其工程组织的效率。”
17家不同科技公司的工程领导采访结果，图片由DX提供。
如果已经证明不存在能捕捉开发者生产力的单一指标，那么任何人怎么能衡量DevOps呢？
Forney说，Uplevel在工程组织层面检查来自多种渠道的元数据，包括:
- 工作日历
- Slack信息
- 代码提交
- JIRA和其他项目跟踪工具
- 事故响应工具和待命时间表
- CI/CD系统
- 同步沟通，如会议
她特别发现，现场对话通常是试图规避官僚主义的一种方式。
“你需要对时间的花费有一个真实的测量。然后你需要在计划和对业务的决策中使用这些数据，”Forney解释道。“这将在你的整个工程组织中产生一致性，以便工程领导者的决策支持实际发生的情况。”
组织现在正在制定自上而下的目标，但随后，她解释说，尤其是在这些传统企业中，“工程团队花费绝大部分时间仅仅是保持系统运行或者处理客户支持问题。可以说是各种各样仅仅使整个系统保持流动的事情，而没有实际为企业创造价值。”
这一切又回到了DevOps最初的目标，即在业务和工程之间建立一致性。2023年平台工程的飙升部分原因在于，它使业务能够理解通常难以理解但规模通常很大的工程成本中心的运转情况。
理解这种沟通流程以及阻碍干扰的好方法，可以启动你的DevOps自动化测量之旅。但工程调查也是另一个重要来源——谁比他们更了解导致瓶颈和打断他们的流状态的主要原因呢？
这些还应该包括生成性文化对话，以了解:“我们的协作方式是否真正帮助我们解决客户问题？”Forney说，通过将这种情绪与数据相结合，你可以开始释放开发者在真正解决实际问题时感受到的激情:
“如果开始测量和平衡工程组织的痛苦三角，你可以开始影响组织内正确的对话。”