下面是一段文字，
在那裡，世界上最大的汽車制造商——大衆，再度對自己動刀展開大刀闊斧的變革：宣布組建自己的軟體部門，這也許是傳統汽車産業中最大的軟體研發中心。
這個新部門的名稱叫做“Digital Car&Service”，一位名叫 Christian Senger 的哥們出任該部門的負責人，同時兼任大衆集團“Digital Car&Service”部門負責人。與此同時，Christian Senger 成了大衆品牌乘用車的董事會成員。
這是今天我剛剛讀到的，對沒錯大衆汽車要玩軟體了。世界變化快，你今天還在追趕某汽車大佬的造車技術，轉眼他就變個❤。
作為一個資料庫er，其實變革不也類似這樣，10年前我還隻能說出的主流資料庫的名字不超過3個，現在的我可以随便就說出10個并且還玩過5 6個，即使這樣面對現在的競争我也不敢擡頭說，I am ok.
這就涉及一個DBA轉型的問題，怎麼從傳統的應試DBA轉換成服務型DBA在進一步變成資料庫的架構師。 可能反對的聲音馬上就響起。
你會多少，你業務量有多少，你好好管你的資料庫不就完了。
非也非也，時代變革了，站在原地如同等死。我還不想那麼早光榮。
說說最近我的體會，以前的dba和政府機構一樣，等着開發過來找你，稽核，修改意見，在稽核，在修改，在稽核來來往往，浪費時間不說，兩者的關系也不會好到哪裡。 其實開發對資料庫的需求沒有那麼簡單，如果從業務開始，到需求，到分析到編碼，一個DBA都跟過來，你就會改變對程式員的看法，一個個看似不合理的表設計，存儲過程都有他的故事，而之前dba的做法大多袖手旁觀，直到程式上線，一堆bug。最近的一段工作給我的啟發，就是在一個需求的開始，如果DBA跟進，就會從DBA的角度來引導開發，在繁花似錦的需求海洋裡面，和繁重的程式設計裡面，引導出多種經濟，不失态的設計，甚至能在雙方的讨論中找到資料庫和程式最完美的契合。
這就是我認為的變，從等，變為主動出擊，在錯誤的起點就将能想到的坑，填上。這是一個雙赢的過程，中間雙方都能得到進步，DBA更懂業務邏輯，更貼近開發，如同緩釋藥劑，而不是到達最後去下猛藥，進行搶救。
第二，DBA要滿足開發的需求，如同開發盡可能的去滿足業務的需求，需求虐我千百遍，我待需求如XX。作為程式的一個歸宿和起始點，DBA在選擇資料庫，或者資料庫中有的先進的技術，并且如何運用到程式開發中，如程式員習慣使用傳統資料庫，而某項需求，你發現nosql,newsql類的資料庫更适合，可能會提高程式的開發速度，減少某些坑，這其實倒是DBA更大的價值所在，而不是守株待兔，你說那個就用那個，或者是你就一直用那個。
主題的思想就是，服務需求，而不是程式遷就資料庫，那程式員一定不會多覺得DBA的存在是一件必要的事情，或美好的事情。
不斷更新知識，在最近和程式員的一段摸爬滾打，程式的架構，程式的開發思路一直都是變化的，并且變化的速度也越來越快，以及裡面使用的輔助中間件，變化非常快，更快的随着需求變化的設計思路，設計思路變了，資料庫表設計不變的去适應，這樣的聯姻多半不會完美。
資料庫在傳統的開發心裡是百年不變，就老三樣。DBA嘴裡就那幾條規矩，估計大部分開發都是這麼想DBA的，實際是DBA的日子，并不比開發好多少，從硬體，到系統，到簡單的腳本，程式，資料庫底層原理，上層花裡胡哨的各家功能，各種failover,高可用的資料庫架構設計，中間件使用，資料歸檔，資料庫安全，加上DBA十幾年的定位爛語句的能力，修補他們的能力，再到溝通，交流的軟實力，最後為了不被淘汰，也要繼續學習新型資料庫，資料庫原理，眼淚也是嘩嘩的，沒有容易的事情，如果你覺得容易，隻是沒有深入。
現代資料庫上雲，新型資料庫免維護，少維護，資料庫AI，paas,各種花錢就能買來的工具，其實留給運維DBA的時間不多了，路怎麼走，是繼續走老轍，還是碾壓出新轍，隻能靠自己。