数据库运维体系

在运维体系分层中,数据库运维只是很小的一部分,很多初创公司都由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.集群架构目标

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

发表评论

电子邮件地址不会被公开。