假期里突然被亲戚拉入一个小群里，一共4个人。除了亲戚的两位我都不认识，然而其中一位语气不像是初次见面，咨询我国产数据库的事，一时有点懵。于是我小窗问亲戚，她反问我：“6年前你在我这教过一个中学生怎么用数据库，自己都忘了？”
DBA这么可怕？！
6年前的暑期，我去亲戚家玩，本着来都来了的原则，被拉去给他们公司那些数据库做做续命式运维。之所以这么称呼，是因为那两套数据库已经真的只吊着一口气，生死随缘了。
亲戚家的小公司部署了两套系统，一套财务系统，一套CRM系统。因为两口子都是年纪偏大不懂计算机，在他们看来系统买了上线了应该就可以正常用。后续的维保也就都没买。结果几年下来，系统越来越慢，各种破事越来越多。靠着公司管设备的员工，勉强维持着。我这一来，自然而然就要被他们拉去给这两套系统续续命。
两套系统都跑在SQLServer上，平时出了问题就重启大法解决，其他全都没有。于是我不得不从头开始梳理：清理垃圾信息（主要是写入数据库的系统日志），配置已经失效的定期备份作业，给一些凭心情写的业务逻辑SQL尽可能做优化。这一过程无比痛苦，一方面我完全不懂业务，另一方面这些老旧的系统不知道到底经历过什么，比如SQL优化我能做的也就是加索引。
最后说服了亲戚，又配了一台备机，把两套SQL Server的镜像给做了，这事我以为就告一段落了。谁知道，亲戚家一个合作企业用的系统和他们家几乎一样。亲戚把这事告诉这家合作企业的老板之后，他干脆直接邀请我去他公司一趟，帮忙也给续续命。来都来了，硬着头皮去吧。
那位老板年纪比我亲戚还大，而且对计算机了解更少，很多上了岁数的民营小企业老板可能都差不多。我在他们那用操作系统认证登进去之后，开始按照亲戚家的流程走了一遍。期间不免要跑一些查询测试一下性能。
这一跑不要紧，一下子让那位老板神经紧绷了起来：怎么所有业务数据甚至业务报表的结果，我都能用一条查询跑出来。我于是给他解释，DBA拥有最高权限，既能看到所有数据，又能看到所有历史查询语句，两者一结合，他的业务报表就全看到了。
吃过午饭，他家小女儿被她拉到的公司。他让我下午辅导一下这个小女儿，学会怎么管理SQLServer，以后这两套系统就让她管着。这可让我犯了难，给我半年培养一个新手DBA确实是有可能，但是就半天时间，我可真没这个本事。
于是我给她讲了一些数据库基本原理，教会了她怎么在图形界面备份数据库。并且告诫她，任何大的操作都必须提前备份数据库。推荐了几本SQLServer的书给她，也就只能做这么多了。
这样一个偶然的辅导，让我都觉得，故事也就到此为止了。
野路子的00后DBA
是的，那个咨询我国产数据库替代的群友就是她。02年的她大学即将毕业，另一个群友是她哥哥。公司系统年限久了，不能再满足现在业务需求，要重新采购。供应商给他们提出国产数据库替代的事，于是想要了解一下背后的风险。
而她自己说，这6年的时间里，她一直在给家里当DBA。除了那两套SQL Server，后来又采购了MySQL作为数据库的其他系统。再没有任何前辈带的情况下，她用自己的野路子当了6年的DBA。
她的野路子都有什么？让我想起自己说过的那句话：一本DBA规范，除了封皮她几乎全都犯过：
1.万事不决，重启大法。甭管是SQLServer还是MySQL，在她搞不定的时候，都喜欢重启。在实际生产环境中，我们每次重启实例都要评估，金融行业甚至要提前提单子来说明这事，这绝对不是重启自己电脑那么简单。然而她就真的敢这么干，运气好的时候真解决问题了，运气差的时候实例都重启不了。好在她一直遵循着我告诉她的那句话，备份备份还是备份。
2.重启不行，那就重装。没错，如果重启还搞不定问题的时候，她就直接重装。用备用的环境重装，然后恢复数据。能成功就把应用切过去，不成功就找新的野路子。我听完头上都冒汗。也就是公司是他们家的，她才敢这么搞。换成我以前任何一份工作，要是这么来，距离被辞退也就不远了。
3.社交网络，穷举尝试。她有个好处，就是擅长利用各种社交网络，先百度后知乎，不行微博小红书，估计也用过墨天轮。总之能找到自己可以用的方法就行，挨个试，直到试出来为止。要是这一过程把环境彻底搞崩不能用了，那就重启大法加重装大法。
4.将白嫖进行到底。大学四年，遇到问题的时候，就去找计算机专业的校友。把自己的问题抛出去，然后白嫖回来各种方案。在这一阶段终于学会了UAT环境和生产环境。每次折腾之前，除了例行的备份，先在UAT环境捣鼓一顿。倒也慢慢上路了。
天知道，这6年她家的系统到底被她玩崩过多少次。她爸爸和她哥哥抓狂过多少遍。从她自己描述来看，似乎也慢慢上道了。
DBA需要标准教材吗
她能成长到今天，让我觉得，既有意料之外，又有情理之中。
还是老生常谈，学校从没教过如何运维管理一个系统，更没有告诉过学生怎么去当一个DBA。相当多的DBA在自己职业成长过程中，是靠着前辈以老带新或者自己不断摸着石头过河一路成长起来的。这位00后少女的野路子，也是其中一种，但是不具备参考价值。毕竟不是每位DBA都有能拿生产环境的系统横冲直撞而不用担心丢饭碗。这个背后的代价有多大，我们无从得知。
之前在做产品经理的时候，也有同事问我，想去做一个DBA，有什么教材可以参考吗？我冥思苦想之后告诉他，好像没有。那么DBA是否需要一个标准教材？我个人的观点是否定的。理由如下：
1.岗位差异。即便都叫DBA，而有不同的方向。开发DBA、运维DBA、架构DBA等等，不同方向差异非常大，所需要的技能和背景也各不相同。没有标准的教材告诉每一个方向要做什么，该做什么，怎么做。
2.企业差异。不同企业对DBA的要求大相径庭。即便是同一个岗位不同时期，也会有不小的差异。拿着所谓标准教材去生搬硬套，结果一定是不出意外地出意外了。最终还是要立足于自身需求。
3.背景差异。DBA的来源也千差万别，既有研发转运维，也有设备管理转DBA，也不乏和我一样应届毕业就直接全职的DBA。大家专业背景不同职业背景不同，很难有标准教材。
没有标准教材的情况下，我们仍然可以做一些事情来尽可能规范DBA的工作，助力未来成长：
1.建立内部知识库。根据企业内部的数据库使用情况，不断积累制定知识库，可以参考Oracle Support。过往的事故、生产环境标准、升级变更流程等等，都可以通过长年累月的文字积累来实现。过往以老带新口头相传的东西，都可以积累下来。
2.实训环境。DBA不但需要知识库，还需要实际动手。实训环境的重要性就得以体现了。可以是内部的测试服务器，也可以是公有云上不涉及业务数据库的环境。让DBA能够有足够的机会去动手。
3.时间冗余。DBA的成长还需要足够的时间去学习，如果每天疲于应付各种事故和部署，是没有时间去成长的。这一点其实是很多管理者所意识不到的。之前公司就遇到过领导看见DBA每天相当多时间不登系统，在看各种网页感到不满，其实也是对这个岗位认知有限的表现。
当然，这个野路子成长起来的00后DBA，并不是我们推崇的路径。而且从跟她的交流来看，她更希望有一天公司招募一个运维DBA，而她去做自己真正想做的事情。只是当下降本增效的阶段里，她在未来读研的3年里，似乎还要继续。
25岁研究生毕业，她的简历将会来一笔“9年DBA工作经验”，想想都觉得奇妙。
