在加入现在公司之前，我做过10年全职DBA，在国企、私企和外企都有过从业经历，行业包括金融、地产、教育等等。这期间也有过多次面试但是没有去的经历，最近一个朋友让我给他提点建议，电话聊了很久，也回忆起很多东西，也想趁着自己印象深刻，总结一下我遇到过的DBA面试的雷区。除了常见的设备规模、业务连续性要求、技术水平之外，还是有很多雷区有待确认。
1.为什么会在这时候招聘DBA？
其实不只是DBA岗位，其他岗位也应该问。通常我面试常遇到的几个场景是：
A.以前的DBA因为种种原因离职了
B.以前的DBA内部转岗了
C.业务规模扩大，DBA工作量超负荷，需要招一个人分担
D.这是个新成立的公司，业务起步需要招聘一个DBA
E.这不是一个新成立的公司，以前没有DBA，现在需要招聘一个专职DBA
比较理想的场景是D，一个新公司刚刚开始起步，很多东西都是在探索中，如果能够从头开始搭建一个数据库体系，对于自己以后的运维管理是很大的一个优势。
其次是B和C，因为以前的DBA还在公司，工作交接的时候有问题还可以请教，有一个过渡期。
场景E相对来说雷区会比较多，一方面没有专职的DBA，各类数据库的管理是很粗放的，甚至连备份都没有。入职之后需要大量的时间来梳理，这其中就有对现有数据库的破坏性改造，要承担很大风险。同时还可能与其他同事产生冲突。
最复杂的是A，因为在一个企业内DBA都是要害岗位，掌握着很多敏感信息。到了需要决定是否接offer的时候，如果能通过朋友联系到前任DBA，咨询一下离职理由以及情况，能避开很多雷区。例如我在面试一家公司时，发现上一任DBA恰好是我微信好友，于是问他为什么选择离职，他透露在公司DBA话语权很低，工作四五年没有涨薪，建议我不要趟这个浑水。
2.部门的组织架构是怎么样的？
通常来说，甲方公司的DBA都在运维团队，但也不尽然，有的公司是把DBA放在了业务条线里，直接服务于业务系统。不同的组织架构通常来说职责也是有很大差异的。运维团队的DBA岗位，需要确认是否值夜班，业务线的DBA，需要仔细确认工作边界。曾经和一位在某个业务线的DBA打过交道，他在入职的时候没有问清楚，导致入职以后才发现小到平时领导要查个数据，大到数据库升级和灾备演练，都只有他一个人做，一年就没有哪个周末完整休息过。
汇报对象也很重要，有的公司DBA是直接汇报给部门总经理，有的和总经理隔了两三层。DBA做的事情本身就不是很容易展示，汇报层级多了，很可能最终到达部门总经理那里就已经没有任何声音。很多DBA以为，自己把技术做好就足够了，可恰恰相反的是，往往职场上容易升值加薪的，都是能展示自己的。活没少做，夜没少熬，升职加薪没自己份的时候，心态会崩溃。
在外企还有一件事情要确认，就是本地的DBA和其他区域的DBA是怎样的协作关系，自己有多少权限。很多外企的IT部门，在中国权限都很低，DBA只是一个纯粹的执行岗位，对于很多东西没有决策权，这种岗位成长空间就很小。我曾经就职的外企，本地IT部门自由度很高，我可以根据业务和应用团队的同事需求，灵活处理，甚至可以每年提硬件预算来升级配置。这些都要在面试时确认清楚。有的外企是双线汇报，本地一条线，全球一条线，哪条线决定自己命运也需要确认。
还有就是开发、项目经理以及运维人员的配比。这个直接关系到DBA要和多少人直接打交道。一个公司如果几十个项目经理，全是外包开发，就一两个DBA，就会出现几十个项目经理数据库遇到问题的时候，都跑来找你，项目经理技术水平高低不一，自己手下的外包人员按照规定是不能碰数据库的，每天要拿出大量时间疲于应付。
3.如何确认DBA的KPI？
DBA的KPI如何量化与确认，这是我在每家公司都遇到的难题。每个行业每个公司，都没有一个确定的标准。本质上还是因为DBA工作的内容以及结果的不确定性所决定。
面试时一定要去和面试官，尤其是级别高的面试官确定，如何给DBA量化KPI，这对于自己入职之后的工作非常重要。比如有的公司全凭领导感觉，这种不确定性就太强了，要自己掂量好到底能不能让领导感觉自己贡献很大。有的可能是根据工单数量或者实际登录时间来定，这种就要去在工作中多注意。
还有的是事故次数和系统可用性，一个好的DBA会在事故发生之前把火苗掐灭，各种优化主动做好。但是有时候又会让研发人员和其他运维人员有一种DBA好像没事做的感觉。很多时候，自己做的东西又很难和对数据库了解不多的同事去讲。
如果面试官提供的KPI确定方式，和自己实际工作的感觉偏差很大，一定要慎重考虑。
DBA作为一个公司要害岗位，工作中遇到的问题是形形色色的，我们都会遇到各种各样的麻烦事，哪些可以让我们成长，哪些会阻碍我们前进，需要我们有一个预期。虽然无法在面试时了解所有的雷区，但是有时候多问一嘴，也许结果就会不一样。
