去年年底的時候，我尤其焦慮，因為圈子的緣故，我能感受到行業裡的變化和趨勢，所以所想和所做不能匹配的時候，焦慮難免產生。當然我們要做減法和解法。
於是這樣一個分享。【萬字箴言】技術焦慮的減法與解法
開年的時候我又開始做了一個新年規劃的分享。
遠離溫水煮青蛙，新的一年做個有規劃的技術人！(有彩蛋）
半年過去了，也算有了一些結果，雖然和預想的還是有差距，多多少少算是邁出幾步。
以前的DBA團隊很多隸屬於運維部門，當然這個不是重點，而在於工作內容，在早些時候，其實我們的大量工作都是被一些事務性操作所束縛，這種束縛你想使勁擺脫這種狀況，但是反而被這些瑣事越纏越緊。
從我的理解裡，早期的DBA的工作內容基本是分為三個方向，佔用的比例大體如下。
第一部分是運維管理，比如基礎的安裝部署，搭建從庫，數據庫權限開通，系統權限開通，備份恢復，監控等，都是基礎運維的範疇。
而對於一些表結構的變更，SQL審核和數據遷移類的操作大都屬於運維管理類的操作。
隨著業務的增長，後面的部分的比例會越來越多，越來越頻繁，在這個變化的過程中，勢必會引發其他模塊的聯動變化，比如運維開發的模塊。
數據庫架構和優化是一個比較大的方向，在以前的工作中，相對來說優化的空間更大，但是很多優化的策略其實更多是添加索引，查看慢日誌等，很多問題都是在發生了之後才能排查，問題的解決是被動式的。至於架構，其實也是隨著業務需求的變化，逐步才能對已有的架構進行完善，否則對於很多情況來說，我們默認的一主一從，或者一主多從就基本夠用了，隨著需求的變化和對於數據庫業務服務的重視程度，架構的變化是為了更好的適應業務。
最後是運維開發，運維開發我把它分為兩個大類，第一個大類是一些應用的開發，比如運維自動化系統的開發，而在早期更多是腳本的開發，第二大類分為兩個子類，一個是系統/應用組件的開發，而另外一個則是內核級別的開發。系統/應用組件比如數據庫中間件的開發或者定製就是一種，智能運維模塊的開發也是一類，而第二個子類，內核級別的開發則不具有普遍性，因為一方面你即使開發修改了代碼，但是後續的維護怎麼去做，如果更加平滑這是一個問題，另外一個，對於內核的定製和改動，需要對數據庫方向有著很深入的理解或者有絕對的技術權威性，否則儘管寫出來了推廣也會很難。
從我的理解來看，他們所佔的比例在早期是一種很不平衡的狀態，大體是6:3:1
而在我的理解中，事務性的工作的意義其實更在於我們可以做的更快，做得更又效率。
但是後期運維開發和架構優化的工作會越來越多，這個比例會有很大的變動，基本的比例我理解會是2:4:4
當然我也看了一些行業裡的數據，這個和我的理解基本吻合，這個是一個互聯網公司在使用自動化之前和之後團隊工作方向的一些比例變化。
其實可以看到在運維價值提升以後，可以有更多的時間去做更有價值的事情了。
雖然不至於是喝咖啡看報紙的地步，但是我們所做的工作技術含量會提高，也所謂行業裡的水漲船高，不進則退。
現在已經到了一種近乎白熱化的狀態，但是行業裡的發展現狀也是層次不齊，不是說不重要，而是你是否順應了時代的發展。
閱讀更多 楊建榮的學習筆記 的文章
