從程式設計師的盡頭是業務說起
我感覺今日頭條挺牛的,最近總是給我推送一些程式設計方面的文章,特別是和C/C++相關的,前陣子還給我推送過幾篇資料庫方面的文章,居然還是PostgreSQL相關的。我從來沒有在今日頭條裡閱讀過類似的文章,不知道這種推送是哪來的?是今日頭條在窺視我的微信聊天記錄呢還是它從網上搜羅到的我的PROFILE中分析出來的。反正是十分可怕,人的隱私已經基本被剝奪的差不多了,而且我們也無能為力。
今天今日頭條推送的文章是挺JAVA,貶C/C++的,雖然寫的不怎麼樣,不過有一句話挺不錯的,那就是“程式設計師的盡頭是業務”,大體意思是程式語言在功能、效能上的差異越來越小了,用什麼語言程式設計並不重要,程式設計師的終極追求目標是業務。
和DBA圈子裡滿是某種資料庫的擁躉,充滿了對異種資料庫的鄙視一樣,碼農的圈子也充滿了各種語言之間的鄙視鏈。不過不管你用何種語言來編寫程式,如果你對業務的理解不深,那麼你也只能是一個初哥,成不了大家。
資料庫運維要更復雜一些,掌握資料庫運維的技術,技能要比掌握一門程式語言要複雜的多,因此在DBA圈子裡並不存在“DBA的盡頭是業務”的說法,雖然這些年這種說法在DBA圈子裡也越來越多了,不過這些觀點大多數來自於網際網路企業。可能我上了點歲數,有些保守了,我甚至有一個觀點是我們很多傳統行業企業的資料庫與資料庫應用正在被網際網路公司帶到一條歪路上去了。傳統企業的業務很難完全網際網路化,因為業務不是完全網際網路化的,因此IT系統也不可能是完全網際網路化的。另外網際網路企業在IT上的巨大投入,也不是傳統企業能夠學的來的。如果我們的高層領導瞭解了網際網路企業在IT投入上的數額和佔比,恐怕就不會整天對IT部門抱怨,你們怎麼不好好學學網際網路企業?我認識的一個企業的IT主管就是因為領導整天嘮叨這句話,有一天摟不住了,就頂了一句:“那你倒是給我網際網路企業的IT投入啊”。那個領導情商很高,聽到這句話,立馬就終止了討論,並沒有去深究網際網路企業的IT投入是個什麼情況。
對於一些管理核心業務系統的,整天盯著幾套關鍵系統看著的DBA來說,“DBA的盡頭是業務”這句話似乎是捱得上邊的,如果DBA不能對核心業務有所瞭解,那麼想要做好運維也是十分困難的。這種企業的DBA可能比研發人員更熟悉系統種的資料架構,一些資料的特徵,增長率,變更率等情況。只有這樣,才能更好的管理好資料庫。有些優化、升級、調整工作,也必須根據業務的發展情況進行分析,才能得出比較準確的結論。前陣子有個客戶的一套核心系統,對於交易的延時要求越來越高,RAC的GCS/GES等待會給每個核心交易帶來差不多10%的延時。因此他們通過對業務的分析,以及每個資料庫節點承擔的交易量,得出一個結論,如果拆掉RAC,採用HA方式來實現高可用,那麼單個節點完全可以承受未來五年的業務增長,而核心交易時間可以節約10多個毫秒。不管他們的方案是否正確,DBA做到這種地步,對業務的理解不夠深入肯定是幹不了的。
在另外一個極端,大多數DBA可能一輩子都不瞭解業務,不理解業務的細節。這些DBA也活得好好的,並沒有失業的壓力。他們只需要掌握資料庫運維的關鍵技術,瞭解一點點自己管理的系統的業務特徵就可以了。現在有些企業動則數千套系統,上萬個數據庫的運維規模,DBA能知道存在這麼一套資料庫就已經挺不錯了,就不要說理解每個資料庫後面的業務了。
所以說,DBA領域並不存在“DBA的盡頭是業務”這一說法。DBA是企業IT執行支撐中的一個重要的獨立環節,獨立到社麼程度呢?系統不出問題的時候,甚至很可能會被領導和同事遺忘;不過系統有活要加班的時候,好像哪個活都得找上你,好悲催的DBA。
- 技術分享 | orchestrator--運維--配置叢集自動切換&測試
- AIOPS的莫拉維克悖論
- 詳談 MySQL 8.0 原子 DDL 原理
- 為什麼不建議用 from xxx import *
- 最近解決的兩個拖延數年的問題
- Oracle資料庫解決方案集錦
- 新一代雲原生資料庫暢想
- MySQL8.0賬戶system_user許可權,你瞭解嗎?
- Data Fabric,下一個風口?
- 帶著孩子做開學準備清單
- 十多年前的入職第一天
- 技術分享 | MySQL 編寫指令碼時避免煩人的警告
- GoldenGate案例一則:抽取程序無法捕獲資料
- 技術分享 | MySQL 設定管理員密碼無法生效一例
- PG資料庫的鎖咋弄得這麼複雜呢
- 金融業分散式資料庫選型及HTAP場景實踐
- 我們的企業為什麼寫不好文件
- 新資料庫時代,DBA 發展之路該如何選擇
- MySQL:修改系統時鐘會導致資料庫hang住嗎?
- 從程式設計師的盡頭是業務說起