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

  • 刘宇

2014 年 9 月 24 日

话题:QCon云计算DevOps腾讯

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,提供了关键服务的核心指标展示和通用的告警处理工具;为了解决告警量大的问题,我们研发了告警预处理系统,告警根源分析系统等等,这些都是运维团队为产品和研发团队输送的超越运维范畴的价值。

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

QCon云计算DevOps腾讯