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

　　云计算时代下，对运维的工作如何进行划分?比如，哪些工作属于运维，哪些属于 DBA，哪些属于研发，哪些属于测试?在运维当中，哪些属于基础运维，哪些属于应用运维?在你负责的部门，是如何对运维工程师进行分工的?

　　我们一起来听听腾讯运维专家的意见。

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

　　减少运维对象

　　专业分工

　　专业分工这点打一个比方，自打有人类以来就有了建筑行业。如果我们现在看建筑这个行业，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，所以我们在网络和服务器部分的精力不用投入太多

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

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

　　接入运维：

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

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

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

　　逻辑运维：

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

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

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

　　存储运维：

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

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

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

　　保障数据 100% 安全

　　业务运维：

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

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

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

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

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

　　责任编辑：张华