民生银行智能运维的探索与实践：DBPaaS数据库统一管理平台

01

背景与挑战

数字化转型带来的数据库运维挑战越来越大

随着数字化、互联网的快速发展，民生银行正在加快推进全面改革转型，以“数据+技术”双轮驱动，着力打造数字化智能银行。业务创新与技术架构演进需要底层基础软件平台的强有力支撑。

目前我行生产环境运行着数千套数据库，数据库种类从成熟的商业数据库产品逐步转向开源数据库、国产数据库。数据库运行环境和架构也越来越丰富，从高性能物理服务器加共享存储转变为各种虚拟化甚至容器化环境；从基于共享存储的双机互备高可用架构，发展为双活数据中心、两地三中心、读写分离、分库分表等架构方式。数据库运维的挑战越来越大。

实现标准化、自动化、集中化、智能化的数据库运维理念

为应对数据库运维挑战，助力我行数字化转型，数据库运维团队提出了标准化、自动化、集中化、智能化的数据库运维理念。

DBPaaS数据库统一管理平台就是在此背景下开始建设的。整体目标是实现数据库运维流程、运维规范的标准化，实现数据库部署上线、扩容、变更、巡检、回收下线等维护工作的自动化，实现数据库资源管理、性能管理、容量管理、问题管理等管理功能的集中化、可视化，实现数据库问题分析，监控预警的智能化。实现数据库运维从手工模式向工具平台化、精细化的转型。

坚持有效整合、自主可控的建设思路

经过多方考察调研，结合实际使用经验，我们决定遵循有效整合、自主可控的思路进行平台建设。一方面我们借鉴整合成熟数据库管理技术框架，与具备丰富数据库管理平台建设经验的外部资源合作，快速搭建基础平台，进行项目一期建设投产。另一方面我们坚持自主可控，根据实际的需求和我行现有运维工具体系对实现策略、具体功能以及建设目标进行灵活调整，投入大量的精力在需求分析、架构设计、运维体系规范化以及运维流程建设上，同时深度参与到平台脚本及源代码的开发工作中，做到源码级自主可控。

02

架构和设计理念

微服务架构

DBPaaS数据库统一管理平台基于微服务架构，对平台中的功能进行分层和分模块设计，明确功能边界，实现自主可控、开放和可扩展的总体架构。

通过层次化设计，从架构上我们将服务分为基础服务，交互服务和集成服务三类，如下图所示：

图1-基于微服务架构的开放式和可扩展性设计

基础服务：基础服务是整个平台的基础，包括监控引擎、自动化运维引擎、CMDB服务、监控数据服务、分析引擎、SQL执行以及任务调度等后台服务。基础服务提供平台基础功能，通过公共API为前端功能提供访问接口；

交互服务：提供平台用户直接使用和交互的功能性服务，包括监控告警、问题管理、性能容量、工具箱、报表、操作审计、配置管理以及用户管理等；

集成服务：提供集成功能服务，将数据库统一管理平台作为数据库运维的统一入口，并无缝对接我行现有运维管理平台或工具，例如单点登录、流程系统、统一告警平台等。

无缝集成

经过多年的持续建设，我行已经积累了丰富的IT运维工具资产，例如单点登录系统，统一告警平台，CMDB系统，移动运维平台，集中监控平台，ITOMS流程系统，云图系统等等，这些运维工具和平台经过多年的实际使用和优化，运行稳定，已经融入了运维人员的日常工作当中。数据库统一管理平台需要与现有的运维体系无缝集成，例如通过单点登录实现系统登录，通过统一告警平台推送数据库告警，通过CMDB系统直接纳管目标数据库，集成集中监控平台采集的主机监控数据，集成ITOMS系统完成运维操作的审批流程等。只有这样才能确保不形成新的工具类孤岛，降低平台的使用门槛，提高平台的接纳程度。

同时，随着应用开发模式向DevOPS转变，以及应用端到端的一体化运维理念，数据库统一运维平台需要提供开放的API供其它工具或平台调用，例如向DevOPS平台提供数据库。

SQL执行与SQL审核的接口，向智能运维平台提供数据库的监控数据等。

功能可扩展性设计

运维的场景千变万化，没有一个产品可以在设计的时候就能满足将来所有的运维需求。虽然自主研发能够保证随时调整需求，但如果任何新功能的实现都需要通过修改代码来实现则显然是不合理的，在成本和质量方面都难以接受。因此平台必须具备功能可扩展性设计，在大部分场景下，通过配置就可以为平台增加新的功能，无需修改代码。

基于功能可扩展性设计的理念，平台在上线以后，平台管理员可以根据需求在平台上设计、配置、测试和发布新的数据库管理功能，在使用平台的预置功能之上，积极参与平台新功能的设计和建设，不断完善平台的数据库管理功能。

