云原生时代的DevOps平台设计之道 _生活百科

开发人员与运维人员是 IT 领域很重要的两大人群，他们都会参与到各种业务系统的建设过程中去。DevOps 是近年间火爆起来的一种新理念，这种理念被很多人错误的解读为“由开发人员（Dev）学习一大堆新的技能，从而掌握运维人员（Ops）该处理的事情” 。然而能力越大，责任越大，当维持生产环境稳定为要位的运维责任落到开发人员的肩头时，多数程序员发出了扯淡的DevOps ，我们开发者根本不想做运维! 的呼喊。那么在云原生时代，到底应该怎样达成 DevOps 的体验呢？我的观点是由平台工程来衔接这两大人群，各自做好各自领域的事情。

令人“厌恶”的DevOps首先，我非常希望你能先看一看引言中提到的扯淡的DevOps，我们开发者根本不想做运维!这篇文章。这篇文章从亚马逊云科技社区参与负责人 Emily Freeman 的一条推特入手，观察了很多留言后，得出了文章标题这种类似咆哮一般的结论。从绝大多数回复这条推特的IT 从业者的口中，我听到了对于将运维职责强加给开发人员这种 DevOps 体验深恶痛绝。
开发人员对于 “谁构建，谁运行” 这种大义凛然的话表示无感，对于学习运维领域的新技能，亦或是将自己加入轮班支持人员的行列都感觉力不从心；运维人员的本职工作被剥离之后，则对本专业的前景惶惶不安，会害怕运维团队的重新洗牌。
开发与运维，的的确确是两个不同的工种，有着类似“车床工与管道工”的区别。
开发人员运维人员专业技能开发语言、开发框架、中间件、数据库硬件、操作系统、网络、存储、虚拟化日常工作理解需求、开发文档写作、开发代码安装部署、监控、日志、问题排查、变更文化标签自由、创造保守、责任一些公司认为从表格中把大量的运维人员管辖的工作，一股脑的“左移”给开发人员就是 DevOps 。在专业技能和日常工作领域带来的缺口，可以通过开发人员的勤劳学习加以补足，然而在文化标签领域的冲突，将会是导致开发人员厌恶这种 DevOps 体验的根本原因。
DevOps 的真意与平台工程在我看来， DevOps 的真意是利用软件工程思维，解决复杂且繁重的运维问题。真正适合做 DevOps 工作的人，是具备一定软件工程能力的运维专家，在这里，对运维能力的要求更重要。
DevOps 工程师，可以通过设计或选择一款平台产品，来将复杂的运维工作抽象为产品化的运维特征。从这个角度上讲，开发人员将会是这个平台产品的用户，他们能够在不了解复杂基础设施的情况下，操作并维护应用程序。DevOps 工程师，应该是更懂开发人员需求的运维工程师。
在追根溯源，找到了这条推特之后，我了解到了更多 IT 业内人士对 DevOps 的看法，从中找到了很多和我有共鸣的声音。

To me that's a sign we haven't made ops intuitive/easy enough for most devs to be able to handle it.
对我来说，这表明我们还没有让运维变得足够直观/简单，以至于大多数开发人员都无法处理它。
?—— @Liz Fong-Jones (方禮真)

The "platform" should do the heavy lifting ops, lacking a real platform the ops team (DevOps/are/platform team) is the platform.Devs can then focus on the application level operations of their apps using the knobs and levers provided by the platform.
“平台”应该做繁重的运维，缺乏真正的平台时运维团队就是平台（DevOps/are/platform team）。然后，开发人员可以使用平台提供的旋钮和杠杆专注于其应用程序的应用程序级操作。
?—— @pczarkowski

IT 行业近年来的发展趋势，一直是不断以平台能力的提升，来解决复杂基础设施的使用问题的。最开始，程序开发人员需要面对的是一台物理服务器，在缺乏运维能力的情况下，会由运维人员处理有关服务器的一切，包括操作系统、网络配置等等。而到现在，程序开发人员已经很少需要跟服务器打交道，甚至我见过的很多程序员并不掌握任何有关命令行的知识，就可以面向服务器开发应用系统。这种转变让程序开发人员更加专注于业务代码本身，不必分神去做一些繁重且琐碎的运维事务。带来这种转变的，是处于发展过程中的平台工程，在让基础设施不断变得简单易用。