DevOps的异化：当方法论沦为工具标签 | 行业深度

编者按：本文最初发表于九月。因其日常相关性，我们从档案中重新调出此文。

企业技术领域向来有寻求简单答案的传统。流程人员与技术人员的混杂相处，其下的深层分歧往往形成切实的对立。

业务利益相关方提出的要求常超出技术人员的合理预期，而层层叠叠的遗留后端技术又让IT部门始终在索求更多资源、人手、资金与工具。

使问题更趋复杂的是开发与运维业务技术者之间的脱节。一旦所有业务需求得到满足，开发者便将软件抛给运维部门，将部署与执行交由他人处理。

混乱随之而来。

然而，一种新的工作方式已日渐流行，它凸显了技术领域文化变革与转型努力相匹配的必要性。与其让技术部署彼此割裂，开发与运维可以在DevOps中实现对齐。通过这一方法论，利益相关方被绑定到单一项目上，创建软件的人也同时负责其部署。

据Puppet生态系统工程副总裁Nigel Kersten在接受CIO Dive采访时表示，DevOps大约在四五年前掀起过一波真正的浪潮，恰逢《凤凰项目》一书问世之际。

行业已超越早期采用者阶段而进入主流，正是在此过程中，采纳DevOps文化的挣扎浮出水面。

人们如此“渴望”了解如何真正实践DevOps，以至于他们跳过了步骤。

T.J. Randall

XebiaLabs客户成功副总裁

“我反复看到的情况是，企业采纳了工具，却没有采纳DevOps的流程变革或文化变革，”Kersten说。

对实施真正组织变革以落地DevOps的犹豫，催生了对供应商生态的潜在依赖。尽管DevOps最初是一种植根于草根采纳的方法论，但规模化成为障碍。这催生了对工具以简化和促进采纳的渴求，而在此过程中忽视了不可或缺的人员与流程原则。

“DevOps如今已被扭曲得面目全非，与它最初的样子相去甚远，”XebiaLabs客户成功副总裁T.J. Randall在接受CIO Dive采访时表示。最初那个“酷炫的小概念”聚焦于如何让企业拼图中截然对立的两面——开发与运维——更紧密地协作。

早期的DevOps部署侧重于迭代式、敏捷化的采纳。如果初期努力未见成效，企业愿意尝试其他方法。而现在，大多数客户问的是同样的问题：“直接告诉我们正确的做法是什么，”Randall说。

在XebiaLabs，Randall负责售后事务以及让DevOps在实践中真正运转。客户表现出对模板和工具的热切渴望，却对所需的文化变革关注甚少。

他说，人们如此“渴望”了解如何真正实践DevOps，以至于他们跳过了步骤。

客户不再尝试与迭代，而是直接索要答案，试图规避错误。但遵循预设路线图对解决深层的文化症结几乎无济于事。

问题在于，没有银弹，DevOps研究与评估有限责任公司（DORA）联合创始人兼首席技术官Jez Humble在给CIO Dive的邮件中表示。“你不能只靠购买工具或实施方法论；你必须付出艰辛努力去改进流程、发展能力，并摸索出适合你组织的做法。”

供应商的“救赎”

供应商已扛起DevOps的大旗，提供各种解决方案，以确保开发实践的简化路径易于被采纳。

围绕DevOps已形成庞大的供应商生态系统，覆盖开发技术栈的方方面面，包括：

领先的云服务提供商，如Amazon Web Services、Microsoft和Google Cloud，已将DevOps能力编织进其服务中。
来自Atlassian和Slack等提供商的协作平台，用于精简开发运营与实时沟通。
其他供应商专注于持续集成/持续交付（CI/CD）及DevOps自动化层面，如Puppet和XebiaLabs。
来自Splunk和Sumo Logic等供应商的分析驱动型工具，用于监控IT性能。

然而，DevOps市场低估了这一运动的本质。一些被重新包装的工具其真实性也令人对其有效性存疑。

“很多人给现有的软件开发工具贴上新的标签，往往是五年前还被称为‘敏捷’的现有工具，他们只是把DevOps加到了标题上，”Kersten说。

以Azure DevOps为例，上周它将Microsoft的Visual Studio Team Services产品重新命名，以适应一个更以开发者为中心的时代。

当不可避免的供应商浪潮袭来时，“我们看到很多对DevOps商业面不感兴趣的人开始带着厌恶情绪退避三舍，”Kersten说。

当运动进入主流，要保留其底层哲学便变得困难。到概念传入高管办公室时，其内在含义往往已被稀释。正如供应商可以篡改DevOps的含义，试图采纳它的企业同样可以。

