开学第一课汉字做网站,石家庄网站建设电话,缙云建设局网站,wordpress 发布文章 慢引言 最初考虑引用“ DevOps 已死#xff0c;平台工程才是未来”作为标题#xff0c;但这样的表达可能太过于绝对。最终#xff0c;决定用了“扯淡的”这个词来描述 DevOps#xff0c;但这并不是一种文明的表达方式。 文章旨在重新审视 DevOps 和平台工程#xff0c;将分别…引言 最初考虑引用“ 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值班。
•**缺乏好用的工具和平台支持**缺乏易用且高效的自动化工具和平台运维工作就会更加依赖手工操作从而增加了运维的成本和复杂性。
以上可能是开发人员不太愿意承担运维工作的一些可能的理由。我接下来看下运维的本质是什么
运维工作的本质
运维工作重点是保障系统的安全和稳定运行。它不仅需要 7x24小时监控线上环境的稳定性还需要处理各种日常的运维任务。这些任务可能包括资源管理、日常巡检、故障排查与修复、工单处理等。 最近一些大厂经历了重大的线上稳定性故障这给业界带来了很大的关注。
最近的这些线上故障对整个行业产生了极大的警示所有企业都一样面临着线上稳定性挑战。
带来的一些思考
**安全生产警钟长鸣**面对线上问题我们绝不能单纯地追求速度和省事对于任何线上操作都必须保持敬畏之心。
**安全生产人人有责**无论是开发人员编写的错误代码逻辑还是运维人员错误的升级操作最终都有可能给公司带来无法估量的损失。
生产环境的稳定性最难得不是技术而是依赖无数细节的落地稳定性的保障需要大量的投入然而这个事最大的问题就是难被认可以及怎么来衡量做的好呢网上曾经一个段子大概意思就是“那些代码写的没有 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%的软件工程组织将建立平台团队作为可重复使用的服务、组件和工具的内部提供者用于应用程序交付。
可见平台工程不仅仅是一种趋势它是软件交付的未来
作者京东零售 井亮亮
来源京东云开发者社区 转载请注明来源
