DevOps是一种文化，是敏捷的一部分，主要是解决引入敏捷活动的持续开发、快速反馈后带来的新的运维问题。
DevOps的初衷是让开发能够掌握运维知识，对自己的产品全生命周期负责（you build it, you run it), 开发者是对它的产品最了解的，如果全流程都是由开发来执行的话，无疑是会提升产品的质量，提升敏捷性（毕竟没有多层的信息损耗）。
但是事实情况却并非如此，开发本身的工作都已经消耗了其大部分精力，让他还要去掌握运维的工作，无疑是给他增加了更多的认知负担，根本不现实！事实上不管是不是开发，大多数人在面临认知负担的时候，往往都会选择逃避。 并且随着技术的不断推成出新，技术复杂度和持续学习成本是不断增加的，这更加导致了让开发去做运维的事情在长期看来更加无法达到预期的。
在 Gartner发布2023年10大战略技术趋势中我们赫然看到了平台工程PLatform Engineering”的存在！
从字面上的意思去理解的话，平台工程是一个能实现让开发者管理产品生命周期的自助式开发者平台。
而深入思考的话，平台工程其实是把运维的大部分工作做了抽象封装，变成一个个功能集成在了平台中。这就从另一个角度给了devops目前面临问题的一个解法：把运维能力封装出去给到开发使用，开发无需知道具体的运维知识，只要会使用对应功能即可。其实目前最火、认知最广、最佳成功实践就是CICD，而CICD就是把以前运维的打包发布工作，通过jenkins这类工具，封装成一个个工程，再在上层封上一个发布平台提供打包发布的能力给到开发，从而使得开发并不需要知道系统是如何打包的发布的，只要知道如何使用发布平台即可，这个认知成本是大大降低的，同时也实现了开发管理产品全生命周期中的发布这一环。
打包发布技术成熟度是随着语言发展速度同步成长的，使用某种语言开发不管在哪家公司，打包流程其实是大同小异的，特异性小，从而让它有可能成为一个产品，而且目前不管是jenkins还是其他产品，都还提供了开放社区和插件功能来进一步消除仅剩的这些特异性，这导致了不管你在哪家公司只要是想做CICD，市面上必然有开源软件能够帮到你，大多数情况你并不需要自己去做特异性开发，那CICD技术的快速普及和发展也是意料之中的。
目前常见的devops工具链已经解决了很多关键的部分，但为什么预测说80%的软件工程组建还需要自己建立平台团队呢？因为目前这些工具链在搭建完后，在宏观上还是一个个孤岛，只能说devops工具链的搭建是从0-1的变化，只是第一阶段，这个时候只是把线下搬到了线上，但是信息是相对割裂的，无法通过这些“隐藏”的数据去产生其该有的价值，而数据的透明化、易获取、可分析是敏捷发展到一定程度所必须的。再者，如果在规划推广上处理不当，出现太多的特殊情况，形成“破窗效应”，devops反而会成为”效率杀手“！这就再次强调了，devops是文化不只是技术。
一方面小规模研发团队是不需要高成熟度的平台工程的，20人以下的研发团队，线下面对面沟通是更加高效的。另一方面现在市面上提供了很多一体化的研发平台，比如说阿里的云效、华为的devcloud等，完全可以满足小开发团队的需求。但是为什么80%不能用这现成的平台呢？还是因为具体到每个公司的差异性太大，平台终究只是一个工具，如果无法结合企业情况形成最佳实践的话，效果也是会大打折扣的。同时目前这些平台自己的生态还不完善，对外开放程度也比较差，无法让开发者们能够基于它的生态自行去扩展以消除差异，就算像backstage这种已经相对灵活的平台，目前也并没有在国内有快速发展起来。
未来很长一段时间平台工程必然会逐渐被更多企业重视起来，自建平台的需求也会越来越多，在这过程中识别哪些能力是可以被封装的是一个突破口。之后必然会孕育出更多专业的工具链服务，一体化研发平台也会迎来新的定义，这个赛道也能开拓出更多新的蓝海！
有任何问题或者想讨论的，欢迎大家留言，一期共识共创！
