第01课:聊聊不一样的

第01课:聊聊不一样的 DevOps(上)

随着 DevOps 的盛行,我和越来越多的人聊到 DevOps,也听到了很多人在讲 DevOps,我发现很多人讨论的背后,对 DevOps 所指并不是同一件事情,所以往往不欢而散。

于是我开始从头整理 DevOps 的所有有关材料,并把他们陆续放在了简书上,形成了“DevOps 前世今生”这个系列,这个系列还在不断补充新的资料。随着知识和实践的不断增长,我也渐渐的对 DevOps 有了更进一步的认识。

在过去的四年中,我作为 DevOps 的咨询师参与了国内外很多企业的 DevOps 转型以及技术实施咨询,也在不同的社区活动和运维大会中分享了自己在 DevOps 上的实践、理解和观点。

含义越来越丰富的 DevOps

DevOps 至今都缺乏一个准确和清晰的定义,这是一件好事,也同样是一件坏事。虽然 Patrick Debios(DavOpsDays 的发起人和运动领袖 )曾经在自己的博客里一再提到自己对 DevOps 的“正确认识”,但社区似乎不以为然。

对于 DevOps 来说,这是一件好事,也是一件坏事。

好事是没有人可以垄断 DevOps 定义的话语权,因此每个人都自己可以参与到这一运动中去,不断为其增加新的概念、新的实践和新的工具,这会让这个社区不断的繁荣,而不会由某一厂商垄断而独大。

而坏事则是对于 DevOps 的跟随者——那些早期没有参与进来的人——需要学习和理解的内容的广度和深度也越来越大,随着开源社区和企业之间的不断“贡献”,各种打着 DevOps 标签的概念、方法论、服务和产品也层出不穷。

于是有了以下这幅众所周知的“盲人摸 DevOps”图:

盲人摸 DevOps

从图中我们可以看出,DevOps 是一系列概念的总和,任何一个单一方面只是 DevOps 的一个部分,但任何一个方面都不是 DevOps 的整体。随着 DevOps 这个概念的不断膨胀,人们就更难理解 DevOps 了。

你理解的 DevOps 是指的什么

在接触了各类客户和社区之后,我开始尝试理解每个人谈到 DevOps 的时候,背后的目标和动机是什么。渐渐的,我把我所接触到的 DevOps 理解分成如下四类,分别是:

  • DevOps 是一组技术实践
  • DevOps 是一个岗位角色
  • DevOps 是一种工作方式
  • DevOps 是一种组织结构

那么,分别来谈谈这四类 DevOps;本篇来谈谈 DevOps 分别被理解为技术实践和岗位角色;下篇再谈 DevOps 作为 工作方式和组织结构。

当 DevOps 是一组技术/实践

在工程师文化的组织里,对先进技术的渴望是最常见的动机,可以促进工程师用更有效率,更优雅的方式解决问题,而对于非工程师文化的组织,新的技术往往是提升其 KPI 的工具。而仅仅追求 KPI 却不追求本质,则是很多组织转型失败的原因,以下是我听到 DevOps 的时候,经常能触及的技术类话题:

  • 高频部署
  • 持续交付
  • 云计算/虚拟化技术
  • 基础设施即代码
  • Docker
  • 自动化运维
高频部署

在 2016 年 5 月中旬的时候,我有机会和某跨国著名银行的 IT 某部门负责人交流 DevOps,对方声称自己是行业里的 DevOps 翘楚,并很自豪的告诉我,他们某应用部署频率每天已经超过100次,这让我很疑惑,于是我问了以下几个问题:

  • 为什么你们需要这么频繁的部署?
  • 有这么频繁变动的业务需求吗?
  • 在这么多次部署里,是发布业务价值的部署更多,还是修复问题的部署更多?

对方并没有直接回答我的问题,而是含糊其词告诉我这是秘密,我看他不好意思回答,也就作罢了。

这让我引发了一个重要的警示:指标导向的 DevOps 转型往往是一种 DevOps 的反模式,它会忽略和掩盖真正的问题,而使问题表面上得到了改进。

