引言
最后思考援用“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 强调团队合作，并激励开发人员承当肯定的运维工作。然而，在事实中，为什么这一点往往难以实现？我认为次要有以下几个方面的理由：
• 专一于外围开发工作： 开发人员通常更偏向于日常软件开发工作，他们可能没有太多工夫和精力在其余方面，否则会影响日常工作的工作进展。
• 不相熟或不感兴趣： 开发人员可能没有足够的教训来解决运维的工作，或者他们对运维工作不感兴趣，导致在运维方面不足积极性。
• 运维的锅太重、事太杂： 运维工作波及到生产环境，因而其责任和影响范畴较大。任何运维失误都可能导致系统故障、服务中断或数据失落等严重后果。因而，对于开发人员来说，承当运维工作可能带来额定的压力和责任。此外，运维工作通常包含各种琐碎而繁冗的工作，包含 7 *24 值班。
• 不足好用的工具和平台反对： 不足易用且高效的自动化工具和平台，运维工作就会更加依赖手工操作，从而减少了运维的老本和复杂性。
以上可能是开发人员不太违心承当运维工作的一些可能的理由。我接下来看下运维的实质是什么？
运维工作的实质
运维工作重点是保障系统的平安和稳固运行。它不仅须要 7×24 小时监控线上环境的稳定性，还须要解决各种日常的运维工作。这些工作可能包含资源管理、日常巡检、故障排查与修复、工单解决等。
最近，一些大厂经验了重大的线上稳定性故障，这给业界带来了很大的关注。
最近的这些线上故障对整个行业产生了极大的警示，所有企业都一样面临着线上稳定性挑战。
带来的一些思考
平安生产，警钟长鸣： 面对线上问题，咱们绝不能单纯地谋求速度和省事，对于任何线上操作，都必须放弃敬畏之心。
平安生产，人人有责： 无论是开发人员编写的错误代码逻辑，还是运维人员谬误的降级操作，最终都有可能给公司带来无法估量的损失。
生产环境的稳定性，最难得不是技术，而是依赖有数细节的落地，稳定性的保障须要大量的投入，然而这个事最大的问题就是，难被认可，以及怎么来掂量做的好呢？网上已经一个段子，大略意思就是“那些代码写的没有 Bug 的人，往往石破天惊，甚至可能被干掉；相同，那些常常写 Bug 的同学，因为日常繁忙于修复 Bug，反而能风生水起”，当然，开发不违心承当运维的起因，的确是因为线上稳定性的责任重大，同时运维工作的累赘也很重，并且不足实用的工具和平台来反对。
然而，平台工程被提出，作为一种新的理念，旨在解决这些问题，并进步软件交付流程。接下来聊一聊，与 DevOps 相比【平台工程】的胜利关键因素有哪些。
平台工程胜利的关键因素
如何在公司内推动平台工程
作为一个绝对新鲜的概念，平台工程已间断两年取得 Gartner 的认可，将其推向了咱们不得不关注的重要位置。要在公司内推动平台工程，我认为需明确以下几个方面：
• 平台范畴： 外部有许多工具，首先要确立权威或认证的工具，进行继续投入与迭代，而非各自倒退，免得造成反复建设和老本的节约。
• 平台文化： 平台到底是为谁而做，为谁服务，技术研发人员是咱们的上帝，建设以服务技术研发人员为主的平台文化，同时满足公司治理角度。
• 平台指标： 外围指标是构建场景化的工具，使技术人员能在平台中自助化应用，把场景化、自助化作为外围指标。
• 平台 Owner： 企业内的 IPD 不可能集中在同一个部门，因而确定特定场景的 Owner 至关重要，能够打消职责边界不清晰的问题。
• 需要起源： 所有以研发需要为主，要兼顾研发人员的应用体验，防止大而全的版本升级改变，导致研发迁徙零碎，迁徙资源，从而带来的额定应用老本。
• 平台 API： 外部平台人造就应具备丰盛 API，满足外部研发的需要，并也应提供具体的文档让技术人员应用。
综上，从全局的维度探讨了如何在外部推动平台工程。接下来，咱们探讨一下平台工程下的工具应具备哪些特质：
平台工程下建设什么样的工具
集体认为，相较于面向消费者的产品，外部工具更为重要。因为消费者产品用户有选择权，但内部人员并无太多抉择余地，最多只是埋怨几句，却仍需持续应用。要打造令内部人员称心的工具，集体感觉至多须要以下要害属性：
• 产品化： 外部的工具平台肯定要产品化，定位于服务全团体，而非局限本人所在部门的几个人，或者几十人应用，肯定要把指标用户定位是团体内所有研发同学，只有这样能力把工具做好。
• 用户体验： 器重用户体验，除了提供根底的 GUI 界面，API 等能力之外，另外也要留神屏蔽简单的后端逻辑，升高用户的应用老本。
• 集成化： 这里讲集成，不仅是像目前行云 / 泰山一样通过工具市场把各个工具集成到平台上就行了，这些仅实现了第一步，还是以研发应用场景为指标，以利用为视角工作区，例如在公布时，整合监控、日志、预案、告警等可观测的视图，让用户在一个中央满足所有该场景的需要。
• 自助化： 用户无需平台同学的帮助，能满足所有性能，这里举个例子，咱们去银行取钱，在柜台人工能够取，但需银行人员的帮助，但咱们通过 ATM，一样也能够齐全自助的取钱。
平台工程下的外部开发团队
在平台工程背景下，内开发团队可能会有以下共性状况，例如这四方面：
• 产品化： 外部工具再需要把控方面特地容易被定制，通过一段时间后，可能调演变成了某个人或者某个小部门的定制产品。
• 优先级： 常常接到或面临“某 C - x 老板”的高优先级需要。
• 认可性： 因为与业务脱节，难以掂量价值，长期下来，对产出的价值认可可能会产生疑虑。
• 反复建设 ：外部工具和平台的反复建设问题较为重大。
集体感觉外部平台团队应要保持做以下几件事：
•继续收集用户需要，并对平台长远规划路线图。
•欠缺用户使用手册和最佳实际，晋升用户体验。
•放弃凋谢心态，肯定要提供 API。
•继续推广和经营所负责的平台。（生孩子和养孩子）
•针对反复建设问题，增强单干共建，防止陷入小范畴的自嗨式“集体 / 部门工具”建设
如何掂量平台工程的胜利呢？
次要在于要从一些指标维度进行掂量评估。如果一个平台或者工具，在做了一年后，对于本身的应用状况无所不知，而仅专一在做性能开发，那么怎么来掂量这个平台带来的价值呢？我感觉最要害的在于要寻找一个要害的指标，这个指标能够是业务维度，也能够是产品维度或组织维度，我抛出几个维度仅供参考：
• 用户维度 （第一个就是要用户维度，晋升用户体验）
◦周沉闷用户数
◦赋能业务数
◦NPS 净推荐值
• 产品维度
◦拜访效率
◦执行效率
◦执行成功率
• 组织维度
◦XX 周期
◦XX 用时
平台工程的将来
针对平台工程的将来倒退，目前国内外的状况如下：
国外的状况
以后，国外各大厂像 Google、Spotify、Netflix、Walmart 等一大批公司均在踊跃推动平台工程在企业外部的施行，11 月份，CNCF 正式公布了平台工程的能力成熟度模型，别离从 5 个维度上划分了 4 个级别，CNCF 公布的成熟度模型维度比拟粗粒度，次要从团队 / 人员、平台利用、用户体验、自服务以及平台迭代等方面进行评估，并未对平台性能维度进行具体划分。
国内的状况
在国内，目前平台工程也逐步受到大家的关注，特地是原来就负责 DevOps 工具相干的人员，更加关注平台工程带来的新的概念和提倡方向。中国信息通信研究院也正在组织行业内的专家，独特梳理一份合乎国内现状的平台工程能力要求规范，会明确平台工程性能维度。我目前也参加了局部工作，如有对此感兴趣的共事，欢送分割我一起参加。
最初，放个一个 Gartner 预测的数据，Gartner 预测，到 2026 年，80% 的软件工程组织将建设平台团队，其中 75% 将蕴含开发者自助服务门户。80% 的软件工程组织将建设平台团队作为可重复使用的服务、组件和工具的外部提供者，用于应用程序交付。
可见， 平台工程不仅仅是一种趋势，它是软件交付的将来
作者：京东批发 井亮亮
起源：京东云开发者社区 转载请注明起源