云计算时代的运维分工与理念变化：腾讯资深运维 Coati 的观点

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

今天 InfoQ 中文站邀请到的嘉宾是一位资深的运维工程师，他是从开发工程师转岗成运维的。运维工作的界限将产生怎样的变化？运维工程师未来的职业发展应该如何规划？运维工程师为了适应时代和技术的变化需要去学习什么？让我们听听他的观点。

嘉宾简介

赵建春（Coati），腾讯业务运维 T4 专家工程师，社交网络事业群运维总监，技术运营通道委员。04 年大学毕业后加入腾讯，先后参与过交友、音乐、贺卡、QQ 空间等业务的开发。06 年后和团队一起专注于技术运维，负责腾讯社交网络事业群社区类 WEB 业务的运维和建设工作至今。经历了业务规模从数十台设备到数万台设备的快速发展历程。过程中 Coati 在运维环境标准化，业务 Set 化，运维自动化及多地分布式部署等方面积累了丰富的实战经验。

Coati 是 2014 年全球架构师峰会（ArchSummit）的联席主席之一。

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

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

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

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

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

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

1. 减少运维对象
2. 专业分工

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

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

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

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

• 接入层运维团队，负责所有从用户客户端发起 - 域名 -lvs/tgw-web 服务器这个链条上的服务
• 数据层运维团队，负责后端从最底层的数据存储 -cache-cache 前面的 access 层。我们不叫 DBA，因为 DBA 的概念有些局限了
• 逻辑层运维团队：中间最复杂的各类架构的 tcp/udp 的 socket 服务器，运维成立了一个专门的团队，推广通用 socket 服务器，让开发只写这个服务器里面的业务逻辑部分，就像 web 服务器上的 CGI 一样。这个团队可以叫做逻辑层运维团队，他们的职责之一就是让开发个性化的 socket server 越少越好，最好没有
• 业务运维团队：3 层分开维护后，需要有人或机制让 3 层很好的协调工作和运转。这个从人员方面讲就是业务运维团队。虽然我们希望没有开发个性化的 socket server，但这毕竟是个美好的设想，实际环境中依然会有个性化，于是这个团队就负责这些个性化的 socket server，同时协调 3 层运维团队来为业务整体提供服务，可以说是对口业务的运维线 PM
• 基础运维（目前由逻辑层运维团队兼任）：从技术角度来看，3 层的访问需要访问的串接，我们使用类似 DNS 的一个名字服务组件来串接 3 层的访问关系、一些 3 层都使用的公共运维和管理组件、以及和网络服务器接口的一些工作
• 网络和系统运维：由于公司有专门的网络和服务器团队支持各个 BG，所以我们在网络和服务器部分的精力不用投入太多

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

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

接入运维：

1. 全面就近的业务接入覆盖及技术加速、节流
2. 用户接入问题的全方位诊断系统和方法
3. 组件的高度统一以及统一后的经验最大化利用，成本及质量最优、批量和一致的操作，提供必要的自助化能力

逻辑运维：

1. 标准组件推广，尽可能减少特殊组件
2. 三层共同需求的服务和组件的维护，提供透明化服务，承上启下
3. 组件的高度统一以及统一后的经验最大化利用，成本及质量最优、批量和一致的操作，提供必要的自助化能力

存储运维：

1. 硬盘和内存数据的快速迁移、分裂、组合能力
2. 清晰明确的仓库资源归属、成本核算等，使服务信息透明（数据集群化后的需要）
3. 组件的高度统一以及统一后的经验最大化利用，成本及质量最优、批量和一致的操作，提供必要的自助化能力
4. 保障数据 100% 安全

业务运维：

1. 协调运维团队资源，支持业务项目对运维团队的整体需求；对业务整体的质量、成本负责
2. 规划科学合理的业务分布、推进，实施业务的架构革新、改造
3. 规划建设以业务视图为视角的运维工具和监控平台

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

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

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

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

