这是一篇张瑞在09年的时候，写了一篇「DBA的未来发展方向」的文章，当时引起了很多人对DBA的思考。如果你也是一名DBA，那么这篇文章就特别适合你。

张瑞，Oracle ACE，网名HelloDBA，2005年加入阿里巴巴DBA团队，擅长数据库性能优化与应用架构改进，历经阿里巴巴数据库技术的变革，现任职于阿里集团技术保障部DBA团队，负责淘宝和天猫的数据库支持工作。

注：原文摘抄来自张瑞的Blog。如想了解更多内容，可以点击阅读原文查看。

DBA（DataBase Administrator ）数据库管理员，我每次和公司其他非技术部门的同事解释我的工作的时候都要颇费口舌，直到最后如果他还是不明白的话，我只好说我们的工作其实和仓库管理员没什么区别，都是管理一个仓库。更多的时候，我还要解释数据库和数据仓库的区别（因为在公司里，我们是两个部门），一般我给出的解释是：DBA虽然是仓库管理员，但是里面的数据不是我们的，你如果需要数据的话，还得找数据仓库。
我把DBA分为三类：第一类：顾问型，他们属于DBA中的高端人才，经验丰富，技术全面，提供专业的数据库咨询服务或培训，擅长用偏门的技术解决问题。第二类：技术支持型，他们属于各集成商或者专业的数据库维护公司，最擅长搭建各种环境，从主机，存储到OS和数据库都很熟悉，经常troubleshooting各种数据库问题。第三类：运维型，他们维护自己公司的数据库系统，稳定是对他们的唯一要求，他们经常要和集成商或者应用开发人员打交道。这三类DBA中都有牛人，而且很多DBA并不局限于其中的一类，他们既是运维DBA，也提供数据库咨询或培训服务。
我们属于运维型DBA，但不同于其他公司的是，我们的数据库每天都要上大量的项目，数据库承受着巨大的压力。由于数据库的可用性基本上决定了网站的可用性，所以必须有人能够对应用加以控制，保证数据库被正确的使用，所以我们的DBA又分为产品DBA和开发DBA，其中产品DBA负责产品数据库的维护，包括主机存储等，而开发DBA则主要与开发人员打交道，为他们提供数据库方面的支持，并参与到项目的设计过程中，开发DBA的权力很大，当一个项目设计不合理，可能会对数据库造成危害时，我们有权力say：No！
我是公司的第一个开发DBA，在我没进公司之前，那时的硬件比较差，流程和规范也没有，经常上一个项目就把整个数据库搞宕机，DBA总是手忙脚乱的四处救火。开发人员只关注SQL是否能得到正确的结果，根本不关心SQL的性能，而如果当项目上线后再发现问题，代价非常高，所以当时的DBA老大就想到了开发DBA这么一个角色（感谢rudolf）。我第一阶段的工作，主要是优化每个项目的SQL，保证每条SQL是最优化的，通过建立适当的索引提高SQL的效率。刚开始优化SQL时，都是采用尝试的方式，就是不断调整执行计划并一次次测试，直到测试的结果满意，到后来就变成了先了解表和索引的状况，看到SQL后，最优的执行计划就在脑海中出现了，然后再去验证是否和我的想法一致。在这个阶段，通过不断建立流程和培训开发人员来简化我的工作。但我逐步发现，如果一个项目在前期设计时就不正确的使用了数据库，即一个不合理的设计，后期很难通过优化SQL来提高性能。第二阶段，我开始逐步参与到项目的设计中去，基于我对数据库的理解，给产品设计人员甚至需求方提供更好的建议。在这个过程中，最难的一件事就是如何说服别人作改变，我觉得最重要的就是信任感。虽然我经常say：No！但同时我一定会给出我的建议，通过一个个项目的证明，使得设计和开发人员越来越信任我并依赖我，后来的所有重大项目，设计人员都会找我商量并听取我的建议，这样我的工作就变得越来越简单。不过同时我也面临着一个问题：就是如何在项目开始时，就评估出对数据库产生的影响。首先你必须非常了解应用，哪些功能会被频繁使用到；第二你必须非常了解数据库，表，索引以及相关的SQL等等；第三你必须非常了解整个系统，当前的负载，逻辑读和事物数等等，根据这样一系列的信息，并结合以往的项目，给出一个综合的判断，事实上这是一个非常困难的事，很多时候我们也是凭借经验来判断。第三阶段，DBA开始与架构部门合作开发一些系统优化的项目，以前我们都是通过statspack发现一些TOP SQL，可能是执行计划不正确或者SQL不够优化，我们会要求开发人员修改。后来DBA就开始主动推动一些数据库优化项目，这些项目往往需要其他部门的协助，比如搜索引擎和架构部门，所以现在我们的很多项目，都是由DBA和架构部门共同来完成，比如今年我们的分布式数据库（amoeba 变形虫）项目。
后来，我转向了产品DBA方向，在这段时间内，我接触到了各种主机和存储，学习了很多硬件和OS的知识，同时对两种DBA的角色也有了更深的理解，产品DBA和开发DBA对于数据库的关注点是不同的，产品DBA更关注运行维护，troubleshooting，备份恢复等方面，而开发DBA更倾向于应用开发，性能优化等方面。
数据库未来发展的方向，智能化自动化一定是个趋势，各数据库厂商也为DBA提供了更方便更强大的管理和诊断工具。并且随着大家使用数据库的不断成熟，低级的错误越来越少见，我们不可能再通过调整某个“参数”就让系统性能大幅度得到提升，尤其是我们管理的数据库，参数基本上都已经是最优化了，调整的机会很少。那是不是都数据库都自动化了，就不需要DBA或者DBA的重要性降低了，我倒不这么认为。但是如果DBA只具备数据库的知识，应该是不足够了。未来的DBA不仅仅要了解主机，存储，操作系统，并时刻关注硬件发展趋势和数据库新特性以外，还应该朝着DA（Data Architect 数据架构师）的方向发展，从Database到Data就说明以后数据不一定在数据库里面了，从Administrator到Architect说明我们要懂架构，虽然我们不一定要懂得coding（PL/SQL不算）。对于开发DBA和产品DBA来说，只是工作职责上的侧重点不同，未来的环境肯定是要求DBA掌握更多方面的知识。另外，好的沟通能力和团队合作能力对于一个优秀的DBA也是必不可少。