指标的背后是对问题的度量,如果我们度量错了东西,那么方向就有可能是错误的。在上面的例子中,如果部署频率一直很高,不一定是个好现象:不是业务的变动很频繁,就是技术的变动很频繁,但如果二者都频繁,我们应该优先变动价值较高的:有可能新的业务尝试让我们从市场上获得了更多的关注,也有可能新的技术提升了生产率。但无论是哪一种,部署频率应该是一个由多到少不断循环的过程。这表明系统在走向成熟和稳定的同时,能够及时响应变化,无论是对技术还是对业务,都需要一个认识的时间。但,如果对为什么变更这么频繁缺乏足够深入的认识的话,问题的严重程度可见一斑。

此外,DevOps 绝不是为了提升部署频率而牺牲了软件质量和业务价值,甚至是安全措施。换句话说,DevOps 不是一种平衡和妥协,它是一种改进。有时候,为了换取更多更快的部署,则会减少一些必要的质量保证措施和安全措施,但这是对 DevOps 的误解,DevOps 是一种改进,改进就意味着以价值兑现为最高原则所度量的相关指标是不能有所下降的。

持续交付

当碰到 DevOps 的时候,我们必然会听到“DevOps 流水线”。这是从持续交付的“持续交付流水线”中演化而来的概念,只是在 DevOps 的场景下,持续交付中的持续部署和发布,被看做是和 DevOps 相关的概念。

持续交付是 DevOps 中非常重要的实践,在 DevOps 概念诞生之前,就有了持续交付的思想,只是持续交付这个重量级话题直到第二届欧洲的 DevOpsDays 才被更多人知道。

持续交付本身也通过技术实践解决了 DevOps 最开始所面临的 Dev 和 Ops 的部门墙的问题。不夸张的说,如果 Patrick Debois 早一点读到持续交付中运维的话题,说不定就没有 DevOps 了。

但是,由于 DevOps 所涵盖的话题已经超出了持续交付本身。因此,持续交付只能算是 DevOps 的其中一个实践。

我把持续交付列为 DevOps 的核心实践之一,因为如果你没有实践持续交付,那么根本不能称之为 DevOps,但是如果你完整实践了持续交付,那么你离完整的 DevOps 技术实践也不远了。

云计算/虚拟化技术

随着分布式应用在互联网时代的井喷式发展,基础设施的管理成为了分布式应用的新瓶颈,在基础设施集中式管理的时代,大型应用只能运行在昂贵的小型机上,只有微软、SAP、IBM、Oracle 和 EMC 这样的企业才有能力提供相应的产品完成这样复杂度很高的架构。因此企业需要单独的运维部门(Ops)来管理这些软件和设备。

而随着虚拟技术和云计算的兴起,企业的基础设施管理工作往往变得很简单。VMWare 这样的虚拟技术企业和 AWS 这样的云计算供应商提供了更加成熟和稳定的产品,大大的节约了企业机房管理的开支。

而传统意义上 Ops 不再需要进出机房,只需要通过远程桌面的方式就可以使用各种 SDK 开发工具去完成过去很多只有在机房才能做到的任务。

但是,即使采用了先进的虚拟化技术提升了 Ops 的工作效率,减轻了 Ops 的痛苦,但仍没有解决 Dev 和 Ops 之间的“部门墙” —— 开发团队和维护团队仍然各自为政,通过责任判定,而不是合作共赢来促进软件交付的高效运行。

基础设施即代码

尽管有了云计算和虚拟化技术,传统思维仍然限制住了资源的管理。随着设备和网络的持续增多,加之更加复杂的应用部署和初始化,基础设施的管理成为了一个十分尖锐的问题,当复杂度上升一个量级,就需要专业的管理工具来管理这类问题,于是 Puppet 这样的框架顺势而出。以至于在 《DevOps Handbook》中,合著者之一的 John Willis 在理解了 PuppetLab 的创始人 Luke Kanies 关于配置管理的核心思想之后,才诞生了 DevOps 的最初想法。

基础设施即代码利用了编程语言和虚拟化工具 API 的无缝连接达到这一目的,并且通过高效的版本和配置管理使其井井有条。

这种技术在很大程度上把基础设施的管理当做其问题域,采用正确的面向对象抽象,让开发人员和运维人员能够理解并设计出更加稳定和灵活的基础设施,并大大降低基础设施变更的风险,这不光提升了运维知识的透明度,并使基础设施变更具备幂等性。

因此,它在一定程度上解决了不同环境(开发、测试、生产)之间的不一致问题,也让开发人员能够学习到 Ops 领域的知识并用软件开发的优秀思想解决运维领域的问题。

