携程首席架构师谈DevOps：找到合适的人最重要

个人简介叶亚明（Eric Ye），携程首席架构师，负责移动、Web、呼叫中心等部门的研发工作，领导开发的业务和领域包括酒店、机票、商务旅游、开放API、全球站、用户体验研究。他从过去十年的电子商务变革中，总结出六种有效的编程模型，目前被广泛应用于携程内部的产品研发过程中。此外，他还致力于升级携程网架构并创建新一代框架，以提高可扩展性和可用性。

1.[url=]大家好，我是InfoQ的主持人，现在在ArchSummit大会现场。今天十分高兴的邀请到携程的技术负责人高级技术副总裁Eric Ye（叶亚明）来接受我们的采访。今天的话题是运维工程师在时代的职业发展，首先您是如何对运维的工作如何划分的？包括在携程这一块你们对运维工程师是怎样分工的？[/url]

Eric Ye:运维工程师在携程，或者是在大部分的中国互联网公司，一般是按照他们的功能划分的，比如说DBA、SA、应用运维、Security、还有Storage、network，加上Tooling，还有一部分是负责上架下架的siteops。

2.[url=]为大规模系统做运维，大概是大型互联网公司开始就是比较兴起的，然后您在这里也是有了十几年的经验了，然后您觉得这个大规模系统运维的思路和理念在过去几年有什么比较大的变化？[/url]

Eric Ye:这个问题，我结合我在海内外的一些经历，稍微展开来讲一下，大致分为3个阶段。

第一阶段：1995年到2005年，互联网刚刚兴起的这个十年，互联网公司随着用户量、流量增加，运维变得越来越复杂，大家还是凭着运维工程师的经验来做事情，按照前面的功能划分，那些工程师对某个方面经验会越来越深入，但是从本质上，还是依赖于人手工来做运维的。

第二阶段，过去凭经验的手工方式，一方面反应慢，另一方面有经验的人毕竟很少，怎么能提高运维的效率，缩短排障时间，他们开发了好多工具。但是有些工具要求基础设施必须要标准化，简单化；如果基础设施很复杂，五花八门的设备，加上架构也不一样，自然影响自动化程度，运维工程师的压力会越来越大。

第三阶段，最近几年，像Facebook，LinkedIn这些公司已经走在前列，负责运维的人很少。像Facebook这么大的公司，运维人员就20个左右，这么大的流量，它是怎么做到的？它们有DevOps这样一个很超前的理念，在开发人员完成功能开发之后到生产环境发布，基本上全自动起来。

除了Facebook/LinkedIn还有一类是云计算的供应商，像亚马逊，Google，他们不光是把DevOps贯彻在公司里头，还要将DevOps展现给第三方开发者。

3.[url=]那么既然讲到DevOps，其实DevOps像您刚才也提到，它涉及一个全链路的，包括从测试，到最后的部署，整个环节。那么如果一个公司的运维团队，现在还没有开始这个阶段，那么他们从哪里开始介入会比较容易一些？[/url]

Eric Ye:你这个问题问的还蛮深的，开发人员完成了一个功能之后到生产发布的所有环节，DevOps负责将其全自动化。

DevOps不光是个概念，它是这样一套系统，开发人员有了它，开发人员就是Ops人员，与传统概念“开发人员不管运维”是相反的。这套系统有哪些组成部分？第一是，你要测试，作为开发人员写完代码以后，要做Unit test、功能Test、CI test，这些对开发人员来说是蛮自然的。之后要到staging，通过整个功能集成测试，再将功能代码发布到生产环境。但生产环境，Dev的人员是不能直接接触的，通过 DevOps把生产环境抽象起来展现给开发人员，也就是说开发人员也不需要知道后面的生产环境是什么样子，通过DevOps平台，可以方便快捷的发布到标准的基础设施之上。听起来很简单，但实际上发布需要非常严谨，有阶梯式的发布（灰度发布），尤其像携程这个规模，每个集群规模都不小，那这些发布过程中一旦碰到问题怎么办？如果一个代码在测试的环境没问题，但生产环境上又有问题怎么办？这背后需要有一套自动检测的工具，监控整个发布过程，当代码出错率高到一定程度，可以自动刹车，自动回滚，如果代码质量符合生产环境的要求，就往前推进，一直到整个生产环境完成发布，没有问题以后，开发人员才能离开这个生产环境。

