引言

在这里插入图片描述

随着业务的发展，软件发布迭代的频率越来越高，传统的瀑布型模式已经不能满足快速交付的需求，DevOps 也因此受到持续关注。越来越多的公司开始接受并尝试使用 DevOps，期望能使得软件开发中的构建、测试与发布工作变得更加快捷、频繁和可靠。

DevOps 究竟是什么，它想要解决的是什么问题？为什么 DevOps 很好，但却很难落地，其中的阻力是什么？DevOps 的采用现状如何，那些成功的公司都做对了什么？本期「TVP 技术夜未眠」邀请了前易宝技术中心负责人、腾讯云 TVP 刘斌老师与腾讯云 CODING DevOps 高级解决方案架构师——陈钧桐老师一起畅聊 DevOps，分享在行业内的落地实践经验，帮助大家更好理解、规划和实施 DevOps。

如何定义DevOps？其究竟是要解决什么问题？

陈钧桐：DevOps 客观来说没有一个官方定义，我们现在市面上大概有三种讲法：
维基百科对 DevOps 的定义是 Development 和 Operations 组合词，它通过自动化的软件交付、架构变更的流程使得更加快捷和可靠。这也说明了 DevOps 是强调开发和运维密切做协作，并且强调通过自动化的方式让整个流程进行改善。
亚马逊云对 DevOps 的定义是它是一种集文化、理念、实践和工具于一身。出发点就认为它们是密不可分的，目的是提高交付能力，它更突出的是传统的开发和运维的出发点，是有帮助组织更好改进或者服务。
Atlassian 提出 DevOps 是一套实践，用于自动化集成软件与 IT 团队之间的流程，以便做到更快的软件发布。它对 DevOps 的定义也是包括了运营这个词，弥补了之前的鸿沟，它强调的是实践，并且强调的是弥补以前开发和运维两个团队之间的鸿沟。

综上，我们可以看到如果做一个大概的定义，DevOps 包含了文化、流程、工具和实践，并且这几者之间的关系是密不可分的。

DevOps 初衷是通过工具平台、流程或者人的文化结合，建立一种可以持续快速安全交付高质量的流程改进。前面来讲它的初衷是让整个组织的用户价值交付更加快速高效，它里面又包含了文化、流程和工具，以及很多的实践，它们之间是密不可分的，所以我们不用太纠结于它的定义如何，只要它能达到我们的目的，那我们可以采用这样一种原则的集合。

为什么DevOps很好，但却很难落地？曾遇到什么难题或阻力？

刘斌：我在易宝做 DevOps 转型的时候确实遇到一些困难，后来也去过蚂蚁，大家对基建确实有很多呼声，都很渴望能改造好，但是我发现达到一种理想的状态各有各的难题。业务快速增长的时候大家会比较排斥基础设施上的折腾，如果工作人员对 DevOps 的理解不是很深刻，会很难做到围绕业务的推进和实施，这些问题导致 DevOps 会变得很难推动。

再有就是传统运维的思路难以转变，传统运维关注的是设备是否稳定，更希望专注自己的领域，各司其职，并不服务于开发者或业务。所以这个思维如果不转变就遇到很大困难，当时我负责的运维团队里就有人觉得我好像一直让大家服务于开发，从而引起不满。开发和运维互相不理解也是一大难处。

我自己遇到的难题和阻力就是从「运维硬刚开发」转变成「运维服务开发」，这个转变是有比较大的困难。再一个是从「互相甩锅推责」变成「主动揽责」的转变，因为我当时的逻辑就是你配合我的改造，责任我来承担。当然会有人觉得特别不理解，觉得特别傻，但是挺过之后就好很多了。

再就是我们要注意寻找业务上的抓手，少说一些比较空洞的话，尽量从业务价值上找价值点，和业务开发的团队找到一个大家共同受力的点推动这个事情，甚至 KPI 或者 OKR 上都可以写成类似一个产出。

还有一个问题就是要坚守我们的核心架构。我非常反对「好的实践就是 DevOps，不好的实践就是 DevOps 反模式」。我们不能根据问题的难易程度来做取舍。还有就是坚持不可变基础设施，否则的话有可能会转变成一个非常凌乱的、针对大家抱怨提的需求来做一些零碎的工具，我感觉主要是这三个阻力和难题。

实施DevOps有哪些常见的坑？

