【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 2014-09-24
  • 本文字数:4581 字

    阅读完需:约 15 分钟

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

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

2014-09-24 20:316364

评论

发布
暂无评论
发现更多内容

本地Kind体验TiDB Operator最小实践

TiDB 社区干货传送门

实践案例

对Indexlookup的理解误区

TiDB 社区干货传送门

管理与运维

【故障解读】v5.1.1-调整变量 tidb_isolation_read_engines 影响 tiflash SQL 执行计划

TiDB 社区干货传送门

HTAP 场景实践

【故障解读】v5.3.0 BR 备份报错并且耗时比升级前更长

TiDB 社区干货传送门

备份 & 恢复

单机 8 个 NUMA node 如何玩转 TiDB - AMD EPYC 服务器上的 TiDB 集群最优部署拓扑探索

TiDB 社区干货传送门

管理与运维 性能测评 数据库架构设计

TiDB HTAP 遇上新能源车企:直营模式下实时数据分析的应用实践

TiDB 社区干货传送门

我和TiDB的故事 | 毫无准备地不期而遇,却想说与你相遇好幸运

TiDB 社区干货传送门

社区活动

Facebook 开源 Golang 实体框架 Ent 现已支持 TiDB

TiDB 社区干货传送门

应用适配 数据库连接

在华为 Kylin V10 SP1操作系统,HUAWEI,Kunpeng 920 CPU(4Cores)单机上模拟部署生产环境TiDB集群

TiDB 社区干货传送门

集群管理

TiDB v5.1.2 - TiCDC 不同步,checkpointTs 不推进的问题排查

TiDB 社区干货传送门

实践案例 故障排查/诊断

新版 TiDB 社区技术月刊,一站式 Get 社区全动态

TiDB 社区干货传送门

社区活动 故障排查/诊断 数据库架构设计 应用适配

TiKV缩容不掉如何解决?

TiDB 社区干货传送门

集群管理 故障排查/诊断 扩/缩容

从2018到2022: 一个大数据工程师眼中的TiDB

TiDB 社区干货传送门

社区活动

统计信息十问: 你不了解的那些事儿

TiDB 社区干货传送门

实践案例

关于auto_random的几个知识点

TiDB 社区干货传送门

管理与运维

TiDB Numa 性能压测

TiDB 社区干货传送门

版本测评 性能测评

TiDB 6.0 的「元功能」:Placement Rules in SQL 是什么?

TiDB 社区干货传送门

6.x 实践

tidb 2.1升级到4.0操作文档

TiDB 社区干货传送门

迁移 版本升级

TiDB Online DDL 在 TiCDC 中的应用

TiDB 社区干货传送门

迁移 TiDB 底层架构

TiDB 在携程 | 实时标签处理平台优化实践

TiDB 社区干货传送门

DM 是如何处理 DML 的

TiDB 社区干货传送门

迁移

TiDB 在连锁快餐企业丨海量交易与实时分析的应用探索

TiDB 社区干货传送门

TiUP:TiDBAer 必备利器

TiDB 社区干货传送门

管理与运维 安装 & 部署

将 AWS S3 数据迁移至 TiDB Cloud 集群

TiDB 社区干货传送门

体验 TiSpark 基于 TiDB v6.0 (DMR) 最小实践

TiDB 社区干货传送门

实践案例 6.x 实践

tpcds performance compare between tidb and impala

TiDB 社区干货传送门

性能测评

PD节点恢复之一个也不剩

TiDB 社区干货传送门

集群管理 故障排查/诊断 备份 & 恢复 扩/缩容

Flink CDC 2.2 正式发布,新增 TiDB 数据源,新增 TiDB CDC 连接器

TiDB 社区干货传送门

新版本/特性发布 应用适配

使用TiUP 修改集群目录实践

TiDB 社区干货传送门

管理与运维

Oceanbase和TiDB粗浅对比之 - 执行计划

TiDB 社区干货传送门

数据库架构设计 应用适配

文盘Rust -- 起手式,CLI程序

TiDB 社区干货传送门

开发语言

梁定安:解密腾讯SNG云运维平台“织云”_QCon_刘宇_InfoQ精选文章