基础设施即代码除了工具以外,更是一种 Dev 和 Ops 之间相互沟通的媒介,能够让开发人员和运维人员相互理解。所以,基础设施即代码毫无疑问的是 DevOps 的核心实践之一。

Docker

从某种意义上说,Docker 是含着 DevOps 的金钥匙出生的,它诞生的第一天就带着 DevOps 的基因:更简单的解决了基础设施即代码和虚拟化在实践中的问题,进一步提升了自动化能力以提升效率,并且对开发人员和运维人员都十分友好。

Docker 一定程度上简化了基础设施的初始化和状态管理问题,通过镜像和运行时容器封装了应用运行时的复杂度,并通过容器的编排使轻量级的分布式架构更加经济快捷,而且很多地方都会以是否采用 Docker 来评判是否采用了 DevOps 的相关技术。

但是,Docker 和任何一种工具一样,都不是“黄金锤”。当用错了场景,使用 Docker 可能是一场灾难。我曾经参与了一个整体基础设施迁移的项目,工具就是采用 Docker,最初的目的是因为 Docker 镜像的移植性好,但是客户为了能让 Docker 镜像的业务场景更加通用和可定制化,又分别采用了另外两种工具对其部署场景进行封装,写出了第三种工具。然而,由于这个工具并没有很好的分离其业务关注点和技术关注点,导致这个工具使用更加繁琐,使得原本为了提升生产效率的 Docker 反而成为了阻碍效率的绊脚石。

自动化运维

有很多对 DevOps 望文生义或有些技术了解的运维工程师认为提高了自动化运维的水平,就达到了 DevOps,虽然自动化在 DevOps 里扮演着很重要的一部分。

所以,做到自动化运维,并不代表你就正在实践 DevOps,但除了运维自动化,还应该有开发的自动化,并且让自动化成为团队的基因之一。很可能你仅仅提升了运维的效率,但并没有从全局的角度提升开发和运维之间的效率。因此,仅仅有自动化运维,还不足以称之为 DevOps。除了运维自动化,还应该有开发的自动化,并且让自动化成为团队的基因之一。

关于 “DevOps 技术”

以上列举了很多所谓 “DevOps 技术”,是从技术的角度来认识 DevOps。然而,任何工具都是为其组织结构服务的,当脱离了组织结构的时候,DevOps 的技术转型会带来很多痛点,就像康威定理说的:

设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。

由于 DevOps 工具可能会引发组织结构的变动,单纯对提升技术工具,带来的结果会有以下两种:

  • 对于执行力强的大型组织来说,组织会要求工具做出改变以适应组织的结构。
  • 对于执行力弱的小型组织来说,组织会根据工具的要求改变以适应工具的结构。

无论以上哪一种,单纯引入工具都无法有意识的解决 DevOps 转型所带来的这种痛点,此外,不探索 DevOps 真正的问题,以及技术背后的目的和最佳实践,往往会使导致对 DevOps 的片面了解而适得其反。

从 DevOps 运动发展的历史上来看,DevOps 相关技术是解决 DevOps 相关问题的结果,而非动起因。因此,对于 DevOps 的理解如果本末倒置,则很有可能起到反作用。

此外,我相信所有第一线的工程师都很聪明,并且随着技术的发展,工具和平台的使用会越来越容易。但是,能够跳出自己的责任区,从全局的角度观察并解决问题的能力则是很多工程师所欠缺的。

当 DevOps 是一个岗位角色

随着 DevOps 的流行,企业也开始对 DevOps 有所期望,希望通过招聘和培训来提升自己的 DevOps 能力或者具备 DevOps 的技能。于是设置了一些称之为“DevOps 工程师”的岗位和角色。通过对这些招聘需求的描述,以及客户对 DevOps 诉求,我整理了四个对“DevOps 工程师”的认识:

  • 作为 Dev 的 Ops(会开发技能的运维工程师)
  • 作为 Ops 的 Dev(会运维技能的开发工程师)
  • 基础设施开发工程师
  • 全栈工程师
作为 Dev 的 Ops

有很多人也会认为,只要让开发工程师掌握运维技能,运维工程师掌握开发技能,就做到了 DevOps,这招来了很多运维工程师的反感。我采访过一些运维工程师,当初他们就是不喜欢也不想写代码,才来做运维方向。

