前言：

 

看到DBA+社群之前分享的那篇原厂工程师赴美的文章，让我也想将之前自己系列分享中的开篇章节，以文章的形式码出来，遂成此文。不足之处还请诸君批评指正。

 

“论DBA的自我修养”是我个人做的一个PPT系列分享。本文取自第一节，目的是帮DBA们拓宽眼界，找到未来的发展方向。属于鸡血文（笑）。

 

1

What is DBA？

 

 

很多人对我们DBA是有认知误区的。特别是开发人员（注意，由于笔者多年与开发对喷的经历，本文将有大量针对开发同学的人身攻击，不适者请前方右转绕行）。

 

根据多年的工作经验，我把这些误解总结为以下几类：

 

1、开发人员：

 

老冤家、老对头、项目评审重点要攻克的对象。他们的误解主要表现如下： 

 

• 导表导数据的，没什么技术含量的，交流通常以“来帮我调一下这个SQL”开始；

• 比较极端的说法：水平不行的全干DBA去了，或者DBA怎么可能比开发牛逼；

• 出问题的时候：这个肯定不是我逻辑上的问题，是数据库的问题！

 

2、业务部门：

 

服务对象，老板眼中的红人，创收部门。他们的误解主要表现如下： 

 

• 数据丢失找他，数据分析找他，出个报表找他，有脏数据找他；

• 比较极端的说法：勤勤恳恳、任劳任怨的...操作工...；

• 出现问题的时候：开发说弄不了，数据问题让我找DBA。

 

3、不明就里的老板：

 

ATM、汇报对象、决策者。他们的误解主要表现如下： 

 

• 平常完全注意不到的人，没有为公司提供任何产出的人，可有可无的人；

• 比较极端的说法：我们公司不需要DBA；

• 出问题的时候：开发同学做的好，业务部门处理的好，DBA...我们公司还有这个部门？

 

4、妄自菲薄的内部人士：

 

不小心入错行的人，之前觉得DBA钱多活轻才跨进来的人。他们的误解主要表现如下：

 

• 工资比开发低、业务出问题时压力大、琐碎的事情怎么都做不完、导表导库删数据，为什么我的工作这么low...

• 比较极端的说法：我要转行做开发、我要去做XXX、我要跳槽...

 

上述这些，不知有没有触碰到大家的泪点。

 

既然进到这个行业里，我觉得我们首先要对自己的职业有一个清醒的认识。那么什么是DBA？

 

Database Administrator or Database Architect？

 

每当我现场问这个问题时，很多DBA都会下意识的说数据库管理员。诚然，他们说的并没有错。可我要引导大家转变只是管理员的这种观念。在和很多DBA朋友的私下交流中，我发现有不少朋友一直有“我不生产数据，我只是数据的搬运工”这样的心态。

 

我希望大家能慢慢从这种心态中脱离，让Administrator变为Architect，这才是我眼中的DBA，或者说是我心目中对DBA最完美的诠释（我是处女座，抱歉）。

 

2

我眼中的DBA

 

 

 

我眼中的DBA应该是这样：

游戏规则制定者，数据风险掌控者，数据业务审核者，数据架构设计者。

 

1

游戏规则制定者：

为什么说DBA是游戏规则的制定者，这是由于各种涉及数据的规范及流程需要我们来制定。其中，规范帮助开发人员控制数据流，流程则协助业务人员更快获取所需数据。

2

数据风险掌控者：

说到数据风险，有些DBA可能并没有意识到。但从近几年行业中暴露出的诸多数据泄露的事件来看，除了风控部门、安全部门外，最应该有所警惕的理应是我们DBA。线上操作要慎之又慎，特别是所处互联网金融行业中的DBA们，一定要时刻牢记你所维护的是“大型在线金融交易系统”，理应对所有的线上操作心怀敬畏。同时，恪守职业操守，让自己成为可以掌控数据风险的人。

3

数据业务审核者：