高可用和性能可扩展性设计

目前平台一期纳入数据库统一运维管理平台的数据库有上千套，随着业务的增长，未来纳管的数据库规模会越来越大，这要求我们在设计数据库统一管理平台时，必须考虑规模可扩展性，平台的各服务模块要求无状态，能够横向扩展，数据存储平台也需要采用分布式存储方案，并支持横向扩展。

另外随着所有数据库的监控、运维都通过平台来实现，平台自身的可用性就显得尤为重要，因此在设计的时候要考虑高可用设计，平台中的每个服务或组件都应该有冗余配置，不能有单点故障的隐患。

03

平台的主要功能

基于微服务架构，数据库统一管理平台实现了分层次和模块化的功能设计，整个平台自下而上分为数据层，基础服务层，功能层和展示层。

图2-分层次的数据库统一管理平台功能

数据层

数据层负责存储和管理平台所有数据，包括CMDB数据，配置元数据，监控数据，以及数据库日志数据等。

1.CMDB数据通过平台的CMDB服务从行内统一的CMDB系统获取，并提供了缓存和更新机制；

2.数据层存储了所有从目标数据库采集的监控数据，这些数据供平台其它功能模块使用，还可以发布至Kafka供其它需要使用数据的系统使用；

3.数据层具备数据归档和清理机制，对监控数据进行聚集和归档，删除超过设定保存期限的原始细粒度数据，这样可以节省空间并提高性能。

基础服务层

基础服务层主要包括SQL执行服务，监控数据采集服务和数据展现服务，这些服务不直接面对平台用户，而是通过开放接口为平台上层功能或其它系统提供基础服务。

SQL执行服务：负责到目标数据库上执行SQL语句，所有通过平台发起的目标数据库访问，无论是监控数据采集，还是用户执行的SQL语句，都通过平台的SQL执行服务去访问目标数据库，这样可以有效控制对目标数据库的访问。

监控数据采集服务：根据配置的数据采集项从目标数据库上采集各种监控数据，并进行计算和处理，然后存储到数据层。平台使用JDBC的方式从目标数据库采集数据，无需在目标数据库部署和维护Agent，同时所有的数据处理和计算都发生在监控采集服务端，因此对目标数据库的性能影响非常小。监控数据采集服务支持高可用和负载均衡，可以通过横向扩展的方式支持监控更多的目标数据库。

数据展现服务：提供标准API用于访问监控数据，这些API根据不同的使用场景组织数据，形成规范化的监控数据访问机制。数据展现服务API除了用于平台自身，还可以提供数据给移动运维平台、应用性能管理平台等其它外部运维工具或系统。

功能层和展现层

功能层和展现层面向最终用户，提供了各种按照主题和维度划分的数据库管理功能，例如资源管理，性能管理，容量管理，问题管理，自动化运维等。

数据库资源管理与CMDB系统无缝对接，提供了我行数据库概览视图。在平台中可以看到所有被纳管数据库的基本信息、运行状态、负载以及容量使用状况。平台具备探活功能，会对数据库状态和角色进行检查。如果数据库无法访问，或者数据库主从角色与CMDB提供的信息不一致，则产生相应的问题或告警；当数据库状态及角色正常后，相应的问题或告警会自动解除。对数据库资源的状态和角色进行监控和管理一方面提升了我行数据库的整体可用性，另一方面也为自动化运维提供了准确的信息基础。

图3-统一数据库资源管理

性能容量管理提供了从宏观到微观的数据库性能容量管理体系。在宏观层面上，通过收集和分析数据库的关键性能指标，对数据库性能进行量化评分，有效反映民生银行数据库系统的整体性能状况，并且可以对某个数据库的性能状况进行横向和纵向比较；在微观层面上，对某个数据库性能评分较低的指标项，提供下钻分析，直接定位到相关的SQL或对象，例如等待占比较高的SQL语句，有效读比例较低的SQL语句，表扫描次数较多的表等，帮助数据库管理员、应用运维人员和开发人员分析和定位问题。

图4-数据库性能评分

数据库热点分析能够详细展示数据库时间分布，同时提供了数据库中的热点SQL以及热点对象，帮助用户分析和定位数据库性能问题根源。

图5-数据库热点分析

SQL性能分析使系统中的慢SQL以及SQL瓶颈一目了然，提供SQL历史执行次数及性能趋势，同时提供SQL多指标关联性分析，可以聚合展示SQL语句的多个指标，帮助分析和优化SQL语句；针对慢SQL，系统还可以自动分析瓶颈并给出优化意见。

图6-SQL语句多指标关联性分析

容量分析和预测功能可以展示数据库容量变化趋势，以及数据库中表空间、表的增长率；同时容量分析功能还可以展示长期未使用的数据库对象以及容量增长与SQL的对应关系，为容量优化提供依据。

