最近几年随着云计算的兴起和DevOps理念的流行，软件工程师领域有关“运维也要会开发”、“运维要自动化”、甚至“运维工程师要失业”这样的话题开始被越来越多的提起并讨论。

InfoQ曾经采访过腾讯资深专家赵建春，他是从开发转岗运维的工程师。运维工作的界限将产生怎样的变化？运维工程师未来的职业发展应该如何规划？运维工程师为了适应时代和技术的变化需要去学习什么？让我们听听他的观点。

InfoQ：Coati你自己是开发转运维的背景，当时是什么因素导致你决定要做这个转变？

Coati： 刚进入公司的时候，我主要做QQ交友、QQ音乐等业务的开发工作。那时候的这些业务的规模还比较小，后来非常幸运的参与到一个新项目——QQ空间的开发，负责日志和留言版2个模块。这个项目成为后来引领中国Web 2.0 的标志性SNS产品，非常受欢迎。顺利完成我所负责的模块、QQ空间发布之后，我又以项目经理的角色，和另外4名同事一起，共同完成并上线了当时为企业版QQ（TMQQ）定制的简洁版空间izone。

在当时，还没有太多可以让用户个性化展现自己的SNS类产品，QQ空间这种满足QQ用户个性化展现自己的产品呈现出爆发式的增长。很快，服务的稳定性和速度出现很大挑战，故障不断。于是，团队决定暂停大功能版本的开发一段时间，把团队分成两部分，一部分同事负责性能优化，一部分负责运营版本开发。我被安排做为运营版本开发的负责人，一方面负责日常运营版本的开发，同时为了保障产品质量，我们在做业务开发的同时还做了很多监控、容量管理、发布流程优化、编译自动化和灰度扩容迁移等工具和系统。

2006年开始公司正好在全公司推广D/O分离，也在我所在的业务系统成立了专门的运营部，因为我们运营开发团队承担了几乎所有的运维类工作，所以运营部一直没有人员对口QQ空间业务。后来我和我的团队顺应公司的D/O分离大方向，调到了运营部，转型为业务运维，走到了技术领域一个更加细分的领域。

InfoQ：你如何对运维的工作进行划分？比如，哪些工作属于运维，哪些属于DBA，哪些属于研发，哪些属于测试？在运维当中，哪些属于基础运维，哪些属于应用运维？在你负责的部门，是如何对运维工程师进行分工的？

Coati： 我们有个两个理念，我也常给团队同事讲，叫做：

• 减少运维对象

• 专业分工

专业分工这点打一个比方，自打有人类以来就有了建筑行业。如果我们现在看建筑这个行业，1-2个人也可以建造出一个结构简单的木屋或土屋。但如果要建造一个类似腾讯大厦的几十层的摩天大楼，必须靠一个分工细致的、在建筑业各个领域都很强的团队精密合作才可以。常常听到房地产相关的报道说如果房地产泡沫破裂，会影响上下游几十个行业，可见建筑领域的行业细分是多么的细致。

运维相比传承了几千年的房地产行业来说，发展才十年，也是互联网技术行业里分工最不明确的一个岗位，几乎什么都要懂，什么都要做，就好比让我们每个人都具备建造一座房子所有相关的知识和能力。但很明显，我们任何一个人都无法建造一座腾讯大厦，只能通过专业细分，做精一个领域，只有这样，我们才能成为某一领域的专家。

减少运维对象，实际上是专业分工的手段。我们把服务器类型、机房数量、QA流程、容错架构、软件架构等都看成抽象的、需要运维去管理的“对象”，希望这些对象越少越好。因为对于运维来说，人员数量总是远少于开发的，对象越少，我们越是能够对这些对象进行更加深入和全面的掌握。而这种寻找、合并同类项的过程，其实也是专业细分的手段。

目前我们的团队是按这样的方式划分的：

• 接入层运维团队：负责所有从用户客户端发起-域名-lvs/tgw-web服务器这个链条上的服务

• 数据层运维团队：负责后端从最底层的数据存储-cache-cache前面的access层。我们不叫DBA，因为DBA的概念有些局限了

• 逻辑层运维团队：中间最复杂的各类架构的TCP/UDP的socket服务器，运维成立了一个专门的团队，推广通用socket服务器，让开发只写这个服务器里面的业务逻辑部分，就像Web服务器上的CGI一样。这个团队可以叫做逻辑层运维团队，他们的职责之一就是让开发个性化的socket server越少越好，最好没有

• 业务运维团队：三层分开维护后，需要有人或机制让3层很好的协调工作和运转。这个从人员方面讲就是业务运维团队。虽然我们希望没有开发个性化的socket server，但这毕竟是个美好的设想，实际环境中依然会有个性化，于是这个团队就负责这些个性化的socket server，同时协调3层运维团队来为业务整体提供服务，可以说是对口业务的运维线PM

