在問這個問題之前，我們先簡單來聊下：DBA到底要不要掌握開發技能。
一直在做DBA，但是不懂開發，現在想學一門語言，大家提點建議，學什麼語言好 ？
最近總有衝動想去學程式設計，但是有怕學下來在工作上沒啥用
應該要懂吧，雖然不是專職的開發人員，但有時要測試之類的要使用啊，讀懂程式碼還是有必要的。
程式設計知識總是有用的，學習一下思路和總體的執行情況，任何一個系統都是應用與資料庫的整合才行。
C、C++和java是程式語言，DBA和這些有什麼關係？你瞭解相應的sql不就行了
先從招聘需求來看，但凡是招聘系統運維和DBA的崗位，幾乎很少能看到不需要開發技能的，運維開發技能已經預設成為了招聘的一個硬需求。或者退一步來說，資料庫技能水平可以再培養，但是不懂開發技術，沒有開發基礎，要通關拿到offer還是很難的。
看看現在DBA的招聘需求，再來看看多年以前，你會發現一個明顯的道理：不進則退。
我會從幾個維度來解釋。
DBA在行業的定位，是和運維保障緊密聯絡起來的，我們經常會說運維DBA,運維行業的潛規則就是背鍋，背系統的鍋，背資料庫的鍋，背網路故障的鍋。。。運維行業的三板斧是重啟、重灌、回滾，不要問為什麼，看起來神奇的問題總有解決的門道。運維部門的痛點是隻花錢不掙錢，每每到了評業績的時候，我們能體現出的最好指標就是節省了多少錢，而研發部門是掙了多少錢，雖然聽起來差不多，實際上從定位上來說差別大了去了。
所以慢慢的就會形成一種很特殊的文化，做了又沒好處，做得多出錯的機率越高，還倒扣分，與其這樣還不如不做。所以在保障範圍內，還是相對保守一些。
當然這種情況是在一個可控維度內的，但是業務要發展，需求會升級，所以原來的那些慢慢就會跟不上了。比如你維護了20臺伺服器，現在手工還完全搞的定，搞什麼自動化，再來20臺，辛苦點，加個班也能搞定。但是再翻倍，那人工基本就沒戲了。這個時候懶政不作為已經不起作用了，現在已經影響到基本的保障需求了。
近些年來提出來的DevOps不是空穴來風，很多都是基於實踐的理念。
這個時候有兩個分支，一個是運維保障，一個是運維服務。
運維保障是份內的事情，對外可能是不透明的，就比如資料庫的災備，高可用，其實很多時候業務壓根不關心，但是DBA要關心。這些在沒有問題的時候都是雞肋，這一層面的工作我們可以理解為體現的是技術價值，這也就是很多業務同學不理解DBA的一個原因。
對於業務來說，能夠和他關聯緊密，並且能夠直接感受到的，就是業務服務了。比如業務要做一個數據遷移，要開通一個許可權，要做下資料變更等，DBA得支援，以前是能支援，現在在運維保障的基礎上要支援的好。
簡單來說，就是下面的三個維度：
響應業務需求
提高服務效率
提升服務質量
下面是一個數據庫方向的運維規劃圖，僅供參考。
我們可以看到對於業務可見的其實就是業務服務。這些工作看起來簡單，但是很瑣碎而且實際上沒那麼簡單。要實現這樣的一個需求，勢必就要你有一些基礎的鋪墊。
說了這麼多，其實是透過一個更加全域性的角度來理解DBA的定位，DBA的核心定位早已經不是資料恢復了，而是提供高質量的資料服務。
所以在敏捷運維的大背景下，我們是希望快速響應業務，儘可能提高業務價值，同時夯實技術價值，兩者缺一不可。
資料管理如何統一，這是第一個現實問題，以前是個人主義的excel就可以搞定，做了什麼事情小本本上都記得清清楚楚，現在要平滑對接，對接的粒度就是流程，所以有元資料的建設，有後續的流程的建設，這些都需要以前的技術積累，也需要一定的開發技能。在這裡需要明確的是DBA不需要花太多精力在前端技術上，而是需要更多關注後端的架構和實現。指令碼開發技術本質上不屬於運維開發技能範疇，你需要一門高階程式語言來輔助你的工作。
而這些要投入精力去做，會發現需要的不僅僅是開發技能，還需要學習產品思維。
產品思維能夠體現出你是否已經深刻理解了要做的事情。而這在很多技術方面的同學是極為欠缺的。一個比較常見的情況就是設計出來的前端慘不忍睹，後端需要10個引數，前端絕對就是10個框或者10個按鈕，所以我剛說不要投入太多的精力在前端上，只有深刻理解了業務需求和定位，你才能擺脫一些技術上的束縛，能夠設計出更加完善的服務產品，單純在技術層面深入只會讓你走入一個死衚衕。最直白的情況就是你設計了一個系統，功能強大，但是使用成本高，學習曲線高，導致用不起來，業務同學不買賬。
專業的人做專業的事情，我們作為DBA是專業的，那麼我們提供的資料服務也應該是專業的，流程不應該沉睡在你的腳本里面，而是應該透過一種更加友好的方式去體現，掌握開發技能僅僅這是我們職業生涯轉型的一個小插曲，我們需要在夯實基礎的前提下，更加深入的理解業務，無論你是做DBA還是其他行業，你都應該會成為一個行家裡手。
在問這個問題之前，我們先簡單來聊下：DBA到底要不要掌握開發技能。
一直在做DBA，但是不懂開發，現在想學一門語言，大家提點建議，學什麼語言好 ？
最近總有衝動想去學程式設計，但是有怕學下來在工作上沒啥用
應該要懂吧，雖然不是專職的開發人員，但有時要測試之類的要使用啊，讀懂程式碼還是有必要的。
程式設計知識總是有用的，學習一下思路和總體的執行情況，任何一個系統都是應用與資料庫的整合才行。
C、C++和java是程式語言，DBA和這些有什麼關係？你瞭解相應的sql不就行了
先從招聘需求來看，但凡是招聘系統運維和DBA的崗位，幾乎很少能看到不需要開發技能的，運維開發技能已經預設成為了招聘的一個硬需求。或者退一步來說，資料庫技能水平可以再培養，但是不懂開發技術，沒有開發基礎，要通關拿到offer還是很難的。
看看現在DBA的招聘需求，再來看看多年以前，你會發現一個明顯的道理：不進則退。
我會從幾個維度來解釋。
DBA在行業的定位，是和運維保障緊密聯絡起來的，我們經常會說運維DBA,運維行業的潛規則就是背鍋，背系統的鍋，背資料庫的鍋，背網路故障的鍋。。。運維行業的三板斧是重啟、重灌、回滾，不要問為什麼，看起來神奇的問題總有解決的門道。運維部門的痛點是隻花錢不掙錢，每每到了評業績的時候，我們能體現出的最好指標就是節省了多少錢，而研發部門是掙了多少錢，雖然聽起來差不多，實際上從定位上來說差別大了去了。
所以慢慢的就會形成一種很特殊的文化，做了又沒好處，做得多出錯的機率越高，還倒扣分，與其這樣還不如不做。所以在保障範圍內，還是相對保守一些。
當然這種情況是在一個可控維度內的，但是業務要發展，需求會升級，所以原來的那些慢慢就會跟不上了。比如你維護了20臺伺服器，現在手工還完全搞的定，搞什麼自動化，再來20臺，辛苦點，加個班也能搞定。但是再翻倍，那人工基本就沒戲了。這個時候懶政不作為已經不起作用了，現在已經影響到基本的保障需求了。
近些年來提出來的DevOps不是空穴來風，很多都是基於實踐的理念。
這個時候有兩個分支，一個是運維保障，一個是運維服務。
運維保障是份內的事情，對外可能是不透明的，就比如資料庫的災備，高可用，其實很多時候業務壓根不關心，但是DBA要關心。這些在沒有問題的時候都是雞肋，這一層面的工作我們可以理解為體現的是技術價值，這也就是很多業務同學不理解DBA的一個原因。
對於業務來說，能夠和他關聯緊密，並且能夠直接感受到的，就是業務服務了。比如業務要做一個數據遷移，要開通一個許可權，要做下資料變更等，DBA得支援，以前是能支援，現在在運維保障的基礎上要支援的好。
簡單來說，就是下面的三個維度：
響應業務需求
提高服務效率
提升服務質量
下面是一個數據庫方向的運維規劃圖，僅供參考。
我們可以看到對於業務可見的其實就是業務服務。這些工作看起來簡單，但是很瑣碎而且實際上沒那麼簡單。要實現這樣的一個需求，勢必就要你有一些基礎的鋪墊。
說了這麼多，其實是透過一個更加全域性的角度來理解DBA的定位，DBA的核心定位早已經不是資料恢復了，而是提供高質量的資料服務。
所以在敏捷運維的大背景下，我們是希望快速響應業務，儘可能提高業務價值，同時夯實技術價值，兩者缺一不可。
資料管理如何統一，這是第一個現實問題，以前是個人主義的excel就可以搞定，做了什麼事情小本本上都記得清清楚楚，現在要平滑對接，對接的粒度就是流程，所以有元資料的建設，有後續的流程的建設，這些都需要以前的技術積累，也需要一定的開發技能。在這裡需要明確的是DBA不需要花太多精力在前端技術上，而是需要更多關注後端的架構和實現。指令碼開發技術本質上不屬於運維開發技能範疇，你需要一門高階程式語言來輔助你的工作。
而這些要投入精力去做，會發現需要的不僅僅是開發技能，還需要學習產品思維。
產品思維能夠體現出你是否已經深刻理解了要做的事情。而這在很多技術方面的同學是極為欠缺的。一個比較常見的情況就是設計出來的前端慘不忍睹，後端需要10個引數，前端絕對就是10個框或者10個按鈕，所以我剛說不要投入太多的精力在前端上，只有深刻理解了業務需求和定位，你才能擺脫一些技術上的束縛，能夠設計出更加完善的服務產品，單純在技術層面深入只會讓你走入一個死衚衕。最直白的情況就是你設計了一個系統，功能強大，但是使用成本高，學習曲線高，導致用不起來，業務同學不買賬。
專業的人做專業的事情，我們作為DBA是專業的，那麼我們提供的資料服務也應該是專業的，流程不應該沉睡在你的腳本里面，而是應該透過一種更加友好的方式去體現，掌握開發技能僅僅這是我們職業生涯轉型的一個小插曲，我們需要在夯實基礎的前提下，更加深入的理解業務，無論你是做DBA還是其他行業，你都應該會成為一個行家裡手。