DevOps，我们开发者根本就不想做运维！

最初考虑以“DevOps已死，平台工程是未来”为标题，但这样的表达可能过于绝对。 最终，决定用“”这个词来形容DevOps，但这不是一种文明的说法。 本文旨在重新审视DevOps和平台工程，并将分别分析DevOps和平台工程的概念，并重点介绍平台工程倡导的一些核心要素。 同时，希望这篇文章能给从事内部开发平台（IDP）工作的同学们带来一些思考。

DevOps本身就是一种强调团队合作的理念，它使开发和运营团队能够密切合作。 虽然强调了自动化和工具的重要性，但它并没有明确指出该去哪里。 因此，平台工程的概念。 虽然无法核实是谁最先提出的，但在2022年7月，一条推特消息“DevOps已死，平台工程万岁”迅速在国内外DevOps圈子里传播开来，得到了广泛的反响。

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

平台工程是设计和构建工具链和工作流的学科，这些工具链和工作流为云原生时代的软件工程组织提供自助服务功能。 平台工程师提供集成产品，通常称为“内部开发人员平台”，可满足应用程序整个生命周期的运营需求。 - 平台工程的定义org（平台工程的定义有很多，但大多都有相同的含义：主要是提倡自助服务，以降低底层基础支持工具的复杂性和不确定性，减少工作流程，降低最终用户在使用过程中的认知成本，从而改善最终用户体验，提高生产力）。

2023 年，Gartner 将平台工程列为首要战略趋势之一。 在最近发布的《2024 年十大技术趋势》中，Gartner 再次提到了平台工程，并将其提升了一个档次，这表明行业对平台工程的认可度进一步提高。

在过去的几年里，DevOps一直从能力成熟度的角度出发，并被推动。 然而，对投入和产出的定量评估相对模糊。 平台工程提出了多种方法来衡量其价值输出，包括自助服务体验和最大限度地减少人工投入。 通过致力于构建自助服务和基于场景的能力，它提供了一个有价值的平台。

回到本文的标题，我们来谈谈为什么开发者不愿意承担运营。

DevOps强调团队合作，并鼓励开发人员承担一些运营工作。 然而，在现实中，为什么这往往难以实现？ 我认为主要有几个原因：

专注于核心开发任务：开发人员往往更倾向于日常的软件开发任务，他们可能没有太多的时间和精力去关注其他事情，否则会影响日常任务的工作进度。

不熟悉或不感兴趣：开发人员可能没有足够的经验来处理操作，或者他们可能对操作不感兴趣，导致操作缺乏动力。

操作和维护的锅太重太复杂：运维涉及生产环境，责任范围和影响大。 任何操作故障都可能导致系统故障、服务中断或数据丢失等严重后果。 因此，承担运营工作对开发人员来说可能是一个额外的负担和责任。 此外，运维工作通常包括各种琐碎繁琐的任务，包括 24/7 值班。

缺乏有用的工具和平台支持：如果没有易于使用且高效的自动化工具和平台，操作将变得更加手动，从而增加了操作的成本和复杂性。

这些可能是开发人员不愿意承担运营工作的一些可能原因。 运营的本质是什么？

运维的重点是确保系统的安全稳定运行。 它不仅需要24/7全天候监控在线环境的稳定性，还需要处理各种日常运维任务。 这些任务可能包括资源管理、例行检查、故障排除和维修以及工单处理。

近日，一些大厂商出现了重大的在线稳定故障，引起了业界的广泛关注。

最近的这些在线故障给整个行业敲响了巨大的警钟，所有企业都面临着在线稳定性的相同挑战。

安全生产，警钟敲响：面对在线问题，我们不能单纯追求速度和便利，对任何在线操作都要保持敬畏之心。

安全生产是每个人的责任无论是开发人员编写的错误逻辑，还是运营商错误的升级操作，最终都会对公司造成不可估量的损害。

生产环境的稳定性，最难的不是技术，而是看不计其数的细节的实施，稳定性的保障需要大量的投入，但这件事最大的问题是难以被认可，又如何衡量好坏？ 网上曾经流传着一个笑话，大致意思是“那些没有bug的写作者，往往默默无闻，甚至可能被杀死; 相反，那些经常写bug的同学，因为每天忙着修复bug，才能茁壮成长“，当然，开发者不愿意承担运维的原因，确实是因为在线稳定责任重，运维工作负担也很重，缺乏适用的工具和平台支持。

然而，平台工程被提出为一个新概念，旨在解决这些问题并改进软件交付过程。 让我们来谈谈与DevOps相比，[平台工程]的关键成功因素。

作为一个相对较新的概念，平台工程已连续两年获得 Gartner 的认可，使其成为我们关注的焦点。 为了在公司内部推进平台工程，我认为需要明确以下几个方面：