• 基础运维团队：从技术角度来看，三层的访问需要访问的串接，我们使用类似DNS的一个名字服务组件来串接三层的访问关系、一些三层都使用的公共运维和管理组件、以及和网络服务器接口的一些工作

• 网络和系统运维团队：由于公司有专门的网络和服务器团队支持各个BG，所以我们在网络和服务器部分的精力不用投入太多。

总结来说，就是接入层运维、逻辑层运维、基础服务运维、数据层运维、业务运维和系统运维几大分类。这个分类也会随着规模的变化不断细化。

我们有对每个运维小组团队核心工作的明确定义，我在这里摘录其中一些条目让大家大概了解一下。从这些条目可以看出，分层的团队都有一条相同的能力要求——就是让自己所维护的对象变的一致和尽可能的少，从而提高效率。而每个团队也要有自己核心的建设方向，以便沉淀相关的能力。比如业务运维团队更多的是项目规划协调和业务架构优化分布能力。

接入运维：

    1. 全面就近的业务接入覆盖及技术加速、节流

    2. 用户接入问题的全方位诊断系统和方法

    3. 组件的高度统一以及统一后的经验最大化利用，成本及质量最优、批量和一致的操作，提供必要的自助化能力

逻辑运维：

    1. 标准组件推广，尽可能减少特殊组件

    2. 三层共同需求的服务和组件的维护，提供透明化服务，承上启下

    3. 组件的高度统一以及统一后的经验最大化利用，成本及质量最优、批量和一致的操作，提供必要的自助化能力

存储运维：

    1. 硬盘和内存数据的快速迁移、分裂、组合能力

    2. 清晰明确的仓库资源归属、成本核算等，使服务信息透明（数据集群化后的需要）

    3. 组件的高度统一以及统一后的经验最大化利用，成本及质量最优、批量和一致的操作，提供必要的自助化能力

    4. 保障数据100%安全

业务运维： 

    1. 协调运维团队资源，支持业务项目对运维团队的整体需求；对业务整体的质量、成本负责

    2. 规划科学合理的业务分布、推进，实施业务的架构革新、改造

    3. 规划建设以业务视图为视角的运维工具和监控平台

我们的运维和测试之间的分工比较明确，很少有交叉。由于我们有比较完善的发布和自动化测试系统，所以测试同事负责了Web类版本从开发到测试，到预发布环境的所有工作，并且在版本测试通过后，由测试发布外网。而运维则负责全新业务搭建、扩容迁移、以及后台服务器的更新（更新量小）。

和开发之间的界限，就是现网由运维负责，但对于故障的响应和处理，我们一直有个传统就是开发和运维都要及时第一时间响应，以加快故障的修复效率，这个方面也非常感谢开发团队同事的长期支持。

InfoQ：为大规模系统做运维，应该是始于大型互联网公司的兴起，腾讯在大规模系统运维方面已经积累了很多年的经验。从您个人的经验，您感觉大规模系统运维的思路、理念在过去几年有什么变化？

Coati： 确实，如前面所讲，在腾讯我感觉我们是从06年开始起步专门做业务运维的。以我所在团队为背景说起过去几年的变化，有这几个大概的阶段：

• 06年前：业务规模普遍很小，当时所有开发同事自己维护自己负责的模块，甚至出问题后还要跑到机房去自己重启服务器，可以算作运维的原始时代。

• 06~08年：各类国外ITIL管理理念引入的时代，突发事件、工作台、问题管理等流程系统。而运维也是不断的将自身的工作通过工具建设来提升，把终端操作转移到前端界面可视化操作。可以认为是工具和流程快速完善的一个阶段。

• 08~12年：随着很多业务逐渐由百万级在线变成千万级甚至亿级同时在线，业务的SET化、全国分布、容错容灾、异地调度等架构优化成为除了工具效率改进工作外的一个重点。这个阶段可以说是建立了海量运维架构体系的几年，工具建设和架构改进互相促进发展。

• 12年到现在：我想大家都在研究和努力怎么把业务云化，尝试做到不做干预的扩缩容变更。同时我们致力利用运维更全的信息、更多的数据的平台积累优势，让运维同事能够帮助到业务目标，促使业务成功。我们提出服务产品、服务研发、服务自己的口号，把产品放在第一位，自己放在最后一位，让大家以业务成功为导向，而不是一直关注自己的效率问题，只关注自动化运维，把自己放在第一位。比如对资源消耗型业务分析top用户资源使用，让产品团队可以更好的设置商业化方案。

InfoQ陪伴技术人，

用优质的技术文章作长情的告白。

技术提升世界的活交给你们了，

高效开发运维在这里给你们提供后勤补给。

长按二维码识别关注，领取优质文章补给~