目睹 DevOps 之怪现状

注释：所有图片均来自网络，如有侵权，请联系删除。

我不是一个具有 20 多年资深 DevOps 经验的大咖，我只是一个生活在电脑前面的一个“键盘侠”。

devops-keyboardman

DevOp 是怎么来的

先来了解一下 DevOps 的发展历史。正所谓以史为镜可以知兴替，了解 DevOps 历史，就知道它怎么来的，也就能知道它是怎么发展的（也有可能是怎么没的）。

说起 DevOps，Patrick Debois 这个名字是无法绕过的，正是下图这张图片所对应的主人公：

devops-Patrick Debois

2007 年，作为系统管理员的 Patrick Debois 在给比利时一个政府项目做迁移的时候，发现开发和运维之间不是很对付，尿不到一个壶里去，这让他有了思考，如何让这两股绳拧到一块儿？

2008 年 8 月，多伦多的敏捷峰会上，一个名叫 Andrew Shafer 的软件工程师本来要做一个题为”Agile Infrastructure“的分享，结果就一个听众，没错，唯一的听众就是 Patrick Debois，Andrew 一寻思，算了，不讲了，于是两个人在长廊聊了很久，随后基于聊天的内容在 Google Group 上创建了一个名为 Agile Systems Adminstration 的 Group，希望能有更多人加入讨论；

2009 年，这是一个重要的年份。在 O’Reilly Velocity 会议上，John Allspaw 和 Paul Hammond 分享了一个主题为” 10 Deploys a Day: Dev and Ops Cooperation at Flickr“。Patrick Debois 一拍大腿，这就是我想要的。但是 Patrick 是远程参与的，大有身不能至心向往之的感受，于是他在推特上表示了未能亲自参与的遗憾。结果 Paul 在推特上回复了他：你为啥不自己搞一个 Velocity 活动呢？于是乎，在同年 10 月 30 日，会议召开了，取名为 DevOpsDays。参会人员众多，有开发，有系统工程师等，会议结束后的讨论阵地挪到了推特上，并最终确定名称为 DevOps，此后 DevOps 相关的活动在全球就一发而不可收拾了。

从 DevOps 的诞生能看出，DevOps 是要解决人的问题。这一点在 2020 年 Patrick 接受一家媒体采访的时候，依旧是这么表达的。当然，初始的时候只是牵扯了开发和运维人员，但是时至今日，已经是所有与软件研发相关的人员了（可查看 Patrick 在伦敦 QCon 上的分享“DevOps beyond Development and Operations“）。

Patrick 在接受采访的时候说过：针对 DevOps 的提出，从来没有一个很宏伟的计划（There never was a grand plan for DevOps as a word）。这一点让我想起了 Linus 的 Just for fun，Linux 最初并不是以一定要变得伟大的信念去创作而诞生的。从这看，可能很多事情是我们过分解读了（有木有想起，国内研究某学的大师们），过分的解读就有点矫枉过正了。
让我们一起看看国内 DevOps 的一些怪现状。

DevOps 之怪现状

01 DevOps 从改名开始

把原来的 Ops 团队改名为 DevOps 团队，宣告 DevOps 的实践正式开始，不对，说 DevOps 实践有点 low，应该是 DevOps 转型。抑或招聘一个 DevOps 工程师，要求上能撸码写算法，下能运维搞迁移，文能背诵方法论，武能搭建工具链。招聘操作猛如虎，一看一个 Jenkins。

02 迷信大厂的最佳实践

先抛开大厂是不是有最佳实践一说，先来看看最佳实践这个表述，从哲学的角度看，最佳这种带有绝对意思的表述就是不成立的。最佳意味着唯一，只有这一条路或者一种方法能达到这个目的。那唯一的那一条路别人都已经走过了，还能给你留机会？其次，如果大厂真有最佳实践，那为何大厂卷成狗，而且发明了 996、007 这种违背最佳实践的工作模式呢，这不是搬起石头砸自己的脚吗？有了最佳实践神功护体，居然还在坑里，岂不是侧面说明大家能力不行？

退一万步讲，大厂基于自己“大规模”、“超大规模”的应用，无数次折腾研发总结，无数个 996，无数根头发堆积出来了“最佳实践”，是否能移植到自己身上呢？自身是否具备孕育这些最佳实践的土壤呢？这有点像某些短视频平台上的大师们教大家如何轻松年入百万，屁颠屁颠儿的花钱报名听课、培训，最后发现答案很简单：让自己有钱的老爹给自己的账户存一个亿，一年利息好几百万，小目标就达成了，多简单，简单的跟吃饭一样。

