专访徐勇州：对运维工作时刻保持敬畏之心

自动化运维，一个和运维效率相关的永恒话题，在业务体量持续膨胀和技术日新月异的今天，如何在巩固原有体系的同时，持续追求极致的运维效率并紧跟业界主流技术，是摆在运维平台规划和建设者们面前的现实问题。

腾讯织云自动化运维体系在过去几年取得突出成绩的同时，也同样遇到和面临着上述问题。2016 年 7 月 15-16 日， ArchSummit 全球架构师峰会将在深圳举行，本届大会，我们邀请了腾讯织云社交网络运营部平台技术运营中心总监徐勇州老师，前来分享《腾讯织云自动化高效运维体系演进》的内容， 结合三个案例，讲述腾讯运维人在自动化运维领域的实践经验。

我们就来采访一下徐勇州老师，看看他对自动化运维的理解。

InfoQ：在腾讯社交网络运营技术团队中，请描述一下您作为技术运营中心总监的角色职责？

徐勇州：首先介绍下腾讯社交网络运营部平台技术运营中心，隶属于社交网络事业群，其下设 5 个小组：接入运维组、逻辑服务运维组、数据运维组、计算资源平台组以及运营开发组，负责社交类业务 (如：QQ、Qzone、音乐等) 通用组件的运维服务和支撑系统建设工作。非通用组件和业务运营规划工作，由部门的业务运营中心负责。

作为团队负责人，我主要负责团队日常管理和平台技术体系建设工作。日常管理部分主要是人事相关的管理，各团队大同小异，这里就不过多阐述。

重点介绍下平台技术体系建设方面的工作，主要分为运维体系和运营支撑体系两大部分。

一、运维体系坚持分层运维理念，接入层、逻辑层和数据层分层清晰，且均采用了统一的框架组件服务，其运维效率非常高，其中最多的一位同学维护了 1W 多个服务器实例。而计算资源平台的核心工作是通过虚拟化和容器技术，构建内部 IaaS，提升内部资源调度的灵活性。

二、运营支撑体系建设聚焦质量和效率两个大的方向，内部的两个产品代号分别是“天网”和“织云”，由运营开发组负责平台研发工作。“织云”通过对内部工具平台的整合、WEB 化建设和流程系统建设，提升运维自动化水平；“天网”通过对海量监控数据的挖掘，帮助业务发现质量问题，提升业务服务质量。

这样的组织架构和技术分工，一方面保证了运维可以足够高效，另一方面各团队技术方向和职责清晰明确，结合我们的海量服务，每一个技术方向都有深挖的空间。

InfoQ：可以介绍一下织云发展历程是怎样的吗？

徐勇州：2012 年，公司提出内部云化战略，SNG 社交类业务被定义为其中的“一朵”，织云因时而生，其定位为社交网络类业务量身打造的内部云管理平台，是高效自动化运维理念在社交网络业务上的实践。经过 3 年多的发展，平台在自动化运维方面助力业务的快速发展，在一些重大项目和突发事件中的表现也可圈可点，目前已经是内部使用频率非常高的运营支撑平台，日常的运营变更、发布、配置下发等工作均在织云上完成。

2015 年下半年启动了织云 2.0 建设，重点提升平台体验，建设决策中心，打造自动化运维的闭环，并实现对公有云的支持。

针对性地解决织云在日常运营中遇到的问题，比如：

1、稳定性不理想，因为我们的流程长，任何一个步骤的失败都会导致整个自动化流程的失败，需要用户进行重试，因使用频率高，遇到次数多了，用户就感觉稳定性差。
2、体验不够友好，因定位为内部系统，很多功能做到能用即可，而未投入交互和重构的资源进行设计。
3、智能化程度不够高，很多环节还需要人工的介入，这部分工作需要翻译成机器语言，并能保证其安全性和可靠性。
4、系统封闭，对公有云的支持较弱。

InfoQ： 作为国内最大的社交网络，织云体系的运维发布、变更操作如何实现自动化？运维扩容工作如何实现智能决策和自动化执行？

徐勇州：自动化的基础是标准化，核心是流程。首先说标准化。织云建设初期，就制定了打包标准，并通过 PKG 包管理系统约束运维和开发人员采用统一的规则制作安装包，以保证在自动化过程中可以通过统一的规范进行安装和服务启停。当然，也有一些非标准的安装包，这部分通过文件中心或配置下发系统进行操作，但这个历史上留下的弱一致性机制，是目前困扰我们的问题之一，我们将在织云 2.0 中进行改进。其次是流程。我们将每一个操作串行为流程，因为有标准化的基础，我们把这些流程抽象成了流程模版，只需要传入参数，完成对目标的操作。

运维扩容工作的智能决策和自动执行，目前的决策和自动化是割裂的，需要人工介入，我们认为这块还不够高效，是我们在织云 2.0 建设的重点之一。

举扩容的例子来说，目前织云通过内部的容量系统模块判断出来需要扩容的模块后，邮件通知到模块负责人发起扩容。模块负责人收到通知后，在织云上发起扩容动作，扩容动作完成后，经过多次的检查和确认，最终完成灰度上线。尽管在有些标准化非常高的模块，我们开启了“自动扩容”标识，但最终的上线还是需要运维甚至开发参与检查确认，以保证上线的服务正常。

InfoQ： 是否已经总结出了自己的一套运维自动化体系的方法论？

