[ 或許你能看到以前的你，現在的你，或者之後不同選擇的你。]
這是一篇有18年互聯網經驗、在阿里工作9年的工程師的真實經歷和感受，與大家分享，或許讀後你能看到一個行業的變化、或許是人生的每一次選擇、又或許是每一次的努力與堅持。
2000年也就是千禧年，我從建築轉行到互聯網行業，一切都是從頭開始，沒有互聯網的背景，能做的只有大量的學習，但好在我是一個能吃苦的人。
轉行的第一家互聯網公司是二六三（北京二六三企業通信有限公司），從一個監控人員、客服人員到系統維護，基本上從網絡、監控、安全所有涉及到運維的事情我都做過。在最開始，我先從運維做起，那個時候的運維工作門檻較現在來說比較低，但同時也是一個非常苦的活，需要值夜班，在入職第一年的後半年，除了正常的工作時間，經常夜班我也是在的，說是24小時在工作都不為過，不是24小時響應，而是確確實實在機房，在崗位上。
IDC（互聯網數據中心Internet Data Center）機房有大量的設備，機器，需要維護，經常有客戶打電話說，機器宕機，讓幫忙處理一下，“Reset”鍵我最熟悉 。後來跟客戶熟悉一些之後，直接告知密碼和賬戶，再後來，也會有客戶打電話諮詢問題如何解決。但當時的我，技術不過關，客戶的問題也拖不得，只能放下電話，趕緊求助部門的大牛，請教問題如何處理，設備如何配置。當時的我，真是抓住機會就一點點學，一點點摳，不斷在實踐中摸索，遇到問題就解決問題。
[2002年，是我的另一個轉折點，努力才會幸運]
當時的IDC機房基本的收費方式是計價和帶寬，後又新增加一個增值業務，就是幫客戶代運維，類似應用層的運維，郵箱服務器，監控存儲備份等等一系列打包。所以那時我的經理找到我，公司要開展一個新的業務，願不願意幹，我二話不說答應下來，也不會考慮過多，只是想著，光腳不怕穿鞋的。
當了小組長，就意味著，你要有一定的管理能力，管人和理事。在當時互聯網裡有一個不成文的規矩，就是誰技術能力強，又肯下功夫，就會有較大概率當選主管。之後我也是花了半年的時間把事情理好，但是管人永遠比理事難，管人又成了我的一個難題，最開始不會分派任務。慢慢的我覺得很苦惱，壓力也大，我覺得這樣不行，我得改變，所以我就想辦法，按系統模塊劃分工作量；給不同的人按照能力，特長分配工作；接著又backup，讓大家的工作能夠互相cover。所以慢慢的我又學會了管人。
之後我又晉升為主管、到經理，直到總監。到06年初，我就離開了二六三。但是時至今日我仍然很感激在二六三工作的那段時光，給我機會成長。
[機會永遠是留給有準備的人]
之後我入職到雅虎(中國），當時全球互聯網的態度都在雅虎，在中國是排進前三名的，排在前面的還有新浪、搜狐。
入職之後就發現一個最大的問題就是雅虎經常出故障，但是沒人知道有故障發生，所以首要任務就是要檢查為什麼會經常出故障，排查故障後發現是監控系統缺失，當務之急就是建立一個監控系統。之後又根據實際情況做了一系列的故障流程、變更流程、發佈流程等等。我寫了能有幾百萬字，毫不誇張的說，任何一個監控中心，按照我寫的流程，都可以解決監控、解決系統、解決報警等一系列問題，寫的可能不好看，但是一定是非常實用的。
09年10月，雅虎（中國）進行業務調整，所以整個技術團隊，被拆分成三個部分，而我所在的運維就被分到了阿里雲。
[人一定要有責任感、要有信念感]
初到阿里雲要做雲計算，那麼架構怎麼做？雲計算管理不同機型，新舊機器，管理不同算力，這難度異常大，根本行不通。行不通主要有兩個原因，一是調度成本非常高，因為要通訊很多不同種類的設備，要了解每一個設備的廠家、型號、批次以及不同設備的運算能力，同時還要快速高效的去計算運行結果，所以這個挑戰是很大的。二是從運維角度較難管理，因為我們在雲上去申請使用雲計算，選CPU，選內存，型號越統一，管理成本越低。除此之外還有監控、存儲、安全，和其他一些方面。
當時是有三臺主控機，我們就必須考慮如何進行集群管理。一旦master掛掉，那誰來接替管理，這又涉及架構的設計，有很多講究。對於公共平臺來說，最關心的三件事是，數據會不會丟失、數據會不會被偷，第三才是服務器是不是穩定。當然服務器穩定也是客戶使用最直觀的感受，但相比較來說數據丟失是更重要的事情，因為數據丟失是不可逆的。基於此當初架構設計時考慮有三個副本，加一個輪詢機制，在運營過程中，要不斷檢測副本的數量，一旦發現副本的數量等於二，就立馬複製出來一份，就是讓系統中永遠保持三份。但是最開始輪詢週期是很慢的，定好時間發現，時間到了還沒輪詢完，經常會發生類似的事情。這就是設計的不合理性，跟底層算法有一定關係，設計不合理就會導致效率低。對於我來說，最熟悉的還是架構和運維，雖然說更多的兼容性，是底層的開發工程師做起來的，但是底層的支撐也是更重要的。
[任何一件事情的成功，絕非一個人的努力，一定是團隊的力量]
2010年2月4日，負責阿里雲的運維工作的負責人組織了一個會議，討論關於飛天當前RHEL4.7版本的侷限性和升級到RHEL5.4的必要性問題，當時作為旁聽者我被臨時邀請參加了會議。參加會議的有13個人，各部門專家與飛天項目主管。不管是有意還是無意，我接管了這次會議的組織，會議結束後，我也就成了這個項目的PM。
2個小時的會議後的結論是：與會人員一致認同有必要升級到5.4。原因是現在的飛天版本是RHEL4.7，該版本存在安全風險，隨著時間的推移，硬件廠商逐漸減少對RHEL4的支持，未來RHEL4的維護成本會逐漸加大。
項目啟動，壓力也隨之而來。對於開發團隊來說，需要在一段時間內，面臨兩個平臺的代碼兼容性問題！資源方面，升級功能和壓力測試，需要一定規模的測試集群該如何提供？時間和業務方面，由於萬網要在5月份進行正式的對外生產，因此必須保證在5月份完成萬網項目得順利，因此3月份就需要搞定飛天對 5.4的支持！對於應用的影響，銀河，郵件，UC，地圖，后羿等等，尚不知道升級到5.4後對他們有什麼影響？
啟動會議上向大家介紹了項目的背景，目標，並和大家討論了所需要的資源和我們的升級工作計劃。最重要的一項就是給項目取一個好記並且響亮的名字。“五彩石”，就這樣誕生了。因為服務的對象是飛天的那些神仙們，存儲叫盤古，調度叫伏羲，監控叫神農，通訊叫女媧。還因為都是修補“天”的洞，女媧補的是黎民百姓的“天”,我們是要修補未來用戶的“飛天”，女媧補天是要讓老百姓過上好日子，我們補飛天是要讓未來用戶使用的更安全，更舒服。都是時間短，所需要的資源複雜，我們需要動用開發，運維，應用等多個部門，並且只有一個多月的時間就要搞定如此龐大的工程，和女媧補天極其相似。最後，確認項目升級到RHEL5.4，意想不到的諧音，五彩石近似於五點四。
名字有了，接踵而來的就是項目啟動時的各種“熱鬧”。
項目啟動後，也受到了大佬和牛人們的重視和回應。承擔項目的同時，當時我還在負責雅虎運維和阿里雲運維工具開發，運維流程等工作。說實在話，阿里雲的運維也正處艱難的開始階段，啟明星項目剛剛進入二期，Clone系統和ODPS如何更好的支持業務，這些難題也擺在了我的面前。但為了保證項目的順利進行，除了推動相關團隊完成既定的計劃，還要將進展通知到幾乎所有的開發和測試團隊。項目日報開始了。回頭看看當初每天的日報基本都是在23:00之後發送的，從2月23日開始到4月7日結束，經歷了44天，一天沒有間斷過。
3月3日，凌晨2點，延超傳來喜報，飛天的UT測試通過，我特意在當日中紅色字體標示，這是在項目正式啟動的第11天傳來的一個最好的消息！另外后羿支持飛天5.4環境的image將在3月6日完成，預計會在3也9日上線。
3月4日，新的5.4的飛天操作系統的模板確認。
3月10日，5.4OS上的P1的UT，ST測試全部通過，5.4OS上的P1 FT測試，有3個問題，其他全部測試通過。
3月12日 取得了重大進展，集群測試通過，WebUI安裝成功，並且通過webUI測試jobs成功，此次測試成功，表明5.4OS版本的飛天應用已經具備可能生產的條件！
終於我們五彩石項目開啟了一個具有標誌意義的里程碑！！ 此次升級不僅完成我們既定的飛天操作系統從RHEL4.7升級到RHEL5.4的最基本的要求，同時也完成了27集群的升級工作，涉及的服務器近3000臺。
“五彩石”的成功，凝聚著每一位的努力與付出。回想起當初項目啟動的時候，情景依舊曆歷在目，也曾彷徨困惑，也曾擔心疑慮，但是最終我們達成一致，一定升級，以滿足未來高可用雲使用的需求。
[ 從運維到業務，我毫不畏懼 ]
阿里金融
12年下半年，我開始做阿里金融的項目：阿里小貸，即貸款給淘寶商家，淘寶在當時號稱有“千萬商家”。阿里小貸的核心業務就是信譽貸款，信譽是有價值的。
在傳統的銀行業務領域來說，銀行有一套自己的系統以及審核流程，首先銀行要審核你的徵信，你的房產等一系列信息，審核過程還要十天半個月甚至更久，之後銀行才會審批給你相應地貸款額度。相較於傳統銀行，阿里小貸則用淘寶商家的信譽貸款，商家在淘寶系統上錄入的所有信息、數據都是信譽值的構成，包括銷售等級、商品屬性、交易量和好評率、以及賣家所在的地區等等。不需要任何的人工成本，也不需要冗長複雜的審核手續，直接登錄後臺，即可查詢信譽值，以及申請相應的貸款額度。
我作為阿里雲運維的負責人和阿里金融業務的負責人一起，花了大概三個月的時間把阿里小貸所涉及的問題整理清楚。因為涉及到整個數據的拓撲結構，首先就是數據源，數據輸入會有不同的輸入通道、數據也有不同的類型；又要把這些數據傳到飛天硬盤上，使用統一的數據處理，進行統一運算。其次在時間上也有一定要求，頭一天截止到十二點的數據，第二天九點就要出結果，這在當時還是有一定難度的。另外，故障也是時常發生。
有問題就要一件件解決，我們從以下幾方面查找原因：數據的安全性：當時發現底層開發有一些問題，數據庫竟然沒有備份，即使我已經有了十幾年的運維工作經驗，也很難做到臨危不亂。一旦出現大的故障，就是大麻煩，之後立馬做了備份，而且是不少於兩份。第二件事，設計可靠性：一旦寫錯程序就會報警，改好之後，報警數銳減。第三.開發設計的不合理性：處理數據任務，對job排序，週期長的優先處理，設計最優路徑，這樣不僅提升效率，也比較穩定。就這樣對數據的安全性、可靠性（包括數據關係）、數據的高效性等方面，對數據的採集、清洗、加工、週期等等一系列工序都做了一系列的加工和整改。
ODPS
從阿里金融結束後，我又接觸了ODPS (現MaxCompute：是一項大數據計算服務，能提供快速託管的PB級數據倉庫解決方案，可以經濟並高效的分析處理海量數據) 板塊的業務，主要負責ODPS的運行維護和產品的商業化。產品是能使用，而商品就是有一定價值。數據產品的商業化，就涉及到計價和收費。算力如何算、存儲如何收費，計算又按什麼標準收取費用等等等等。
我們當時服務過客戶有：華大基因、中信21世紀（現在的阿里健康）、施耐德等一些大企業。核算下來的數據成本價值還是很高的。
阿里金融雲
13年年底，我和我的搭檔做了一個項目叫做“聚寶盆”，而且是真正的做了一個產品並且商業化。這個項目的最核心應用是餘額寶，當時餘額寶的用戶是百萬級的，但是趕上雙十一的時候，要上升到億級。原本的架構難以承受這麼重的任務量，所以遷到雲上是勢在必行的。直到現在這個項目也仍然還在運營，上面已經有上千家的金融類的企業。
數據中國
2014年阿里有了新的戰略目標，數據中國，雲計算在中國各地的落地。這個項目的三條主線分別是各省、部委和大企業。當時，我被分到各省的這條線，長江以北的我的主場，第一個落地項目的城市是寧夏，我簽了第一個合同，金額達3.3億。
就這樣我做了幾個大的項目從阿里雲、ODPS、阿里金融到數據中國，我真正的意識到數據是有價值的，數據就等同於金錢。基礎設施的不斷完備，技術的不斷髮展，使得數據業務也在爆發式的增長，但同時也帶來了性能和成本的挑戰。
世界上只有一種真正的英雄主義，那就是在認識生活的真相後依然認真生活。從運維、運營、產品到業務，從建築到互聯網，我不斷的選擇，不斷地突破自己。14年我離開了阿里，開始了做的第一個創業項目，基因檢測。18年，我加入了Gravity ，區塊鏈項目。
[寫在最後]
人的每次選擇都決定了最後生活在哪個平行宇宙，08年1月份，我加入了Gravity 項目，一個真正有了實際需求的區塊鏈項目。
傳統的雲計算基礎設施和高性能的計算操作過於複雜和成本高昂，同時，科學領域以及各行業在運行大型程序和處理大量數據的過程中對計算能力的需求與日俱增，尤其是中小企業也很需要計算能力和數據能力。而Gravity 提供一個共享計算引擎，將空閒的手機、終端、PC 等設備組成一個巨大的計算集群。一種新形式的分佈式雲計算來實現較低成本的計算。利用區塊鏈價值網絡，使資源共享者在互信的網絡中獲取激勵。
區塊鏈是趨勢，而我們都將順勢而為。
閱讀更多 Gravityqiu 的文章