这一整个过程都由开发去掌控，这样全自动的效率会非常之高；

刚才讲了DevOps整个流程的细节，这里头门槛还是蛮高的，如果是传统运维的人，会觉得这是蛮不可思议的事情。从开发人员来说，这怎么弄？我以前只知道写代码，这个整个过程是怎么玩儿的。

对于成功的那些公司像LinkedIn、Google、Facebook，是怎么做这件事情的呢？它们有个组织架构，叫做Infrastructure Tooling，既做基础设施，又负责自动化工具研发，他们是蛮资深的工程师，还不是一般的产品开发的工程师，而是对系统、对基础设施的建设非常有兴趣的一些人。

现在来回答你的问题，作为一个公司，他如果没有DevOps怎么进入，怎么去开发这套系统？我觉得门槛是蛮高的，第一你要找到合适的人，这些人是对基础设施、对工具很有兴趣、很有研究的一些人；第二他们需要了解当前开源社区、业界的技术趋势，有很多与DevOps相关的开源系统已经非常流行，比如说代码管理工具Git，代码Code review工具Review Board/Gerrit，还有像CI方面有Jenkins。需要借助于现有开源系统来构建DevOps；第三基础设施的标准化非常重要，没有标准就无法实现最大程度自动化。有了基础设施标准，这套系统应该是每个开发工程师的开发、测试、发布用到的工具是一样的。如果每个团队、部门都不一致，那个DevOps又变成一个空的东西。

总之DevOps涉及到的细节蛮多的，如何打造，简而言之，就是要有合适的、有经验的人，起点要站的高一点，不要闭门造车，在标准的基础设施上构建各种涵盖各个环节的统一工具。

4.[url=]第一步找到合适的人最重要的，而且这个人是不是我从企业内部，他本身了解这套系统会比较好，因为如果从外头引入的话，他可能不了解这套系统？[/url]

Eric Ye:两方面的力量都要结合。内部工程师对现有系统比较了解，是有帮助的，因为我们做DevOps这样的系统，是要解决他们眼前碰到的问题。不过这还是不够，你需要引进知道DevOps的概念，知道DevOps怎么搭建的人才，这两个力量会产生合力，更快开发出DevOps系统。自己学的话还是比较慢，而且容易走弯路。

5.[url=]刚才您也提到了云计算的那个运维跟之前的运维也不太一样，云计算是将很多这种边界的工作，就是以前开发、运维的边界，他移到了运维这个端。然后如果是传统的运维工程师他到了云计算会无法掌控，因为它要复杂很多，比如说很多运维吐槽OpenStack，说我搞不定，他就没有办法去运维那套系统，您觉得这是因为云计算的系统做的还不够友好，还是说这些人的能力跟不上？[/url]

Eric Ye:我觉得两个原因都有，第一云计算不算很成熟，也很复杂，涉及到的东西太多，刚才讲到有Storage、Network、Compute，也涉及到跟开发有关的发布，应用的运营，还有Scale UP，Scale down，有弹性计算能力，在世界上比较成功的云计算公司也是少数几家，都是以技术为导向的，驾驭这个产品对技术要求非常高，不是只靠一个运营团队就能搞定的，所以难度比较大。

第二对于传统运维工程师，这些理念对他是蛮挑战的，因为他以前知道系统是怎么运维的，DB如何管理，但这些技能在云计算面前，它发不出力，有的时候都找不到门。那让他们去驾驭云计算平台，需要一个重新学习的过程，好比他以前是开车的，一下子要他开飞机，这个难度还是不小的。所以说他必须要学习了。

