他在螞蟻金服做後端:那些堅持在一個崗位做八年的人,後來怎麼樣了?

1985年出生的他,在OB團隊裏絕對算是一個“老人”,從研究生畢業加入OB至今已經邁入第八個年頭了。
有人覺得花這麼長時間做同一件事會變得“螺絲釘”,用他的話說,做底層的同學需要比一般人更多一份耐心。除了耐心以外,驅使他一直“做下去”並且“往深了做下去”的原動力還是基於“興趣”。
從P5到P8他完成了職業生涯的三級跳,也完成了三個階段的成長和蛻變。機會從來都是留給有準備的人,當然,也總是留給那些耐得住寂寞的人。


元啓,螞蟻金服高級技術專家 

有時候離成功就差一次機會

「當時自己就憋着一股勁,就是非常想來 OB,覺得自己說什麼也要再試一次。」

1985 年出生的席華鋒(花名:元啓)出生於湖北襄陽。

“我接觸計算機算比較晚的,高中的時候有計算機課程,不過那個時候完全沒有概念,每次進機房都要套上鞋套,所有設備都被保護的很好。”

說到報考計算機專業,元啓說那個時候想法特別簡單,當時他連計算機跟軟件工程兩個專業都分不清楚,但是他始終堅持的一點就是自己以後是要做研究的。當時他覺得計算機對於搞研究很有幫助,計算機可以用來處理大數據,可以幫助人們去做更深入的研究。

2004 年,元啓順利考入了華中科技大學,華科是湖北省最好的理工院校。大學期間,他對數據庫並沒產生特別大的興趣。大學的數據庫課教的都是關係代數、範式之類的內容,覺得特別枯燥。

後來順其自然選擇了讀研,在研究生期間,實驗室做的方向是大數據,當時主要做的項目是大數據的 benchmark。相當於是在做一件定標準的事,雖然導師的想法很好,但是由於國內之前沒有類似的先例,做起來困難重重。雖然過程很艱難,但是元啓對最後的結果還是挺滿意的,研究生畢業的時候他拿到了優秀畢業論文。

就這樣順利的畢業了,找工作的經歷卻遠不如求學順利。

“我其實並不是特別自信的那種人。但是當時我有一點特別明確,就是一定要去一家互聯網公司。”

2011 年的時候,外企風頭正猛。當時外企的薪資和待遇比互聯網公司還要高不少。但是元啓相信互聯網行業的前景,相信互聯網一定是下一個趨勢。

當年基本上所有的互聯網公司巨頭:BAT、網易、搜狐他都投了簡歷。有一些過程很順利,比如騰訊的 offer 就拿的非常快;也有一些沒那麼順利的,比如最後拿到阿里的 offer 就經歷了不少挫折。

“第一次投遞阿里是因爲一個關係不錯的同學一畢業就來到了 OceanBase,他特別喜歡這個團隊的氛圍,就一直鼓勵我來 OB 積極幫我內推。但是第一次面試不太順利,沒有過。當時自己就憋着一股勁,就是非常想來 OB,覺得自己說什麼也要再試一次。後面自己就花了很多時間做準備,這個同學也特別好後來又幫我內推了一次,讓我獲得了寶貴的第二次機會,這一次終於拿下了 offer。”

讓元啓印象深刻的是,當時最後一面的面試官是時任阿里雲 CTO 的章文嵩。雖然元啓在研究生期間做的項目更多是偏實驗性質,章文嵩覺得通過一個點就能夠體現出一個人做事的深度。過五關斬六將,最後元啓終於來到了阿里巴巴,來到了 OB 團隊。

跟 OB 一路狂奔的這八年

「那個時候確實是下了狠勁,基本上 9 點下了班以後,回家繼續自學,每天學習到 12 點以後。」

2011 年,OceanBase 0.3 版本剛開始開發。剛來 OceanBase 的時候人比較少,基本上不論職位高低所有人都在寫代碼。當時元啓進來後,主要做的事情就是跟事務和日誌相關。這部分工作雖然不是最難的,但是卻很關鍵。