刘斌：我说一下除了推动别的团队所受的阻力外，我们自己内部的一些坑。其中一个很大的坑就是运维容易把运维自动化等同于 DevOps，可能有些人会这么想。但我认为 DevOps 应该先做贴近于业务开发的事情，而不是只把运维的自动化做得特别好。如果把自动化等同于 DevOps，可能会导致沟通模式还是开发在找运维解决问题，然后运维再基于自己挺满意的自动化运维工具操作服务于开发，这样就是没有做到 DevOps。本质上应该让开发自己去自主运维，大家都对自己的事情负责，而不是委托给别人做完操作再让他去看结果。

另外一点就是我发现我当时团队里在做 DevOps 平台和工具的时候过早关注界面，可能觉得要先把先进的理念展示出来，但其实这种做法是本末倒置的。

我觉得 DevOps 应该从交付物出发，交付物指的什么呢，就是源代码、配置信息，打出的包，镜像，或者测试脚本，甚至包括日志。例如这个交付涉及的环境或者你希望它的运行是不是 DevOps 的；你的自动化测试是不是真的可以自动执行，而不是只是一个触发工具，更多还是依赖人工。再有是日志的管理，还有包括监控的事件能否对应起来。这个就是整个围绕运维这块的几个对象，你的建模、标签是否能串起来，需要先把这些事情做好，哪怕先找一个简单的开源软件，甚至你用商业软件也要先把这个问题先考虑清楚，之后再考虑界面上该怎么用。因为我遇到过很多做得非常漂亮，但是大家用起来很难受的界面。实际上也增加了使用的复杂性。所以我觉得对制度、交付的约定是一个最优先的事情，非常难以反过来，我认为这也是一个坑。

DevOps需要打通部门之间的“墙”，您觉得最困难的地方是什么？

刘斌：从我自己的经验，当时 DevOps 的八字循环，左边是 Dev，右边是 Ops。那个循环我当时感觉右侧的环是相对好推进一些，大家做 DevOps 也可以考虑先做右边的环，很容易出效果。左边的环我觉得非常困难，因为对开发人员的工作方式侵入比较多，毕竟需要自动化测试。他们的工作离业务更近，业务压力也更大，所以非常难推动，这是一点。

如果单从部门之间的“墙”而言，我认为最重要的是改变运维的服务意识，这个说起来有点虚，但是也是最核心的，而且是我当时一直在团队里反复关注的事情，大家很清楚技术都是为业务服务的，我们整体的阵型应该更贴近业务，而不是下沉夯实自己的基础。例如我当时遇到运维团队非要做自动化运维工具，这样会花费更多的精力，人肯定离业务越来越远，这思路是错的，只会导致自己思维守旧。如果我们关注于服务业务会看到更丰富的场景，看到更高的挑战，这个是最困难的，因为必须得有对业务的服务意识。所以我会反复盯这个团队里大家是否把这个思维转变过来了。

陈钧桐：本质上还是团队之间思维的转变是很重要的事情。大家要对齐认知和目标，要持续地和大家讲事情是如何推进，目标是什么。我们从认知到真正的落地实践中间还有很大的隔阂，需要不断磨合。

其实我自己对这个话题也有点感慨，以前我也是开发，会更关注代码，但是我们怕大家沉溺于写工具代码去了，实际上你做的事情可能是在你团队的第一个，但是放大到市面上或者业界有很成熟的工具或案例，不管是开源的还是商业的直接去用就好了，我们的目的并不是生产基础设施，它的目的是有一个使命、价值观和愿景，要把这个东西转换成金钱的收入的一个商业链条，中间我们做的种种事情只是手段之一而已。我们更加关注的还是业务价值的交付，这个业务价值以前开发会觉得产品很难沟通，但实际上我们在 DevOps 的文化里更加强调于沟通和协作，大家交付的目的是一致的，更有利于打破部门墙。

DevOps实践情况如何？那些成功的企业有何共同点？

陈钧桐：其实现在 DevOps 这种实践很多企业都会运用，因为这些东西是为了交付业务价值，绕开这个话题，其实它只是一系列原则的打包，只要我们做的任何动作有益于我们想追逐的东西，那么我们可以说它实践了 DevOps。

成功案例大家可能会比较关注国外的先进公司，以谷歌为例，我们梳理一下谷歌研发模式的变革过程，当时他们第一个变革点就是对测试下手，开始招聘具有测试思维的开发人员，整个测试开始向测试开发转型。然后就是运维，开始招有开发经验的运维，加上 SRE 角色的转型，当然这是第一时代。到了 2008 年他们就做了第二次变革，他把测试开始的横向延伸至整体研发效能的领域。从 2013 年到 2014 年进行了第三次变革，针对工程效率，通过开发的工具、基础架构、指标分析做了一个精细化的运营，针对运维 SRE 的工程实践也可以对外输出一些能力，整体的方向是向自动化和智能化发展。

