关于数据库运维系统的一些思考

news2024/11/15 18:21:14

这是学习笔记的第 2461篇文章

前段时间整理了一下数据库运维系统的一些内容，比自己预期的要难一些。我来简单回顾下一些参考点。

一、立足当下，混沌之中梳理问题

通常我们可以会问为什么，即为什么要做数据库运维系统，但是我们先放一放，不用完全从0到1的思考，而是立足当下，当前的数据库运维系统到底有什么问题？

零零散散收集上来几十条，我重新组织整理，按照大的维度拆分后，又重新组织和补充了下,这是一个抽象提炼到补充完善的过程。

大体来说，存在4个主要问题，包括缺少整体规划和步调、运维服务可用性不够，缺少开发规范和流程约束、思想意识不对齐。

小结：但凡经过了一定的阶段之后，总是有好有坏，有各式各样的问题，我们接下来需要明确目标和范围。

二、从宏观，微观和岗位属性来理解为什么要做数据库运维系统

宏观

宏观层面，数据库的相关服务管理模式也在从运维视角逐步转化为运营视角，公有云毫无疑问早就买迈过了这一步。运维视角大体是从稳定、安全、高效来着手的，而运营视角则更多是从质量、效率和成本这几个维度来考量的。维度不同，目的不同，所做的事情就大大不同。

微观

从微观层面，其实要做数据库运维系统，我们都是带着一些私心的。第一是能够让DBA以研发的标准来要求和约束自己，能够形成研发流程和规范闭环，实现可持续的管理模式。第二可以形成可复用的服务模块，具备可扩展性；第三是提升个人和团队能力和成就，向最基本的研发标准能力对齐

所以微观看起来，更多是在研发质量规范的基础上，提高个人成就。

岗位属性认知偏差

岗位属性偏差是一直以来在逃避的概念和认知。这里有几点需要纠正下。

数据库服务化开发不是数据库方向的最核心目标，不是最核心的目标，也即意味着有更重要的事情需要做，对于这一点有几点可以补充理解
数据库服务化重要，这个事情是由专业研发来做是不是比DBA来做更专业，实际上有些公司从组织结构上已经是这样的分工了
目前很多公司没有数据库运维开发的专岗，在中小型的公司里面，可能还是稳定性保障需求，至于实现方式。。。
不是我想干什么，而是基于当前的痛点和需求来明确接下来重点需要解决的问题有哪些，通常我们对于服务化开发的理解是更偏向于自我实现的视角
研发侧的需求导向，研发侧的需求目前主要以效率为主，不大可能会经常提出挑战性的问题和任务；而要使得需求升级，让研发有更高的期待，这个还有很长的路要走

三、回顾问题和需求，数据库运维系统需要解决哪些问题

这个时候可以把刚刚整理的问题放出来了，做一下细化和补充。

缺少整体规划和步调

对于服务模块的边界模糊，后续的扩展和迁移复杂度高
做的工作没有重心和整体步调，碎片化开发导致业务价值不高
服务化概念泛化，导致这项工作持续没有阶段性成长
对于专业技能的追求过于理想化，脱离了初衷
基于需求被动支持，需求边界不够清晰

运维服务可用性不够

新旧运维系统并存，功能割裂集成复杂度较高
发布流程影响后端进行中的任务和前端业务
运维任务管理不可控
目前是串行模式管理，系统并发、吞吐率存在瓶颈

缺少开发规范和流程约束

重复造轮子，开发效率可控，复用度不够
命名规范不统一，后端服务开发风格差异化导致集成复杂度高
接口规范和接口模式不统一，后续的改造和迁移成本高
研发流程还不够标准化，需求管理和bug管理没有形成闭环

思想意识不对齐

对于基础建设不够重视，当前大家关注的更多是解决自己的问题而不是全局的问题
运维模式依赖控制台，后续如果转换为运维原子操作，思想意识还没有转换过来
对于专业研发的成长动力不足，被专业研发替代和降维打击的风险很高

四、明确发展步调和阶段

我盘点了下行业里面对于运维系统的发展阶段，大家的认知和定义偏差还是挺大的，大体有这样的一些阶段定义：

脚本化、工具化、产品化、自助化、自动化
流程化、规范化、可视化、自助化、智能化
脚本化、平台化、自动化、智能化
刀耕火种的石器时代、标准化和系统化、融合智能化

我们按照规模和后续的演进方向做了下聚焦，步调定为了：脚本化、平台化、自动化、智能化

五、数据库运维系统的划分

整体上把数据库运维服务分成了4个部分，分别是RDS自助平台，DBA挂历平台，基础数据平台和数据分析平台，底层的基座是基础工具和服务。

这样的一个好处是可以把服务做解耦和拆分，比如基础数据平台的变动相对较小，则管理平台内部功能的迭代不会影响对外的RDS自助平台。

数据分析平台是面向未来的一种规划，对于数据分析的潜在价值和模型构建，需要提前规划出一个摊子，最后这部分的工作可以反哺DBA管理平台和RDS自助平台。

如果把这个图展开和细化，我做了初步的一个设计图，其中蓝色部分是偏运维层面，而绿色部分则是偏运营层面。

其中DBA管理平台是偏后端的服务，对于这个服务本身也需要认真规划，我的设计中是考虑了服务层次，会按照平台层，架构层，实例层和基础资源层4个层面来设计，平台侧主要是提供一个统一的数据存储平台对外服务，架构层则主要包括高可用架构，水平扩展架构和架构变更等，实例层主要包括实例管理和监控报警等基础运维服务，基础资源层主要包括资源管理，容量管理等。