2011 到 2012 年間,對於整個 OceanBase 團隊而言特別特別困難。當時找不到對 OceanBase 而言特別有價值的業務,甚至整個團隊隨時面臨着解散,活下來成了整個團隊的唯一目標。

2012 年底,OceanBase 從淘寶調到支付寶,當時預估到支付寶在數據庫方面所面對的挑戰更大,後來證明確實如此。

這一年多時間對於元啓來說,是真的下了狠勁。因爲研究生階段花了很多時間做實驗,項目經驗比較少,編程基礎比較薄弱。當時的主管非常關注他的個人成長,讓他每天寫一份日報總結除了工作以外自學到的知識。基本上是 9 點下了班以後,回家繼續自學,每天學習到 12 點以後。

2013 年 5 月,支付寶下線了最後一臺 IBM 小型機,完成了去 IOE 進程中的一次重要嘗試。如何取代最要命的“O”成了橫亙在支付寶面前的一道大山。

OceanBase 0.5 版本應運而生,在次年雙十一,0.5 版本就取代 Oracle 支持了支付寶當天 10% 的流量。

對於整個 OB 團隊,或者說對於螞蟻來說,0.5 版本的上線都是一個里程碑式的存在。它最大的意義在於真正幫助螞蟻完成了去“O”,也真正讓高可用在螞蟻落地。

0.5 版本在螞蟻金服核心交易系統的上線讓 OceanBase 真正活了下來,甚至 OceanBase 還有了不少“擁躉”。在當時整個阿里巴巴還沒有一款數據庫產品能夠真正解決高可用的問題,OceanBase 一下子被捧到了一個前從未有的高度。

對於元啓個人而言,他除了持續負責日誌部分的工作,另外很大一部分工作就是跟性能相關。那段時間基本上把所有精力都完全撲在 0.5 版本的研發上,整個團隊是一種全力以赴的狀態。

這之後,2014 年到 2016 年,整整兩年的時間,元啓和其他 40 多個 OB 同學一起,再一次投入戰鬥,全身心投在 OceanBase 1.0 版本的開發上。

1.0 版本的誕生主要是解決擴展性的問題。“1.0 版本放在當時並不是爲了馬上解決業務的實際問題研發出來的,而完全是一套面向未來的架構。”

陽振坤(OceanBase 創始人)曾經提到,其實在交易庫還沒有完全上線的時候,就已經啓動了1.0 版本的開發。1.0 版本的設計初衷就是希望做出一套沒有任何限制,完全可擴展,高可用的系統架構。

1.0 版本的里程碑事件就是 OceanBase 在 2016 年的雙十一上線了螞蟻的賬務系統。對於銀行系統有一定了解的朋友可能知道,對於銀行來說最最核心的其實是賬務系統。

對於元啓來說,他的感受更直接更具體。突然覺得那一年數據庫的數量飛速增長,同時 OceanBase 上了非常多的業務。這對運維提出了更高的要求。OceanBase 1.0 版本的質量比 0.5 版本提升了整整一個層級,每一個版本發佈前都要經過一輪又一輪嚴密的測試,發佈週期也變得長了很多。正因爲有質量的保障,纔有了 OceanBase 1.0 版本在規模上幾何倍數的擴大。

OceanBase 2.0 版本在 2018 年 9 月正式發佈。2.0 版本的重要意義在於真正將 OceanBase 打造成一款通用型的商業數據庫產品。2.0 版本在 1.0 版本的質量標準上又提升了一個量級,除了對 MySQL 的兼容,2.0 版本更多的是打磨對 Oracle 的兼容性。

當時做 Oracle 兼容是有爭議的,團隊內部都覺得 MySQL 已經做到了 90% 的兼容,爲什麼還要花這麼多時間再去做一套 Oracle 兼容。

但是元啓心裏明白,這件事不得不做。OceanBase 正在走向商業化,然而很多金融機構裏的核心業務大多還是基於 Oracle。如果不做 Oracle 兼容,就意味着業務改造的工作量變得非常大,更換數據庫的成本非常之高。

