梁定安：解密腾讯 SNG 云运维平台“织云”

SNG 是腾讯体量最大、产品线最丰富的一个事业群，其覆盖了 QQ、手机 QQ、腾讯开放平台、腾讯云平台、广点通、移动分发平台应用宝在内的多条业务线。可见 SNG 的运维体系的庞大，早在 2013 年 QCon 北京大会上，腾讯业务运维 T4 专家、总监赵建春就在 QCon 分享过《海量SNS 社区网站高效运维探索》，当时引起了运维界的广泛关注；而整个SNG 的运维又是如何运作的呢？

梁定安，2009 年加入腾讯运营部，先后从事系统运维、业务运维、运维规划和运营开发的工作，目前是社交平台业务运维组Leader，可以说是整个SNG 云平台的缔造者，也是今年 QCon 上海 2014 大会自动化运维的讲师，届时将分享《腾讯 SNG 织云自动化运维体系》的话题。

为什么会有织云？织云重点解决什么样的问题？面对错综复杂的业务，织云又是如何自寻突变的呢？梁定安会全面介绍这个平台的特性、底层技术组成、以及给 SNG 所带来的价值。

InfoQ：梁定安你好，织云是什么时候开始做的？

梁定安：2012 年底 CTO Tony 将云化战略推广到公司内部各个 BG，织云正是在公司云战略的背景下，为 SNG 量身定做的内部云管理平台，定位是为 SNG 自研业务提供虚拟化管理和自动化运维的平台，几乎所有 SNG 的业务（Qzone、QQ 秀、QQ 相册、QQ 音乐、QQ 等等）的运维操作都基于织云平台完成。

InfoQ：织云定位为内部的自动化运维平台，那么它具备那些特征呢？

梁定安：织云平台定义了 SNG 业务的标准化运营规范，在平台中运维人员抽象出上层的管理节点，减少与统一运维对象，降低海量运维的复杂度，得益于运营环境的标准化建设，有更多通用的自动化工具被设计开发，配合流程引擎的驱动，使我们逐步迈入自动化的运维阶段。平台最大的特色是“一键上云”帮助 SNG 自研业务快速实现织云最初的上云目标；而“自动调度”则实现标准化服务的容量自动维护；还有我们基于内核 inotify 的一致性监控，保证了配置资源与现网资源的一致性。此外，织云的核心模块还有：资源管理，包管理，配置管理，自动流程，中心文件源，权限中心，都是自动化运维必不可缺的重要功能模块之一。

InfoQ：“一键上云”实现没有那么容易吧？非标准化业务应该是很难接入，在实现这一目标时，你们又遇到那些难题？

梁定安：困难是必然存在的，我们第一个遇到的难题是虚拟化选型和适配改造，在 XEN 和 LXC 之间，我们选择更轻量成本更低的 LXC 作为织云平台的虚拟机，在运营过程中，由于虚拟机与实体机管理模式的差异，我们没少踩坑。如同母机下子机对 CPU、网卡流量抢占造成相互影响，子机多 crontab 集中调度，常用系统命令只显示母机状态，LXC 内网 NAT 管理改变原运维习惯等等问题，都被一一啃下，LXC 顺利本土化成功。

第二个难题是运维标准化的普及，像 QQ 秀、会员这类腾讯比较早期的业务，在当时没有标准化规范的背景下，现网的运维管理有诸多阻碍顺利上云的问题点，如程序混布、hardcode IP 地址、依赖非标准库等等，在接入织云前都要经过运维和开发的适配改造。为了顺利推动让业务开发配合运维做上云的改造，我们设计了织云的“自动调度”、“一致性监控”、“权限中心”等核心功能，让开发改造的工作量有了充足的利好回报，让旧业务标准化的改造如期完成。我们乐观的看到织云平台使 SNG 运维从 D/O 分离转型为 DevOps 模式。在织云平台中，没有运维和开发的严格区分，平台的用户会在既定的标准管理框架中，对统一管理对象——模块，进行录入或变更资源配置（包、配置文件、权限、目录、脚本），流程引擎则会按照既定的次序和调用不同的自动工具，完成用户的一键上云或其他变更需求，而这一切都会在织云的标准化体系保障中自动化的实现。

