数据库运维系统，听起来高大上，其实也就是一堆问题等着我们去解决。先别急着问“为啥要做”，咱们先看看现在的问题。整理了一堆，发现主要就四个：缺规划、服务不稳定、没规矩、想法不一致。
宏观上，运维系统得从“稳定、安全、高效”的运维视角，转向“质量、效率、成本”的运营视角。说白了，就是得更注重效益了。
微观上，我们做运维系统，其实有点私心。一是让DBA们按研发标准来做事，形成闭环；二是能搞出可复用的模块，有扩展性；三是提升个人和团队能力。
岗位属性上，有些误区得纠正。比如，数据库服务化开发不是核心目标，有更重要的事要做。而且，这事是不是该让专业研发来做，而不是DBA？很多公司其实已经这么分工了。
问题和需求方面，得细化一下。比如，服务模块边界模糊，工作没重心，服务化概念泛化，专业技能追求过于理想化。运维服务可用性不够，新旧系统并存，功能割裂，发布流程影响任务，任务管理不可控，系统并发、吞吐率有瓶颈。开发规范和流程约束不够，重复造轮子，命名规范不统一，接口规范和模式不统一，研发流程不够标准化。思想意识不对齐，对基础建设不够重视，运维模式依赖控制台，专业研发成长动力不足。
发展步调，行业里对运维系统的发展阶段定义不一，但咱们得有个明确的方向，比如：脚本化、平台化、自动化、智能化。
运维系统划分，咱们把服务分成四块：RDS自助平台、DBA管理平台、基础数据平台、数据分析平台。好处是服务可以解耦，比如基础数据平台变动小，不影响RDS自助平台。数据分析平台是面向未来的规划，对数据分析的潜在价值和模型构建要提前规划。
设计上，DBA管理平台是后端服务，得认真规划。设计时考虑了服务层次，按平台层、架构层、实例层和基础资源层来设计。平台层提供统一数据存储服务，架构层包括高可用、水平扩展和架构变更，实例层主要是实例管理和监控报警，基础资源层包括资源和容量管理。
苏公网安备32021302001419号