《事后看来，DevOps 是个糟糕的主意》。
这是Adam Ard的一篇讨论DevOps 发展过程和现在存在的问题的文章。作者认为 DevOps 最初的理念是正确的，但为其命名并设立专门的 DevOps 团队却是一个错误，这导致了开发人员与生产环境的脱节，违背了 DevOps 的初衷。下为全文翻译。
---------------------------------------------------------------------
我们需要谈谈 DevOps。
起初，DevOps 是有道理的。它是健康工程实践的逻辑演进。但我们本不该给它命名。一旦我们贴上了标签，事情就彻底失控了。
在 DevOps 出现之前，开发者编写软件后交给运维团队，后者得想办法让软件在生产环境中运行。这种做法效果不佳。后来，关心部署的开发者开始介入，确保代码能顺利过渡到生产环境。这是一个巨大的进步。
而这正是我们本该止步的地方。
我们本应直言：“开发者应当自行部署代码。”不仅如此——他们还应对代码的运行负责。开发者需监控系统、响应问题，并运用编程技能实现部署自动化，确保流程安全、可重复且便于团队使用。具备生产意识的开发者（作为团队一员！）应多做些额外工作，让整体运作更顺畅。这才是正确理念——必须摆脱运维团队孤立管理生产环境而开发者置身事外的旧模式。
当云服务出现后，这种转变变得更加自然。启动服务器与调用 API 无异。基础设施可被编程化。可进行版本控制。可实施测试验证。
但我们犯了一个严重的错误：我们给它起了个名字——DevOps。
突然间，那些擅长与生产系统打交道的开发者被赋予了一个新头衔。而一旦“DevOps 工程师”成为一个职位，人们就开始组建 DevOps 团队。这便是一切的终结的开端。
当我们创建 DevOps 工程团队时，我们将工程师从产品团队中抽离，赋予了他们新的使命。我们让产品开发团队失去了专注于生产环境的人手。我们亲手拆解了最初让 DevOps 得以运作的一切。
实际上，我们创建了一个名为 DevOps 的新运维团队，而运维又回到了孤立管理生产的状态。当然，他们采用了更新的工具并融入了一些自动化。但这并非关键所在，因为 DevOps 的真正优势在于让开发者能够掌控自己的部署流程，并根据团队的具体需求自动化生产流程。
企业再次试图将一切标准化，追求规模经济。在这个过程中，他们剥夺了 DevOps 的实用性。
如今，DevOps 团队构建的内部工具更多是为了限制而非赋能。他们将每个 API 都包裹在自制的抽象层中，这些抽象层落后于 AWS 等云服务提供商已有的功能。开发者最终不得不乞求支持那些在其他地方已是标准的功能。
最初，DevOps 的理念是信任开发者能够管理生产环境。然而，现代 DevOps 团队却秉持着开发者不可被信任的观点。由于 DevOps 掌握着合规清单，他们将这种不信任感融入了规则之中。例如，SOC 合规最终充斥着各种假设开发者可能是潜在不良行为者的限制——这些规则阻碍多于帮助。
当然，这一切都毫无意义。DevOps 工程师与其他任何工程师一样，都有可能做出恶意行为。解决之道不在于封锁访问权限，而在于让操作透明且可审查。安全源于可见性，而非紧锁的大门。
那么，设立“DevOps”这个职位究竟给我们带来了什么？
它把关注生产环境的工程师从团队中抽离，既剥夺了团队对管理自身生产环境的兴趣也取消了他们的权限。我们通过形式化 DevOps 毁掉了它的本意。
附注：平台工程如出一辙。用瑜伽·贝拉的话说，“这简直是似曾相识的历史重演。”