这可能比较好理解，因为我们的大量日常工作便是对各种数据业务的审核。这里建议DBA们思考如何将这些日常业务审核自动化，当然这也是我近期在关注的问题。 

4

数据架构设计者：

这一点可能有些DBA也会有抵触，觉得这不太像是DBA需要关心的事情，而更多的应该是架构师要做的。这种观点比较普遍，主要因为不同公司里DBA的话语权不太一样。这也是我在之前的公司里一直致力于推动DBA角色前置的一个原因。

 

我为什么特别想强调这一点？

 

是由于我的从业经历里见过太多优秀的产品，由于前期设计时，架构师对数据侧设计有失误，导致应用对数据的存取成为严重的性能瓶颈，而不得不返工、重构。那么，作为互联网行业中的DBA，我一直坚持的观点是：绝对不要把宝压到一款数据产品上。也就是说，针对不同的业务，结合不同的技术手段解决才是出路。而不是单纯的对开发说，我这是RDBMS，你放心存，Oracle很强大。等等、等等。

 

不同的业务场景，结合不同的技术，这样的业务才能良性发展。而不是所有的数据都往RDBMS里扔，所有的业务都必须向RDBMS靠拢。不是的。

 

比如不少开发人员说，“我现在要把应用里的打点日志放MySQL里”。我会立马回绝掉。为什么不用ELK？不能分析？那为什么不交给Hadoop？再如，开发人员的需求让我在设计表的时候非常头疼，那么有没有考虑不使用RDBMS？MongoDB和Cassandra不能满足么？类似这样的例子有很多很多。总之，某项技术的出现一定是为了解决某种业务上的痛点。活用不同的技术，为你的数据设计相应的技术架构，这才是DBA应当做的。

 

3

DBA的核心价值观（我的）

 

 

坚守底线，简化日常工作，不断学习。那么我们的底线是什么：数据完整性、一致性及安全性。

 

这三点是每一个DBA绝对不能被触及的部分。所有与这三点相违背的应用需求绝对都可以被Cancel。

 

为什么这里还要强调简化日常工作？

 

我的研究生导师讲过这样一段话，他问我们如何评价一个公司的产品是否优秀。记得当时在座的同学大部分都是说看业绩。导师给我们的答案却是去看这个公司的运维、DBA每天在做什么。他解释道，一个产品优秀的公司，它的后端一定是相对稳定的。数据部门作为后端的一部分，如果每天运维和DBA同学都在忙着修复错误（比如并发压力上来时的“雪崩”，笑），忙着修复数据，那么这个公司的产品一定存在某些问题。

 

那么产品优秀的公司，DBA的理想状态应该是什么样的呢？

 

“早上一杯茶，一坐一上午。下午看看报，又是一下午。”当然这种状态过于理想化，不过相对琐事较少才能证明你们的产品设计是没有问题的。

 

为了能达到简化日常工作的目的，DBA们应当着手将自己的日常工作自动化。

 

日常工作自动化后，有了大把的时间。那么这些时间绝对不能浪费掉。

 

很多人跟我说过，为什么觉得有些人工作3年已经可以独当一面，有些人即使5年还是5年前的样子。那么我要说，利用好我们的时间，规划好我们的学习计划。一定要把别人和咖啡的时间用在……喝啤酒上……（囧）。

 

4

Why need A DBA? And when?

 

 

这个问题主要是针对各位“总”的。

 

三年前，我的一位朋友，一家创业公司的CEO，他当时的想法就觉得DBA这个职位仅适合大公司。像他这样的创业公司其实是可有可无的，没有DBA其公司的业务也在飞速发展（原话）。然而就在今年年前，我得知他的公司遇到瓶颈，主要还是由于后端数据库太不稳定，导致其产品经常出问题，用户体验不佳。然后我对其的建议是：尽快找一个资深一点的DBA，协助开发人员进行重构。

 

那么为什么需要DBA呢？主要由于以下几点：

 

