实践者的 DevOps 之路(1. 被误解的 DevOps)

近几年随着敏捷在国内日趋流行,DevOps 作为与敏捷方法论相辅相成的 IT 实践也被广大管理者所重视。在过去的几年中我参与实施了大约十几个 DevOps 的相关项目,有成功的,也有失败的。而我的工作跨度也很大,既有作为技术顾问,也有作为 Scrum Master,或者是一名开发者甚至是一名运维。正是这些不同的项目,不同的角色让我对 DevOps 有了更为全面的理解与实践。这次我希望通过一个系列的文章与大家一起分享,也算是自己做一个阶段性的总结。

本文是系列的第一篇,我先谈谈日常遇见的对 DevOps 的一些误解。

DevOps 是银弹

我遇见的大部分想要进行 DevOps 的组织或是团队最直接的原因就是发布困难。例如有些公司的每一次发布犹如孕妇分娩,而且还是难产的那种。整个发布流程充斥着各种「祖传」脚本,手工掺杂自动,相同的操作都可能引致不同的结果。每次发布是否成功都需要些运气,就算是这样发布后还可能遇到类似忘记运行某个脚本这样的低级失误。

这些团队管理者的诉求就是: 给我一个按钮,上面写着「发布」,按一下就凡事搞定!最好这个按钮还是声控的 ????。

实践者的 DevOps 之路(1. 被误解的 DevOps)

但是从系统化思考的角度出发,我们不应该简单的在结果周围找原因,应该从更宽泛的视角去寻找引起问题的根因与解决方案。发布上线的自动化并不是 DevOps 的核心问题域,只是 DevOps 的一种最基础的表现形式而已。

而遇到这些问题的团队或是组织的共同问题就是它们往往不是一个真正的敏捷团队。发布遇到的问题只是前序流程中问题的累积,在最后一个环节爆发而已。你很难单纯地用 DevOps 帮助到一个每月发布一次,缺乏自动化测试,开发运维对立情绪严重的团队做到每天 100 次部署的程度。

所以在考虑实施 DevOps 之前先想一想想要解决问题的根本原因,而不是一味指望 DevOps 一枪解决掉那个狼人。

DevOps 就是采购软件平台

作为第一种错误思维的延续,很多管理者的第一反应是购买一个「按钮」。细心的你会发现这几年 DevOps 软件犹如雨后春笋,有大量软件公司研发了所谓 DevOps 平台软件,仿佛购买了这些软件就走上了 DevOps 之路。

实践者的 DevOps 之路(1. 被误解的 DevOps)

这种想法其实与购买了 JIRA 就等于是个敏捷团队的想法如出一辙。看一下经典的 DevOps 「三步法」,其实其中与所谓 DevOps 软件平台没有什么必然的联系,工具永远是工具,只有遇到合适的人,工具才有价值,否则可能适得其反。

我在许多项目中遇到的情况是,客户上了一套高价采购的 DevOps 平台,经过千辛万苦之后将一些系统的部署流程移植到了这套系统上,本以为之后可以高枕无忧,但是之后发现完全不是那么一回事。

由于系统仍然是基于一个巨大的单体应用,因此发布频率依然是一个月一次,无法快速灵活的提升业务价值,还是整个敏捷流程最后一公里的短板。而发布频率的冗长造成代码冲突概率增加,这些冲突又无法自动 merge,绝大部分仍然要靠人工解决,结果还是效率低下。

因为缺乏自动化测试,发布程序的质量毫无改变,上线之后该有的 bug 还是有。全局监控机制的缺失造成反馈回路的缓慢与滞后,系统的稳定性并没有发生实质性的改变。

类似的例子可以写出很多,最终的结果是管理者质疑 DevOps 的价值,但是却忘了 DevOps 并不是软件系统的别名,而应该是全方位,涵盖整个开发流程的方案,从最片面的一点去寻找全局的成功无异于缘木求鱼,终不可得。

DevOps 就是开发干运维的活

可能是因为名字的关系,许多的 IT 管理者觉得 DevOps 就是开发,运维二合为一,开发干运维的活,运维也做一些开发的工作。这只能说对了一半,的确在 DevOps 的实践中应该打破开发与运维的隔阂,让开发-运维一体化。但这并不是简单的让一个人干另一个人的活,而是应该在组织文化,全功能团队,自动化运维工具的基础上建立的工作角色转换。

实践者的 DevOps 之路(1. 被误解的 DevOps)

曾在一个项目里遇到领导一声令下,开发开始负责部署环境,系统上线的工作,而运维则开始写起了业务系统的代码。开发这边遇到一些网络防火墙的配置抓耳挠腮,搞了半天还是问了运维的兄弟才算搞定部分的配置。而运维这边以前是使用 shell + python 为主,对 Java 一窍不通,只能 copy 代码,一边问开发的同事,一边修修改改,勉强通过编译,但是正确性不得而知。

最后的结果是开发与运维的关系空前的团结,互相理解对方工作的不易,但是开发效率,系统稳定性却是下降的惨不忍睹。DevOps 目标在于培养开发-运维一体化的文化以及 T 型人才,而不是简单的工作内容的互换。

开发与运维都有各自的技能长处,在实际工作中也存在不同的侧重点与分工,这是客观存在,不容回避的。但是一些通用的团队文化才是 DevOps 关心的,例如自动化,例如使用工具解决问题等,如何做好这些是 DevOps 落地的真正挑战。

反思

在过往的项目中我看到了太多对 DevOps 的误解,人们往往在短期内高估某项技术的价值,但是在长期内又会低估它的价值,DevOps 亦是如此。错误的预期 + 错误的实践方法造成了很多 DevOps 的失败案例,下一篇中我会带来我对 DevOps 的认识与实践之路,希望你能够喜欢。

实践者的 DevOps 之路(1. 被误解的 DevOps)

实践者的 DevOps 之路(1. 被误解的 DevOps)

相关阅读:

面对疫情这样的复杂问题,有什么招呢?

疫情中的员工关怀,我只服这家公司

DevOps关键能力之产品和流程 - 重磅新书预览《加速》

实践者的 DevOps 之路(1. 被误解的 DevOps)

小说体敏捷/DevOps转型教科书

和实战经验分享

购书指南


纸质书、电子书在京东当当亚马逊、微信读书等渠道已全面上架,搜索关键字“猎豹 敏捷”即可找到。点击阅读原文可直接购书。

有声书已登录喜马拉雅、微信读书,适合路上听书的你。

关注公众号看其他原创作品

实践者的 DevOps 之路(1. 被误解的 DevOps)

敏于思 捷于行 

坚持每周输出一篇高质量文章

觉得好看,点个“在看”或转发给朋友们,欢迎你留言