螞蟻金服自研架構 SOFA 背後的工程師|1024快樂
我們講了很多分散式架構，今天我們講講背後的他們
創新都是被逼出來的，螞蟻金服自研SOFA同樣如此。SOFA走的是一條跟傳統金融行業不同的分散式架構之路。要基於不可靠的硬體系統實現金融級的效能和可靠性，要應對支付寶這樣的超大規模網際網路金融應用，有很多難題要解決。螞蟻金服構建了一整套處理金融級交易的分散式架構與平臺，在金融級的一致性要求和海量併發處理能力上達到了很好的平衡，並在快速容災恢復、彈性伸縮能力、多地多活高可用保證能力和按需供給的精細化資源排程能力方面沉澱了豐富的實踐經驗
這十年，有很多的工程師參與，比如：
程立，花名魯肅，螞蟻金服 CTO。
胡喜，螞蟻金服副總裁、副CTO。
楊冰，螞蟻金服中介軟體負責人。
今天我們來講講他們的故事，是否也會成為你的故事？
面對極限業務場景催生極限的 IT 體系 - SOFA 的緣起
程立，花名魯肅，摩羯座，工號3896。2004年，支付寶剛剛有自己獨立的系統，基礎平臺還得靠外包團隊提供技術支援。而2004年2月，程立還在上海交大攻讀博士，一個偶然機會讓他接觸到阿里巴巴，並以外包架構師的身份協助支付寶網站的建設。一年合作下來，程立決定放棄博士學位，並於2005年2月正式加入支付寶。程立以嚴謹務實、邏輯嚴密，被螞蟻技術團隊的同事視作 “神一樣的存在”。
作為曾經的支付寶首席架構師、支付寶第一代架構設計者，以及支付寶史上最大危機——2008年1月1月停機發布17小時——的救火大隊長，可以說如果說沒有程立，就沒有現在的支付寶。在螞蟻金服入門手冊《拾念》中，記載了支付寶史上最驚心動魄的17小時：2008年元旦，支付寶宣佈要停機8小時釋出“財務三期”，但各種意外接連出現，當時“財務攜款潛逃”、“溼抹布導致伺服器宕機”的傳言滿天飛、沒有包裹送的快遞小哥發帖跪求支付寶快點回來，程立在關鍵時刻敲了近兩個小時的程式碼，最終結束了17小時的停機發布。
程立講述了SOFA的誕生歷史：最早的支付寶系統，是由還不太會大系統開發的人員實現的，像程立剛從學校出來就做支付寶第一代架構，因此第一代系統非常簡單——就是一個簡單的應用，裝在一臺應用伺服器上，使用一個資料庫，服務一個大客戶淘寶。一個簡單的系統，支撐了支付寶從2004年到2006年早期的發展。支付寶早期的系統架構雖然簡單，但好處是特別快，產品經理希望怎麼改、馬上改一下程式碼就能實現了，比如說支付寶紅包，從需求提出到上線就四天的時間，但是到後面，這樣一個簡單系統無法支撐更多的交易量，也不能支撐更加複雜的業務。
從2006年底開始醞釀，那時候支付寶面臨最大的一個問題是業務變得越來越複雜，而工程師數量越來越多，原來的系統被稱為monolithic——即龐大的單體系統的意思。這個系統慢慢變得無法裝載更多更復雜的業務邏輯，也不能讓那麼多工程師在一起並行的工作。當時，支付寶希望可以成百上千個專案並行進行，而且每個工程師可以不受干擾的工作，而當業務邏輯增加的時候，系統的複雜度不要成指數級上升。
所以，在2006年的時候，支付寶技術團隊要做對未來的技術架構做一個選擇，當時有兩派意見：一派意見是向銀行老大哥學習，老大哥已經走了十幾年，這條路一定是安全的；另一派意見是走一條新的路，即用分散式的架構去支撐未來的交易支付系統，而這條路在當時還沒有人走過。這裡的分散式架構，並不是客戶端/伺服器時代的面向企業級的小規模分散式架構，而是在網際網路時代的超大規模分散式架構。經過差不多大概一年左右的討論和思考之後，支付寶團隊做了一個決定，要走一條過去沒有人走過的路，於是啟動了支付寶第二代架構的建設，即支付寶技術系統的服務化。2007年開始，支付寶啟動了對交易系統、商戶系統、會員系統、支付清算系統的改造。
就在那一年，支付寶到大連招聘遇到了胡喜（花名：阿璽），他之前已經在前一家公司研究SOA以及OSGi相關技術，於是就加入支付寶團隊，幫助程立做下一代架構的轉變。胡喜回憶，他在2007年加入支付寶團隊的時候，研發人員都比較痛苦。當時的支付寶使用的是阿里巴巴的統一技術框架WebX。WebX是阿里自研發的一套基於JavaServlet API的通用Web框架，在阿里巴巴集團內部廣泛使用，2010年底向社會開放原始碼。WebX比較偏向於前後端融合的架構，能快速搭建一個網站，但是沒有考慮到業務發展到一定程度後的複雜度，怎麼更好的搭建後臺。例如，當時支付寶的一個電子錢包系統叫iWallet，每次系統啟動就得五六分鐘，開發人員出去抽根菸，回來後如果發現錯誤又得修改後重新啟動，開發人員每天不是在程式碼編譯的過程當中，就是重啟的過程當中，一個系統包含了幾十個工程，十幾個團隊並行開發，專案併發也導致了很多的合併衝突和耗時，整個研發效率低下導致很難進行下去。於是，從那開始就著手研究解決支付寶整個架構的變化。
程立給當時要做的這套分散式架構起了一個“SOFA”的名字，其背後有兩個含義：一是按照當時的技術趨勢，要做面向服務的架構，即ServiceOriented Architecture，但加入了金融業務，所以是Service Oriented Fabric Architecture；二是希望能夠像沙發一樣，讓工程師可以非常爽地工作。所以當時出於這麼簡單的考慮，就開始打造SOFA。所謂SOA和服務化改造，就是把企業的IT系統以“服務”的方式重新組織起來，再通過“服務匯流排”連線起來形成可插拔式的企業IT架構，這個架構就是SOA。這裡要注意的是，SOA其實是一套面向傳統企業IT的架構思想，而且在SOA早期則只有理論框架而無具體的成功實踐。
第一代的SOFA其實就解決兩個問題：一是當要把系統變成分散式的時候，怎麼有一個像“膠水”的機制也就是聯結器，可以把分散式系統連線成一個整體；二是希望每一個服務本身是元件化，所以當時第一代SOFA裡採用了OSGi（一套Java模組化規範，允許應用程式使用精煉、可重用和可協作的元件構建），這樣每個工程師可以專注於各自的元件，最後又能夠把這些元件拼裝在一起成為“服務”，再把“服務”拼裝在一起成為整個大系統。這一整套框架，就是第一代SOFA框架。
有了第一代SOFA技術架構之後，支付寶團隊就開始做非常關鍵的業務服務改造。首先是把支付寶所有使用者的核心賬務系統變成一個業務服務，從而可以和其它業務組裝起來。但是把賬務拆出來以後，遇到一個更難的問題：怎麼解決分散式服務一致性的問題，也就是分散式事務問題。而在解決這個問題的時候，當時支付寶團隊冒了很大的風險，在啟動這個專案的時候還並不清楚怎麼解決最好，而當時可以參考的行業技術趨勢就是SOA以及業界提出的幾個SOA框架。
SOA業界那時候提出兩個SOA事務的標準：一個是基於Atomic Transaction（原子性交易），叫WS-Atomic Transaction；另一個是基於業務流程編排的事務，叫WS-BusinessActivity；開源社群通過JBoss的TransactionServer實現了這兩個參考標準下的事務。當時，支付寶的技術團隊就在想，能否用JBoss開源技術與這兩個標準去構建支付寶的核心交易和賬務？然而，專案開始後的不久，也就三個月左右的時間，當專案進行到一半的時候，發現這兩個當時業界的標準和開源實現卻根本不可能支援一個實際的應用。
原因很簡單，一個最簡單的核心交易系統和核心賬務系統，進行最簡單的一個事務，也要經過十幾次的訊息傳遞，其中任何一次訊息傳遞如果中斷，那麼這個事務就失敗了，而且失敗以後，當時業界的SOA標準並沒有提出該怎麼恢復失敗的事務，同時任何一次交易都經過十幾次的訊息傳遞的話，也導致整效能非常低。這樣一個系統如果最後釋出的話，其實是不能支援支付寶當時的交易量。所以當專案進行到一半的時候，團隊就放棄了業界標準及其開源實現，必須找到自己的一條路。
當年，關於分散式事務的一致性，業界另一條路徑是基於兩階段事務標準（Prepare階段與Commit階段）和開源分散式實現XA，但當時已經知道PayPal曾經走過這條路，結果是導致系統宕機一週，最後系統全部回滾。
所以那個時候，支付寶技術團隊就考慮能否自己提個標準，這樣一來就簡單了：首先是要解決分散式一致性問題，必須要分散式的提交協議，這個協議如果在資料庫層實現，效率會非常低下，因為資料庫層不懂任何的業務邏輯，只能以一種通用的方式去實現，從而導致無法對上層的業務邏輯層進行優化，所以就想到把提交協議放在服務層。
“那個時候，我們大的想法很簡單，既然支付寶系統已經拆成了一個個非常小規模的服務，那麼就讓這個服務本身具備事務的屬性，叫事務性服務。這樣一個個小的事務性服務就像一個個小石頭一樣，可以裝到一個大的杯子裡，然後再設計一個分散式的提交協議，把這一個個小的事務繫結成一個大的業務事務。而這個服務也不僅是微服務，而其實是一個微交易，把每一個服務變成一個交易，再通過一個編排的框架，把每個交易變成一個大的整體服務。”程立用比較形象的語言解釋了現在被稱為螞蟻金服黑科技的分散式事務XTS (eXtended Transaction Service)的由來。
有了這個思路，當時支付寶技術團隊就開始去做了。克服的第一個難點是把已經有的交易服務、賬務服務等，變成一個個交易型服務，這個難點當時就突破了；第二個難點是要實現一個可擴充套件（Scalable）的框架，去編排海量的事務，那就是XTS。大概在2008年1月份，SOFA專案就上線了，上線以後至今不斷打磨，一直到現在還支撐螞蟻金服整個的業務交易。
齊心協力不斷解決問題 - SOFA 的演進
從第一代到眼下的第五代，SOFA的演進過程其實是支付寶從最早的一個大型的業務與IT交織在一起的單體系統，一邊拆金融業務系統（即後來的業務中臺）、一邊拆底層IT系統（即後來的資料中臺、計算中臺）的過程，在拆分的過程中還要解決新出現的可擴充套件性、一致性問題等各種問題，同時不斷應付每年都能擊穿系統極限的雙十一，還要把資料從原有系統一點一點“倒騰”到新系統裡、同時管理新增的海量資料，這樣一個極為複雜的過程是怎麼進行的？有趣的是，這個過程的附加值之一，就是在無意中完成了去“IOE”，因為從單體系統拆分到網際網路分散式系統，本身就是用PC伺服器機房代替昂貴IOE裝置的過程。
“整個過程可以說一路狂奔。”楊冰後來回憶整個過程。“‘蘿蔔’就這麼幾個，坑那麼多，根本就填不過來的狀態。每個中介軟體產品連‘一個蘿蔔一個坑’都做不到，很多‘蘿蔔’是放在兩個三個坑裡面的狀態，你就想有多挑戰了。其次，每一年都是翻一番的業務指標倒逼。整個團隊的狀態基本上是一年大促結束後，春節一過就開始密集準備下一年大促，一眨眼的功夫離雙十一就沒幾個月了，很多系統的技術改造可能要到6、7月份準備好，再全部升級上去，業務還在不斷變化，不停有新的想法冒出來，每年就是這麼個狀態，基本都是開發飛機就把發動機給升級上去了。
程立回憶，SOFA早期的開發是完全違背專案管理邏輯，在專案推進的過程中既有研發平臺又有研發上層的業務系統，相當於把很多風險都導在一個專案裡面一起做，SOFA第一代專案就是靠團隊齊心協力，每天都會遇到新問題、每天都要去解決各種問題，但大家背後有必勝信念而且非常擁抱變化，敢於在專案的中後期把前期架構決定全部推翻掉，再用一套新的架構替代。“所以到2008年那次賬務三期的釋出，那次原定釋出8個小時，後來我們釋出了17個小時，說明在專案釋出過程中，還是有很多問題沒有解決，但最後我們硬生生把這個專案給釋出下去，而且成功了，現在回想起來，其實是有一點後怕的。”程立笑說。
2008年之後，支付寶技術團隊開始確定一個原則，即所有的釋出不得停機，必須要確保專案釋出沒有風險。其次，要結束所有的研究型專案，技術研究要把技術問題解決了，再用到商業系統裡面去。而且從2008年開始，每個新技術都不會首先用到最核心的系統裡，而是會在相對邊緣的業務系統裡經過充分考驗以後，再用到核心系統裡。
在SOFA初期，可以看到做交易和賬務這兩個專案的時候，業務系統開發人員與技術平臺的開發人員是不分的，無論是程立還是胡喜，都是一會兒寫業務交易的程式碼，一會兒寫下面的技術平臺程式碼，工程師團隊也沒有嚴格區分。後來開始建立中介軟體團隊，楊冰基本上也是那個時候加入，分配一部分人專門研究底層技術，另一部分人專門寫上面的應用系統架構，慢慢開始變得越來越正規了，包括對於新技術上線過程的灰度和控制，也會做得更好。
楊冰回憶他在2009年以剛畢業的研究生身份加入支付寶團隊的時候，當時服務化拆分的過程是程立、胡喜親自參與，一邊對WebX系統做服務化拆分，一邊胡喜寫了SOFA框架的原型，楊冰與後面加入的小夥伴就幫助不斷完善SOFA。“當時我們還很初級，基本上是程立和胡喜帶著我們去實現他們構想出來完整一套思想。當時雖然服務化和SOA的概念很火，但業界的實踐遠沒有現在這麼豐富，很多實現機制都是摸著石頭過河。業務服務化拆分又是另外一條主線，當時主要是程立、胡喜、倪行軍（花名苗人鳳，支付寶第一代首席架構師，螞蟻金服支付寶事業群總裁）參與，這幾個人都是既寫框架程式碼和元件程式碼，又參與業務程式碼拆分。當時支付寶所有的業務都在演進，支付寶架構團隊一方面在業務邏輯拆分和技術架構拆分的過程中熟悉支付寶的業務，一方面在熟悉業務的基礎上思考如何從中抽象出可複用的程式碼、資料和框架，以更好的支援未來的業務。所以當時就是一邊在做業務和技術的人肉拆分，一邊又把拆分的部分挪到新的框架中去承載。整個過程不是設計好了再搞，而是一邊做一邊搞。”
XTS框架都是在那樣一個過程當中寫出來的。因為在原先集中式架構是不會出現事務一致性的問題，拆分以後就出現了這樣的問題。當問題出現以後，就一邊拆一邊解這個問題。當然，解決的時候也不是人為介入，而是構想出技術化的方案，甚至沉澱出來一套技術。那個時候，支付寶系統裡的Oracle資料庫還在用，小型機等高階傳統裝置都在用，支付寶的業務系統包括會員、交易等被拆分出來後，就直接跑在X86架構上，這不僅是物理形態和部署形態上的差異，更是由單體應用的開發模式變成SOA化的分散式開發模式，這就是從WebX到SOFA的演進過程。賬務系統是最後一個從支付寶拆分下來的系統，隨著賬務系統的拆分成功，IOE裝置也徹底從支付寶系統裡下線。
在整個支付寶架構的改造以及SOFA的發展過程中，關於中介軟體的基本構成和思想是有業界參照的，比如訊息中介軟體、資料中介軟體、事務中介軟體等，但SOFA技術團隊要做面向超大規模網際網路金融交易的分佈化改造，而其中的黑科技諸如單元化，則是被業務倒逼出來，完全沒有業界參考的實踐，“我們找到的一些論文，一些概念，一些類似的做法，但當時支付寶的體量已經很大了，沒有人確定這事兒真的能做成，而且是在金融這個高危的業務場景下”。
“套用螞蟻金服前CEO彭蕾的話，她曾提到過大家做的很多事情就是怎麼把馬雲的決定變成一個正確的決定，而我們在整個中介軟體工程實現過程中，也是類似的情況。比如SOFA3時代的合併部署，當時胡喜提出這個概念的時候，內部爭論非常大，大家都覺得這件事情不靠譜，而且很難做、非常複雜，阻力非常大。最難的事情，是說服團隊。但最後大家還是為能做成這件事情，併為公司節省下這多成本而感到驕傲”楊冰回憶。
為了解決新的挑戰，螞蟻金服的中介軟體技術團隊想了各種辦法。楊冰為單元化架構當中RPC呼叫設計的路由邏輯：對於各種業務系統，有的可以升級、有的可以改造、有的不行，那麼在RPC遠端服務呼叫時就會有五六種分支去決定到底是本地優先、還是要跨機房、還是要根據業務的分庫分表做路由等等。這個邏輯極其複雜，在於既有同構機房、又有異構機房，而異構機房又要把通訊收斂到一個代理，所以又會有代理的存在，導致非常複雜。而為了收管沒法升級的系統，甚至該系統的負責人都已經不在的情況，就用一個類似於Service Mesh技術代理，去“偽裝”這個服務。“整個架構是很漂亮的，但是工程實現中的每一個細節都很複雜，所有的設計都充滿了架構的平衡的智慧。我們在實現整個過程以後，再慢慢把完全沒有必要的三四個路由邏輯去掉，變成比較規整的模式。基本是這樣的過程，因為不能把支付寶停下來。”
負責過SOFA體系中訊息中介軟體的王磊（花名：文若）回憶，阿里從2008年開始辦雙十一，第一年只是試一下，所以沒有很大規模的宣傳，甚至連內部很多人都不知道。從2009年是開始支付寶和淘寶一起參與雙十一，當時宣傳淘寶商城裡面所有的商品都是半價，但是因為2008年時候對雙十一的力量並沒有清楚的認識，到2009年那一年的時候就突然出現了各種問題。王磊當時負責訊息中介軟體，內部叫做Message Broker，屬於訊息佇列：訊息從上游應用通過訊息中介軟體傳遞給下游的系統，包括當時還在使用的Oracle資料庫。“當時正在看這個活動的過程，甚至我們自己也在買東西的時候，突然DBA跑過來說要趕快對訊息進行限流，因為下游的資料庫馬上就要撐不住了，資料庫的日誌空間馬上就要耗光了，如果耗光就會導致資料庫宕機，再啟動起來就是幾個小時以後的事情。當時我們小組是三個人，以前從來沒有快速對訊息進行限流，最後就只能人工登入上游應用的伺服器上，然後在伺服器上敲命令做流量控制，一條一條的敲下去，最後保住了下游系統沒有被沖垮。那個時候很遺憾，因為不是靠訊息中介軟體去限流，實際上是把上游發訊息的應用‘殺’死了。後來，經過這件事情以後，我們就下定決心要做一件事情，就是叫做一鍵限流，在中介軟體層面對於訊息中心的一鍵限流能力，就是從那天開始建設的。”這樣的故事還有很多。“整個過程就像打怪升級，看到一個幹掉一個。”王磊的實踐，代表了整個SOFA團隊的工作狀態，也代表了SOFA與其它網際網路分散式中介軟體的最大不同——沉澱了支付寶/螞蟻金服十多年來，整個業務與IT體系的最佳共享實踐。
就是這樣，SOFA 的演進伴隨著支付寶整個架構的演進而發展，程立回憶，第一代SOFA比較簡單，只是搭了一個框架和模型讓系統可以執行，到後期系統執行中做了大量的優化，包括要解決通訊的效能、最高效的容災、異地容災架構的建設、單元化改造、LDC邏輯資料中心專案等，所有這些慢慢就沉澱在SOFA裡面。而SOFA則逐漸從解決分散式服務和分散式交易的問題，變成一個真正解決金融級系統構建的基礎架構問題，所以現在把SOFA改名，從原來的Service Oriented FabricArchitecture改為Scalable Open Financial Architecture：這個框架是可以真正解決金融級系統的異地多活的容災和擴充套件問題，而且SOFA的可擴充套件能力不僅是處理更多的交易，還可容納更多的業務，能夠讓幾千位工程師甚至未來上萬個工程師一起協同工作的可擴充套件架構；Open的意思是希望這個框架相對可以讓業務應用非常容易使用，又能與經典架構系統有機融合，SOFA框架未來不但可以編排螞蟻金服工程師自己寫的業務邏輯，而且可以編排合作伙伴的業務邏輯，成為一個完整的編排框架；Financial則意味著SOFA必須是具備金融級屬性，能真正實現金融級的一致性、可用性和穩定性。
跟上網際網路迭代速度 - SOFA 的設計
SOFA從第一代發展到第五代，是一個異常複雜而龐大的過程，程立總結SOFA的研發方法論和經驗時表示：在整個研發方法和流程上，螞蟻金服相對於來說是以網際網路的方式去做金融，因為螞蟻金服本身就是一個金融系統，在要求非常嚴格的同時，也希望有網際網路的迭代速度，在這個過程中沉澱下來的經驗。
首先，注重架構的治理。 螞蟻金服一直有一個架構師團隊，既有總架構師團隊，同時又把各個分域的架構師集合在一起，始終保持螞蟻金服的架構在一張圖上。螞蟻金服架構的迭代演進也非常清晰，從一代、二代、三代、四代到現在的第五代架構，都有非常清晰的演進階段，這是從治理層面進行頂層設計的結果。
第二，關注技術的風險。 螞蟻金服研發任何系統，要比其它網際網路公司多付出可能10%的努力，去保證系統風險的可控，所以螞蟻金服技術風險管控是嵌到流程裡面、控制在整個研發生命週期裡面，從而實現了非常好的控制。當然，螞蟻金服的研發效能團隊也會把控，讓研發人員儘量簡單、儘量智慧化。
第三，系統優化是在高度分佈化的前提下實現的。 螞蟻金服是比較少有的、幾千人工作在一條業務流程上面，最核心支付流程從前端到後端分了很多層、每層裡面有很多功能，在這個過程中能夠保證非常好的分佈和整合效率以及質量，就變得非常關鍵。所以從整個專案管理的需求、分析、分解，到每個團隊去實現，最後再做高效的整合、迭代釋出，有非常多經驗沉澱在研發部署運維平臺上。螞蟻金服的研發部署運維平臺經過多代的變化，有段時間也引進了IBM等供應商的整套方法和工具，用了兩年左右時間後發現完全不適合螞蟻金服工作方式和速度，所以轉向自研的平臺，並不斷輕量化。但也不是外界的開源模式，因為也不適用於螞蟻金服的情況。
第四，螞蟻金服中介軟體團隊的另一個共識，Design for failure，即假定在任何情況下底層都有不可靠的風險存在。 對金融IT系統來說，任何的底層硬體臨時故障或網路抖動都有可能被放大到資金損失或整體服務穩定性層面。對於支付寶這樣體量的網際網路應用，從設計之初就把高可靠、高可用、高效能的能力要轉到中介軟體層和資料庫層去保證。下面的IaaS必須要簡單，就是允許底層硬體可以掛掉，掛掉以後由中介軟體和資料庫層負責。為什麼會這麼做？這是由業務的容忍程度決定的，沒法沉到底下的IaaS層，但也沒有必要讓每個寫業務程式碼的人都自己編寫一套程式碼，所以就沉澱到中介軟體層。
中介軟體會被所有人用到、會影響所有的系統，像螞蟻金服現在有幾千個系統和上萬個微服務、幾千號研發人員，怎麼能使在中介軟體層做的每一項工作都能使整體架構都能平滑升級，而不要讓業務系統受影響，怎麼建立跟其他開發人員之間的連線，如何平衡效率和運維，這是中介軟體的挑戰。
被問到SOFA 跟別的微服務平臺有什麼不同，楊冰舉了個例子“如果有兩套架構在頂層設計的時候，一套將平衡傾向了「成本最優」，一套則傾向了「風險最小」，在實現過程中就會有千百次設計決策會依據這個大原則做出「架構平衡」，到最後出來的架構會完全不同，就像 CAP 理論中的平衡一樣，什麼樣的業務決定著會孵化出什麼樣的技術，技術最終還是為業務服務的。
給年輕工程師的一些建議 && 歡迎加入我們：
2018 GIAC大會期間，螞蟻金服楊冰，黃挺等講師面向華南技術社群做了《數字金融時代的雲原生架構轉型路徑》和《從傳統服務化走向Service Mesh》等演講，就此機會，高可用架構社群編輯魏佳和王淵命對螞蟻金服技術團隊的楊冰和黃挺進行的訪談。
在訪談中提到工程師的職業發展，楊冰給出了自己的建議
楊冰：其實這方面的雞湯是很多的，我就說一下多自己個人的感受，因為這個也不算我個人原創的，我是看到一些東西，結合我自己的體會。前一段時間摩拜的創始人後來套現離開了，發了一篇比較負面的文章，說你的同齡人現在在幹嗎什麼的。後來又有了一篇比較正面的文章，我覺得分析得挺好的
第一個，年輕人在做選擇的時候，要看點線面，首先選擇比努力更重要 ，怎麼選擇呢？我面了很多的年輕人，大家非常看眼前的。我分享一下，一個是看微觀，一個是看巨集觀。看巨集觀是說，你在選擇的時候，你要把自己投在一個大面上是好的，有機會讓你成為億萬富翁的或者是欣欣向榮這個方向去發展的，你行業要看得準，方向要看得準。第二個，你看線的時候，你要看這幾個賽道當中有幾家公司，你削尖腦袋也要前去，或者是儘量優先去考慮，而不是說隨便找一個就可以了。第三個，再到點是指微觀的，有可能你在面上OK，線上面不是最佳，在點上面可能要去做一些平衡。你可以在年輕的時候帶著一個向前看的心，多選擇到一個投資自己或者是自己能夠學到更多東西的地方去，差不多就是線、面選好之後，在點上做平衡。比如說有一家公司很好，在線上明顯優於另外一家公司的，但是那個團隊沒有特別牛的人，只是說這家公司很好，你進去可能會帶著這家公司的光環，但是你學不到很好的東西。光環沒有了之後，你原先可以做的事情，在你到了另外一家公司之後你是做不了的。所以你寧可去選擇大方向正確，弱一點，但是那邊有一個牛人或者說你能夠成長的公司。我覺得這個就要看自己在巨集觀和微觀上的平衡了。
第二個，靠譜比聰明更重要一點。 我在看團隊的一些人，包括養，包括髮現走得快的⼀些人，都是一些站在比較高的角度或者是完成事情比較靠譜的人。改變環境其實是挺難的，如果說你可以改變自己來適應這個環境，招數不一樣的話，你在哪裡都可以做好。如果你覺得這個公司，這個廟已經裝不下你，你自己再怎麼變，這個能量已經到了天花板的話，你就換一個地方。你一定要想辦法去改變自己，去為這件事情負責。
第三個，如果說年輕人的話，我們面試的時候還會比較看穩定性。 雖然說剛剛講了那麼多，但是其實如果說大家無論是做業務還是什麼，其實可能3年為期，很多東西一年、兩年是很難有沉澱的。你一旦從一個地方換到另外一個地方，人際關係要重新建立，信任關係要重新建立，你的機會要重新去獲取。你再不斷重複，在新的地方去證明自己就會消耗掉很大力量，你就很難再往上全走了。所以他在深度和廣度上就會出現一個瓶頸。我們會在看人的時候，如果真的是招比較有潛力或者是比較好的人才的話，不僅是看穩定度和忠誠度的問題，也是在看他是否有耐心沉澱下來在這個領域裡深耕一段時間的。我個人結合一些東西，我覺得這三個點是比較重要的。
作為工程師你有什麼難忘的故事麼？
歡迎留言與我們分享
ofollow,noindex"> http:// weixin.qq.com/r/YymEnET E8xmMrQD-93xx (二維碼自動識別)