作者：Cory O’Daniel是Massdriver公司的联合创始人。

DevOps一开始是一套初衷很好的实践和文化。但这些年来，它已退化成为一头令人憎恶的野兽，导致部门分裂、目光狭窄。

为什么我们不再有更宏大的梦想？拆除孤岛、提升工程速度、增加价值？DevOps承诺的这些优点还记得吗？这些不是DevOps应该做到的吗？

但事实上，撇开FAANG（五大IT巨头）和财力最雄厚的公司不谈，贵公司的团队可能存在以下其中一种情况：

你有一个DevOps团队

恭喜，但那不是DevOps。我敢打赌，他们做的大部分工作无非是使用Terrform和YAML为工程团队做一些琐碎的任务。

需要数据库？向DevOps提交工单。

需要身份和访问管理（IAM）角色？向DevOps提交工单。

不久后，贵公司庞大的工程师团队提出的众多要求让人手不足的“DevOps”团队不堪重负。

这种方法不具备可扩展性。

你在做DevOps，但感觉糟透了

DevOps，感觉每个工程师都可以随意地做必要的运维来完成其工作。

最佳实践？我们会一路上发明它们！

安全吗？我正忙着提高转化率呢！

命名约定？不。生产环境中没有命名约定。

成本管理？删除未使用的云资源？不，我们有AWS积分还没用掉呢！

问题是大多数工程师不想做运维工作。

工程师只想构建产品。他们只想添加有形价值。但是组织会把运维工作强加在他们头上，工程师们要么使用已有的工具来工作，一路蒙过去，猜测某种新的云服务，要么DevOps任务慢慢地变成少数几个人的责任，这些人于是成为了“DevOps”团体。

这个场景最糟糕的部分就是截止期限规定，产品利益相关者看不到运维。

你上一次看到产品经理与运维人员击掌时说：“自动扩展器速度真他娘快!”是什么时候？

你的团队慢慢觉得可灵活扩展的DevOps变成了僵化的基础架构，因为团队不再做出艰难的运维决策，而是完全围绕已有的工具开发软件。

到最后，所有基础架构最终都变成了一个平台——你的基础架构变更起来有多容易？

运维好比大众化商品，不妨把它当作大众化商品来对待

我在工程部门的运维团队已工作了很长时间。我从Rails 1.0开始就一直在用Ruby从事开发。在此之前，我编写过一些世界上最糟糕的PHP。当AWS EC2在2006年推出时，我有机会从数据中心迁移到EC2。随着我在运维方面的经验越来越丰富，我被“归类”到“DevOps”工作岗位。

到目前为止，我已经在少数几家公司部署了200多个生产级Kubernetes集群。

想知道秘密吗？

我为每一家公司复制粘贴了几乎一模一样的Terrform模块。我的工作感觉像是在行骗，但这些公司付钱给我是冲着我在Kubernetes方面的专业知识，而不是因为我编写Terraform。

我构建了基于复制粘贴的单一用户平台即服务平台；只要没出现问题，就没有人在意。

事已至此，我就直说无妨：

建立“DevOps”团队的公司正朝着正确的方向前进，但它们需要从基础架构配置管理转向平台工程和使开发人员能够实现自助服务。

知识孤岛没什么不对。孤岛是一项特性，而不是一个bug。

专业知识是好事。

DevOps是扯淡。

Ops如何打破循环？

通过团队合作持续进步、高效沟通、提升士气、向力求改进的建议敞开大门……

当云很简单时，这种模式管用，甚至很明智。之前我们有几个虚拟机，可能还有一个S3存储桶和几个队列，这个循环是可以实现的。阻挠或破坏一切的是我们的系统越来越复杂、这些系统的运维负担以及合规。对于许多组织来说，运维团队不可避免地成为了循环中每个阶段的DevOps看门人。

规划

今天的规划需要了解云服务，并进行取舍。随着云变得越来越复杂，团队只剩几个选择：使用已有的工具，或者与运维同步，看看积压的任务是什么。

致力于平台工程的组织要么已确定了一条最佳路径（golden path），要么使团队能够迅速研究开发新的最佳路径。这种灵活性是优秀平台的关键。我们不是在建设“最佳道路”，它们是路径。最佳路径应该提供方向和保护，但是当业务需求发生变化时，又能灵活适应。

编程

编程正变得越来越像云API大杂烩。这是一件好事！我们应该希望编写和运行更少的代码。

你知道比在规划阶段等待运维积压处理完毕更糟糕的是什么吗？那就是由于你没有意识到SNS主题与你的SQS队列在不同区域，于是加班加点，还是未赶在截止日期之前完工，因为你在等待运维团队的某个人更新IAM策略并创建KMS密钥。

优秀的内部开发平台已明确了约定，以处理云端那些琐碎的任务，比如IAM和KMS，这些任务耗费大量的时间来处理。优秀的内部开发平台专注于工程师的意图，而不是让工程师为实施细节而操心。

构建、测试、发布和部署

