扯淡的DevOps，我们开发根本不想做运维！

最初考虑引用“ DevOps 已死，平台工程才是未来”作为标题，但这样的表达可能太过于绝对。最终，决定用了“扯淡的”这个词来描述 DevOps，但这并不是一种文明的表达方式。 文章旨在重新审视 DevOps 和平台工程，将分别探讨 DevOps 和平台工程的概念，并重点分析平台工程所倡导的一些核心内容。同时，希望通过本文能够给从事内部开发平台（IDP）工作的同学们带来一些思考。

DevOps的目标

在 2009 年，DevOps 这一概念就被提出，重点强调团队协作、自动化工具和流程改进，旨在提高软件开发和部署的速度和质量。然而，提出之后有近 15 年了，发现这一方法并未如预期完美实现了目标。在我们公司内部，我们也会发现软件交付成本仍然还是较高，从部署发布工具的角度来看，无论是 J-ONE、JDOS 还是目前的行云部署，对于研发人员日常部署发布仍存在一定的成本，但这种现象好像不仅仅是工具层面的问题。

DevOps 本身是一种理念，强调团队协作，使开发团队和运维团队能够紧密合作。尽管强调了自动化和工具的重要性，但它并没有明确指出具体的发展方向。因此，出现了平台工程（Platform Engineering）这一理念。虽然最早是谁提出的已无法考证，但在 2022 年 7 月份，一条Twitter上的消息“DevOps is dead, long live Platform Engineering” 在国内外的 DevOps 圈子迅速传播开来，并得到了广泛的回应。

平台工程（Platform Engineering）是一种新的运维理念，强调内部开发平台应该提供技术研发人员自服务的能力。其核心观点之一是通过屏蔽基础设施的复杂性，为技术研发人员提供灵活的工具链和工作流程。这样，可以利用平台的基本能力，自主解决问题，无需依赖平台层的参与，使得开发团队能够更加高效地开展工作，提高软件交付的速度和质量。

平台工程的定义

平台工程是设计和构建工具链和工作流的学科，可在云原生时代为软件工程组织提供自助服务功能。平台工程师提供的集成产品通常被称为“内部开发人员平台”，涵盖了应用程序整个生命周期的运营需求。 --定义来自 platformengineering.org （关于平台工程的定义较多，但大部分意思较一致：主要是倡导自助服务减少底层基础支撑工具的复杂性和不确定性，减化工作流程，减少最终用户在使用过程中的认知成本，从而改善了最终用户的体验，和提高生产效率）

平台工程和 DevOps 都是软件开发和运维领域的概念，它们共同关注提高软件开发和部署的效率和质量，但它们的重点和方法有所不同。平台工程着重于构建可重用的平台架构，提供场景化的能力，提供自助化的体验。而 DevOps 则侧重于团队协作、自动化工具和流程改进，以提高软件开发和部署的速度和质量。

在 2023 年，Gartner 已将平台工程列为顶级战略趋势之一。最近发布的 2024 年十大技术趋势中，Gartner 再次提到了平台工程，并且将其提升了一个级别，这表明平台工程在业界的认可度得到进一步提升。

在过去的几年中，人们一直追求 DevOps，并从能力成熟度的角度推动提升。然而，对于投入和产出的量化评估却相对模糊。平台工程提出了一些衡量其价值产出的方式，包括自助式体验和尽可能减少人力投入。通过致力于建设自助化、场景化的能力，提供有价值的平台。

回到本文的标题，我们来谈谈为什么开发人员不愿意承担运维的工作。

开发为什么不想做运维

DevOps 强调团队协作，并鼓励开发人员承担一定的运维工作。然而，在现实中，为什么这一点往往难以实现？我认为主要有以下几个方面的理由：

以上可能是开发人员不太愿意承担运维工作的一些可能的理由。我接下来看下运维的本质是什么？

运维工作的本质

运维工作重点是保障系统的安全和稳定运行。它不仅需要 7x24小时监控线上环境的稳定性，还需要处理各种日常的运维任务。这些任务可能包括资源管理、日常巡检、故障排查与修复、工单处理等。