“我們在做在 OceanBase 0.5 版本的時候,當時做的系統已經可以算得上是業界領先了。到了 2.0 版本的時候,這個感覺就更明顯了,我們遇到的問題都是現有的系統從來沒有遇到過的,所有問題都是全新的,充滿挑戰的。”

在 OceanBase 2.0 版本的開發中有兩個非常大的難點:一個是資源的緊缺,人力不足。Oracle 對外宣稱要招聘 1000 個人來做內核開發,實際上 OceanBase 的系統遠遠比 Oracle 複雜,如果按照他們的標準 OceanBase 可能要招 1000 人還不夠。

另外,還有一點就是技術實現上的困難,也就是如何保證分佈式系統中數據的一致性。在事務執行的時候如何讓它們看起來好像是獨立執行,同時又能完成併發。這些問題在單機環境下已經很難解了,在分佈式的環境下實現更是舉步維艱。

三個階段的蛻變

「你可以不去考慮自己所處的位置,勇敢的提出來,並且放手去做。做成了以後團隊裏所有人都能看得到。」

與 OB 一起狂奔的這八年,他完成了職業生涯的三級跳,也完成了三個階段的成長和蛻變。

第一階段:從自我視角到客戶視角

剛進入團隊的時候,最開始主要就是在做技術深度的積累和技術廣度的擴展。除了一直在事務層面做更深入的研究外,後面元啓也接觸了像測試、運維相關的知識。用他的話說,“當你瞭解的越多,你會發現自己看問題想問題的視角也在變化。”

當接觸的東西越來越多,慢慢的自己會從狹隘的技術上的自我視角轉向客戶視角,去開始理解客戶的痛點,感悟到技術是爲了服務業務而存在的。

第二階段:往高看,往遠看

在進入團隊前面幾年的時候,經常有一些技術方案的做法自己不是完全認可。還在第一階段的自己,一般第一反應就是覺得它不對,會去跟主管辯論。當你接觸的越多,思考的越多的時候,其實觀念也在變得越來越開放,自己會深入去想主管爲什麼想這麼做,部門老大爲什麼會這樣想,慢慢你就會發現所有選擇都是有原因的。

“你現在如果還是一個 P6。可能沒辦法去理解 P10,P11 的想法,因爲你還沒看到他們看到的東西。但是你要開放的去接納別人的想法,從更高的層面去思考,可能到了未來某一個時刻,你突然就頓悟了。”

當時 OceanBase 選擇走上自研這條路來說,很多人都不認可也不理解。尤其對於剛畢業的同學來說,可能心理會有障礙,他會認爲現在已經有一套開源的 MySQL,做一套自研的數據庫有什麼用,不理解做這件事的價值。

出現這種認知的偏差可能有兩方面的原因,一方面是這個同學可能瞭解的信息比較少,眼界還不夠開放,很多東西他看不到。另外一方面是他了解的不夠細緻,還認識不到這件事情背後的難度,可能是因爲他覺得這件事情太簡單,不知道從裏面能夠玩出什麼花樣來,所以會變得很浮躁。

在總結招聘經驗的時候,OB 團隊裏曾經有人總結出這樣一句話:“如果一個人在一個看似很無聊的崗位上都能夠玩出一些花樣兒,這種人就很值得要。”說明這個人能夠沉得下心,願意也能夠去發現一些別人看不到的東西。做數據庫的人天然需要這樣的特質,或者說也只有具備這種特質的人才願意投入這個行業。

第三階段:擴展你的邊界

陽老師說過一句話讓元啓感觸特別深,“企業裏的組織架構大多是人帶人的模式,並不代表這就是你做事情的邊界。如果你願意做一件事,並且覺得是對團隊真正有價值的。你可以不去考慮現在自己所處的位置,勇敢的提出來,並且放手去做。做成了以後團隊裏所有人都能看得到。”

