不知什么时候开始，有国外的开发者公开发声：DevOps就是扯淡，开发根本不想做运维！
更有甚者，直言“DevOps 已死，平台工程才是未来”，“是时候埋葬 DevOps 了”。
国内一些技术社区随之加入，成为这些声音的所谓支持者，大肆渲染所谓“DevOps 已死”的论调。
这些言论的支持者的理由主要是：DevOps 就是让开发去做运维；DevOps 对大多数公司没用；平台工程才是良药；
你做的是真正的 DevOps 吗？
DevOps 的兴起源于企业有意弥合运维与开发之间的裂隙，从而加强研发运维的一体化，从而达到IT的提质增效。
真正的 DevOps 是一种软件开发与运营的方法论，本质应该是一个内部平台和维护内部平台专门团队，以及相应的 DevOps 文化建设，而不是一堆需要程序员自己去搞定的零散开源工具，甚至是让开发把运维的活也干了。
但在实施过程中有部分企业简单粗暴地将其理解为“让开发人员去负责运维的工作”，甚至让高级开发人员接管了运维角色，导致了开发渐渐不堪重负。
真正的 DevOps 不仅仅是一种技术和工具的堆砌，而是一种技术、文化和理念的融合。以下是一些关键特征，可以帮助你识别真正的 DevOps 实践：
自动化：真正的DevOps通过自动化来实现快速、可靠和可重复的软件部署和交付。
协作：真正的DevOps强调开发和运维之间的紧密协作，弱化组织内部的壁垒。
持续交付：真正的DevOps实践持续交付，即将软件的部署和交付过程从一次性的、手动的过程转变为自动化的、可重复的过程。
测试与质量：真正的DevOps强调质量的重要性，倡导在开发和部署过程中进行自动化测试和质量保证。
反馈与改进：真正的DevOps实践注重反馈和改进，倡导在整个软件开发和部署过程中收集反馈，并根据反馈进行改进和优化。
总之，真正的 DevOps 不仅仅是一种技术或工具的应用，而是一种文化和理念的融合，它强调协作、自动化、持续交付、测试与质量、反馈与改进。
DevOps 实践已经获得业界广泛认可
DevOps是一个非常成功的实践。它将开发和运维部门紧密结合，通过自动化工具和流程改进来提高软件开发和交付的速度和质量。
DevOps可以降低故障率和恢复时间，提高交付速度和可靠性，并改善开发团队和运维团队之间的协作。
这种方法已经被许多组织成功地采用，并为其带来了显著的收益，并受到相关研究机构和企业的认可。
Gartner 认为DevOps将在2-5年内成为生产成熟期的技术。
Gartner 发布的2022年中国信息和通信技术成熟度曲线中 DevOps(Gartner译为开发运维)正式进入泡沫破裂低谷期(Trough of Disillusionment)，意味着正式迈向成熟期，将在2-5年内成为生产成熟期的技术：⏬
国外每年发布的State of DevOps（DevOps年度报告）也表明越来越多的企业在实践DevOps，并且取得效能的提升：⏬
在国内，根据 《2022 中国DevOps现状调查报告》显示，中国企业 DevOps 落地成熟度不断提升，近六成企业向全面级迈进：⏬
央行发布的《金融科技发展规划（2022-2025）》中要求银行、证券、保险等金融企业借助业务开发运维一体化（BizDevOps）持续优化研发和交付质量：⏬
更重要的是 DevOps是一个不断发展的领域。虽然它已经得到了广泛的应用，但是它仍然在不断地进化和发展。随着技术的进步和业务需求的变化，DevOps实践将不断地进行改进和调整，以满足不断变化的需求。
平台工程和 DevOps 是你死我活的关系？
平台工程并不是 DevOps 的替代方案。事实上，平台工程可以被视为 DevOps 实践的一个重要组成部分。
平台工程是指构建和维护一个可靠的基础设施和工具链，使得开发团队能够更快地交付软件并保证其质量。这与 DevOps 的理念非常相似。
“平台工程”实际上是 DevOps 的一种补充形式，DevOps 之所以形成是因为企业希望把“运维”和“开发”两件事情融合起来，希望把“运维”和“开发”两个本来不同的岗位、不同的职能部门，让它统一起来。
“平台工程”通过一些工具和流程，为企业的软件开发团队提供一个自助开发门户，或者叫“内部开发平台”，涵盖整个应用程序的整个生命周期当中的所有操作需求，它由一个专门的平台工程团队创建和维护。
平台工程主要聚焦于构建和管理软件的基础设施平台，例如云计算平台、容器平台、数据平台等等，这些平台可以为开发人员提供各种工具和服务，例如自动化部署、资源管理、日志监控等等。平台工程师负责设计、构建、管理这些平台，并为开发人员提供支持和服务。
DevOps 则强调开发和运维的紧密协作，倡导自动化、持续交付和质量保证，旨在加快软件交付速度，提高软件质量和可靠性。DevOps 团队负责将开发和运维的过程自动化和整合，并在整个软件交付过程中实施质量保证和监控。
虽然平台工程和 DevOps 有些相似之处，但它们的职责和目标不同，平台工程聚焦于构建和管理基础设施平台，而 DevOps 聚焦于整个软件交付过程的自动化和整合。因此，平台工程不会取代 DevOps，而是在 DevOps 的基础上提供更好的基础设施平台支持。两者应该是相辅相成的关系。
平台工程 和 DevOps 绝非替代的关系，更谈不上你死我活，我们需要做的是更多思考技术的本质，而不是只停留在技术的表面，甚至是以玩概念为噱头....
摘自网友的一些观点：
技术不能二极管，平台工程这种新概念刚出来就必须去否定 DevOps 吗？
脱离技术价值本质单纯去讨论技术概念毫无价值，以否定同行理念的形式抬高自身价值也不可取。
如果企业没有在软件工程上下真功夫，没有敏捷和精益的方法指导，没有实施DevOps实践的经验积累，平台工程也只能是空中楼阁。实际的情况是，很多企业在不停的寻找所谓“创新”而忽略了基本功的锤炼。真正企业需要的研发系统，一定不仅仅是DevOps工具就能覆盖的，但没有DevOps也一定是不能覆盖的。
每种技术都有自身的优缺点，老是追新不想着革新的团队永远不会有啥成长......
DevOps 不仅仅未死，而且在快速成长，愈发成熟，并且衍生出DevSecOps（安全内建）、BizDevOps（业技融合）等新理念、新方法。
DevOps 一定会有离开我们的那一天，当那天来临时，我们会送别，而不是欢呼。
写完到这里，一句话浮现心头：踏踏实实为用户创造价值，剩下的就交给时间去证明吧！
探索实践 DevOps 的最佳路径，DevOps 能力成熟度模型助力企业IT提质增效⏬
截至目前，共有65家各行业名企216个项目参与 DevOps 能力成熟度模型评估，包括六大国有银行、股份制银行、城商行、互联网、证券、保险和通信等行业的众多头部企业。
向下滑动查看所有内容
* 统计截止日期至：2022年12月26日。数据来自于DevOps评估官方网站，以评估总数排序，数量相同则依据评估批次先后排序。
* 数字为对应企业通过 DevOps 持续交付标准 3 级、技术运营标准 2 级/2+级、安全及风险管理2级、系统和工具评估的项目/模块数量。上述统计数据已包含企业及子公司参评情况。另有企业通过 DevOps 持续交付标准 2 级评估共 9 个项目，安全及风险管理 1+ 级 1个项目。
还不过瘾？招行领衔！BATJ专家齐聚，4月7日-8日，第20届 GOPS 全球运维大会 · 深圳站~看国内一线名企如何落地实践 DevOps、SRE、BizDevOps 的……
<< 扫码查看更多 >>
推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论，来说两句吧...