最近，一些大厂经历了重大的线上稳定性故障，这给业界带来了很大的关注。

最近的这些线上故障对整个行业产生了极大的警示，所有企业都一样面临着线上稳定性挑战。

带来的一些思考

安全生产，警钟长鸣：面对线上问题，我们绝不能单纯地追求速度和省事，对于任何线上操作，都必须保持敬畏之心。

安全生产，人人有责：无论是开发人员编写的错误代码逻辑，还是运维人员错误的升级操作，最终都有可能给公司带来无法估量的损失。

生产环境的稳定性，最难得不是技术，而是依赖无数细节的落地，稳定性的保障需要大量的投入，然而这个事最大的问题就是，难被认可，以及怎么来衡量做的好呢？网上曾经一个段子，大概意思就是“那些代码写的没有 Bug 的人，往往默默无闻，甚至可能被干掉；相反，那些经常写 Bug 的同学，因为日常忙碌于修复 Bug ，反而能风生水起”，当然，开发不愿意承担运维的原因，确实是因为线上稳定性的责任重大，同时运维工作的负担也很重，并且缺乏适用的工具和平台来支持。

然而，平台工程被提出，作为一种新的理念，旨在解决这些问题，并提高软件交付流程。接下来聊一聊，与 DevOps 相比【平台工程】的成功关键因素有哪些。

平台工程成功的关键因素

如何在公司内推动平台工程

作为一个相对新颖的概念，平台工程已连续两年获得 Gartner 的认可，将其推向了我们不得不关注的重要地位。要在公司内推动平台工程，我认为需明确以下几个方面：

综上，从全局的维度讨论了如何在内部推动平台工程。接下来，我们探讨一下平台工程下的工具应具备哪些特质：

平台工程下建设什么样的工具

个人认为，相较于面向消费者的产品，内部工具更为重要。因为消费者产品用户有选择权，但内部人员并无太多选择余地，最多只是抱怨几句，却仍需继续使用。要打造令内部人员满意的工具，个人觉得至少需要以下关键属性：

平台工程下的内部开发团队

在平台工程背景下，内开发团队可能会有以下共性情况，例如这四方面：

个人觉得内部平台团队应要坚持做以下几件事：

如何衡量平台工程的成功呢？

主要在于要从一些指标维度进行衡量评估。如果一个平台或者工具，在做了一年后，对于自身的使用情况一无所知，而仅专注在做功能开发，那么怎么来衡量这个平台带来的价值呢？我觉得最关键的在于要寻找一个关键的指标，这个指标可以是业务维度，也可以是产品维度或组织维度，我抛出几个维度仅供参考：

平台工程的未来

针对平台工程的未来发展，目前国内外的情况如下：

国外的情况

当前，国外各大厂像Google、Spotify、Netflix、Walmart等一大批公司均在积极推动平台工程在企业内部的实施，11月份，CNCF正式发布了平台工程的能力成熟度模型，分别从5个维度上划分了4个级别，CNCF发布的成熟度模型维度比较粗粒度，主要从团队/人员、平台应用、用户体验、自服务以及平台迭代等方面进行评估，并未对平台功能维度进行详细划分。

国内的情况

在国内，目前平台工程也逐渐受到大家的关注，特别是原来就负责DevOps工具相关的人员，更加关注平台工程带来的新的概念和倡导方向。中国信息通信研究院也正在组织行业内的专家，共同梳理一份符合国内现状的平台工程能力要求标准，会明确平台工程功能维度。我目前也参与了部分工作，如有对此感兴趣的同事，欢迎联系我一同参与。

最后，放个一个Gartner预测的数据，Gartner预测，到 2026 年， 80% 的软件工程组织将建立平台团队，其中 75% 将包含开发者自助服务门户。80%的软件工程组织将建立平台团队作为可重复使用的服务、组件和工具的内部提供者，用于应用程序交付。

可见，平台工程不仅仅是一种趋势，它是软件交付的未来

作者：京东零售 井亮亮

来源：京东云开发者社区 转载请注明来源