• 数据安全的需要

• 业务发展的需要

• 数据库架构、重构的需要

• 高并发、高可用解决方案的需要

• 等等等等

 

一个好的DBA会帮助一个项目完成数据侧的全部工作，包括监控的搭建及后期的运行维护、审计等。他对一个成熟的项目来说是不可或缺的。

 

很多人会说：好，就算你上面说的都对，那么我什么时候需要一个DBA呢？

 

我总结了以下三点（欢迎补充）：

 

• 公司成型，业务处于高速增长期；

• 公司业务稳定，但是出现了增长瓶颈，且瓶颈出现在DB层；

• 不建议初创团队使用专职DBA，额外增加人力成本。

 

5

How to be A DBA?

 

 

我也是写到这儿才发现，PPT写成文章怪怪的，其实我更擅长把这些东西讲出来。

 

文章的最后了，不知道我上面的鸡血文有没有激发你继续在DBA的道路上越走越远。

     

我最后留给大家一个开放式的问题：如何成为一个合格的DBA呢？

 

再把问题放长远些：DBA以后的出路又在哪儿呢？

 

如何成为一个合格的DBA，我觉得应该包括以下几点：

 

• 责任心，求知欲，不甘于每天做重复的工作；

• 开源、分享、包容、交流；

• 基础！基础！基础！

 

作为DBA，责任心应该是最重要的部分。很多DBA说我是开发DBA，运维这事儿不归我管。有这样想法的同学一定要转变下观念。我们说，失败使人成长。同样，排障也会让DBA成长。因此，开发DBA不要再继续坚持运维工作事不关己的想法，多多参与运维排障，这样会让自己成长的更快。

 

DBA同学还要保持高昂的求知欲。大牛博客、大牛微信、各种论坛（我是盖国强老师脑残粉）等等。对别人提出的问题不要不屑于回答，你帮别人解答问题也在为自己积累经验。

 

要有一颗开源和包容的心态。

 

不要急着否认别人的观点。尊重每个人，特别是能力比你低的人的话语权。

 

我接触到的真正的牛人，基本都没有什么架子，会跟你聊天，会回你邮件，会指导你一些细节。这种心态会更有利于你的成长。所以这里会建议大家调整。

 

最后，重要的事情说三遍：基础。

 

做了很多年之后，你一定会发现大学里学的知识终于在实践中成为体系了。然后就会想要再回头恶补这些知识。基础真的相当重要。一个连HTTP协议常用概念都弄不清楚的人，我怎么会相信你在做REST API的开发？

 

因此，在面对一些理论问题的争论时，最好的解决方法就是大家都回头补基础去。

 

6

写在最后

 

 

其实在我分享的PPT后面还有蛮多内容的。但考虑到篇幅问题，后面的部分干货就留到有机会再写给大家。

 

在此，祝DBA+社群越办越好。也希望我们的DBA们在2016年都前程似锦！

 

作者简介  张小虎

• 现任甜橙金融持久化组MySQL TL。多年开源数据产品架构及优化经验。

• 擅长吹牛及与开发撕逼。做过开发、搬过机器、拉过网线，最后又回到老本行。

• 目前兴趣点在DevOps和MySQL源码开发。

 

评论有礼

 

 

新一波福利来啦！认真读完本文，并在文末写下评论，分享到朋友圈，邀请好友对评论点赞。在本文发布后24小时之内获得点赞数最多的前5人，每人可获赠以下书籍一本！

 

《Linux就是这个范儿》

本书内容源自淘宝技术大学的培训实战。通过对Linux的版本选择与安装、基本使用与系统结构、设计哲学与思想、脚本编程与软件开发、内核编译、网络与认证，以及多媒体等多方面的精彩讲解，将Linux操作系统的灵魂与运用教授给读者。

 

 

特别鸣谢图灵出版社（www.ituring.com.cn）为本次活动提供图书赞助。