图7-数据库容量大小分布及趋势

图8-数据库容量下钻分析

问题管理针对平台监控和分析发现的数据库问题，提供了问题生成、处理、验证和关闭的完整生命周期管理。

图9-全生命周期的数据库问题管理体系

问题由分析引擎对采集的监控数据进行实时分析，自动生成。生成规则可以配置，并且通过规则表达式，支持复杂的条件判断。问题管理的初衷是对所有可能导致数据库事件的问题进行发掘和预警，因此问题项的可配置性非常重要，数据库管理员可以根据实际经验通过配置不断地修正和完善问题规则。目前平台配置了77个问题项，其中包括许多容易忽视但却需要额外警惕的问题，例如Sequence接近使用上限、分区表可用天数过少等。

同时问题管理功能还可以记录问题的处理过程，建立针对问题处理的知识库体系，为解决具体问题提供参考和指引，帮助运维人员不断的完善和积累数据库运维知识。

图10-数据库问题列表

报表服务提供了标准化和定制化的报表功能，针对不同的用户和场景，提供了多种不同类型的报表。

深度巡检报告：提供丰富全面的数据库深度诊断报告。深度分析数据库各项指标，准确反映数据库全方位的健康情况；

汇总报告：提供多个数据库的汇总诊断报告。从整体上分析被监控数据库的指标状态，主要用于对比、分析多个同类型的数据库的运行情况；

性能容量报告：提供数据库性能容量诊断报告。定位需要调优的SQL语句或数据库对象，并提供专业的调优建议。对于SQL语句，提供超链接跳转功能，准确定位到SQL分析页面，提供SQL详细分析信息。

平台所有的报表都是根据监控数据定时自动生成或者人工触发一键生成，相比于传统的人工报表模式，节省了大量的人力成本，报表数据更加准确，覆盖更加全面。

自动化运维功能与基础软件PaaS自动化执行引擎无缝集成，提供了大量的标准化数据库运维操作，包括数据库的启停、参数修改、用户权限管理、表重组、统计信息收集、表空间扩容、降低高水位等。通过平台执行数据库运维操作可以大大降低不规范操作带来的数据库操作风险。

平台支持能够从操作类型和管理对象两个维度对运维操作进行权限管控，对于变更类操作，平台还设置了客户端白名单机制，只有授权终端才可以进行操作。此外所有经过平台的数据库操作，都有相应的操作日志用于审计，包括但不限于用户、执行时间、执行操作、执行参数、执行对象、执行结果等，可以按照时间、操作对象、用户等不同的维度对所有数据库操作进行审计。

平台的运维功能支持扩展，且不需要修改代码。运维人员可以根据实际需求开发新的标准化脚本，通过平台集成并发布，实现新的标准化运维操作。

04

总结与规划

该系统一期于2019年6月4日正式上线，经过2个月时间的纳管和试运行，于2019年8月12日正式向所有运维人员开放。

截止2019年10月，该平台纳管上千套生产数据库。生产环境的使用人数共计75人，服务请求总调用超过6万次。生产稳定的采集数据量为1.5TB，同时采集后的数据又为后端的智能分析提供了数据支撑。

依托于该系统的上线，我们为数据库运维工作提供了更便捷的工作方式，将原先老旧的半手工半脚本式的运维模式转为全自动自助式的运维模式；建立了完善的数据库问题管理体系，用于发现和跟踪各种重要非紧急类问题，有效的填补了现有监控系统的不足，与现有监控系统形成有效的互补；有效减少了审计平台的操作次数，操作指令发送次数平均减少50%,登录次数平均减少30%，极大的减少了非法操作的风险；建立了数据库的报表体系，每周定期向各系统负责人发送完整的巡检报表和问题报表，将每个系统的数据库情况100%的暴露出来，极大的解放了手工出报表的工作量，提高了报表的覆盖维度；提供丰富的API和数据同步功能，极大方便了我行其他系统的分析使用。

DBPaaS数据库统一管理平台是一个开放的平台，在后续的工作中，我们会持续投入平台建设，迭代开发新的功能需求；优化平台架构，实现容器化部署，实现秒级监控和数万目标数据库的纳管能力；在性能容量方面，实现数据库SQL语句执行计划管控和元数据对象管理；在自动化运维方面，实现一键故障诊断和一键故障处理，并和问题管理集成，实现基于场景化的引导式和全自动化数据库运维操作；同时加大对国产数据库支持力度，实现多数据库参数比对、元数据比对、数据分布和访问读倾斜分析等分布式数据库管理功能。在建设过程中，数据库运维团队成员会继续深度参与，共同努力，持续打造民生银行标准化、自动化、集中化和智能化的数据库统一管理平台。