工作幹久了，自然而然就會有做面試官的機會，考驗別人的同時對自己也是一種考驗。

總結一下我遇到過的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成長的途徑。

更多精彩內容，關注我們▼▼