你刚才讲到的OpenStack最近是比较火，但OpenStack的历史来看相对短，没有多少年时间，并且涉及到的模块、技术非常广，质量还在提升过程中。如果你有一个团队去用OpenStack，三个月到六个月，只能知道一些皮毛，里面的水还是蛮深的。也可以这么说一些运维团队，要真正去学会OpenStack，驾驭OpenStack，难度非常之大，会觉得有点力不从心，容易觉得这个系统太庞大、不好用，或者是Bug比较多。

携程算是比较早就用OpenStack了，大概在一年半以前已经进入，我们现在很多的系统已经基于OpenStack来做，我前面提到基础设施标准化，就用OpenStack的方式去实现，而不是用一个文档规范来标准化。另外携程有一个比较独特的OpenStack应用场景，就是呼叫中心虚拟桌面云。所有的呼叫中心不再需要台式机，呼叫中心员工办公只需要一个云客户端加显示器即可，真正的桌面都运行在后端的云里面。虚拟桌面云整个平台，包括后端对桌面、云终端的运维管理、资源分配调度、动态伸缩等等功能，都是基于OpenStack来打造的。在整个过程中，我们也碰到了很多坑，但我们还是跃过去了，给OpenStack修复了很多bug。一旦研发到这个深度，OpenStack会对携程这样的企业，或者其他的互联网企业很有价值。如果光是去做一个POC，十几个人去用用它，用了三个月以后觉得太复杂放弃，那么很难发现它的真正价值。

总体来说，造成不少对OpenStack吐槽的现状，不仅仅是运维的能力不够，也因为OpenStack还不够成熟，这两方面都有。

6.[url=]最后一个问题，就是长远来看，有个预测，就是未来可能整个IT架构会逐渐往云的方向倾斜，可能像小的企业他也不太会倾向于自己架台机器跑跑，那么所以就有可能运维工程师都跑到云平台去做了，没有进云平台的就只好改行了。您对这个运维工程师这个工种未来是怎么看？[/url]

Eric Ye:随着云技术越来越深入，越来越成熟以后，云技术这个趋势是不可避免的。一些小的创业公司，小的企业，把系统搬到云上，难度不是太大。举例来说，原本需要一百人的团队来开发、运维云系统，现在十个人就可以搞定。小公司对运维工程师的需求，会随着云技术的推进会减少。 所以说这种职业需求在这些公司会缩小。

对于中型的公司，又面临这么一个选择，已经有一定的规模的IT设施，把这些IT设施搬迁到云上去，从技术上说是可行的，但是需要很多改动，需要逐步落地，这个改动落地是一个成本，可能有这样的疑问，已经有成熟的团队，可以把现有基础设施维护好，那为什么还要搬迁到云上去？搬迁过程还有额外成本。但是因为一旦搬迁落地后，它对运维的需求就大大降低了，可以说是一个长痛还是短痛的选择问题。

云技术的好处除了整个运营成本会降低，还能支持弹性计算，当网站流量突然增大的时候，能快速扩容；所以很多中小企业非常愿意采用云技术。当然不是说有了云技术就不需要运维了，而是会直接减少运维的人员数量。

大企业接纳云技术，需要一个漫长的过程，一方面现在提供云技术的公司，还不能直接快速的把大企业的应用搬迁上来就能直接运行；背后还需要大量的工作，并且出于数据安全的考虑，支撑业务的核心应用会很长一段时间在由内部运维人员进行管理，但边缘的一些应用或者新开发的应用、比较符合标准的应用，搬到云技术上还是可行的。我认为这些大企业会分批的，逐步尝试云技术，这个过程应该会很漫长。

对于你的问题，那些运维的人员在云的前面会不会成为消失的工种？这个工种会长时间存在，但是长远来看，随着云计算的成熟，对于传统运维的技能的需求会逐渐的降低，所以如果一个运维工程师要去规划自己的职业，他应该去考虑这个问题，适应这个趋势，重新学习，才是长远之计。

InfoQ：十分感谢Eric接受我们的采访。