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

• 专注于核心开发任务：开发人员通常更倾向于日常软件开发任务，他们可能没有太多时间和精力在其他方面，否则会影响日常任务的工作进展。

• 不熟悉或不感兴趣：开发人员可能没有足够的经验来处理运维的工作，或者他们对运维工作不感兴趣，导致在运维方面缺乏积极性。

• 运维的锅太重、事太杂：运维工作涉及到生产环境，因此其责任和影响范围较大。任何运维失误都可能导致系统故障、服务中断或数据丢失等严重后果。因此，对于开发人员来说，承担运维工作可能带来额外的压力和责任。此外，运维工作通常包括各种琐碎而繁杂的任务，包括7*24值班。

• 缺乏好用的工具和平台支持：缺乏易用且高效的自动化工具和平台，运维工作就会更加依赖手工操作，从而增加了运维的成本和复杂性。

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

运维工作的本质

去年宕机事故频发，某APP出现超长宕机，根据网上流传的信息，故障事件的原因是选择了成本较低的K8S的原地升级方案，由于错误的升级操作，导致升级变成了降级，干掉了所有的pod，直至次日下午，该APP才基本恢复正常。

带来的一些思考

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

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

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

• 平台范围：内部有许多工具，首先要确立权威或认证的工具，进行持续投入与迭代，而非各自发展，以免造成重复建设和成本的浪费。
• 平台文化：平台到底是为谁而做，为谁服务，技术研发人员是我们的上帝，建立以服务技术研发人员为主的平台文化，同时满足公司管理角度。
• 平台目标：核心目标是构建场景化的工具，使技术人员能在平台中自助化使用，把场景化、自助化作为核心目标。
• 平台Owner：企业内的IPD不可能集中在同一个部门，因此确定特定场景的 Owner 至关重要，可以消除职责边界不清晰的问题。
• 需求来源：一切以研发需求为主，要兼顾研发人员的使用体验，避免大而全的版本升级改动，导致研发迁移系统，迁移资源，从而带来的额外使用成本。
• 平台API：内部平台天然就应具备丰富API，满足内部研发的需求，并也应提供详细的文档让技术人员使用。

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

• 产品化：内部的工具平台一定要产品化，定位于服务全集团，而非局限自己所在部门的几个人，或者几十人使用，一定要把目标用户定位是集团内所有研发同学，只有这样才能把工具做好。
• 用户体验：重视用户体验，除了提供基础的GUI界面，API等能力之外，另外也要注意屏蔽复杂的后端逻辑，降低用户的使用成本。
• 集成化：这里讲集成，不仅是像目前行云/泰山一样通过工具市场把各个工具集成到平台上就行了，这些仅完成了第一步，还是以研发使用场景为目标，以应用为视角工作区，例如在发布时，整合监控、日志、预案、告警等可观测的视图，让用户在一个地方满足所有该场景的需求。

• 自助化：用户无需平台同学的协助，能满足一切功能，这里举个例子，我们去银行取钱，在柜台人工可以取，但需银行人员的协助，但我们通过ATM，一样也可以完全自助的取钱。

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

• 产品化：内部工具再需求把控方面特别容易被定制，经过一段时间后，可能会演变成了某个人或者某个小部门的定制产品。
• 优先级：经常接到或面临“某C-x老板”的高优先级需求。
• 认可性：由于与业务脱节，难以衡量价值，长期下来，对产出的价值认可可能会产生疑虑。
• 重复建设：内部工具和平台的重复建设问题较为严重。

• 持续收集用户需求，并对平台长远规划路线图。
• 完善用户使用手册和最佳实践，提升用户体验。
• 保持开放心态，一定要提供API。
• 持续推广和运营所负责的平台。（生孩子和养孩子）
• 针对重复建设问题，加强合作共建，避免陷入小范围的自嗨式“个人/部门工具”建设

• 用户维度（第一个就是要用户维度，提升用户体验）：周活跃用户数、赋能业务数、NPS净推荐值
• 产品维度：访问效率、执行效率、执行成功率
• 组织维度：XX周期、XX用时

国外的情况

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