从生命周期的角度来规划数据库运维体系

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

iMZvUzM.gif!mobile

最近在和团队规划OKR目标的时候，我们讨论了很多问题，我先抛砖引玉，列举了一些现有的问题，打算按照推导的方式：

1）列举当前问题

2）问题归类和总结

3）梳理现有经验和现有方案

4）结合时间/性价比得到一定时期的预期目标。

整体来看，工作量还是蛮大的，再加上大家对于问题的理解角度不同，所以在容易在很多细节上讨论太多，难以聚焦。

所以我想了下，准备按照生命周期的维度来进行考虑，于是整理了一版设计图，整体是分为四个层面，也就是按照业务从申请资源和权限，到服务上线，服务优化，最后是相关的服务数据迁移和流转。

VJveQjR.png!mobile

整体设计下来，我们会发现很多考虑中不足的地方和遗漏的角度。在多次提炼之后，我把这个设计图调整为如下的模式：

AzyYrqf.png!mobile

我来逐个解释下：

1） 规范/选型/规划 ：这个阶段更强调整体，很多问题如果直接从基础运维入手，其实就已经晚了，有些服务质量差，交付时间长，本质上还是前期的基础建设不够扎实，所以这是一个互惠互利的关系，比如开发规范的设计和落地执行，架构设计（如分布式架构设计），技术选型（如MySQL 8.0适配的中间件技术调研，ClickHouse技术调研，TiDB技术选型，MyRocks存储引擎测试分析等），SQL审核（已有审核服务的升级和改进等），高可用（重中之重，涉及健康检查脚本，Consul服务快速切换，数据库高可用方案预研测试等），基础服务（如监控，报警和任务调度等相关服务），基础设置（如抛弃CentOS_6等低版本，磁盘配置统一为SATA-SSD等类似的方式）

2） 基础运维 ：涉及资源交付（包括上下线，资源扩容等），权限交付（申请账号，账号权限变更，账号回收等），安装部署（如数据库软件安装部署，初始化），基础配置（基础配置，如ntp,crontab等），备份恢复（按照数据备份，数据恢复的基础维度实现基本备份集，基于时间点的数据恢复）

3） 运维优化 ：对象变更（需要演进为自动化上线模式），对于大表变更需要集成在线变更工具来实现，此外，重点是做一些相关的优化，如参数优化（如数据库优化参数，基础配置适配），对象优化（数据表优化，索引优化），SQL优化（执行计划优化，索引建议等），配置优化（系统配置，服务配置优化等）

这三个维度做好之后，其实会发现一些还是会恨吃力，那就涉及到数据迁移和数据流转，数据本身是在不同类型的环境间流转的，如何保证数据能够稳定，准确的流转也是重要的目标。

4） 数据迁移和数据流转 ，数据迁移主要实现一键式数迁移，主要包括两个个方面：

（1）一键式数据库迁移，从1个服务器迁移到另外一个服务，一键实现

（2）数据库版本升级，如从MySQL 5.5升级到5.7，从5.7升级到8.0等，可以一键实现

此外，数据流转到数据仓库，大数据，如何高效稳定的支持，如何实现实时的数据流转机制和多环境间的快速迁移/同步也是重点目标。

对于技术底座而言，首要的目标就是文档，文档可以从上面的四个维度拆分为多种文档,如规范设计文档，预研文档，方案设计文档，操作文档，案例文档等。

接下来的服务的交付都应该统一为API的模式，演进可以从脚本到工具，从工具到API的路径来演进。

底座的两大分支是云平台建设和服务建设，云平台建设覆盖面更大，提供的是产品化思维的服务交付，对于技术架构和开发效率的要求较高，这部分不能好高骛远，还是得结合自身情况来提供强大的动力，其中，元数据建设是核心目标，在这个层面元数据要集成，实现流程化管理。

而右侧的服务建设更贴近后端服务，从生命周期的角度来进行实例，数据库，表，字段，索引层面的周期性管理，而提供的辅助服务则是更加贴近运维实际的，比如慢日志优化，巡检服务和故障自愈，和业务侧是一种半透明的开放形式。