1. 06 年前，业务规模普遍很小，当时所有开发同事自己维护自己负责的模块，甚至出问题后还要跑到机房去自己重启服务器，可以认为是运维的原始时代。
2. 06~08 年，各类国外 ITIL 管理理念引入的时代，突发事件、工作台、问题管理等流程系统。而运维也是不断的将自身的工作通过工具建设来提升，把终端操作转移到前端界面可视化操作。可以认为是工具和流程快速完善的几年。
3. 08~12 年，随着很多业务逐渐由百万级在线变成千万级甚至亿级同时在线，业务的 SET 化、全国分布、容错容灾、异地调度等架构优化成为除了工具效率改进工作外的一个重点。这个阶段可以说建立了海量运维架构体系的几年，工具建设和架构改进互相促进发展。
4. 12 年到现在，我想大家都在研究和努力怎么把业务云化，尝试做到不做干预的扩缩容变更吧。同时我们还在尝试，如何利用运维更全的信息、更多的数据的平台积累优势，让运维同事能够帮助到业务目标，促使业务成功。我们提出服务产品、服务研发、服务自己的口号，把产品放在第一位，自己放在最后一位，让大家以业务成功为导向，而不是一直关注自己的效率问题，只关注自动化运维，把自己放在第一位。比如对资源消耗型业务分析 top 用户资源使用，让产品团队可以更好的设置商业化方案。

InfoQ：从前几年开始流行的 DevOps 理念提议将运维工作以结合脚本、工具的方式实现自动化。自动化运维其实是一整套体系，从开发环境、测试环境的搭建，到代码的集成、测试，到上线部署、回滚，以及一系列的监控、报警体系，都包含在内。你们在实现运维自动化的过程中都经历过哪些阶段？目前完成到了什么状态，下一步计划是什么？

Coati：我们的运维自动化是一个持续演进的过程，如果非要分几个阶段，我觉得是运维原始阶段的自动化脚本命令行执行 ->web 化界面形成独立的子系统 -> 独立子系统整合成完整业务或组件 OMS-> 自动调度云化的一个过程。

目前的自动化运维以我 13 年 4 月在 QCon 北京分享的《海量 SNS 社区网站高效运维探索》中的管理方案为主，通过以业务和组件为维度的 OMS 管理系统做自动部署。同时我们这 2 年来一直在编织我们的长尾业务的“织云”项目，使用腾讯云的 LXC 的 container 管理平台进行云化。最新的进展是我们有 330 多个模块实现了无需人为干预的全自动化扩缩容。以 4 核为主的 Linux container 实例数 6300 多个，很好的解决了长尾业务的低负载以及变更少雷区多的问题。

下一步的设想是将实体机模块也逐渐接入这个系统，将方案统一。两者的主要区别在于设备资源的管理，container 可以随时创建和销毁，实体机则不行，受资源数量和类型限制更大。

InfoQ：你认为未来企业还需要雇佣维护单机服务器或者几台服务器的内网小集群的系统工程师吗？

Coati：我觉得还是会需要小集群的工程师。虽然未来一定是大公司越来越大、越巨无霸，对运维人员的需求会像我前面讲的会要求分工更加专业和深入，但同时互联网的疆界也会不断扩大，很多传统行业会逐渐拥抱互联网，也会不断有创业公司成长为中小企业，使用云平台的公司会越来越多。小企业不会请太多人，所以几个人的团队势必要求大家是全才，导致技术不会很深入；更多的小企业的工程师则可能是使用云平台等资源维护企业服务；而大企业则是需要分工更加精细的专业化运维团队。

相关资料

ArchSummit 全球架构师峰会即将于 7 月 18-19 日在深圳举行，此次会议重点解析九个当前最受关注的领域，包括：SNS、 移动互联网、 金融、 大数据、 智能硬件、 游戏、 云计算、自动化运维、电商等专题。目前正在火热报名中，感兴趣的读者可以访问网站主页了解更多信息。

• ArchSummit 专题：数据中心与自动化运维
• 两位资深运维谈人生：开发和运维之间要形成你退我进的节奏
• 速度与成本共赢的运维之道