在运维体系分层中，数据库运维只是很小的一部分，很多初创公司都由OP或RD兼任DBA.（下图为博主画的运维体系分层）

业务快速发展和迭代的过程中，实例交付、数据库优化以及备份管理等任务都对DBA提出了更高的要求，初创期单纯凭借记忆力去管理几十套DB已经不再适用。那么如何去批量管理这些实例的备份、元数据、定时脚本和快速实例交付就成了急需解决的的问题。因此，构建数据库自动化运维体系势在必行。

在搞清楚DB自动化运维体系之前，我们需要根据DB运维的核心指标：稳定+安全的角度深入思考，我们的deadline在哪里。

安全:不丢数据
稳定:全年可用性指标99.99%

可能会有老板提出质疑，不丢数据也算是核心指标吗？数据库的可用性不都是100%？这种质疑我们很难解释，根据墨菲定律”凡是可能出错的事情必定会出错”， 作为DBA，唯有从体系化、方法论，全局视野出发，通过更多的思考+实践积累更多的经验。不丢数据并没有想象中的那么简单，眼前的案例比比皆是，顺丰DBA从删库到跑路，腾讯云丢失数据被索赔1100万。4个9的可用性指标也没有那么容易，作为国内市占率第一的阿里云，其ecs可用性并没有达到4个9，同时其RDS服务的可用性也仅仅是99.95%。

引入DB运维体系如下:如图所示

1.OS层，针对各类型数据库制定各类标准，包括硬件选型、系统选型、网络安全、系统参数。

2.在OS层的基础上，集群冗余、高可用架构、数据备份&恢复。

3.在高可用的基础上设计服务管理。

4.服务管理的基础上运维工具化，开始提升效率。

5.需求入口的工单系统，我们往往会收到来自QQ、微信、邮件、电话、jira等各种工单，没有统一需求入口，那么误操作概率必然增大。

6.监控系统。

7.CMDB，这里的CMDB主要关联VIP与集群实例、主机、业务之间的关系。

现在我们需要关注一些重点切面:

1.DB服务管理如图所示:

系统&软件层面:版本最好统一,同集群系统初始化要统一。当某一个风和日丽的午后，你收的redis需要扩容的报警，当你按照操作流程完成后发现无论如何都无法迁移槽位，花了很长时间发现线上的老集群版本久远，你心里一定是万马奔腾。

应用标准化：应用标准化指的是网络、端口、目录等统一规划。工作中我们经常涉及批量操作，而这时往往发现批量脚本的if..else多的令人发指。这些都是由于种种历史原因造成的，但我们能做的就是尽量别给后来人挖坑。

操作工单&操作审核：人非圣贤孰能无过，我们所有的操作都需要工单+审核机制。

生命周期管理: 在业务申请的初期，DBA就应该确认生命周期管理机制，重点关注到期提醒。我们遇到过服务器空跑的现象，也有垃圾数据永久保存的现象，如果运维人员不去推动和思考，那么这种管杀不管埋的现象只能是越来越多。

2.CMDB部分。

CMDB是一切服务的基石，除了人为操作导致数据丢失及DB故障之外，另一个主要故障来源就是人员交接时的乐不思蜀和口口相传，堆积成一系列历史问题。

3.备份体系

备份体系的重要性不言而喻，是”不丢数据”的最后保障。大厂往往做的更好，而诸多创业进击期的公司由于服务稳定与资源不足之间的矛盾，导致备份文件”东躲西藏”，造成有备份但无法确认其可用性的状态。我们最好的方式是梳理备份定期还原测试。

4.集群架构目标

各类型集群架构方案已经非常成熟，高可用性跟成本正相关。我们唯一要注意的是：适时数据不要过度依赖专线。