一键上云的成功，得益于 SNG 自研业务的标准化运维管理的良好基础，我们所有程序的包管理（pkg 包系统）、配置文件 svn 管理（CC 系统）、目录管理（中心文件源）、权限管理（标准 api）、名字服务（L5）的高覆盖率，都可以经过轻量的改造即可成为织云平台的功能之一。再辅以流程引擎，将上云的步骤串成自动化的流程。用户只需在织云平台上管理好模块与依赖资源的关系，织云便可以一键式的完成整个迁云的过程。

InfoQ：织云的自动调度是实现业务动态扩缩容？你们又是如何控制“雪崩”的？面对业务的大量突发，是全自动，还是人工干预？

梁定安：是的，我们认为当一个模块可以灵活的实现扩容自动化时，它便具备了跨 IDC/ 城市迁移的调度能力。同理，我们对运维的业务按核心功能的不同分别抽象成不同类型的 SET/ 服务视图（包含多个模块），当整个 SET 的标准化程度且 SET 内的模块都具备自动调度的基础能力时，我们便可以对整个 SET 进行调度操，目前 Qzone、说说、广点通等重点业务的 SET 已经具备快速调度能力。

雪崩的预防是负载均衡管理中必须解决的一个问题，在 SNG 我们拥有一款十分出色的负载均衡 + 容错组件 L5，L5 利用名字服务将一个集群标识成一个 L5ID，主调方可以通过嵌入 L5api 并调用 get_route 来获取被调 L5ID 中的每个 IP：port，然后当请求结束后 update_route 来更新该 L5ID 的每个 IP:port 的成功与延时信息，L5 组件便可以通过全局数据的整合，在下个调用时间片动态的为 L5ID 下的每个 IP 分配合适的请求量，利用这个原理，L5 根据实际每个被调 IP:port 的请求量、成功率和延时的波动数据，可以计算出每个 IP：port 最大可支持的请求量，当遇到业务请求量陡增的场景，L5 会启动过载保护，在保证被调方饱和的请求量前提下，对新到的请求全部拒绝服务，以防止雪崩的发生。这些都是由 L5 组件全自动实现的。

织云的自动调度原理是对服务 / 模块的容量指标（CPU/ 流量）进行监控，当触发扩容阀值时，织云后台便自动触发部署、测试、灰度、上线这一系列的全自动流程，保证线上服务容量的可用，除非耗尽可用设备 buff，否则织云的自动调度功能辅以 L5 的优秀容错能力，可保持业务容量处于高可用的水平。

InfoQ：一致性应该是多个方面的，包括上面有提到一致性监控，还有织云的另一大特色服务一致性管理，这里的关系与具体包含的内容都有那些？

梁定安：先介绍下一致性本身，这是一套 C/S 的监控程序，C 利用内核 inotify 订阅监控的对象，并通过动态上报的架构，在一个集群内选取一个 leader 汇总数据后，传输到 S 进行数据落地，实测性能可达监控 1000 个文件秒级感知，是我们实现织云前台实时监控现网环境的核心手段。

回到一致性管理，视乎场景的不同，具体可以分为两大类：资源的一致性和服务的一致性。资源的一致性，比较容易理解，织云自动调度中依赖的资源，包括：包（进程、版本、运行状态）、配置文件（md5）、目录（md5）、权限、后置脚本（md5）。通过一致性的管理，使织云能够在无人职守的前提下，自动的变更运营环境。 服务的一致性则与 SNG 业务的形态耦合比较重，如 Qzone 的多地容灾分布，每地的服务彼此一致，主要也是利用一致性的监控管理，服务一致性管理的会比资源一致性管理纬度要粗，往往只包含多个模块的包、通用目录、权限这 3 类。

InfoQ：织云的核心模块有：资源管理，包管理，配置管理，自动流程，一致性监控，中心文件源。对于开发团队而言，在织云做这些操作，和不使用织云有什么区别？ 大体的操作流程是什么样子的？

梁定安：织云提供给开发和运维团队的是工作效率的提升，让我逐一为大家介绍这些核心模块的功能。

