在CTO俱乐部第96期《 产品创新之路及DevOps实践分享》活动上，CC视频CTO 侯明强讲述了DevOps概念在CC视频的实践，DevOps是Development和Operation两个英文单词前面几个字母的组合，主要是指研发人员和运维人员在实践中的之间的沟通、协作与整合。

在DevOps给CC视频技术团队带来了高效率之余，侯明强还谈到了实践中面临的挑战。他指出，对研发人员而言，DevOps给研发人员带来了新的要求和新的挑战。长期做研发的人对代码之外的东西并不是很熟悉，对工具、环境，尤其是在线运维的东西涉猎不多。对运维来说，运维人员转成半开发人员的角色，困难重重，相关人员也很难招聘。

以下为侯明强本次分享内容精华摘选：

DevOps的由来

传统的开发和运维的配合

研发团队负责：离线开发，开发，测试；运维团队负责：线上，打包，部署，更新；

研发与运维的矛盾

研发认为，我本地运没问题，线上出问题是你们运维的事情；不更新业务怎么办？

运维认为，我们运维没问题，是你们程序烂才出了线上问题；你一更新出问题我的KPI就下降。

研发与运维的不同

研发团队与运维团队的关注点不同；

研发更关注产品的优化和更新，也就是更关注变化；

运维更关注系统的安全和稳定，也就是更关注不变；

这就导致了研发和运维之间的关注点是完全不同的，甚至对立的。

由于研发和运维矛盾的不断凸出，甚至在有些场合下，出现对立。这就引出了DevOps的概念。这个概念很好理解，研发（Development）和运维（Operation）英文单词前面几个字母合起来就是DevOps。

维基百科这么描述DevOps：

它是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、运维部门之间的沟通、协作与整合。它的出现是由于软件业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

DevOps能解决什么问题

更密切配合业务。让你更加以业务为中心，你们团队必须是配合的，你们要想出更好的方式来配合；

解决对变更部署的恐惧。通过一些好的方式方法或者工具，能够让变更部署不再成为大家共同的恶梦；

解决开发和运维部门配合，减少双方之间的扯皮问题。

为何选择DevOps

业务

互联网创业早期，一切围绕业务快速变化。当时为了实现业务目标，在团队人员比较少、资源有限的情况下，我们就想办法尽量把运维工作省下来，让研发人员直接负责业务目标的达成，从开发到最终上线，保证它在线上正常工作的事情，都由开发去做。

服务质量

如果不是开发直接来确定质量能够达到理想的标准的话，拆分成两个部门分别做，运维不懂业务，你让他进行深入的调整是很困难的。尤其是在创新的一些业务，或者是一些技术方案上，它会需要很多的尝试，甚至包括配制的尝试，服务器或者应用服务器，或者数据库架构的构造，自然要出状况。

成本

以业务目标为主，为了服务质量，在成本相对较低的情况下，我们从创业公司的初期就选择了这种方式，我们是以开发尽量多做东西、运维主要负责系统，开发负责线上的质量。

围绕DevOps的一些初级措施

测试环境镜像线上环境。为了缩短本地开发和实际线上运行的差异，我们的开发人员用的系统和线上的系统一样，测试环境也是一个完全一样的，就是尽量把一些鸿沟缩短掉。

从SVN自动化部署。我们也开发一些脚本，让它从SVN里自动化去部署，把相应的内容拿出来，然后更新到线上去。

应用级监控系统。我们做的一些应用级的监控系统，如果从传统的运维监控来看，大家会用工具去监控系统本身的负载，监测各种各样的指标，但是他们没有办法知道，这个应用本身是不是出了问题。

此外，我们会做大量视频的处理，在全国视频网络里进行视频的分发，这些工作都是比较耗时、耗CPU。一天上传上万个文件，会有非常多的工作项目在进行中。因此这些任务，比如视频处理一半，服务器宕机了，还能不能继续。那些东西只是一个外部系统访问的话你看不出来的，或者你只监控一下，网络也没问题，硬盘什么都没问题，有可能你应用队列已经出现了故障。

研发负责从代码到线上，负责快速更新。我们研发人员去负责从代码到线上，有快速更新、快速上线的东西，都由研发直接来做，有点像医生在没有护士的情况下亲自操刀把所有的东西都做了。这样的好处就是出现了各种各样的问题，能够更加快速的反应，更加快速的定位。

