DevOps的第一阶段已近尾声，下一阶段（卓越的工程）即将开启

Gartner 曾经在 2018 年预测：

到2022年，在启动 DevOps 转型计划的企业中，因组织学习和变革问题而无法达到预期的企业将达到 75% 之多。

DevOps代表了 IT 组织文化的变化，它通过在面向系统的方法中采用敏捷、精益的实践，专注于快速的IT服务交付。DevOps 强调人（和文化），并寻求改善运营和开发团队之间的协作。

DevOps 的第一阶段，局部自动化，已近尾声

随着数字化转型的浪潮，企业对于更高速度和更高灵活性运营有了更迫切的需求。这使得 DevOp 快速增长，并成为许多组织追求竞争优势的关键。追求持续软件更新的 DevOps 正在彻底改变企业进行软件开发的模式。这样做可以让软件产品团队跟上业务需求，并加快云和移动应用程序的更新速度。

然而，尽管 DevOps 似乎可以带来引人注目的业务优势，然而，如何实现这些所谓的优势却有高度的不确定性，这让很多组织难以从 DevOps 计划中获益。

在过去的五年中，在实施 DevOps 计划的很多企业中，通常是以「自动化」之名围绕 “CI / CD 流水线”进行相关的工具链投资。不幸的是，很多企业仅仅将很多（开源的或商用的）工具连接在一起，将已有的流程串联了在一起，这种串联甚至导致了过度自动化。同时，质量保证团队可能（又一次）开始尝试投资于上层回归测试的自动化用例编写。

这种级别的 DevOps 自动化可能会导致各种不良结果。我们可以把这一阶段的 DevOps 称为**「局部自动化」**。

这种局部自动化并非没有收益，它属于 「低树梢上的果实（low-hanging fruit ）」。当原有工程效能比较低的情况下，它的确可以为团队带来收益。

但是，很快会走到瓶颈，如下图所示。该图发表于2018年，我在 DevOpsDays 大会上的演讲。

当对上层自动化测试用例进行持续投入后，由于很多原因会导致投入产出比会下降。例如，

• 所需集成测试环境数量不足
• 集成测试环境的维护成本高
• 自动化测试用例运行太慢，无法提供快速反馈
• 自动化测试用例不稳定，无法提供有效且可靠的质量反馈
• 自动化测试用例所需数据的生产与维护困难

一旦类似事情增多，企业管理者会对 DevOps 方向的投资产生疑问。

事实上，组织通常应该在启动 DevOps 变革时充分考虑业务结果，并且，重要的是要认识到，「一步到位」的方法会带来巨大的失败风险。DevOps 涉及的变量太多，大型 IT 组织中很难使用这种方法。

DevOps 即将进入第二阶段：卓越的工程效能

此时，我们应该退后一步，重新审视过去的改进工作。很多企业仅仅是对现有流程进行了局部性优化，并未对整个工作过程中各种活动与协作进行优化。

组织学习和变革是让 DevOps 蓬勃发展，实现业务收益的关键。换句话说，与人相关的因素往往是最大的挑战，而不是技术。大型企业尤其如此。它们通常有大量的遗留系统与遗留技术。同时，也拥有大量的工程技术人员。

无论怎样，软件生产与运营仍是一个“大规模的知识工作者的手工协作行业”。

• 每个工程师每次生产的“零件”都各不相同，

• 却要将这些不同规格的“零件”持续不断地安装到正在运行的巨大软件机器上，

• 同时要确保这台复杂的手工打造的机器仍旧能持续正常工作

这需要卓越的工程实践体系，而不仅仅是所谓的“通过自动化工具，将流程串起来”那么简单。

卓越的工程体系，对“工程一致性”有着迫切的诉求，这一点在“大规模生产”的情况下是毋庸置疑的。

那么，我们如何才能快速具备体系化的工程实践呢？企业的数字化转型与研发效能该如何结合？别人家的研发效能实践以及平台，又是如何搭建的呢？

2021 年 10 月 15 日，我在北京与你一起讨论“工程一致性与效能度量”。

为了帮助大家找到对标企业，加速企业掌握研发效能体系快速升级之道，组委会携手了 70 余位来自eBay、微软、阿里、美团、滴滴、字节跳动、腾讯云等一线互联网技术专家及效能负责人为主的大咖讲师及出品人，将在 2021 卓越生产力工程大会（简称：EE大会）上为大家进行深入的技术解读与探讨交流，本届大会涉及“效能度量”、“DevOps”、“敏捷协作”、“代码整洁”、“架构演进”等多个热门技术领域。

本届大会日程现已上线，欢迎大家查看全部议题：