元啓說特別喜歡 OceanBase 團隊開放的氛圍。剛進 OB 團隊的時候,很多事情都是領導安排你去做。慢慢進入到現在這個階段,自己會更多的主動去想應該去做哪些事,做哪些事才能發揮自己最大的價值。

在 OceanBase 的這八年,元啓最明顯的感覺就是自己做的越多,懂得越少。早期的時候會覺得自己特別牛,越往後越覺得自己身邊的人特別牛。這一路還有很多東西要學習,還有很多事情值得去探索。

一個特別正確的決定

「如果你選擇了這個行業,最重要的就是一定要有耐心,一定要相信自己的選擇。」

談到選擇數據庫行業,元啓說這是一個特別正確的決定,也是值得選擇的一條路。

首先,數據庫離業務最近,不管是在功能上的增強,還是在性能上的提升,數據庫的價值都會被放大。比如你寫了一段代碼,如果這段代碼是一個具體的業務邏輯,可能只有幾十或者幾百個人去訪問,它的價值就比較有限。如果你寫了一段代碼放進數據庫,因爲數據庫擁有海量用戶,它的價值就會被放大,給更多的人帶來影響。

另外一點就是數據庫行業的技術壁壘很高。技術壁壘一方面指的是技術的門檻高,所以一旦你在這個行業站穩腳跟,就擁有了非常強的核心競爭力。另外一方面是指從工程上來說數據庫是一個超大型項目,代碼行數在幾百萬行都算是規模小的,這就使得這個行業必須長期投入,在這一行也必須要沉下心來耐得住寂寞。技術壁壘越高,也就意味着一旦做成了,價值也會越大。

“如果你選擇了這個行業,最重要的就是一定要有耐心,一定要相信自己的選擇。還有一點就是保持好奇心,多瞭解當下和未來,比如現在整個行業有了哪些新硬件或者新業務產生,瞭解的越多,你就越容易找到自己的突破點。”

數據庫發展的這八年

「數據庫的價值在於它的開放性。」

元啓與 OceanBase 的這八年其實也是數據庫行業變遷的一個縮影。對於元啓來說,這八年時間感觸最直接的變化就是單機的性能和性價比越來越高。SSD 越來越便宜也越來越快,內存變得越來越大,CPU 核數也在變多。而 OceanBase 在最開始其實就是基於 SSD 大內存多核來設計的,這也是 OceanBase 的一個後發優勢。

然後就是從集中式轉向分佈式的這樣一個大浪潮。其實互聯網最開始是基於 KV 或者文件系統來做分佈式。數據庫的分佈式主要依賴於業務配合中間件來做,但是 OceanBase 是真正開創了一套在工業上可用的分佈式數據庫。

亞馬遜的 Aurora 做的是數據庫的雲服務,也可以叫做雲原生的數據庫。可以說是數據庫方向的另外一個趨勢,也有很多公司在效仿這個思路。Aurora 它的思路是首先保證數據庫功能的完善,然後再去解決它的擴展性。OceanBase 相當於是走了完全不同的一條路,我們一開始的設計就是無限可擴展的,然後再開始持續不斷完善功能。雖然過程會難很多,但是 Aurora 最終的擴展性是有限的,OceanBase 卻是無限可擴展的。

談到數據庫未來的發展,元啓一直強調“數據庫的價值在於它的開放性”。

提到數據庫,大家首先想到的就是 MySQL、Oracle。數據庫之所以這麼有價值,某種意義上是因爲數據庫開放的定義。關於什麼是數據庫其實這個概念一直在發生變化,比如時序數據庫、空間信息數據庫等等全新的概念層出不窮。

人工智能的普及化也給數據庫帶來了新的機會點。現在的人工智能更類似於用數據去訓練,得到的更像是一套算法,最後能夠進行識別和反饋。未來人工智能跟數據庫有更緊密的結合,才能夠發揮更大的價值。

數據庫的邊界在不斷擴展,隨着新技術的興起未來數據庫的機會點還會有更多。
 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章