回应 | “DevOps是扯淡：是时候埋葬 DevOps了！”

导读

到底什么是Devops？

DevOps 是衔接自动化软件开发和运维团队之间的流程实践，以便更快地构建、测试和部署应用程序。DevOps 被赋予组织内相对孤立的运维团队之间以协作文化。DevOps 的优势在于加快软件发布速度、优化流程、增强信任以及快速解决关键问题和更好地为客户服务的能力。

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

这并不是Devops方法论出问题了，而是错误的实践给人们带来了困惑，从而让人开始质疑Devops，人们对任何方法论态度变化几乎如出一辙，捧到天上，然后摔到地下，找下一个代替，永远不关注问题本身，而是寻找一合法性说辞来说服老板，说到根儿上这是企业负责人到底懂不懂以及企业文化的问题，跪权威获生存，你说的都对，但跟老板意思不符。

疫情将加速有些传统企业下滑，他们要么一盘散沙，要么充斥独裁专制之风气。这都会在无形中扼杀员工的创造性。随着市场竞争加剧，他们的生存环境将越来越恶劣，最终走向衰亡……

这是一最简单问题，但无数人在不断重复，从过去到现在...也还会到未来，人群有这么个毛病，就是从来不会从错误中真正反思。复盘都是扯犊子。

为什么我们对Devops不再有更宏大梦想？

拆除孤岛、提升工程速度、增加价值？

DevOps承诺的这些优点还记得吗？

这些不是DevOps应该做到的吗？

Devops的价值应该是什么？

通过按 feature 发布，feature 发布可以到天 

对客户来说需求的响应速度更快 

每次减少发布范围，降低出错的概率，提升质量 

出现问题，及时响应；通过回退，或者快速修复，提升产品质量 

通过合理的拆解，降低耦合度，通过分田到户提高团队积极性 

减少吃大食堂，相互等待，上下文切换导致的效能降低 

对管理者可以释放低效的组织协同工作，聚焦到更 high-level 的业务机会和项目机会上 

打通开发、运维边界，减少上下文切换 通过合理的微服务拆分，单个任务的难度变低

Devops “CALMS”原则是什么？

Culture（文化）- 是指拥抱变革，促进协作和沟通 

Automation（自动化）- 是指将人为干预的环节从价值链中消除

Lean（精益）- 是指通过使用精益原则促使高频率循环周期 

Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期 Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进

（CALMS有问题么？没有，很对。不以为然的人会说：这都是怎么都说不错的废话，然而只有上士闻道勤而行之。）

你有一个叫DevOps的团队，但它是真正的DevOps吗？

他们做的大部分工作无非是使用Terrform和YAML为工程团队做一些琐碎的任务。

Terraform是一个IT基础架构自动化编排工具，可以用代码来管理维护IT资源。它编写了描述云资源拓扑的配置文件中的基础结构，例如虚拟机、存储账户和网络接口。Terraform的命令行接口（Command Line Interface，CLI）提供一种简单机制，用于将配置文件部署到云上，并对其进行版本控制。

YAML的意思其实是："Yet Another Markup Language"（仍是一种标记语言）YAML是一个可读性高的用来表达资料序列的格式。

需要数据库？

————向DevOps提交工单。

需要身份和访问管理（IAM）角色？

————向DevOps提交工单。

"不久后，

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

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

你在做DevOps，但感觉糟透了......

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

最佳实践？

