腾讯海量数据仓库运维系统 : 鹦鹉螺

一、前言

时值建军90周年之际，相信大家的朋友圈都被好友的“军装照”引爆刷屏。而在运维圈，则更多是被腾讯织云运维平台的运维能力所深深折服，并燃起熊熊的探索欲望。然而，在SNG内部，系统的最后端，还活跃着一群低调、坚韧的攻城狮--没错，就是我们的DBA团队。SNG社交网络运营部的数据组，负责着QQ、Qzone、相册、以及腾讯云CRS等整个SNG产品的数据运维，保障QQ、空间等社交产品的稳定运行，以及腾讯云上对外数据库产品的日常运维。目前数据团队拥有亚洲最大的nosql分布式数据仓库，日均数十亿的qps访问，过万台的机器设备。这么庞大的体量、繁复的工作，我们DBA是怎么完成的呢？

二、提升效率

随着业务的不断发展，新产品的不断开发，数据容量也不断增大：仓库数量也由原先的几十个逐步增长到几百个，机器数量也达到了惊人的几万台。随着CRS等数据库组件在腾讯云上售卖，dbc面对的网络环境由原先的自研网络逐步扩展到腾讯云、私有云等网络环境，网络差异带来的运维工作量和复杂度也直接翻倍。日常设备维护、机器上架、组件版本升级、仓库扩缩容等，这么庞大的体量和工作量，给我们dbc团队提出了严峻的挑战。

相对于web层和逻辑层等无状态、轻量级的组件，数据层组件则显得沉重很多。数据层组件有状态、重资产（数据），很多的运维操作过程复杂，更多的涉及数据搬迁。既然数据层对状态维护、准确性、一致性有着苛刻的要求，又希望能够适应业务的发展而做出快速调整，DBC团队依托织云（利用织云提供的api，如命令通道、包发布等）研发了自己的数据库管理平台：鹦鹉螺。鹦鹉螺将所有的运维操作分解为细粒度的原子操作，再通过流程把原子操作串联起来完成复杂的功能。前端用户发起的运维操作最终落到后端具体的原子任务或流程上。

例如对仓库接入机的扩容操作，用户在前端只需填入需要上架的机器列表，提交后由后端作业平台自动发起扩容流程并负责调度。

三、系统总体架构

    上图是鹦鹉螺系统的核心模块，主要包括DB-CMDB、变更中心（即作业平台）、数据中心、决策中心，还有前端的dashboard展示模块等。其中DB-CMDB记录了仓库相关的配置信息，如仓库包含的机器设备、所在网络区域，接入的业务信息，机器ip的角色信息（接入机角色、配置中心角色、cache角色）等等。变更中心--也就是作业平台，是实现运维操作的关键，鹦鹉螺系统对现网的所有操作都通过这个模块完成。数据中心包含了现网仓库的运行数据、指标数据、和相关告警数据，这也是决策中心的数据来源。在决策中心中，完成一些告警的预处理。对于常见的有预处理方案的告警，可以在这里设置，当告警发生时，由决策中心发起相应的处理措施。

四、变更中心（作业平台）

变更中心，也就是鹦鹉螺系统中的作业平台。它是一个分层的架构，从下往上，依次是底层工具层、任务层、流程层，总体架构图见下图。采用分层结构，任务层、流程层并存，主要是基于实际的运维场景需求。为了实现快速调整的能力，这里把所有的运维操作场景，都分解为最小粒度的原子任务（原子操作），再由原子任务（原子操作）串联组合成流程来完成复杂的运维操作。

基础设施层主要是对一些基础工具和周边系统接口进行封装，方便上层模块调用。其中不同网络的差异也在这一层进行抽象适配，例如远程命令通道，对上层应用暴露统一的通道接口，在接口内部再根据目标ip所在网络区域不同分别调用不同的命令通道处理。

任务层主要是负责原子任务的托管、调度。一个原子任务是一个最小粒度的操作，它可以独立运行（可以在dashboard上发起，或者通过平台提供的api发起执行），也可以同其他原子任务组合形成流程依次执行。在鹦鹉螺的作业平台中，原子任务划分为两类：本地任务和远程任务。远程任务，顾名思义，即需要到目标机器上执行的任务，它可以是一个shell脚本或者python脚本，执行时需要用户给定目标机器列表，由框架将任务脚本分发到目标机器上发起执行，并把执行结果整理返回。本地任务，同远程任务相对应，即不需要在远程目标机器上执行，而是在运维系统的管理机上执行。在我们实际工作中，个别运维场景会使用到这类任务。原子任务的编写，我们做到了平台无关性，即用户编写原子任务时无需关心平台框架的任何东西，只需完成原子任务所要完成的功能即可。

流程层主要是负责流程的管理和调度。一个流程就是若干个原子任务的编排。在实际业务中，大多数运维场景都不会是简简单单的一个操作就能完成，复杂的业务操作需要由若干个原子任务按一定顺序组合而成。在流程支撑模块中，可以根据不同的业务场景，制定不同的任务执行策略，流程的执行支持失败重跑、部分成功等。

无论是原子任务还是流程，作业平台都提供了统一的调用接口，以达到任务、流程复用的目的。整个作业平台，是鹦鹉螺的基石和核心，所有对现网的操作，都是通过任务、流程来完成。

五、数据中心

数据库组件在运行过程会产生很多的运行数据，这些数据对我们了解组件的运行状态、服务情况起到至关重要的作用。在SNG内部，数据库组件在开发的过程中会定义好若干个（一般有几百个）属性，如收到的请求量、处理耗时、主备同步差异等等，并在现网运行过程中将这些属性值上报到monitor（织云监控）中。因此对这些数据的分析、计算，是我们掌握数据库运行状态的最佳数据来源。鹦鹉螺中数据模块的大致架构如下：

数据总线采用push/pull方式收集组件各个属性的实时数据，按照一定的规则对数据进行简单的过滤清洗，最终将数据落地到本地数据库中。计算单元从本地DB中读取相关的元数据，按照预设的算法、规则，对元数据进行实时计算、聚合，产出具体的指标数据或告警数据。前端dashboard可以从这里拉取指标数据进行实时的绘制，告警数据则可以按设置的规则发送给业务负责人或发送到决策中心进行告警预处理。

六、决策中心

目前我们的决策中心主要是一些告警的预处理决策。我们对那些常见的、有既定排查和处理方案的告警抽象为可识别的规则，配置到决策中心。外部网管产生的告警或数据中心计算产生的告警，首先发送给决策中心，决策处理模块根据告警的类型，在规则库中查找对应的预处理方案。当需要对现网发起变更时，则调用作业平台上相应的原子操作或流程进行变更。

七、未来方向

正如上面说到的，我们的组件在代码层面就做了很多的埋点，组件在运行过程中会以分钟为粒度上报每个属性值，因而我们有大量的元数据可供分析（每天上亿条元数据）。按照以往方式在代码层面写算法，分析数据，显然不能够充分发挥现有数据的价值。在未来，我们计划引入机器学习，将AI落地到实际运维场景中，比如访问量、流量的异常检测；异常发生时的根因分析、关联分析等等。在决策模块引入AI，利用有监督、无监督抑或强化学习等，打破预设专家规则模式的局限，进一步强化决策能力。事实上，我们也已经在机器学习上迈开了步伐，探索AIOps的未来。