与许多流行的技术术语一样，DevOps 已从乐观的顶峰跌落到疲惫的深渊。
其失败的原因在于对软件难以编写的原因存在严重误解。
误解：通过消除部署障碍，可以部署更多软件，事情会变得更简单、更好。
真正原因：问题在于开发人员和运营团队被荒谬的流程和协调所阻碍。
什么是 DevOps？
DevOps 于 2007 年左右推出，这是一个相当激进的概念，旨在消除运行硬件的人和编写软件的人之间的分歧。
当我当时在一家老牌公司工作时，发布软件的流程如下。
- 开发团队通常会与前端团队一起，将服务器软件打包成一个完整的实体，然后剪切出一个带有版本号的版本。他们会在自己的机器上进行本地测试，然后交由质量保证部门进行测试，最后在质量保证部门的检查合格后交付给客户。
- 运营团队会收到一份操作手册，有效说明软件正在发生哪些变化，以及如果软件崩溃了该怎么办。其中包括软件的安装方式、是否会对数据库造成影响等，是一份完整的活文档。这样做的目的是，管理服务器、网络设备和 SAN 的人员根本不知道软件是做什么的，也不知道如何修复，因此他们需要的实际上是一步一步的指导。有时，你甚至会得到一份纸质文档。
- 由于这些问题经常发生在数据中心内，因此你没有无限增长的弹性。因此，如果可能的话，你会慢慢地推出更新，并每隔一段时间停止监控。但你不能像现在人们看到的那样进行蓝/绿部署，因为你很少有足够的多余服务器容量为所有用户同时运行两个版本。有些组织确实会在不同时间使用不同的数据中心，并在它们之间进行切换（这被认为是最高级别的安全措施）。
- 你会选择一个部署日，通常是一周的中间，当地时间上午 10 点左右，然后监控你所掌握的任何指标，看看发布是否成功。这些通常都是非常基本的成功指标，包括一些令人瞠目结舌的指标，如 "支持部门是否收到了更多的服务单 "和 "我们的正常运行时间网站是否获得了更多的点击率"。实际上就是 "负载平衡器是否满意 "和 "客户是否主动向我们抱怨"。
- 您将完成部署，然后待命团队将在您进行部署的过程中监控进度。
为什么这个方法不管用
部分问题在于这种设计非常耗费人力。你需要足够多的开发人员一起协作才能发布。然后你需要一个配备人员的 QA 团队来实际使用该软件，并在刚刚开始成为一种事物的自动化测试的基础上确保该软件确实有效。最后，你需要一名技术作家与开发团队合作，讲解发布手册是什么样子的，然后最终让运营团队接收、审查该手册，然后实施该计划。
它也非常缓慢。即使功能已经完成，也经常要花几个月的时间才能推出，因为必须先推出更重要的功能。或者这次更新会对数据库进行重大更改，我们不想将六件事与一个可能造成灾难性的变化捆绑在一起。这实际上是敏捷与瀑布设计分解为实际步骤。
当时，很多关于组织变革的空谈都是废话。企业如此迫切地想要变革的真正原因如下：
- 有很多技术员工是必须的，他们不能轻易替换，这让人很无奈
- 招聘难度大、成本高。
- 销售人员不能轻易地将他们最后一刻提出的交易要求注入发布周期，因为这往往是板上钉钉的事。
- 这为 SaaS 供应商提供了一个绝佳的机会，他们可以将复杂性卸载到自己的堆栈中，从而将自己注入到流程中。
- 在云平台开始吞噬市场份额的时候，这一变化也强调了云平台的优势。你不需要大量的规范，只需分配更多的服务器即可。
- 钱（实际上）是免费的，所以不管每月账单如何，提高速度才是上策。
- 开发人员可以理解地感到沮丧，因为微小的改动可能需要数周时间才能完成，而他们却因客户投诉而受到指责。
DevOps 与 Agile
DevOps 与 Agile 的结合最终产生了一种非常不同的编程哲学，其具有以下特点：
- 用户就是测试者
- 每个系统都是你的专长
- 运输速度高于一切
- 通过指标来掌握
- 正常运行时间免费，SSO 需要花钱（免费功能是付费功能，昂贵的可用性不收费）
- 日志是商业智能
这种模式的漏洞很早就出现了。开发人员在本地 Mac 和 Windows 机器上进行测试，然后将代码部署到根据 Ansible 剧本配置的 Linux 服务器上，并运行数月甚至数年。运行中的生产服务器群不可避免地会出现细微差异，要么是出于安全原因的软件包升级，要么只是随机配置事件。
很快你就会看到类似这样的信息：“它在 1、2、4、5 号机器上运行良好，但 3 号机器似乎有问题”。在 DevOps 模型中，谁应该去弄清楚发生了什么或如何发生并不明确。
很快，开发人员的反馈开始堆积如山。他们不想花费这么多时间来弄清楚他们想要哪个 Debian 软件包来满足这个或那个依赖关系。这不是他们感兴趣的工作，而且他们也不会因为这项工作而得到奖励，因为他们几乎完全是根据他们发布的软件来衡量晋升的。
此时，您会看到非常奇怪的工作流程：在部署期间，按小时付费的生产服务器数量增加一倍，然后慢慢缩减，所有这些都依赖于相同的 AMI（服务器映像）来确保某种基本一致性。但是，由于对 AMI 的任何更新都需要进行完整的开发阶段生产检查，因此安全升级等工作需要很长时间。
进入容器
升级 Kubernetes、升级主机操作系统、制定防火墙规则、设置服务网格、执行网络策略、运行堡垒主机、配置 SSH 密钥等。组织很快发现，这些事情非常耗时，而且通常需要比他们之前摆脱的角色更多的专业化。
以前，您需要一名 DBA、一名系统管理员、一名网络工程师和一些一般的运营人员。现在，您需要的人员不仅要了解数据库，还要了解特定云提供商版本的数据库。您仍然需要具备系统管理员技能的人员，但此外，他们还需要是您的云平台专家，以确保您不会将数据库暴露给互联网。
平台工程
由于没有新的想法，只有新术语，王位的继任者已经出现。开发团队不再需要了解和排除运行其软件的平台的故障，相反，整个过程完全从他们身上抽象出来。他们提供容器，这就是关系的结束。
将平台运营的所有权交给了从一开始就应该拥有它的人。这也消除了一些关于谁的问题的模糊性。开发团队仍然需要随时处理特定的应用程序错误，但平台团队可以执行更多的全局规则。
结论
我们现在看到基础设施领域正在大幅萎缩。团队越来越多地寻求简单、更少平台特定性工具。在我的个人圈子里，这感觉就像是真正的回归本源，因为中小型组织放弃了 Kubernetes 之类的技术，并采用了更简单、更易于故障排除的工作流程，例如“拉取新容器的 bash 脚本”。
从某些方面来看，这是一个积极的变化，因为组织不再假装他们需要“全球规模”，而是可以专注于实际服务其拥有的用户和开发人员。
然而，平台工程并不是解决问题的灵丹妙药。相反，它只是云提供商急于显示月度增长的另一种行业杜撰，他们知道团队缺乏创建此类实践所描述的工具的专业知识。在现实中，企业需要更加坦诚地了解自己的实际需求，而不是被引导去相信自己需要什么。