20多年前在Oracle上吃過的苦要重新吃一遍嗎？

國產化替代進入第六個年頭，很多核心系統已經切換到國產數據庫，期間也或多或少發生過一系列的故障。前陣子就某銀行的故障和移動的一位老專家探討了一番，他們對這個故障進行了模擬推演，最后的結論是，如果他們遇到了類似的因為國產數據庫引發的未知故障，故障恢復時間不會低于2小時，如果運氣不好，業務中斷半天的概率也極大。他個人感覺，2000年左右在Oracle上吃過的苦，是不是在數據庫國產化的今天還要再吃一遍?

　　我和那位專家是同齡人，也經歷過90年代末的那場以銀行、運營商為代表的企業信息化大潮。當年運營商使用的Oracle數據庫大多數還是8.0、8i和后來略微成熟一些的9i，銀行則大多數在使用Informix和DB2。那時候的Oracle還沒有在中國的大型核心業務系統上磨練過，軟件開發商也對如何在大型核心系統上把數據庫用好缺乏經驗，數據庫出現故障，導致核心業務停業也是常見的事情，于是DBA成為了那個時代的英雄。但凡對數據庫技術有點追求的人，在那個時代都能得到極大的鍛煉。其實鍛煉這個詞十分形象，現在這個詞被90后、00后形象地稱為“虐”。

　　經過二十年的不斷發展，Oracle在企業信息系統中變得十分“絲滑”了，實際上這些年成長起來的DBA是比較幸福的，Oracle變得極其好用了，Oracle的相關生態也相當繁榮。

　　不過隨著數據庫國產化替代的開始，似乎一切又要回到20多年前了。國產數據庫產品與關鍵業務系統的磨合還需要幾年時間，國產數據庫相關的知識也如25年前的Oracle一樣欠缺，但是經歷了Oracle“絲滑”時代制定下的“規矩”已經不像25年前那么隨意了，那時候數據庫故障了，業務就停了，30分鐘到1小時左右能恢復，業務部門也大多數能認可。用戶的要求也比較低，知道“電腦壞了”，大家就會靜靜地等著電腦好起來。現在的人對IT系統的依賴程度極高，某個公共服務停半小時，甚至十分鐘都可能意味著巨大的經濟損失，哪怕是不會有經濟損失的個體閑人，也會覺得極大的不爽，認為自己為之付費后獲得的服務打了折扣。

　　目前我們把應用系統從一個十分成熟的數據庫遷移到了一個不夠成熟的數據庫上，可靠性下降，出現某些故障可能是必然的事情。但是在數字化浪潮下，我們的IT系統的依賴度又遠高于二十五年前，這樣就出現了考核體系與必然的客觀規律之間的矛盾。我們必須要求關鍵公共服務的系統不出故障，從而保障經濟和生活不受干擾，但是客觀規律又決定了這些系統很難達到這個要求。這個課題就擺在了系統開發商、數據庫廠商、用戶、第三方服務商的面前。隨著時間的推移，以及不斷磨合，大家吃點苦，扛上一段時間，會慢慢有所改善的。關鍵是企業的考核制度，是不是給大家一條活路呢?面對出現的故障是不是能更大地寬容呢?