————我们会一路上发明它们！(读到这儿，请允许我笑一会儿）

安全吗？

————我正忙着提高转化率呢！(茶水差点喷出来）

命名约定？

————不。生产环境中没有命名约定。（哈哈哈...这哥们儿文笔真的幽默，他说的是典型的没经历服务管理优化，直接放个Devops工具上去的后果）

成本管理？

————删除未使用的云资源？不，我们有AWS积分还没用掉呢！（哈哈哈，这思路够坑爹了，你公司老板看到这儿估计要喷血了，到底啥重要啊，哈哈）

你的Devops是不是已经做到死胡同里了？

看到这，我们不能被他给带偏了，别管它叫啥ops，是什么业务背景催生了生产模式的必然变化？ 

1、业务的敏捷性持续发布 

2、应用平台的弹性诉求 

3、商业环境的变化 

这是整个云原生产生的业务背景。

云原生应用程序都是关于动态性的，而微服务架构对于实现这一目标至关重要。通过部署专注于明确定义范围的较小服务来帮助分而治之。这些较小的服务需要与不同的软件即服务端点、旧版应用程序和其他微服务集成，以提供业务功能。虽然微服务将其功能公开为简单的 API，但理想情况下，使用者应将这些功能作为集成的复合 API 进行访问，以符合业务需求。API 主导的集成平台与云原生技术的结合有助于提供对数字化企业至关重要的安全、托管、观察和货币化 API。

定义和实现微服务后，应将它们与其所有依赖项捆绑在一起，并作为容器映像提供。Docker 是目前流行的容器映像格式。这些映像应存储在注册表中，其他开发人员以及运行时环境可以从这些映像中提取和创建容器。

ITIL/Devops到底重不重要呢？

在企业中，大多数工程师不想做运维工作。工程、产品、运维都只想操心自己这一摊儿。工程师只想构建产品。他们只想添加有形价值。但是组织会把运维工作强加在他们头上，工程师们要么使用已有的工具来工作，一路蒙过去，猜测某种新的云服务，要么DevOps任务慢慢地变成少数几个人的责任，这些人于是成为了“DevOps”背锅侠，然而他们扛不了多久。

这个场景最糟糕的部分就是上线到达之日，产品利益相关者看不到运维。

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

"你的团队慢慢觉得可灵活扩展的DevOps变成了僵化的基础架构，因为团队不再做出艰难的运维决策，而是完全围绕已有的工具开发软件。"（这就完犊子了，运维灵魂没了，ITIL到底重不重要啊？哈哈）

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

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

Cory进一步分享了他的故事：

我在工程部门的运维团队已工作了很长时间。

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

Ruby，一种简单快捷的面向对象（面向对象程序设计）脚本语言，在20世纪90年代由日本人松本行弘(Yukihiro Matsumoto)开发，遵守GPL协议和Ruby License。我们需要向日本人学习...这已是大约30年前日本人干的事儿了..我最近在看90年代日本商业电影，发现内时候日本人已经预言了当今市场应该做什么，已然在谈“硬体向软体业务甚至向内容业务转变....”

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

想知道秘密吗？

我为每一家公司复制粘贴了几乎一模一样的Terrform模块。我的工作感觉像是在行骗，但这些公司付钱给我是冲着我在Kubernetes方面的专业知识，而不是因为我编写Terraform。（显然核心价值不在于资源调用侧，而是如何更好的辅助多变业务、多快好稳的更新业务）

kubernetes-面向应用的容器混合云，专为多云，多集群，多团队，多租户应用场景而设计。一个控制台解决开发，测试，运维所有困扰。

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

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

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

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

专业知识才是正事，要回归本位，探求真的企业知识。

说ITIL/DevOps是扯淡，那是因为你把它当成了新华字典，但学习新华字典，还要让供

应商把新华字典在你们公司推广，那不仅仅毫无意义甚至荒诞离奇。

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

别纠结方法论本身，适宜用之这是高手。

你真做过Devops了吗？还是只是一直在叫？

规划

今天的规划必须了解云服务以及技术栈，并进行标准取舍。

致力于平台工程的组织更须确定一条最佳路径，以及一系列优化流程。

这条最佳路径应能提供方向和确定性，并当业务需求发生变化时也须能灵活适应。

对于DevOps实践上，Dora曾经提出过五个阶段的指导，

其分别是： 

Stage 1: 规范化技术栈 

Stage 2: 推进标准化&降低不一致性因素 

Stage 3: 扩展DevOps实践 

Stage 4: 自动化基础框架交付 

Stage 5: 提供自服务能力

编程

编程正变得越来越像云API大杂烩，但却如此重要。

从目前运维的发展形势来看，云活跃了十几年了，各云平台为提供给用户灵活的运维，都已提供API接口，这些接口都支持python的sdk，再过2年如果你不懂得如何调用云平台接口去开发适合自己的定制化运维系统，我估计连做运维的资格都没了，还有像现在的开源系统ansible,saltstack,等，这都是Devops基本技能要想玩好这些，python不能不学。

声明：我没收python培训公司广告费。

如果想做运维业务，无论甲乙方，不会python，早晚面临下课。

我们应编写和运行更少的、更精简的代码。

编程协作同样重要。

如，由于你没有意识到SNS主题与你的SQS队列在不同区域，于是加班加点，还是未赶在截止日期之前完工，因为你在等待运维团队的某个人更新IAM策略并创建KMS密钥。

优秀的内部开发平台须明确协定，以规约职能集中、从而处理云端那些琐碎的共性任务，比如对IAM和KMS这些耗费大量时间的任务进行集中处理。

优秀的内部开发平台应专注于工程师的需求，而不是让工程师为实施细节而操心。

构建、测试、发布和部署

持续集成/持续交付（CI/CD）阶段是运维团队与工程团队之间产生挫折和分歧的根源。

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

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

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

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

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

操作和监控

在Devops里，由网站可靠性工程师（SRE）来解决这个问题。

SRE起源于国外大型互联网公司，直接掌管着互联网公司的机器和服务，保证网站不宕机是他们的使命。SRE基本是从软件研发工程师转型，有很强的编程算法能力，同时具备系统管理员的技能，熟悉网络架构等，是一个要求非常高的职业。 

大部分人理解SRE等于传统运维工程师(OP)或者系统管理员(SA)，实则不然，这两类角色离一名合格的SRE还有太大的差距，完全无法匹配得上这个称号。在国内，只有少数几家顶尖互联网公司才会出现真正的SRE。

为什么诞生了 SRE？这是全新的事务么？

原因一：企业成本的增长同用户的增长不成线性变化。但是随着系统的复杂度提升，组建越来越多，用户的流量压力也越来越大，相关的变更也会越来越多，各模块之间的变更顺序也会越来越复杂。在这样的情况下，单纯的靠运维人力的数量提升无法满足业务的发展需求，而且会提升企业的成本；

原因二：传统的研发团队和运维团队天然具有冲突。公司的IT人员的配置：研发（Dev）和运维（Ops），研发部门聚焦在快速构建和快速发布；运维部门关注的是如何避免发生故障，从目标上讲就是矛盾的。且随着 IT 技术的发展，对 IT 从业者的要求也越来越高，既要懂得底层系统，也要懂得数据算法，同时对主流技术还要快速追赶，满足这样要求的人才太少；

原因三：生产工具为适配生产力发展的必然产物。为了提高IT行业的整体效率和质量，使得从手工运维时代，逐渐过度到脚本工具运维，在发展到平台数据运维，再到平台软件运维，在发展到智能自动化运维。通过一系列手段、工具、理念的进步，将 Ops 技术发展到 DevOps、DataOps、AIOps 等；

SRE到底干点啥，一张图就清楚了

（理解ITIL的人，立马知道这是啥，可用性管理的具象化，对不对？呵呵，毫不新鲜，也不可能有啥新鲜东西，技术革命都已经陷入停滞了，IT这么细分的技术领域怎么可能有惊天动地的变革？是的，都说长安尽头无故里，然而你就是故里，哈哈哈）

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

PostgreSQL是一个强大的开源对象关系数据库系统，经过35年的积极开发，在可靠性、功能健壮性和性能方面赢得了很高的声誉。

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

是时候埋葬DevOps了?

在过去这两年，Cory花了大量的时间与诸多团队讨论他们的云基础架构和DevOps流程/文化。

从一个又一个团队听到了是时候埋葬DevOps的抱怨。

说到如今DevOps的现状，更令人担忧的是听到了其他一些声音：

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

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

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

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

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

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

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

Devops在企业的实践状态确实已经进入迷途。

越来越流行的时代精神是“平台工程是未来。”

“许多组织无法指望“DevOps”团队来搞平台工程，从而抵达成功彼岸。在git代码存储库之间复制/粘贴一些Terrform模块是糟糕的“平台”。你的工程师不想处理它，运维团队将不可避免地负责支持它。”——Cory

Git 存储库将每个文件的每个版本存储在存储库中，除非你告诉 Git 忽略某个文件。Git 有效地保存文件版本，因此存储大量版本不一定需要大量磁盘空间。Git 支持比较文件版本、合并不同版本、在版本之间切换等。

平台工程的思路是对的，但这显然不是Devops一个小团队可以承受之重哈。Devops其实是一种工作模式，不能将其扔给某几个人承担企业整体信息化的责任。

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

只要雇佣更多的前端和后端工程师来开发一个优秀的内部PaaS，使用运维团队在构建设计的所有最佳路径，同时尝试构建在其上运行的实际产品。（这哥思路非常清晰，产品研发留给产品团队，运维设计留给运维团队，Paas平台交给前后端工程师，）。如果你要做业务外包，则可参照下图明确双方管理分配。

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

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

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

一定要保持敏捷。

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

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

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

变与不变

变的是更精益敏捷，不变的是以客户为中心，服务为导向。

在短开发周期、频繁的发布以及不断变化的市场需求中，用户体验扮演着重要的角色。为应对这一趋势，软件开发人员开始在每个SDLC阶段优先考虑以客户为中心的方法，以减少产品生命周期的早期阶段的性能故障和瓶颈。相应地，性能测试目标已经转变为详细检查系统的不充分性能，并了解它在软件开发过程中的根源。