DBA需要掌握些什么？这是一个老生常谈了。老白进入这个行业的时候，数据库还是十分神秘的东西，能顺利的在两三天内把一个数据库安装起来的人就是高手高手高高手了。如果你再能弄几条SQL分析下BUFFER CACHE的命中率啥的，那就是神一样的存在了。随着信息化技术的发展，数据库也不那么神秘了，DBA也从神变成了类似码农的存在了，如果可以起个新名词，那么叫库奴也许比较贴切，和码农真真的好哥俩。十多年前，我们和客户交流数据库运维甚至是系统运维的时候，“以数据库为核心的系统运维”是一个十分时髦的概念，而且也往往能打动运维主管的心。
在一个传统架构的系统中，网络是最不容易出问题的，而且网管系统也相对健全，不论企业的哪个系统，都在一张大网中，通过冗余设计，小问题都被容错了。存储也和网络一样。最容易出问题的无外乎应用服务器、数据库与应用。在这三驾马车里，数据库是核心，通过数据库可以解决绝大多数的问题。所以“以数据库为核心的运维”、“以数据库为核心的优化” 这些工作方法往往是能够行得通的。不过随着信息系统的日益复杂，一个企业也从有一两套关键系统到拥有几十套甚至上百套关键与不关键的系统。虽说有些系统也没什么人在用，不过一旦出问题也会影响一方诸侯的业务，于是，DBA的工作也变得复杂起来了。数据库出了问题，是应用的问题？应用服务器的问题？网络问题？存储问题？还是数据库本身的问题？如果DBA只知道数据库这一亩三分地，往往最后就成了背锅侠了，所有的问题，都可以怀疑是数据库的问题。无论是你不想做背锅侠，还是你真的想成为一个有点作为的DBA，你都需要掌握一些数据库以外的技术。
上面这张图是老白在十多年前给客户培训的时候，对开发DBA提出的技能要求，做开发辅助的DBA，重点是如何帮助研发人员写出好的代码，以及设计好的数据库物理模型。其中掌握存储优化的原理与技术是为数不多的和数据库专业无关的技术要求。那时候的存储系统的性能较差，数据库往往会在存储性能上出现问题，如何做好条带化设计，以及采用合适的RAID技术对于数据库长期稳定运行至关重要。老白在2000年后，也多次帮助用户通过优化存储架构，优化RAID组的设计，解决了一些十分棘手的性能问题。对于运维DBA的技能要求如下图：
是不是很悲催，DBA这口饭真的不好吃。实际上，DBA需要掌握的不仅仅如此。在2015年的一个沙龙上，老白讲了一个DBA应该掌握关键基线与容量指标的故事。
其中一个例子就是，DBA如何判断一个IO问题是后端存储的问题还是数据库服务器自身的问题。一个存储IO延时过高时由于存储出问题了，还是存储的能力达到了极限所导致的？掌握核心硬件的容量也是DBA需要去积累的。比如一台存储的IOPS能力是多高？一条SAN链路的带宽有多大？如果DBA不知道一块15000rpm的SAS盘的随机读写能力大约是200 IOPS，那么你就无法去估算你的后端存储能够给你提供的IO能力是多大。2013年的时候，老白帮助一个客户优化他们的ERP系统。当时发现，其实年底扎帐时候，系统确实有很大的IO负载，但是这套数据库系统一旦达到了200MB/秒的吞吐量后，就再也上不去了，IO延时也高达100毫秒。当时我们分析了后端存储，后端是一个HDS的高端存储，提供这套系统的RAID组有100多块盘，做了RAID 0+1,CACHE 也有128G，算是不错的配置，后端存储也不会有问题。数据库服务器是IBM 的P750，有两块8GB的HBA卡，做了HA配置，按理说，理论带宽也能达到800M，不至于有瓶颈。这个问题困扰了我们很久，后来发现接入SAN交换机是一台利旧的老交换机，端口都是4GB的，可能会有些瓶颈，不过也不至于只有200M的吞吐能力。不过为了试一试我们把两条链路配置成负载均衡的，一下子流量就提高到300多M了。看样子问题确实在SAN链路上，于是我们就把P750上的4块HBA卡全部用起来，SAN的上联链路变成4条，这样带宽就超过600M每秒了，IO延时也降到10毫秒左右了，基本上解决了用户的问题，度过了这次年终扎帐。后来经过分析，发现这两台利旧的老SAN交换机都是返修老机，虽然接口板是4GB的，但是背板接口都是2GB的老板子。这么深的路子，如果DBA不掌握一些容量的概念还真搞不定。
随着云时代的到来，数据库轻量化是个趋势，复杂的大型数据库运维可能只是DBA的一部分工作了，想在云时代立足，给DBA提出的要求就更高了。DBA必须是个十项全能选手，一专多能才能更好的立足。特别是在云时代，网络和安全日益重要，DBA掌握更多的网络与安全方面的技能能够更好的在云上做工作。DBA这个悲催的工作，一入库门，终生为奴，库奴是也。
