导读：此前，由 OceanBase 社区主办的 「跨境电商数据融合的最佳实践及数据库智能化运维」直播专场已经落下帷幕，本文是基于白鳝老师现场演讲的《基于知识图谱的开源数据库智能运维》内容梳理，以下为演讲整理稿件。
嘉宾介绍：徐戟（花名：白鳝），现任南京基石数据技术有限责任公司技术总监，国内著名的系统优化专家，从事过电信、政府、金融、能源行业的应用软件开发与信息系统建设工作。曾主持开发了全国第一套电信级联机实时计费系统、全国第一套三检合一的检验检疫综合管理系统和EDP电子申报系统。
企业数字化转型的运维挑战
据我对企业数字化转型多年的观察发现，IT 部门和运维部门往往是整个企业中最后完成数字化转型的。相信你也注意到了，企业中的业务部门即使没有数字化，也进行了信息化，但IT和运维部门连信息化都谈不上，更多的还是靠人、靠脚本......这样整个企业就无法完成数字化转型。
与此同时，在企业数字化转型的过程中起到主要作用的CIO也面临着诸多挑战，如更复杂的IT环境、更高的运维目标与成本。
更复杂的 IT 环境
随着业务增长及数字化的深入，企业 IT 架构日趋复杂，数据规模呈指数增长，传统人工维护捉襟见肘。前段时间一个用户的反馈也更直观地说明了这一点，他说，“我们现在换了国产数据库，想请国产数据库的厂商来帮我们做运维，但难点在于无论我们给出多少钱，数据库厂商都不愿意派人过来做运维，因为他们也没有人。”
这不禁让我想起了前段时间我在做国家电网数据库转型选型工作时做过的调研：真正超过1000人的国产数据库企业只有2~3个；少于50人的国产数据库企业有四十多家，它们可能连研发进度都跟不上，更别提去帮别人做运维了。
更高的运维目标与成本
一方面，业务的数字化需要越来越主动的 IT 运维，从被动维护到主动管理需要更系统、更高效的 IT 运维工具。另一方面，众多国产数据库崛起，短期内难以形成数据库生态，使运维难度加大。同时，IT运维人员的薪资成本也在逐年提升。总之，IT运维面临的挑战可以总结为三点。
- 不断攀升的规模与成本
- IT 规模越来越大，运维工作量越来越大
- 人力成本越来越高，高水平专家严重缺乏
- 市场竞争越来越激烈，项目费用越来越少
- 缺乏技术积累
- 经验与知识都在人的脑子里
- 企业无法沉淀核心技术
- 很难从历史故障中积累经验
- 信创方面的缺失
- 信创 IT 产品的服务生态不完善
- 信创数据库产品技术技能缺失严重
- 信创产品运维人员稀缺
据 2021年工信部的统计，国产关系型数据库大概有 87 家。至今关系型数据库已经超150家。这么多数据库产品，如何运维 ？
我们也在探索能否形成生态化的服务体系，公司或者服务厂商从以前的竞争关系转变为合作关系，将大家的力量捆绑在一起才能在信创的环境下，为客户提供更好的服务，让客户对数据库用得更好。
运维体系重构四要素
近两年我们也从党政、小企业、能源、运营商等方面做了一些尝试，效果还不错。具体而言，我们所尝试解决数字化转型运维挑战的方法是构建一套通用的标准化语言，即重构运维体系，其中包含四个要素：完善/标准的指标体系、高水平的专家团队、低成本训练的智能化算法、强大的生态合作伙伴。
要素一：完善/标准的指标体系
在这里我解释一下“完善”和“标准”是什么意思。
对于标准而言，现在我们和客户团队去谈一件事的时候，我们用的指标体系是不一样的。哪怕是讲同一个指标，也可能 ID 不一样、表述不一样。
我在 2019 年为国家电网建立了一套运维系统的指标体系，包括各种数据库、中间件、存储......例如，国家电网采用Oracle数据库有六百多个指标，而全国都采用统一的指标，这就可以为后续的生态化运维协作提供便利。因为有一套标准化语言，所以如果一个省的系统出问题了，在问题排查报告中，我们只需要观测报告中的指标，就能知道问题所在。
之所以需要完善的指标体系，是因为以前的运维自动化系统是基于网管思路，所需要的指标数量是很少的，判断标准只有好和不好。但如果我们想进入数字化运维的阶段，进行自动分析、诊断，需要的指标数量相较于自动化系统是成倍的。如今，有些企业做数据库运维工具的时候，都是通过MIB（管理信息库）来实现MIB库的指标，但MIB库大多数是配置信息，真正可以用于深度分析的指标相当少，导致各个企业都需要扩展MIB 库。因此，我们就需要形成一套完善的体系，避免此类问题。
要素二：高水平的专家团队
以 OceanBase 为例，OceanBase 开发团队及重度用户，积累了大量的经验，这些高水平的专家团队，能否在数据库生态中共同协作也是十分重要的。
要素三：低成本训练的智能化算法
如今的数据大爆炸时代，完全靠人力去做分析是不可行的，还需要通过算法工具才能更高效地完成分析任务，但现在的很多算法比较“重”。前年我去北京和裴丹老师做技术交流时，发现他们采用的是自有的闭源算法。虽然他的国内团队在异常检测算法方面算是顶级的，但他也面临一个问题：算法太“重”，到客户的现场实施一次算法至少需要50万的前期成本，如果需要做很多个系统的话，成本是大多企业无法承受的。能否有低成本及少量的专家标注，也是需要解决的问题。
要素四：强大的生态合作伙伴
在之前的一次交流中我也提到过：一个企业想要积累大量的故障案例，能够训练出模型是很难的。需要大家广泛的参与合作。
当有了运维体系重构的四要素，就可以构建出自己的知识库，进而实现智能化的分析。接下来我跟你分享一些在实践过程中积累的经验。
运维体系指标标准化建设
指标标准也是一种运维知识，D-SMART 的开发者通过运维专家对运维对象指标体系的分解，构建了足以进行全面分析的标准化指标体系。
运维指标管理
想去做一个智能化运维工具，首先需要梳理运维对象的要点，我们将这些要点分为三大类：
- 管理类，包含对象关系（如数据库与网络的关系）、运维的要点（如将技术指标设定为基础指标，风险指标设定为高级指标）、关键操作命令。
- 配置类，包含配置文件、核心参数。
- 技术类，包含各种指标和日志。
将管理要点梳理出来，就会形成一个运维对象的基础指标体系框架，随着应用的不断增加，指标也在不断增加与完善，这是一个积累的过程。在此过程中，也要形成高质量的指标采集。举个反例，我经常遇到一些企业或组织因为自动化系统故障导致整个企业系统宕机的情况。某医院每隔30s采集一次表空间使用率，库的容量达到十几TB，每执行一次查询都会扫描一遍库，用时最低5分钟，负载高时需要20分钟，最终I/O都被执行SQL占据，触发了系统故障，导致医院业务停滞了1小时。这个反例告诉我们，一些高风险的指标采集尽量规避或换种采集方式，而且，采集到指标后在自动化系统中加工而不是直接在数据库系统中操作。
对于高质量的指标采集，传统的网管式监控系统采集的指标比较少，无法用于深度分析与故障预警。采集大量的指标需要注意以下几点：
1）高效，避免运维对象造成影响；
2）安全，不做存在风险的指标采集；
3）最小资源消耗，大量的计算在运维平台上做；
4）有效，采集的指标集可覆盖运维分析需求。
运维知识图谱
我们需要通过专家协助来梳理出一份知识图谱。结合每次出现故障的案例（案例的抽象可以是不准确或错误的，都没关系。因为在智能推理的过程中会将一些错误的分支裁剪掉），通过不断地提炼和丰富知识图谱，使其分析能力不断提升。通过不断的扩展在达到一定程度以后，这个图谱就可以通过一些算法，来超越专家的能力。
图谱的积累是很重要的。我们第一版的图谱只有四千多个顶点，现在我们有十几万个顶点、几十万条边。这份图谱的能力也不断在提升。
我们构建了一个系统，下图为系统的逻辑架构。底层是我们要监控的对象，我们会通过 Collector 定期进行指标采集，在采集后将初始化指标放到 ZK 中并进行紧急状态的评估，紧接着数据会进入 Redis 缓冲，由Monitor 根据规则进行健康评分、性能评分，最终由 Monitor 将数据固化到 PG数据库中。
在这张逻辑架构图的左侧是 Fstask 任务平台，如果我们发现了一些问题并对它们展开分析，那么目前的数据量是不够的，需要补充，这就涉及去系统中采集数据。Fstask 任务平台大部分情况下是在访问本地 PG 数据库。我们也希望采集过来的指标在大部分情况下不再去干扰生产系统，而是希望数据分析通过离线的方式实现。我们有一个离线的数据中心版本，存储了几十个用户分享的数据，有一个用户每隔三个月会将他的监控数据发给我们。我们远程帮他做巡检、定位问题。
目前我们平台管理的最大用户有两千多个数据库实例，这就需要支持海量数据的环境，需要分布式技术，可以跨越不同网段去采集指标。下图为我们目前实现的一个架构。
如何构建知识图谱
那么我们是如何构建知识图谱的，以及知识图谱怎样发挥它的作用呢？下图是一个典型例子，首先我们通过各种预制的规则来进行问题感知，进而定位到一个问题场景。可见运维都是面向场景化的，比如说存在长时间锁定的情况或同一个 SQL 两次的执行时间差异大......
在发生类似这样的现象后，会存在诊断路径。我们通过上图中的知识点建立一张网状关系，每个知识点会和指标有一定关系。所以我们在做 OceanBase 知识图谱的时候，经常会去咨询社区的研发人员。比如，某个指标异常大概是什么意思？可能会影响哪些方面？一定要将问题和答案梳理出来，越多越好。如果找不到答案，就需要去翻代码。我们还可以从案例中获取经验，比如，在案例中哪些指标是异常的，将经验放到知识图谱中。
通过诊断路径把一个个指标收集出来。当某个现象发生时，将和它有关的指标尽可能多地找出来，也可以通过社区发现算法，将关系不是很近的指标也找出来，然后对这些指标做异常检测。通过异常检测将正常的指标剔除，不正常的指标形成一个集，再通过算法去做问题归类，这样就形成了一个问题路径。最后，再通过知识图谱来验证问题是否存在于系统中，如果确实存在，可以将其归类形成最终的根因分析。这就是我们目前通过知识图谱去做智能化诊断的大体过程。
平时我们也需要去积累，一个指标或一个场景可能和哪些问题/路径有关？这些知识点可以通过哪些工具去做验证/分析。我们还增加了泛路由节点，泛路由节点是一个低代码化的诊断工具，在系统中，它会和已有的一些节点建立关联。随着翻转流知识点越来越多，整个诊断路径会被不断地优化。当我们将问题分析清楚后，就会形成新的专家诊断路径，将原有知识图谱进行优化，不断迭代整个过程，也可以快速地进行知识扩展。
下图是我梳理出来 PG 数据库的例子：每秒 BufferPin 等待事件数量，可能会和五方面有关。在我们构建出这样一个知识图谱后，一旦今后出现同样问题，就可以通过这个图谱就找到相关的关键指标，去做更新定位及分析。
不知道大家是否有关注过OceanBase 的两个指标，一个是 memstors read lock succ count，另一个是 memstors read lock fail count，将这两个指标加工一下，衍生出右侧的四个指标：每秒 MEMSTORE 读锁总数、每秒 MEMSTORE 读锁成功数、每秒 MEMSTORE 读锁失败数、MEMSTORE 读锁成功率。这四个指标和什么有关？它影响因素是什么？一方面，社区的研发人员可以提供一些帮助，另一方面，我们分析源代码也可以获取到一定的知识。同时对照我们现有的生产环境做数据分析。
另外，当指标异常的时候，我们通过分析当时系统的状态和存在的问题，梳理出这四个指标相对于两个指标的突破。便于当系统再次发生问题时我们能给快速定位问题。
当我们能把OceanBase 的600个指标都分析清楚。那对于OceanBase出现的问题就非常容易解决了。这件事可以在共享的环境中让大家一起来参与，共建知识图谱。
总的来说，对于数据库智能运维的方法，我们探索出一个生态化的运维体系。在这个体系中，有四个关键要素：完善/标准的指标体系、高水平的专家团队、低成本训练的智能化算法、强大的生态合作伙伴。另外，我们需要梳理及管理各等级的指标，并逐渐完善指标体系，进而结合专家团队的建议和反馈建立异常指标的知识图谱，以便在系统异常时我们能快速诊断问题并找到解决方案。
以上就是我的分享，希望我们的智能运维方法能给你提供参考价值。
推荐阅读：
OceanBase 拟真压测系统深度解析
携程经验分享：MySQL数据同步OceanBase时DDL遇到的问题
————————————————————————————————————————————
社区版官网论坛
社区版项目网站提 Issue
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
