讓領導懂資料庫是資料庫國產化替代成功的一半

qing_yun 發表於 2022-11-29
資料庫

前陣子和一家大型企業討論資料庫國產化的方案,這個工作實際上是去O,在技術層面上並不難,弄清楚企業資料庫應用現狀,確定幾條遷移路線,剩下就把各個系統往這幾條路線裡套就可以了。

我們討論確定的總體思路也不復雜,對於新建中小型系統,原則上使用雲上RDS;對於存量大型核心系統,選擇裸金屬部署的國產資料庫或者雲原生分散式資料庫,經過系統改造後完成替代;對於新建大型系統,採用裸金屬部署的國產關係型資料庫或者雲原生分散式資料庫;對於存量的原來使用Oracle資料庫的中小型系統,已經計劃上雲改造遷移的,儘可能使用雲上RDS,暫無升級改造需求的,挑選一款與Oracle相容性較好的國產資料庫做遷移。

讓領導懂資料庫是資料庫國產化替代成功的一半

按照這個方案把上千套系統歸類到這幾條裡雖然工作量不小,不過也很快完成了。本來以為方案讓領導認可了,就可以開展選型工作,然後就可以進行試點了。沒想到領導看到這個方案後覺得這個方案考慮的太複雜了,他覺得,反正所有系統都要上雲,那麼為什麼不全部使用免費的雲上RDS,還花錢去買什麼國產資料庫呢?他覺得雲平臺比傳統架構強太多了,以前沒上雲用Oracle的時候還總是今天這個系統出問題,明天那個系統出問題。自從上雲後,他還沒聽說哪個雲上系統出過問題呢。

經過領導這一番教導,前陣子花了一個多月搞的方案算是白搞了。雖然不太甘心,但是也覺得很難去說服領導。會後企業中一個搞技術的朋友和我聊這件事,他說目前上雲的系統雖然有好幾百套,但是都是一些很小的非關鍵系統,哪怕真的出了事,領導也不會知道。而企業的核心繫統目前還都沒有上雲,都在Oracle資料庫裡跑著呢,那些系統出點小問題,都會反饋到領導那裡去,所以領導就自然而然的認為,系統上雲了就萬事大吉了。

另外一方面,以前稍微大一點的系統搬遷上雲,改用RDS的時候,都是做了拆庫分表工作的,在研發上大大投入了一把,把資料庫都切分為多個小型資料庫了,這麼一切分,資料庫變小後,哪怕缺個索引啥的,也都不怕了,確實是上雲用了RDS後反而問題比以前少了很多。只不過採用這種方式研發投入比較大,很多沒錢的二級企業搞不起,像他們這種大型的比較有錢的二級企業,目前的整個應用架構都改成這樣了,自己下屬的IT公司的研發目前也比較適應這樣的應用模式了。

領導的思路也不是完全不可行,也不是完全不正確。如果所有的應用系統都能夠比較徹底的完成上雲適配改造,那麼把所有的Oracle上的應用系統遷移到雲上RDS也並不是不可行。這種方式還可以省去購買國產資料庫許可證的費用(事實上這個費用是省不下來的,因為企業購買的商用版雲平臺,RDS節點的授權費用基本上與國產資料庫許可證授權相當,只是領導認為這是雲平臺投資,不是資料庫許可證投資而已),因此在領導眼裡,資料庫國產化改造並不需要花那麼多心思去區分各種技術路線。幾個核心系統單獨考慮,其他的系統全部用RDS替代就好了。因為在領導眼裡,Oracle和RDS雖然有區別,但是都只是資料庫而已,因此資料庫國產化替代不如化繁為簡。

不過在技術人員眼裡,資料庫的差異就大了。應用從Oracle遷移到不同的資料庫,應用改造,效能最佳化、高可用執行、日常運維,都有極大的差別。而作為企業IT部門的高階管理人員,領導並不一定了解這些不同,甚至無法理解這裡存在什麼不同。再加上領導身邊也經常有些半懂不懂的人忽悠忽悠,出現類似的情況就很難說了。

在和很多企業探討資料庫國產化的方案的時候,我經常提出一個總體成本的問題。實際上目前大多數領導都只關注購買資料庫許可證的費用,並不會去考慮總體的成本。我曾經和一個企業的IT主管討論過資料庫國產化改造的成本問題,最後發現實際上最難解決的是存量系統的問題。一個大型企業,經過近三十年的資訊化建設,至少有上千套大大小小的系統使用Oracle資料庫,這些系統中至少一半系統使用了大量的PL/SQL儲存過程。如果不選擇一款與Oracle高度相容的資料庫系統作為遷移物件,那麼整個遷移改造的成本是一個天文數字,這個數字遠比已經讓各位領導頭痛的國產資料庫許可證採購費用大的多。

除了遷移之外,選擇不同的資料庫,運維的費用也是需要考慮的。國產資料庫哪怕在一些介面上與Oracle做的有多像,實際上內部核心與Oracle的差異還是巨大的。在運維上,以前我們積累的經驗大多數不可用了。因此在運維、原廠服務、第三方支撐等方面都會存在巨大的差異。企業的IT主管在考慮資料庫國產化改造的時候,往往會忽略這方面的費用投資,這將導致國產化遷移大規模開始的時候,一定會遇到很多運維方面的問題,導致應用系統不斷出問題,IT部門疲於奔命。

與資料庫國產化工作開展有關的技術路線選擇、產品選型、費用與預算、人才培養、技術儲備等相關的工作,無論哪一個環節沒有做好,都會給資料庫國產化工作帶來極大的困難。但是如果這些無論哪一項都不是基層技術人員能夠決定的。如果不讓領導真正明白這些關鍵,那麼這項工作想做好都不容易。

另外每個企業的實際情況不同,技術能力、投資策略、改革目標等的不同都會導致最後的策略在領導眼中與技術人員眼中存在巨大的差異。就像我開始說的這個例子,如果企業下決心要將所有的系統都做雲化改造,也有大量的資金可以用於應用改造,那麼領導的方案也並不是無法實現的,只是要花更多的時間,花更多的錢而已。而如果領導選擇這個技術路線是想省錢,那麼這個方案就很危險了。我們在討論資料庫國產化技術路線的時候,是不是也要想辦法先讓領導搞清楚資料庫是怎麼一回事?領導真的懂了,再結合企業的IT發展路線去做決定,可能會比基層技術人員只是從技術層面去考慮問題更全面一些。

來自 “ 白鱔的洞穴 ”, 原文作者:白鱔;原文連結:https://mp.weixin.qq.com/s/qCNkH0D09SMPXw9jUAGtow,如有侵權,請聯絡管理員刪除。