平台范围：内部工具很多，首先要做的就是建立权威或认证的工具，并不断投入迭代，而不是单独开发，避免重复构建和成本浪费。

平台文化：归根结底，平台是为谁而造的，为谁服务，技术研发人员就是我们的上帝，建立以服务技术研发人员为基础的平台文化，同时满足公司的管理视角。

平台目标：核心目标是构建场景化工具，让技术人员在平台内自助服务，以场景化、自助化为核心目标。

平台所有者：企业内部的IPD不可能集中在同一个部门，因此确定特定场景的所有者对于消除责任边界不清的问题至关重要。

要求**：一切都以研发需求为导向，要兼顾研发人员的经验，避免大而全面的版本升级和改动，导致系统和资源的研发迁移，造成额外的使用成本。

平台API：一个内部平台自然应该有丰富的API，以满足内部研发的需求，也应该提供详细的文档供技术人员使用。

综上所述，本文讨论了如何从全球视角在内部推进平台工程。 接下来，我们来看看平台项目下的工具应该具备哪些特征：

就我个人而言，我认为内部工具比面向消费者的产品更重要。 因为消费品用户有选择权，但业内人没有太多选择，顶多只是几句抱怨，但还是需要继续使用。 要创建一个让内部人员满意的工具，我个人认为您至少需要以下关键属性：

产品化：内部工具平台必须产品化，定位于服务于整个集团，而不是局限于自己部门的几个人，或者几十个人使用，目标用户必须定位为集团内所有研发生，只有这样才能把工具做好。

用户体验：注重用户体验，除了提供基本的GUI界面、API等功能外，除了阻塞复杂的后端逻辑，降低用户使用成本。

集成：这里说到集成，不仅仅是像现在的兴云泰山这样，通过工具市场将各种工具集成到平台中，这只是第一步，而是以开发使用场景为目标，以应用为工作空间的视角，比如在发布的时候， 集成监控、日志、计划、告警等可观测视图，让用户一站式满足所有场景的需求。

自我服务：用户不需要平台同学的协助，可以满足所有功能，这里举个例子，我们去银行取款，在柜台人工取款，但是需要银行工作人员的协助，但是我们通过ATM，同样也可以完全自助取款。

在平台工程的背景下，内部开发团队可能有以下常见情况，比如这四个方面：

产品化：内部工具在需求控制方面特别容易定制，经过一段时间后，它们可能会演变成针对某个人或一个小部门的定制产品。

优先权：经常收到或面临来自“某个 C-X 老板”的高优先级请求。

识别：由于与业务脱节，很难衡量价值，从长远来看，对产出价值的确认可能会受到怀疑。

重复构造：内部工具和平台重复构建的问题更为严重。

我个人认为内部平台团队应该坚持做以下几点：

持续收集用户需求，规划平台长期路线图。

改进用户手册和最佳实践，以改善用户体验。

保持开放的心态，并确保提供 API。

持续推广和运营其负责的平台。 （生儿育女）。

针对重复建设问题，要加强合作、共建，避免陷入小规模自吹自擂的“个人部门工具”建设。

最主要的是要从一些指标维度来衡量和评估。 如果一个平台或工具构建了一年，它对自己的用途一无所知，只专注于功能开发，那么你如何衡量平台带来的价值？ 我认为最重要的是寻找一个关键指标，它可以是业务维度、产品维度或组织维度，我抛出几个维度仅供参考：

用户维度（第一个是按用户维度改善用户体验）。

每周活跃用户数。

为企业数量赋能。

NPS 净推荐值。

产品尺寸

访问效率。 执行效率。

执行成功率。

组织维度

xx 周期。 xx 时间。

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

目前，谷歌、Spotify、Netflix、沃尔玛等一大批国外厂商等一大批企业都在积极推动企业内部平台工程的实施，11月，CNCF正式发布了平台工程能力成熟度模型，从5个维度划分为4个层次，CNCF发布的成熟度模型维度更加粗粒度， 主要从团队人员、平台应用、用户体验、自助服务和平台迭代等方面进行考核。平台的功能维度没有详细划分。

在国内，平台工程逐渐吸引了大家的关注，尤其是原本负责DevOps工具的人员，更加关注平台工程带来的新概念和倡导方向。 中国信息通信研究院也在组织业内专家，共同梳理出符合我国现状的平台工程能力需求标准，明确平台工程的功能维度。 我目前正在参与一些工作，所以如果您有兴趣，请随时与我联系。

最后，根据 Gartner 的数据，到 2026 年，80% 的软件工程组织将拥有平台团队，其中 75% 将包括开发人员自助服务门户。 80% 的软件工程组织将建立平台团队，作为可重用服务、组件和应用程序交付工具的内部提供商。

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

作者：京东零售 景亮亮.

*：京东云开发者社区**转载请注明**。