众所周之，CC视频是做SaaS服务，客户都是to B，客户一出问题，立刻打电话过来，处理时间的长短严重影响服务质量，因此我们缩短从生产环境到真正线上运行的环境的环境，让研发直接到底下去负责。

传统处理线上问题流程：运维和研发相互隔离

运维收到系统报警，常规检查，尝试解决，如处理不成功，紧急上线更新包；

再将问题提交给研发，研发再让运维提供相关资料，比如日志；

运维在服务器上收集资料并提供给研发，研发查找问题，给出解决方案。

在这种流程下，运维和研发都很着急，却使不上劲。

CC视频的经验：研发与运维联动 快速解决问题

研发收到系统报警，定位问题、解决问题。

运维和研发相互给予系统环境级技术支持，双方在解决完成后沟通解决方案，以及问题原因。

我们有一个视频的缓存模块进行一个算法更新，缓存的命中率是很重要的因素，之前命中率不是特别高，我们自己开发了一个新的缓存模块进行算法更新。

我们线上有几百台服务器，我们要看算法是不是比之前要好，所以必须要做AB测试，要进行对比。同时把算法测验在生产环境下运行没有问题的时候，它还需要部署，慢慢的把所有的服务器都升级成最新的应用。

我们的工作就是由研发来操刀进行。这个如果让运维主动去做的话，这个其实挺困难的，中间要关注非常多的数据，同时部署过程中发现各种各样问题，从各种地方收集，会关注特别多的点，如果让运维去操作这是很困难的。所以我们这个过程就是研发来主导，运维来协助配合的。

从10%发现没有问题的时候，上升到50%运转非常良好的时候，后面自动的脚本就拿出来，让运维批量的去实施。

线上故障或异常

CC视频有异常统计系统，我们会把每天系统里出现的异常信息统计出来，看看是什么样的问题，如果统计出信息比较多的话会报警。

有一次我们发现一个异常。我们知道自己的接口可能是没有问题的，结果检查了，就发现原来有一个客户他请求的时候参数给错了，这种情况下我们就通知客户进行修改，那个客户后来发现他调用我们API的时候调走了，修过了就好了。

假如运维如果他不负责系统的日志处理，他只干服务器或者网络的信息，他是查不到的。

从外表上看也看不到，因为我们整个系统都是正常的，只有到我们客户的具体调用方的视角才能看到有一些什么样的异常存在。如果他的程序写得不够好，外表也看不出来。

总结

用最短路径对线上问题进行快速响应。我们的核心思路就是想尽量用最短的路径，对在线的业务出现的技术问题进行更快速的响应。

从业务本身出发进行的技术优化。进行技术优化的目标，还是围绕着业务去做。

提前开发工具，减少临时处理。碰上临时处理的事情救火的话是很痛苦的，如果开发团队和运维团队老是处在救火的状态的话，持续不了多久，肯定有人就要考虑离职。

未来

更敏捷的持续交付。未来我们想在这些方面做更多的尝试。

更好的自动化、工具化。利用现有的开源工具，在它的基础上开发一些适合我们现有应用模式的更好的、更个性化的工具。

考虑结合开发与测试的环节。测试在这里面也是非常重要的一环，未来怎么把开发和测试结合起来，跟运维环节能够更好的去融合，这块也是我们未来想去探索的事。

DevOps实践中的挑战

既然DevOps这种理念是一个很好的东西，为什么实施的人那么少呢？其实在美国这个东西也还不是主流，也还没有那么大影响力。

下面就是我们在实践中的一些挑战：

对研发人员的挑战——对代码之外的东西不熟悉

比如说用DevOps，这对研发人员加了很多新的要求的和新的挑战。长期做研发的人员对代码之外的东西并不是很熟悉，对工具、环境，尤其是在线运维的东西涉猎不多。

对运维人员的挑战——运维开发人员不易招聘

对运维的挑战，既然很多运维的职责转给开发，那运维应该做些什么呢，他们应该朝着工具化、自动化这些方向去转型。运维人员转成半开发的角色，其实有很大困难，CC视频几乎很难招聘到这样的人才。在很多大公司里他们也会有很擅长测试开发的人，但是那些人身价也都很高。

招聘不容易，内部培训也很困难，如果只是会搬服务器、插插网线那样的运维，你让他转开发，等于从头开始，同样非常困难。