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

腾讯织云负责社交类业务(如：QQ、Qzone、音乐等)通用组件的运维服务和支撑系统建设工作。这个自动化运维体系在过去几年取得突出成绩的同时，也同样遇到和面临着上述问题。

InfoQ采访了腾讯织云社交网络运营部平台技术运营中心总监徐勇州老师，邀请他谈谈对自动化运维的理解，下面的文章根据采访对话整理而成。

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

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

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

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

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

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

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

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

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

1、稳定性不理想，因为我们的流程长，任何一个步骤的失败都会导致整个自动化流程的失败，需要用户进行重试，因使用频率高，遇到次数多了，用户就感觉稳定性差。

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

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

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

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

1、用于CGI、静态文件发布的ARS系统。

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

1、作业平台：向用户提供操作入口，通过作业平台组织资源，制定部署计划。

基于我的工作经验，对于运维自动化体系，重点说以下三点技术层面的建议。

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

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

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

最后想强调一点，不要迷信方法论，它终归是理论，只是我们建设的参考，最终落地的效果应该是要解决具体的问题的。关于这部分内容，我也会在AS架构师大会（注：2016ArchSummit全球架构师峰会深圳站已闭幕，演讲PPT可以下载http://sz2016.archsummit.com/content/3006 专题：深耕运维，精益求精）上展开来讲，详细阐述我们在践行方法论过程中遇到的问题，以及如何思考和解决这些问题的。

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

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

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

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

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

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

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

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

提问

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

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

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

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

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

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

高效开发运维加群啦！

入群之后，先不要说话哦！

第一件事情先找群主报道。

群主：木环@InfoQ

十一之后，每周定期邀请专家分享技术内容。