徐勇州：重点说以下三点。

1、建立标准和规范，并取得一致认可。这点在自动化建设过程中尤为重要，回顾织云的建设，我们会发现，那些定义明确规范的模块建设是最为顺畅的，而那些标准和规范模糊的模块，在后面运营过程中遇到各种问题，坑人坑己。

2、从场景中提炼需求。运维自动化的建设必须要解决某一个具体的问题，而这一问题的背景是什么，这需要我们理解清楚整个场景后，系统化地分析、思考和解决，而避免片面地了解某个需求，拍脑袋做出一个很少人使用且还很容易出问题的功能或模块。

3、架构设计高内聚低耦合。自动化涵盖的模块比较多，各模块必须有清晰的功能定义，接口尽量少而简单，最理想的情况是每个模块都能独立部署和运行。

最后想强调一点，不要迷信方法论，它终归是理论，只是我们建设的参考，最终落地的效果应该是要解决具体的问题的。关于这部分内容，我也会在架构师大会上展开来讲，详细阐述我们在践行方法论过程中遇到的问题，以及如何思考和解决这些问题的。

InfoQ： 作为运维团队，曾经遇到的最重要的事是什么？什么对工作的帮助最大？经历了哪些重大事件的检验? 最难解决的问题是什么?

徐勇州：运维团队在不同的阶段面临不同的问题，总结来说有两大类。

第一类是“救火式”，或是支撑业务野蛮生长，或处理些紧急突发事件。比如农牧场游戏火爆时，运维每天做的工作就是协调服务器资源，然后机械式扩容，对业务发展来说，这个工作非常重要。

第二类是“防微杜渐式”，或是中长期规划类的项目，或是运维内功建设。比如，QQ 和 Qzone 在 2010 年共同合作的上海异地分布项目，正是因为这些前期的能力建设，我们在 2015 年可以从容应对天津塘沽大爆炸事件。

刚好说到 2015 年天津塘沽大爆炸事件，这是对运营规划和运维内功的一次全面检验。8 月 13 日，我们启动业务调度，在用户无感知的情况下，将两亿多华北地区的活跃用户迁移回上海和深圳。容灾架构、业务调度、自动化工具在整个过程中没有掉链子，在实战中得到了检验。而将时间倒退回 2009 年，QQ 服务因深圳电信出口故障影响持续 2 个多小时，尽管采用了各种有损服务方案，还是对用户造成了大面积的影响，也正是经历了那次事件后，QQ 业务启动了异地容灾部署项目。

我理解的最难解决的问题可能是两个字“平衡”，听着比较虚，举两个例子吧。

1、面对业务的快速扩张，如何平衡运营成本，尤其是一些平台类不赚钱的业务。当然，你可以说把这些问题抛给老板，但这是一个管控运营成本的运维团队应该要思考的问题。你需要结合技术、产品体验给出一个让老板可以通过的方案，是考验情商智商的活。

2、为了跟进业界技术，需要采用 Docker 技术，但到底是按官方建议从研发到运维全部打通，采用 dockerfile 进行发布和变更，还是维持现有研发流程不变，用原有的发布和变更方式，将基础镜像制作成虚拟机，仅在某些场景中使用镜像的功能。

总的来说，技术的问题相对来说反而好解决，往往是在一些非技术的问题上，我们很难抉择。

InfoQ： 请具体讲讲内部织云自动化部署平台？

徐勇州：织云自动化部署平台主要有以下 3 个。

1、用于 cgi、静态文件发布的 ARS 系统。
2、用于 Qzone 类业务后台文件发布的包管理系统。
3、用于 QQ 业务发布的 release 系统。

社交网络类业务的日常部署均由以上系统承载，前台页面面向所有的开发和运维人员，然后通过各系统对接的命令通道和文件传输通道，实现日常的部署和发布。之所以有 3 个，是因为历史的一些原因，我们还没有进行整合，但对部署平台来说主要包括 3 个关键模块。

1、作业平台：向用户提供操作入口，通过作业平台组织资源，制定部署计划。
2、命令通道：接受作业平台的指令，在目标机器上执行部署命令。
3、文件传输通道：将文件从文件中心同步至目标机器。

InfoQ： 您作为技术运营中心总监，有什么感悟或经验可以和大家分享吗?

徐勇州：分享的是感悟也是对自己的要求。

保持对技术的热情，持续学习。互联网行业变化太快，技术的更新演进也非常快，我们需要时刻关注行业的变化，关注技术的变化，甚至在热门技术方面需要投入进行研究，不要落伍。

追求卓越，精益求精。对技术有追求，不能仅仅是为了完成任务，混口饭吃。你给出的方案是不是最优方案，需要经过深思熟虑，经得起挑战。支撑系统实现的某一个功能能否超出用户的预期，而不是一个很蹩脚的功能，实现了却没人愿意用。

对运维工作保持敬畏之心。运维的一次不严谨的发布变更可能导致亿万网民没法愉快地聊天，支撑系统的一个 bug 可能导致服务器大面积宕机，要意识到自身责任重大，对生产系统的每一个操作必须严谨，避免疏忽，以保证业务服务可靠稳定。

技术只是解决问题的工具，而解决问题是为了更好地服务用户。上面我强调了技术的重要性，但我们切忌为了技术而技术，任何技术的引入都需要评估是否能解决目前所遇到的问题。