资源管理，我们对现网操作的最小管理对象——模块，部署上线所依赖的所有资源，和操作这些资源的先后次序，都将录入到织云的资源配置，并存入模块的 CMDB 配置管理数据库，成为该模块必不可少的属性之一，结合自动流程可实现多种自动化的操作。原则上模块的资源配置只能由少数模块负责人修改，并且当资源发生变更时，织云提供锁表的能力，防止交叉篡改。没有织云的资源管理，运维 / 开发只能依赖 wiki、文档等古老的方式记录，并且无法自动化。 包管理，是 SNG 一个最基础的系统，运维要求每个上线运营的程序，都必须按照 SNG 包管理规范打包，包管理本身提供了一套完整的框架，包括：进程名字与端口管理，启停方式统一管理，标准化的目录结构，完善的进程监控体系，灵活升级回滚的 svn 管理等等。包管理是一切标准化的基础，离开它，运营环境将一片狼藉。

配置管理，指的是配置文件管理，包括线上编辑、版本迭代、diff、前后置脚本、批量下发 / 回滚等等功能，是单文件管理的利器。没有它的话，就只能回到脚本发布时代了。

自动流程，指的是织云的流程引擎，主要功能是将不同的标准化工具串联起来，前者的输出可作为后续工具输入用途，支持流程分支汇总的能力，可通过串联不同的工具，拼装出不同的自动化流程，实现无人职守的各种操作。这就是人肉和自动化的差别。

一致性监控，主要就是秒级感知现网变化的能力。有了它，开发再也不会提让运维批量查一批 IP 的配置是否一致的需求了。

中心文件源，主要是为目录管理诞生的一套 svn 管理的系统，可根据策略不同，自动与现网同步或被同步，且支持大批量的分发能力。没有它，大伙还是只能靠脚本来进行目录类的发布管理，效率低下。

InfoQ：在织云上的业务部署监控、日志收集是如何实现的？而运维“织云”这个平台运维工程师又是如何保证平台的稳定性？

梁定安：托管于织云上的业务使用的是 SNG 内部统一的上报通道，将监控数据和日志上报到监控平台的 storm 集群中，监控数据处理集群利用 mongoDB、rabbitMQ 和 Infobright 对大量的流数据进行处理，最终产生监控告警或报表。织云负责提升运维效率，统一监控平台则负责提供监控告警管理。

织云平台本身的可用性，也是严格按照 SNG 可运营规范要求设计的。值得一提的是，织云为了保证具备自动调度能力的模块在关键时刻的可用性，我们特别设计了演习功能，每天都随机抽取演习，随时检验平台核心能力的可靠。

InfoQ：大部人都认为运维不如研发，作为一名运维工程师，你是如何看待这两者之间的关系的？

梁定安：干一行爱一行，既然选择了运维岗位，我认为就应该热爱运维工作并努力在这个岗位上做到卓越，否则就是对个人对工作的不负责。

谈谈运维和研发的区别，任何一款互联网产品，当具备一定的运营规模时，必然会有开发和运维的明确分工。开发专注于产品功能的实现，运维则会从质量、监控、容灾、成本、安全等纬度去支持产品的发展。

认为运维不如研发的看法，往往都是看到了处于初级阶段的运维。我认为优秀的运维团队，和开发团队之间是互惠互利、缺一不可的。以 SNG 社交平台业务运维团队举例，我们会根据业务的规模，提出很多优化建议，如优化 Qzone 的分布架构，制定跨地域、机房的容灾策略，对核心服务抽象成 SET 化管理，建设 SET 调度的智能决策和执行系统；降低业务的运营成本，引入更廉价的运营方案，根据不同的场景，提出用 SSD 硬盘存储替换内存存储，用虚拟化解决长尾服务的成本压力，或者利用 buff 设备提供离线计算能力；我们还建立了大数据分析系统，为移动业务提供运维 SDK，利用机器学习能力建立外网用户反馈智能分析告警的平台；为了让运维和研发能够更及时的查阅业务运营状态，我们还开发了手机侧的运维工具 MSNG，提供了关键服务的核心指标展示和通用的告警处理工具；为了解决告警量大的问题，我们研发了告警预处理系统，告警根源分析系统等等，这些都是运维团队为产品和研发团队输送的超越运维范畴的价值。

也许运维这个岗位不常会在镁光灯下，成为耀眼的明星团队，但是目前运维团队的价值远未被发掘完，我们仍在积极探索未来可以触及的新方向。