本帖最后由 adminlily 于 2018-9-20 17:21 编辑
在过去的三年中，我作为 DevOps 的咨询师参与了很多企业的 DevOps 转型咨询以及技术实施，也在不同的社区活动中分享了自己在 DevOps 上的实践、理解和观点。
随着 DevOps 的盛行，我在很多场合和越来越多的人聊起 DevOps。也在不同的渠道听到了很多人在讲 DevOps。然而，讨论的背后，我发现每个人对 DevOps 所指并不是同一件事情，也由于各执一词导致不欢而散。
于是我通过 DevOpsDays 的官方网站整理所有 DevOps 的有关材料，随着学习和了解的不断增多，我也渐渐的对 DevOps 有了更进一步的认识。
我把学到的材料经过整理后把陆续放在了简书上，形成了” DevOps 前世今生” 这个系列，这个系列还在不断补充新的材料。
一、含义越来越丰富的 DevOps
DevOps 至今都缺乏一个清晰和统一的认识。对于一场运动来说，这是一件好事，也同样是一件坏事。虽然 Patrick 曾经在自己的博客里一再提到自己对 DevOps 的”正确认识’’，但社区似乎不以为然。
缺乏“官方定义”好处是人人都可以定义，因此没有一个人或者组织可以垄断 DevOps 定义权。所以每个人都自己可以参与到这一运动中去，不断为其增加新的概念、新的实践和新的工具。这会使 DevOps 社区不断的繁荣。
而坏处也很明显，对于 DevOps 的后来者 —— 那些没有参与进来的人，需要学习和理解的 DevOps 知识的广度和深度也越来越大。 以至于后来出现了这幅众所周知的“盲人摸象图”：
这幅图中包含了很多概念，但主要表现的意义 DevOps 是一系列概念的总和，任何一个单方面的定义只是 DevOps 的一个部分，而不是 DevOps 的整体，随着 DevOps 这个概念的不断膨胀，人们就更难理解 DevOps 了。
二、那么，你理解的 DevOps 是指的什么？
在接触了各类客户和社区之后，我开始尝试理解每个人谈到 DevOps 的时候，他们分别指的是什么，以及所指内容背后的目标和动机。渐渐的，我把我所听到的 DevOps 概念分成如下四类，分别是：
那么，我们分别来谈谈这四类 DevOps。
三、当 DevOps 是一组技术/实践
在工程师文化的组织里，对先进技术的渴望是最常见的学习动机。可以促进工程师用更有效率，更优雅的方式解决问题。而对于非工程师文化的组织，新的技术往往是提升其 KPI 的工具。以下是我听到 DevOps 的时候，经常触及的话题：
1、高频部署
曾经和某跨国著名银行的外汇交易产品的 IT 产品负责人交流 DevOps。对方很自豪的告诉我，他们产品每天的部署频率超过500次，我听了不以为然。因为，部署频率高不见得是件好事。于是我问了以下几个问题：
1.为什么你们需要这么频繁的部署？有这么频繁变动的业务需求吗？
2.在这么多次部署里，是发布业务价值的部署更多，还是修复问题的部署更多？
3.这些生产环境的变更难道完全是不可规划的吗？
由于对方的金融业务有相应的法律法规，理论上没有这么频繁的变更需求，除非清理技术债，否则没有很强烈的变更动机。但对方并没有直接回答我的问题，而是换到了其它问题上，因此我最终也不清楚对方这么频繁变更的驱动力。
这对我有一个重要的：指标导向的 DevOps 往往是一种 DevOps 的反模式，它会忽略和掩盖真正的问题。 指标的背后是某种度量，如果部署频率一直很高，一定反应了某种现象。
而这些现象不一定是个好现象：不是业务的变动很频繁，就是技术的变动很频繁。但如果二者都频繁，我们应该衡量变更带来的价值和风险（当然，DevOps 可以降低变更的风险），并优先变更价值较高的请求。
有可能新的业务尝试让我们从市场上获得了更多的关注，也有可能新的技术提升了生产率。但无论是哪一种，部署频率应该是一个有多到少不断循环的过程。
这表明系统在走向成熟和稳定的同时，能够及时响应变化，无论是对技术还是对业务，对变更产生的影响都需要一段时间去积累和总结数据。
此外，DevOps 绝不是为了提升部署频率而牺牲了软件质量和业务价值，甚至是安全措施。
换句话说，DevOps 不是一种对质量的平衡和妥协，它是一种全局改进。全局的改进就意味着以价值为最高原则所度量的相关指标是不能有所下降的。
2、持续交付
持续交付是 DevOps 中非常重要的实践，持续交付的思想远早于 DevOps 。但直到第二届欧洲的 DevOpsDays 才有了持续交付这个重量级话题。因为持续交付本身也通过技术手段和实践解决了 DevOps 最初所面临的 Dev 和 Ops 的合作问题。
不夸张的说，如果 Patrick Debois 早一点读到持续交付中运维相关的话题，说不定就没有 DevOps 了。
然而，随着 DevOps 的理念的发展比持续交付融汇了更多的概念（这就是没有一个人能垄断定义的好处），使得 DevOps 更加广泛和盛行。因此， DevOps 所涵盖的范围已经超出了持续交付本身。
我把 持续交付 列为 DevOps 的核心实践之一，因为如果你没有实践 持续交付。那么根本不能称之为 DevOps，但是如果你完整实践了持续交付，那么你离完整的 DevOps 也不远了。
3、云计算/虚拟化技术
随着分布式应用的井喷式发展。基础设施的管理成为了分布式应用的新瓶颈。在集中式管理的时代，大型应用只能运行在昂贵的小型机上，只有微软，SAP， IBM ，Oracle 和 EMC 这样的企业才有能力提供相应的产品完成这样复杂度很高的架构。因此企业需要单独的运维部门（Ops）来管理这些软件和设备。
而随着虚拟技术和云计算的兴起，企业的基础设施管理工作往往变得很简单。VMWare 这样的虚拟技术企业和 AWS 这样的云计算供应商提供了更加成熟和稳定的产品。大大的节约了企业机房管理的开支。
而 Ops 也不再需要进出机房，只需要通过远程桌面的方式就可以使用各种 SDK 开发工具去完成过去很多只有在机房才能做到的操作。
然而，即使云计算和虚拟化技术提升了 Ops 的生产率，减轻了 Ops 的痛苦。但仍没有解决 Dev 和 Ops 之间的矛盾 —— 开发团队和维护团队仍然各自为政，仍然通过制度谈判而不是合作共赢来工作，毕竟目标是相对立的。
4、 基础设施即代码
随着设备和网络的持续增多，加之更加复杂的应用部署和初始化。基础设施的管理成为了一个十分尖锐的问题。
当复杂度上升一个量级，就需要专业的管理工具来管理这类问题。于是 Puppet 这样的框架顺势而出。以至于在 《DevOps Handbook》中，合著者之一的 John Willis 在理解了 PuppetLab 的创始人 Luke Kanies 的想法之后，才有了 DevOps 的最初理解。
基础设施即代码利用了编程语言和虚拟化工具 API 的无缝连接达到这一目的。它在很大程度上把基础设施的管理当做其问题域，采用正确的面向对象方式，让开发人员和运维人员能够理解并设计出更加稳定和灵活的基础设施。
大大降低基础设施变更的风险：提升了运维知识的透明度并使基础设施变更具备幂等性。
此外，它在一定程度上解决了不同环境（开发，测试，生产）之间的不一致问题，也让开发人员能够学习到 Ops 领域的知识并用软件开发的优秀思想解决运维领域的问题。
因此，基础设施即代码除了工具以外，更是一种 Dev 和 Ops 之间相互沟通的媒介，能够让开发人员和运维人员相互理解。所以，基础设施即代码毫无疑问的是 DevOps 的核心实践之一。
5、Docker
Docker 是含着 DevOps 的金钥匙出生的，它诞生的第一天就带着 DevOps 的基因：更简单的解决了基础设施即代码和虚拟化在实践中的问题，进一步提升了自动化能力以提升效率，并且对开发人员和运维人员都十分友好。
甚至很多地方都会以是否采用 docker 来评判是否采用了 DevOps 的相关技术。
Docker 一定程度上简化了基础设施的初始化和状态管理问题。通过镜像和运行时容器封装了应用运行时的复杂度。并通过容器的编排实现轻量级的分布式架构，也更加经济快捷。
但是，Docker 和任何一种工具一样，都不是”黄金锤“。当用错了场景，使用 docker 可能是一场灾难。
我曾经参与并帮客户完成了一个数据中心迁移的项目，就是采用的 docker 作为统一的运行时容器。最初是因为 docker 镜像的移植性好，在各种异构 Linux 系统上可以正确执行，且镜像构建过程透明。
但是客户为了能让这个业务场景更加通用，又分别采用了另外两种工具对其部署场景进行封装，并写出了第三个工具。
由于这个工具并没有很好的分离其业务关注点和技术关注点，导致这个工具使用异常繁琐，需要增加更多额外的配置去定制化容器运行环境。原本为了提升生产效率的手段反而成为了阻碍效率的绊脚石。
6、 自动化运维
看了以上那么多的工具和技术，很多对 DevOps 望文生义或有些技术了解的运维工程师认为提高了自动化运维的水平，就是 DevOps。
虽然 DevOps 里的一个重要特征是“自动化”，但拥有自动化运维，并不代表你就正在实践 DevOps，很可能你仅仅提升了运维部门的效率，但并没有从全局的角度提升开发和运维之间的效率和端到端价值的流动。因此，仅仅有自动化运维，还不足以称之为 DevOps。
7、关于 “ DevOps 技术”
以上列举了很多所谓 “DevOps 技术”，是从技术的角度来认识 DevOps。然而，不探索 DevOps 真正的问题，以及技术背后的目的和最佳实践。往往会使导致对 DevOps 的片面了解而适得其反。
从 DevOps 运动发展的历史上来看，DevOps 相关技术是解决 DevOps 相关问题的结果，而非起因。
因此，对于 DevOps 的理解如果本末倒置，则很有可能起到东施效颦的结果。你会发现你拿着一堆 DevOps 的锤子，看见了可能并不存在的钉子。
此外，我相信掌握工具对于工程师群体来说不是一件难事，并且随着技术的发展，工具和平台的使用会越来越容易。但是，能够跳出自己的舒适区和思维习惯，从全局的角度观察并解决问题的能力则是很多工程师所欠缺的。
四、当 DevOps 是一个岗位角色
当 DevOps 传播开来，大家都会倾向于去找叫做 “DevOps” 的人，希望通过招聘和培训来提升自己的 DevOps 能力。
于是设置了一些称之为 “DevOps 工程师” 的岗位和角色。通过对这些招聘需求以及客户对 DevOps 的需求，我发现了四个不同但是相关的 “ DevOps 工程师 “ ：
1、作为 Dev 的 Ops
有很多人也会认为，只要让开发工程师掌握运维技能，运维工程师掌握开发技能，就做到了 DevOps。
这招来了很多运维工程师的反感。我采访过一些运维工程师，当初他们就是不喜欢也不想写代码，才选择了运维方向。
这种想法的其中一个动机是在于架构的逐渐稳定带来的运维工作减少，特别是使用了云计算技术和虚拟化技术的企业。这会让管理层有一种错觉，认为运维团队的空闲状态，一定程度上是浪费。
因此，为了达到“人尽其用”，让运维工程师进入开发团队去写业务代码。并用“DevOps”作为对这种措施这一合理化的幌子。
这种想法的天真在于忽视了开发和运维的专业性和差异性。这让我想起一个段子：
老板：“我怎么觉得在公司的运营中你们部门没起多大作用？”
运维经理：“你走过大桥吗？”
老板：“走过。“
运维经理：“桥上有栏杆吗？”
老板：“有。”
运维经理：“您过桥的时候扶栏杆吗？”
老板：“不扶。”
运维经理：“那么，栏杆对您来说就没用了？”
老板：“那当然有用了，没用栏杆护着，掉下去怎么办？”
运维经理：“可是您没有扶栏杆啊！？”
老板：“…… 可是 …… 可是没有栏杆，我会害怕！“
运维经理：“那么，运维就是桥上的栏杆。“
虽然我不否认技术的发展对二者来说难度和门槛在不断降低。而且掌握一定开发技能的运维工程师前景更加光明。但是强人所难并不会让事情变好。此外，这类人才可遇不可求，也不要因为招不到这样的人而阻止了 DevOps 实践。
2、作为 Ops 的 Dev
同样的误解也会发生在开发工程师身上。对于开发工程师来说，其实难度并没有增加。无非是把 Ops 的工作当做需要通过别的工具完成的开发需求而已，甚至很多开发工程师自己也这么认为。
运维除了知识以外，很大一部分的不可替代性来源于生产环境的维护经验。然而这些经验不可复制，因为有些问题作为开发人员来说你很难碰到。我曾打趣的说，当你听到有人说“这不可能啊”，他一定是个运维新手。
就像我在上文强调的，软件开发和软件维护是相互关联但是各自独立的专业领域。DevOps 并不是要消除任何一方，而是要通过更加深入的合作成为彼此工作的润滑剂而非绊脚石。
对于开发工程师来说，掌握更多的技能绝对是一件好事。但也不要低估运维的专业性和经验性。
3、基础设施开发工程师
由于有了虚拟化和基础设施即代码这样的技术，“通过 Dev 的方式完成 Ops 的工作，就是 DevOps “ 也很自然的成为了很多 Ops 对 DevOps 的认识。指的是通过 SDK，相关工具和配置文件，利用现有的平台资源，为应用程序构建基础设施。
而他们往往有一个新的称谓：基础设施开发者 （Infrastructure Developer）或这 云计算工程师 （Cloud Engineer）。
有一次到马来西亚出差，我称自己是 Infrastructure Developer 被 Uber 司机当做政府基建项目开发商问了一堆稀奇古怪的问题，当然我并没有澄清，而是继续逗他 。在一些企业里，基础设施开发工程师都会肩负着推行企业 DevOps 的责任。
但很少有企业能够明确 DevOps 是要做什么（这就是 DevOps 缺乏基准定义的坏处），而这些基础设施开发工程师会慢慢变成一个孤立的“平台团队”，这对 DevOps 是不利的。
4、全栈工程师
当然绝对不排除有些工程师是既懂开发也懂运维的”复合型人才”。但这样的人才的成本也十分高昂：一方面是寻找这样的人所花费的时间。另一方面是雇用这样的人所花费的资金。此外，对于某些企业来说还有培养这样人才的成本。
但是，仅仅认为有了这样的人才就具备 DevOps 的能力也并不现实。首先，DevOps 是一个团队属性，而不是一个人属性。
一个人的力量相较于一个团队来说，还是很有限。其次，招聘这样的人主要还是为了胜任纷繁多变的工作，创业公司尤其如此。因此，我有时候会戏称全栈工程师为“全干工程师”，听起来很厉害，但工作境遇并不见的很好。
五、你可能只需要一个 “DevOps 晃动器”
软件开发和软件运维，是两类不同但联系很密切的事务，在过去很长的时间里。由于专业性和责任的不同从甲乙双方的矛盾变成了企业内部的矛盾。
这是企业在互联网转型过程中的必经阶段，因为运维的开发不密切合作带来的问题日渐突出。
而如何平滑的过渡，则是 DevOps 成败关键所在。你所需要不光是工程人才，你还需要新型的管理人才或者外部顾问来推动这项改进。
一般来说，DevOps 的变革一定会调整组织的制度和做事方式。而制度层面的改变从企业内部是很难做到的。
企业越大，“不求有功，但求无过”的鸵鸟心态普遍存在，因此越是大型的组织，所面临的组织僵化会越严重。组织僵化不见得是一件坏事，这意味着你的企业组织形态更加的问题和高效，这是长时间积累的结果。但由于过于高效，组织僵化的负面效应就是缺乏创新。
所以，要推动企业的 DevOps 转型，特别是制度方面的创新，往往需要从组织外部引入“晃动器”（无论是聘用新的管理人才，还是外部顾问）来松动一下过于高效的组织，这都是能够帮助组织解除僵化的方式。
本文讨论了 四种 DevOps 认识的两种：
在 DevOps 的实践中，我们仍然需要理清不同 DevOps 所包含的内涵。才能正确实践 DevOps，并为 DevOps 的实践提供启发。关于剩下两种 DevOps 的认识，请见后续文章。
原创：在过去的三年中，我作为 DevOps 的咨询师参与了很多企业的 DevOps 转型咨询以及技术实施，也在不同的社区活动中分享了自己在 DevOps 上的实践、理解和观点。
随着 DevOps 的盛行，我在很多场合和越来越多的人聊起 DevOps。也在不同的渠道听到了很多人在讲 DevOps。然而，讨论的背后，我发现每个人对 DevOps 所指并不是同一件事情，也由于各执一词导致不欢而散。
于是我通过 DevOpsDays 的官方网站整理所有 DevOps 的有关材料，随着学习和了解的不断增多，我也渐渐的对 DevOps 有了更进一步的认识。
我把学到的材料经过整理后把陆续放在了简书上，形成了” DevOps 前世今生” 这个系列，这个系列还在不断补充新的材料。
原创：顾宇
| 
转播
分享
淘帖
()