工作干久了，自然而然就会有做面试官的机会，考验别人的同时对自己也是一种考验。
总结一下我遇到过的DBA面试的问题点，与大家共同探讨。
1、企业会在什么时候招聘DBA？
以前的DBA跳槽或者内部转岗了；
业务规模扩大，DBA人手不够用了；
公司原来没有DBA，老板觉得需要一个了。
不限于DBA岗位，假如以上场景的工作机会都给你发了offer，你会倾向于哪个？
对于有三到五年工作经验的老手来说，我会推荐第三个，能够从头开始搭建一个数据库运维体系这种机会可遇不可求，毕竟很多公司的数据库运维体系都很成熟了，DBA进去也就是做些添砖加瓦的工作。能参与数据库运维体系建立对于自己的工作履历来说是个很好的加分项。
当然第三个选择坑也会比较多，之前没有专职DBA，各类数据库都处于散养状态，后续不但需要大量的时间来梳理各数据库的信息，还可能涉及到权限回收，有些拿着超级管理员权限的开发同事还不一定乐意。
对经验不足的小白来说推荐第二选项，最好有人带一带，可以少走很多弯路。
2、DBA隶属哪个部门？
每个公司的DBA都是稀缺“物种”。如果不是规模够大人数够多，一般不会有专门的DBA部门，通常来说DBA都在运维团队，少量在开发团队，配合业务系统做一些开发审核工作。
运维团队的DBA和开发团队的DBA工作内容有可能不太一样，通常运维DBA的工作职责如下：
安装和升级数据库服务器；
制订数据库的存储方案，创建数据库存储结构；
创建数据库对象，在必要的时候修改数据库的结构；
管理数据库的用户维护数据库的安全性；
控制和监控用户对数据库的存取访问；
监控和优化数据库的性能；
解决数据库故障问题；
制定数据库备份计划,备份和恢复数据库；
联系数据库系统生产厂商,跟踪技术信息；
保证安全连接。
成熟的运维DBA团队，工作内容是清晰明了的，除了特别需要，很少做超出分内的事情。
开发团队的DBA，工作边界最好也能确认好。如果有十几个开发项目就一两个DBA，就会出现数据库遇到问题的时候都跑来找你，项目开发技术水平高低不一，每天要拿出大量时间疲于应付，会累死的。
3、DBA工作如何量化？
一个好的DBA会防患于未然，但是系统运行太好了又会给人一种DBA好像没事做的感觉，年终回报甚至也很难体现工作量，这就很尴尬了。
在职场上，认真干活的干不过写PPT的。DBA也是如此，做好技术是不够的。
所以提前确认好DBA的KPI如何量化很重要，每个行业每个公司，都没有一个确定的标准。有的公司凭领导感觉，有的可能是根据工单数量来定，还有的是用系统可用性来量化。面试时一定要去和面试官，尤其是级别高的面试官确定。
4、面试，问什么？
体系结构
通过这些问题可以了解面试者对这个数据库的基础了解程度。同时结合岗位实际情况有所侧重，比如都是集群数据库那么多问一些RAC相关的问题，例如ASM；如果是有多地灾备的环境，就多问一些Dataguard相关的内容。
对基础知识和体系结构的理解，会一定程度上反映出一个人的真实水平，视岗位级别决定问题的深度。
系统优化及故障处理
优化就像做阅读理解，不一定有标准答案。很多时候只能是通过问题来借此考察面试者遇到过的问题的程度以及他对数据某些方面的理解程度。我还遇到过对方讲述问题和解决过程，我自己对这块几乎不懂的情况。
如果没有太好的切入口，可以让面试者讲几个优化和故障案例，再根据具体的案例展开说说技术细节。
运维规范
DBA是IT部门一个风险比较高的岗位，有时候一个误操作就可能给公司带来很大的损失。除了对技术的要求，还需要有很高的职业素养。
尤其是要求比较高的公司，流程不正确做的所有事情都是错的。流程正确，即便影响开发进度，也是正确的做法。
这是这么不可理喻又理所当然。
职业规划
面试的末尾都会有这么一个问题：谈谈你的职业规划
求职者希望自己的职业生涯不断突破，面试官则希望的是团队稳定，尤其是DBA这种需要稳定性很高的岗位，这种矛盾看似不可调和。
意识到这个问题之后，我一般会在问题中加一个具体的时间，比如未来3年你的职业规划是什么样，能否接受3年内一直在做同一个岗位。
现在的时代，让一个人长期做一个岗位本身就已经很难，公司和员工签约一般也是3年左右。此外也会问问，过去两份工作的离职原因作为参考。
每一次面试当作一次对自己的检验和学习，做到见贤思齐，也是一个DBA成长的途径。
网友评论