王宇庭
Shindata 新数科技售前技术总监
专注数据库行业多年，熟悉并掌握多种数据库架构，对数据库运维领域具备独到的见解，先后参与了民生、泰康、邮储等多个企业数据库智能运维体系建设，有着丰富的数据库运维实施经验。近年来，在信创大背景下，主要从事一体化智能化数据库云管平台的搭建与实施，在国产数据库落地企业核心系统上有较深入的研究与经验，为众多企业的数据库转型提供了完善的系统建设方案。
智能运维是企业数字化转型过程中不可或缺的重要部分。但对于长期使用传统运维方法的企业而言，转型智能运维的道路上往往存在很多困惑。企业希望能有简明易懂的手把手教学，帮助团队和管理者建立基础的认知。
在 2022 年第二期 DBTalk 技术公开课中，ShinData 新数科技售前技术总监王宇庭带来了主题为《如何从 0 到 1 实现智能化运维》的分享，介绍了数据库智能运维的痛点及破解之法。
数据库运维挑战
数据库运维人员会发现，真正导致数据库变化的一般是业务的变更。前些年运维人员做业务变更支持还不算频繁，但近年来随着互联网业务兴起，以前一个月甚至一个季度才可能做一次应用变更，现在基本上每周甚至每天都有可能有变更上线。DBA 要给开发和测试人员提供很多技术支持，因为他们对数据库的了解不够深入，所以这给数据库的运维带来很大负担。
另外，从内部来讲，数据库行业整体的运维方式相对而言较被动。这里有两点，一是需求驱动，一是事件驱动。平时开发、应用、业务部门找到我们说需要申请一个数据库，业务有点慢了给我分析分析，给我抓一些 TOP SQL 去优化优化，这些事情都要 DBA 做，他们有请求的时候我们才跟进处理这些问题。
事件驱动更好理解，基本上我们会等数据库出问题的时候才会跟进解决问题和故障。好一点的情况是我们有一些监控或者告警工具，在出现故障的时候及时通知我们，但因此导致的业务损失已经无法挽回了，所以整体上我们都比较被动。
随着外部环境变化，对 DBA 的技术要求越来越高，尤其是现在国产化软硬件这么多，少量 DBA 要应对所有类型的数据库就有较大挑战。
基于这些背景，大部分企业都会考虑通过建设数据库统一管理平台解决多种类型数据库，各种复杂架构的统一纳管的需要，基于平台满足数据库运维的自动化、自主化甚至智能化的目标。
我们梳理了以往客户建设平台的时候所考量的一些任务点：
行业应对方案
金融行业面对以往的困境所采用的常见方案有三个特点。
第一个是自主研发，自主研发对企业自身的能力要求非常高，这种整体效果会是最好的，但它的问题也比较明显，一是投入比较大，另外建设周期比较长。我们都知道数据库运维部门并不是真正给企业带来实际业务收益的，不是每一家企业都可以针对这块集中投入，所以自主研发方案一般集中在某些较大型的企业，或者经济实力较雄厚的企业。
第二个是借助优秀产品框架去建设统一管理平台，它的特点在于能够发挥企业现有的 IT 能力。企业内部 IT 建设并不是从零开始，之前一般会陆续建设很多系统，大部分客户不是非必须的情况下并不会把现有系统直接替换掉，还是希望充分发挥它的能力。运维人员做运维流程的时候，也会看到它中间有一些关联性，各个系统之间很难关联起来。这个建设思路就是基于成熟的框架，在企业内部快速搭建数据库自动化、智能化运维体系，把现有的 IT 资产很好地串联起来。比如我们以前有告警系统，也有一些简单的监控，我们以前是产生一些告警后看一下问题如何处理，然后又有一些运维平台触发运维动作，各个系统是独立的，没有办法很好地串联起来，内部一些流程化的管控都比较困难，基本都靠人。现在有了成熟框架嵌入进去，就可以充分发挥内部效率。另外，这个系统在建设的时候需要我们投入较大的精力去思考，建设平台的时候要跟哪些系统做日常对接，才能让整个体系通过对接和集成快速搭建起来。如果我们前期没有考量完善，它会影响后期建设的效果。
第三是采购成熟软件产品，这也是很多企业现在所采用的方案。有的企业之前没建设过平台，针对运维问题或坑不是特别熟悉，如果自己研发会花很大精力。如果市面上有成熟产品这时就可以快速落地。另外，基于产品研发企业在其他客户的建设经验，我们可以很好地吸收相应的历史经验。这对于想快速构建相应运维体系的企业来说是非常好的选择。它的特点是前期可以快速实现构建，后期也需要我们逐步完善，因为它是标准化的东西，并不是说每一个细节都非常符合客户的需要，所以在后期也需要逐步做修整。
大部分企业会采用后两种方案。
成功要素
客户落地系统的时候一般会考量四点。
第一是自主可控。中国企业落地实时系统的时候有很多个性化需求，国外的产品没有遇到过那么大的并发量、数据量。落地标准化产品的时候，一定要根据客户实际情况做定制化，这就需要我们所选择的架构或产品要自主可控，能够为我们提供定制化服务。
第二是无缝集成。平台需要跟企业内部 IT 资源很好地协同对接，就需要具有无缝集成的能力，能够满足各种各样的系统对接需求。
第三是长期演化。需要明确，建设这样的平台并不是一蹴而就的，不是今天买了这个产品装上之后，整个运维体系就好了。它并不是这样，它要结合自主可控、定制化研发，去满足各种各样的场景需求，和 IT 对接，后期逐步完善一些更高级的功能。比如说前期建设了统一纳管平台，实现了基础的监控、巡检能力。后期我们考量逐步增加一些运维操作，甚至结合监控、告警及运维操作实现自愈能力，包括把 DBA 的能力通过平台输出去，而不是说只有 DBA 去使用，让开发、测试部门也能够借助这个平台做一些事情，从而提升整体的运维效率，这些事情都是一步一步地去做的。为什么要有定制化调整？因为每个细节都影响着实际落地效果。所以建设的时候要深度考量前期最主要的痛点是什么，后期准备往哪些方面发展。
第四是可扩展性。可扩展能力对平台也非常重要，架构、功能上都需要有可扩展能力。比如现在有一百多套库在用，一两年内增长到几千套的规模都有可能，需要平台具备相应的可扩展能力。另外数据库运维非常复杂多变，针对不同的运维场景，一些特殊问题产生的时候系统能不能提供很好的技术手段，帮助我们快速定位风险和问题、解决故障，这也考验平台的功能扩展能力。
我们以往的客户在建设平台过程中关注几个非常重要的点。
第一是高可用和安全。既然平台要以非常重要的位置在企业内部落地，我们势必需要系统具备持续稳定运行的能力，所以在系统架构设计上需要具备高可用性。应用阶段能不能做高可用部署？后边基于采集或者信息保存的数据库能否满足高可用架构部署需要？同时前后都是高可用架构配合，能否稳定运行？包括我们的采集节点去做海量数据库纳管的时候，负载能力除了集中在数据库这块，数据采集这块也有比较高的要求，它能不能充分发挥计算资源的能力？
安全性上来讲，因为我们所纳管的是数据库资源，就是为了提前分析定位数据库可能存在的瓶颈和问题。如果说我们建设平台的时候还要再跟数据库争抢资源，反而得不偿失。所以建设过程中我们基于过去的客户经验，考量针对数据库统一管理的时候使用无代理方式，一方面可以远程访问到数据库，主动式地管理这些访问请求，另外对数据库的资源占用是非常可控的。同时也应该具备灰度发布能力，保证每一个举措经过验证之后上线。此外还要有模板化配置能力。
第二个要点是整个平台需要面向所有用户。我们所面临的问题并不仅是 DBA 日常运维的那些痛点，同时 DBA 有大量时间花在给其他部门提供技术支持上。如果平台可以把 DBA 的能力开放出去，让普通用户也可以完成一些简单的分析定位工作，可以大大降低 DBA 的负担，让 DBA 更多的能力输出到对数据库的优化上，在没有发生故障之前把相应的风险解决掉。
以上是开放性上的一些常见需求。如果平台能够跟上述系统对接好，内部的运维体系流传会更加顺畅，各个 IT 系统在企业内部能更加充分地发挥作用。
数据库领域的可扩展能力一般考量几个点。
第一个是自定义监控和告警。实现多种类型数据库统一管理，最基本的就是监控和告警。遇到一些新的监控告警需求的时候，平台需要能够快速自定义一些功能，满足实际运维场景需求。
第二是自定义分析工具，比如通过自定义方法快速实现可视化分析工具，让我能够借助这些数据做进一步的问题定位。
第三是自定义运维操作。除了监控、告警、巡检、问题分析，我们定位到这些最终原因的时候也希望能够通过平台快速解决问题。我们之所以考量通过平台做运维操作，其实是考虑到数据库运维安全上的重要性，通过这个平台把数据库运维操作实现标准化、自动化，这样也有利于整个数据库安全稳定运行，同时这个平台上的自定义运维操作可以补充日常数据库运维的需要。
案例分享
最后分享一个客户的建设案例。
他们因为一些内部流程和系统使用上的不便，使用的软件产品没办法满足纳管需求，就考量做国产化架构选型，建设统一管理平台，最后的效果挺不错。前期 DBA 会花大量时间在应用、开发、测试支持上，从问题抓取到分析、处理、解决，再到上线，DBA 都要全程参与，占用大量时间。这个系统上线后非常明显的变化是，整个平台并不仅仅面向 DBA 团队使用，好多功能可以让应用人员自助完成。
比如说抓一些 TOP SQL，其他部门人员可以自己到平台上做，做一些简单分析可以自助完成，不用找 DBA。应用人员可以完成从问题的发现到一定程度的优化处理过程，再到最终上线也可以自助完成，DBA 只要在一些关键节点上介入，做一些流程化管控，就可以很好地保证数据库运维及使用上的安全性，效果非常显著。DBA 每周在数据库风险定位上花一些时间，把相应工作安排下去，对现有数据库做优化和提前风险处理，相应的关键节点让 DBA 介入，做一些管控。所以系统落地之后成果显著，这其实也是我们建设数据库自动化运维体系时，每个客户最终都想要达到的效果。