俗话说，成功的经验不可复制，失败的教训倒是可以借鉴。如果反着听所谓的最佳实践，或许还能有一线生机。

03 喜欢新词，更喜欢造词

DevOps 的出现就像打开了 Ops 的潘多拉魔盒，造词浪潮一波接一波（AISecOps，GitSecOps，DevBizDecOps，DevBizFinSecOps 等等），各种 xOps 的创始人也浮出水面，可以从一环（Ops）造到二环（DevOps 是个倒 8 字，可以视为两个环），再到三环（比如 GitSecOps，笔者在去年的多个场合分享过 GitSecOps，现在想来惭愧至极），要是心情好，“奥运五环”信手拈来（DevBizFinSecOps）。

当然，这些也不足为奇，毕竟外国同行有时候也这么搞，但是我们除了造词，还喜欢咬文嚼字。比如规模化 DevOps、DevOps 规模化。

当然，这些也不足为奇，毕竟新的词语能吸引一波流量，可以给大会带来一些报名（赞助）。只是吃一顿肘子很香，顿顿吃肘子就有点腻歪了。不管你是甜味的肘子（DevOps），咸口的肘子（AISecOps）还是其他口味的肘子（xOps），终归还是肘子。

04 喜欢高度，更喜欢拔高度

DevOps 转型的 xx 要素，xx 步法，xx 原则；

DevOps 1.0 时代，DevOps 2.0 时代，……；

DevOps 是提升 xx 效能的有效手段，是 xx 转型的重要基础，是推动 xx 经济的重要抓手；

这一点貌似并不只属于 DevOps 领域。如果套在云原生，开源领域，似乎也很顺口。

05 培训 + 认证，新的双循环

35 岁这个可怕的数字一抛（焦虑感爆棚），DevOps 高薪的广告一打（佛光出现），过万的培训课程一出（零基础可学），不出三月，一批批 DevOps 专家就诞生了，至于能不能最终入职大厂，拿到高薪，那就得看命。如果不信命，你就再来报一个其他的配套课程，只要你敢来（有钱），就能让你变成资深专家。

对于从小在考试中摸爬滚打中成长的我们，这些都似乎见怪不怪了。

06 流于形式，耻于工具

不管 DevOps 是一种文化也好，一种运动也罢，归根结底需要落地的。就像前几年习大大提的脱贫攻坚一样，最终落地的形式根据不同区域来制定不同的脱贫手段，比如养殖、种植、农村旅游等。再美好的 DevOps 最终也需要落地，不能总是飘在天上，这种落地的支撑就是工具。但是，很少看到宣讲的资深 DevOps 工程师们去分享工具的具体使用，甚至当场给你撸个码，给你展示一下神奇的力量。

分享的 PPT 内容一定是高大上的，DevOps 转型的能力或者平台一定是底层是各种云（公有云、私有云），上去是各种能力，最上面是各种成功，横竖很分明，有纵深有横阔。你要是能看到与工具相关的技术实践，那你听的这个分享算是赚到了。

可能工具是技术人的事情，是个人都能搞，百度一哈，就能轻松搞定，没有挑战，不足以显示 DevOps 转型的高大上。如果搞不定，不好意思，那你就加班吧，转型的牛我已经吹出去了，至于落地，那是你们的事情。

在这一点上，笔者查看了 cdCon 2021 的分享话题，大概做了一个统计，讲 Tekton 的有 9 个 topic；讲 Jenkins 及 Jenkins-X 的也有 9 个，其他还有 Spinnaker、GitLab 等。话题里面频繁出现 CI/CD + Pipeline 出现的频次达到 20+，下图只是简单的搜索，就有三个话题连续是 CI/CD 相关：

完整的 topic 内容可以查看：https://cdcon2021.sched.com。

至于国内是什么样的，大家可以在眼花缭乱的 DevOps 会议的海报上自行查看。

07 DevOps 宣言

基于 PPT 的 DevOps 优于基于工具 DevOps
基于口号的 DevOps 优于基于实践的 DevOps
面向领导的 DevOps 优于面向开发者的 DevOps
面向造词的 DevOps 优于面向创新的 DevOps

写在最后

DevOps 不是灵丹妙药，把好自己的脉，根据自己团队的情况，大家踏踏实实搞点事情才是王道。
DevOps 要解决的问题自软件诞生以来就存在，归根结底是人的问题，毕竟有人的地方就有江湖，有江湖的地方就有利益争斗，尔虞我诈，这里面暴露的是人性的问题，如果感兴趣，可以翻阅一下笔者前面写的一篇文章：DevOps 的问题是关于人性的问题，你信吗？