“很多人给现有的软件开发工具贴上新的标签，往往是五年前还被称为‘敏捷’的现有工具，他们只是把DevOps加到了标题上。”

Nigel Kersten

Puppet生态系统工程副总裁

随着术语被炒作，其含义总有流失的风险，College Board副总裁兼首席数据官Jeff Olson在接受CIO Dive采访时表示。当组织创建DevOps部门或将运维部门更名为“DevOps”时，这种现象便可见一斑。

如果你在创建一个DevOps部门，你可能并未在实践DevOps，Olson说。“完全可能拥抱某事物的表象，却没有拥抱它的精髓。”

DevOps的精髓在于，开发代码的团队同时也运维该代码。任何将写代码的人与运维代码的人分开的做法，都会给写代码的人制造一种“道德风险”，因为“他们感受不到自己可能引入的任何问题所带来的痛苦，”Olson说。

与许多其他组织一样，负责高中先修课程考试和SAT考试的College Board，已致力于将其单体应用迁移至云端，并以更简单的方式重新架构软件。

那次迁移的一个关键原则是运用DevOps，将团队同时绑定到应用的开发与运维上。

College Board指派早期的“滩头”团队采纳其核心原则，其中就包括DevOps。每一次成功都推动了进一步的采纳，并帮助引导了技术工作方式的广泛变革。

自上而下的变革

企业对数字化转型的关注助长了DevOps之火。变革的意愿通常来自领导层，而非那些对技术效率低下感到不满的普通员工。

这种自上而下的视角让高管对DevOps实施抱持稍显乐观的看法；高管并不总能看见开发中难以克服的跨部门分歧。

C-suite依赖上行沟通，往往看到的是“经过过滤和美化的”采纳结果，而对“阻碍进展的瓶颈和破碎流程”并不知情，Puppet与Splunk联合发布的《2018年DevOps现状报告》如此指出。

在经历了中等程度DevOps转型的公司中——这占Puppet 3,000名受访者的80%——有三分之一在单一团队内拥有强大的DevOps文化，而报告在单一或多个部门内拥有强大文化的比例更低。

而在高演进水平的公司中，仅有19%将DevOps应用到了多个部门。

DevOps的采纳也可以来自组织内部，作为一种更草根的运动。经常出现的情况是“一些孤立的成功点，即个人或团队已经摸索出如何采纳这些实践，并在自己的影响力和领域范围内取得了真正了不起的成就，”Kersten说。“每个人都知道那些团队是谁。”

在组织内部创造成功的DevOps案例并非难事。但每个团队都认为自己的挑战独一无二，而看到其他团队的成功更可能引发的是怨恨情绪而非灵感闪现。有些技术挑战似乎就是难以逾越。

那是因为企业领导者正背负着巨大的技术负担。有了DevOps，你“永远不可能从零开始，”ISG合伙人兼EMEA数字战略与解决方案负责人Prashant Kelker在接受CIO Dive采访时表示。

“人人都说文化会把DevOps战略当早餐吃掉。我认为架构会把战略当早餐吃掉。你根本无法抹去30年的遗留。”

Prashant Kelker

ISG合伙人兼EMEA数字战略与解决方案负责人

在绿地讨论中，企业和供应商很容易赞美DevOps，因为用户可以从零开始构建一种全新的开发方式。

据Kersten所述，DevOps运动最初诞生时有两股早期采纳力量：一股来自在超大规模互联网公司工作的人——如Google、Twitter和Facebook——那里的软件团队和运维人员往往具备相当的开发能力。另一股则源于小型初创公司，它们有机会从零开始构建架构。

现实是，在经历了第一波早期采纳并进入更主流的案例后，如今大多数DevOps项目都是棕地性质的。

“人人都说文化会把DevOps战略当早餐吃掉。我认为架构会把战略当早餐吃掉，”Kelker说。“你根本无法抹去30年的遗留。”

这种挣扎加剧了供应商在DevOps实施中的角色。“DevOps听起来越来越像是一种责任”，而“越来越不关乎流程，不关乎文化，”Kelker说。

然而，推动采纳的力量来自结果。

精英级DevOps执行者每天进行多次部署，并且可以按需部署，根据DORA最近的一份报告显示。

同样的执行者从代码提交到生产环境运行所需时间不到一小时。相比之下，低绩效者需要一到六个月。中等绩效者至少需要一周。

DORA关于DevOps采纳者软件交付绩效的发现

软件交付绩效：	精英	高	中	低
组织部署代码的频率	按需	每小时一次到每天一次之间	每周一次到每月一次之间	每周一次到每月一次之间
从代码提交到生产运行所需时间	不到1小时	1天到1周之间	1周到1个月之间	1个月到6个月之间