现在说说持续集成/持续交付（CI/CD）。开发和生产之间的界限很模糊。这些阶段充斥着没用的东西，以至于它们都成了表情包：

但它不是“运维问题”，而是整个组织的问题。我确信CI/CD阶段是运维团队与工程团队之间产生挫折和分歧的根源。

不妨举这个很常见的例子：

在生产环境中，我们在容器中运行应用程序，但是在容器中开发实在太慢了，于是团队倾向于asdf和README文件，里面全是用来复制粘贴的内容。在迭代开发周期（sprint）过程中，工程师添加了convert（ImageMagick）以支持图片操作，却忘记更新Dockerfile，然后生产环境戛然而止。

这时候，开发人员和运维人员之间的信任开始削弱了。

内部开发平台应该允许工程师在他们想要运行的地方、以他们想要的方式运行应用程序。Lambda和Docker，当然可以。K8s + buildpack，当然可以。虚拟机和打包文件（tarball），当然也可以。

遗憾的是，现在许多平台都强迫开发者在Kubernetes上运行。无论工程师在哪里，优秀的开发平台都可以满足工程师的需求。平台在架构方面应该灵活，但在自助服务方面又应该自成一体。

操作和监控

这个“完美”循环模型的最终阶段大概是运维应该发挥作用的环节。太好了，只不过现在我们有网站可靠性工程师（SRE）来解决这个问题。

如果“DevOps”团队交付一个Postgres RDS实例，实例可能一直顺畅地运行下去，直到应用程序开始使用它。突然之间，N+1级联出现，CPU使用量激增，查询陷入停顿。谁在半夜被叫醒了？为什么这一幕总是发生在凌晨两点？在这种情况下，运维人员没有什么可做的，但他们又得在场。

你还认为DevOps在做它应该做的事情吗？

运维团队和SRE团队拥有的专业知识对于开发安全、可扩展的系统至关重要，但是“DevOps”的旧观念以及行业给其带来的障碍在阻碍我们前进的步伐。

是时候埋葬DevOps了

在过去这两年，我花了大量的时间与诸多团队讨论他们的云基础架构和DevOps流程/文化。我从一个又一个团队听到了是时候埋葬DevOps的抱怨。说到如今DevOps的现状，更令人担忧的是我听到了其他一些声音……

试问贵组织中有多少人认为CI/CD就是DevOps？

试问贵组织中有多少人因在运行Serverless而认为自己不需要DevOps？

试问又有多少人认为上述两种解释都有问题？

对大多数人来说，“DevOps”这个术语已完全失去了意义。

如果你真的在做DevOps，你认为重新发明所有这一切果真值得工程团队为之花时间吗？这对公司来说是划算的投入吗？

“你构建它，你运行它”更像是你构建它，但所花的时间比你的迭代开发周期估计的要长，你在不符合“完成定义”的运维方面偷工减料。

知识孤岛和专业知识是同一枚硬币的两面。从全栈工程师到DevOps从业人员，我们行业喜欢假装每个人都能做任何事情。我们这个行业的人生性喜欢捣鼓。我不知道我们是在自欺欺人，还是这个行业一直在利用我们喜欢捣鼓的天性，但是时候将DevOps扔到窗外了。

越来越流行的时代精神是“平台工程是未来。”遗憾的是，许多组织无法指望“DevOps”团队来搞平台工程，从而抵达成功彼岸。在git代码存储库之间复制/粘贴一些Terrform模块是糟糕的“平台”。你的工程师不想处理它，运维团队将不可避免地为负责支持它。就连HashiCorp也开始为其“请联系销售人员”方案搭上“无代码”配置这股潮流。所有这些拥有企业客户收入的公司也都在苦苦挣扎。

那么，普通组织如何抵达平台工程这块乐土呢？

很简单，只要雇用更多的前端和后端工程师来开发一个优秀的内部PaaS，使用运维团队在构建设计的所有最佳路径，同时尝试构建在其上运行的实际产品。

很显然，这说起来容易做起来难。

为了实现这个目标，许多组织都需要认清现实。

每1个没有软件开发技能的运维人员，就有40个没有云运维技能的工程师。如果你要建立一个内部平台，就需要在这两个领域都有经验的专家协同工作。

你还需要大量的时间和预算。这不是黑客马拉松项目。这不是新官上任三把火的新首席技术官的宠爱项目。你可以给它起一个“特别研发项目”的名称，向所有人表明你也可以访问维基百科，但建立内部平台是在贵公司内的创业项目。构建内部开发平台就像在汽车冲向悬崖时更换轮胎和引擎。

一定要保持敏捷。

将辅助服务快速迁移到内部开发平台。

从工程客户那里获得反馈。

是的，工程客户。他们不再是你的团队了。他们是贵公司的第二批客户，但如果这些客户不买账，你最终会遇到士气问题，工程师们渴望“旧方式”、一大堆技术债务以及大量浪费的时间和精力。

别气馁！你或新首席技术官的下一个团队可以完成重任。