其中有一个动机是在于基础设施技术的进步和架构的稳定,这会让高管有一种错觉,认为运维团队一定程度上是浪费,因此,为了“物尽其用”,讲运维工程师去写业务代码,并用“DevOps”作为对这种措施这一合理化的幌子。

这种想法的天真在于忽视了开发和运维的专业性和差异性。虽然我不否认技术的发展对二者来说难度和门槛在不断降低,而且掌握一定开发技能的运维工程师前景更宽,但是强人所难并不会让事情变好。

作为 Ops 的 Dev

同样的误解也会发生在开发工程师身上,对于开发工程师来说,其实难度并没有增加,无非是把 Ops 的工作当做需要完成的需求而已,甚至很多开发工程师自己也这么认为。

然而软件开发和软件维护是相互关联但是各自独立的专业领域。DevOps 并不是要消除任何一方,而是要通过更加深入的合作成为彼此工作的润滑剂而非绊脚石。

对于开发工程师来说,掌握跟多的技能绝对是一件好事,但也不要低估运维的专业性和难度。

基础设施开发工程师

由于有了上面介绍的虚拟化和基础设施即代码这样的技术,“通过 Dev 的方式完成 Ops 的工作,就是 DevOps”也很自然的成为了很多 Ops 对 DevOps 的认识。他们往往有一个新的称谓:基础设施开发者 (Infrastructure Developer),指的是通过工具和配置文件,利用现有的云计算和虚拟化平台资源,为应用程序构建基础设施。

在一些企业里,基础设施开发工程师都会肩负着企业 DevOps 的重任。

全栈工程师

当然绝对不排除有些工程师是既懂开发也懂运维的“复合型人才”,但这样的人才所花费的货币成本和时间成本也十分高昂:一方面是寻找和雇用这样的人所花费的成本。另一方面是培养这这类人才的成本。

但是,仅仅认为有了这样的人才就具备 DevOps 的能力也并不现实。首先,DevOps 是一个团队属性,而不是个人属性。一个人的力量相较于一个团队来说,还是很有限。其次,招聘这样的人还是为了胜任纷繁多变的工作。因此,我有时候会戏称全栈工程师为“全干工程师”,听起来很厉害,但工作境遇并不见的很好。他们往往会身兼多职而变得异常忙碌,成为团队的“瓶颈”。这并没有让效率提升,反而是一种下降。这并没有改善工作情况。

你可能只需要一个外部 DevOps 教练

不要以为缺乏 DevOps 人才就无法实现 DevOps 了,正确了认识 DevOps 之后,DevOps 就没那么困难。

软件开发和软件运维,是两类不同但联系很密切的事务,在过去很长的时间里,他们都是分别在不同的部门中工作的。但随着企业的互联网转型,这种专业性和责任的不同从甲乙双方的矛盾变成了企业内部的矛盾。这是企业在互联网转型过程中的必经阶段。而如何平滑的过渡,则是 DevOps 成败关键所在,你所需要不光是工程人才,你还需要新型的管理人才或者外部顾问来推动这项改进。

一般来说,DevOps 的变革一定会调整组织的制度和做事方式,而制度层面的改变不是企业内部能够很轻易做到的。由于“不求有功,但求无过”的心态普遍存在,因此越是大型的组织,所面临的组织僵化会越严重。因此,从组织外部引入“晃动器”才可以避免组织的卡壳,例如:聘用有 DevOps 经验的高管,或者是专业的 DevOps 教练。

由于 DevOps 的定义很广泛,DevOps 转型也不会千篇一律。那么,如何识别好的 DevOps 方案呢? 一般来说,我认为优秀的 DevOps 方案包括以下几点:

  • 能完整的 DevOps 的定义和理解(至少回答 DevOps 相关问题能自圆其说)
  • 有业务组织的分析(跳脱了组织谈技术很危险)
  • 有技术技能的分析(没有技术能力的提升都是口头转型)
  • 两者的分析有度量(没有度量就没有改进)
  • 方案落地里有技术和组织改进两部分(工具和实践相辅相成,两部分缺一不可)

未完待续

本篇我们讨论了常见的两种 DevOps 理解,分别是:

  • DevOps 是一组技术实践
  • DevOps 是一个岗位角色

下篇我们将讨论 DevOps 的另外两种理解,谢谢。

上一篇
下一篇
目录