我们分析谷歌的这三个变革可以发现关键岗位和人员它的要求有以下几点变化。第一点是开发需要对整个软件生命周期的质量负责，包括最基本的执行单元测试，要做自动化部署。第二点，测试研发效能提升转型，现在把整个招聘标准按照开发能力做严格升级，这样也是一个重要的变革点。第三点是向运维开发 SRE 转型，关注的是整个运维系统工具化和智能化，并且有一个隐性的要求，50% 的时间 SRE 用于开发，并且它在变革的过程中会有意识地培养大家的质量意识、安全意识等，这是一个整体持续渐进的过程。我们可以借鉴其中的某些点应用到自己的环境中，比如说规律性的定期培训，统一大家的意识，制定统一的规范，然后在招聘人员的标准上有意识做一些区分。

它的变更模式是自上而下、有高层的支持，这个对国内来说非常重要。

如何平稳落地DevOps？

刘斌：第一点还是要贴合业务和业务开发那边做 DevOps 的建设，不需要追求工具的完备性，不要等工具都完善了才去做另外的事情。我们当时是结合诉求最强烈的点来推动 DevOps 的实践，这是一方面。当时我们做的时候就是从现象可观测，让开发能快速查出问题，所以要从业务价值上找抓手。另外就是从一个横向面去推动，会有很多东西会配合做这个事情。

另外一个我们说要服务于开发，但实际上也不能太顺着开发的需求走，不然可能陷入到一种杂事的鏖战里，有种思路就是你在做这个事情的时候得找个锚点，这个锚点得影响他去往你期望的方向思考这个问题。我觉得这个还是需要引导的，这个锚点实际上就锚定了他的关注点，关注点如果关注错了就陷入到一种需求实现的汪洋大海里去了。

有哪些比较推荐的DevOps工具分享？

陈钧桐：我简单分类列举一下，整个软件开发最开始有代码，有代码就要做代码托管，代码托管的工具有大家耳熟能详的 GitHub，有 Bitbucket、GitLab，包括 CODING 也是在 2014 年的时候在做国内的代码托管工具。

源代码打完包之后我们叫制品，制品的管理工具这里也有一些选择，比如常见的 JFrog 的 Artifactory；然后是 Harbor，它更专注于 Docker；还有 Nexus 等。

接下来就是持续集成工具，就是 CI，这里有 Jenkins、CI，包括 GitHub，本来它是没有这个功能的，后来它也上了，还有 Travis。

有了制品就要运转到生产环境上去我们需要持续部署，持续部署也有很多的工具，有 Spinnaker。还有很多一站式的工具，GitLab、GitHub，包括国内 CODING 也是做一站式的解决方案，也是覆盖了需求的诞生，甚至前面 OKR 目标的拆解，到最后的交付上线，CODING 都有一整套的产品方案，感兴趣的同学可以在腾讯云的官网搜索 CODING，可以更加具体地了解我们的产品。

对企业而言，比较推荐根据现状去选择更合适自己的工具，比如说如果这个企业自身的研发能力很强，它的业务复杂度不高，只是对某个研发阶段有一些痛点，就可以用单点的工具做组装。如果企业本身的研发资源有限，或者说它的目标专注度更在业务场景，这个时候可以选择一些一站式工具，比如 CODING，当然我们在这个环节里还有其他的角度，比如说重视质量，重视安全，这些里面都有一些插件，我们在一站式的平台里也可以针对企业关注的点对插件做集成和嵌入。

DevOps是否会成为一种趋势？

刘斌：我说这个问题的时候先从运维发展的眼界来讲，是我自己的总结。我认为分三个阶段运维发展，第一阶段就是按需获取机器，第二阶段是按需获取资源，第三阶段是按需获取服务。

这个演进过程的趋势本身是为了更好支撑业务响应市场，我们的技术整体的振兴是在往业务靠近，而且这个阵型越来越紧凑，向下沟通层级越来越少了，而且是变得越来越薄了。这个趋势会一直有，随着技术能力的发展，包括对设计能力的演进，包括对业务的理解，我们会越来越贴近业务，这个基础设施团队，包括运维团队也会往前端跟进，所以 DevOps 会是一个进化的过程，而不只是一个工具。所以 DevOps 本身也会是一个趋势，如果没有实践 DevOps，也会向 DevOps 转变，因为这个团队阵型更紧凑，就像现代足球，它是一个敏捷的团队，业务发展肯定会比你快，这个公司如果不想被淘汰肯定会往这个方向转型。