創業感悟：工程師的自我突破

前言

第一次寫非技術分享的話題，而促使我提筆的動力源自去巴黎參加Openstack Kilo Design Summit大會之行，由於我從外國工程師的身上深深感覺到了他們對於技術的執着。在本文中，我想探討的是如何實現工程師的自我突破，由於初入茅廬的工程師更關心的是如何從一個菜鳥成長爲某個領域的專家。那麼這個關鍵的突破點在哪？

 

Emilien的故事

故事從一年前提及，我正在參與Puppet-Openstack社區開發和代碼審查，來了一位名叫Emilien Macchi的新面孔，他持續地向社區提交了大量高質量的patch，我開始關注他，瞭解到他是eNovance公司(年初被RedHat收購)的一名Openstack開發工程師。他很是積極主動，我和他在Gerrit和IRC上有過許多交流。後來他加了個人Linkedin，因而我隨意瞄了一眼他的profile，第一印象是驚訝：

1.  翔實的簡歷：從他的我的經歷介紹中，任何人均可以迅速瞭解他從07年到14年專業上的經歷，大學上過的課程，實習經歷，工做過的公司等等全部和專業技能相關的經歷，參與過的項目，擁有的證書，以及同事和上司對他工做上的評價一一具有;
2.  最讓我吃驚的是，這哥們的先前工做經驗是作網絡設備維護的，有一堆網絡相關的證書。

他是在12年末纔開始接觸Openstack，13年開始專一Puppet和Openstack相關的自動化部署工做。我記得在HongKong Design Summit上，他並無參與太多的討論，而在時隔一年後，在Paris的Design Summit上，他不只主持會議的Agenda，更重要的是他在社區作出了不少重量級的貢獻，雖然他的語速很輕緩，但他的發言卻變得擲地有聲。

一個徹底沒有Openstack項目經驗，一個徹底沒有Python和Puppet語言基礎的網絡工程師如何在這麼短的時間內實現自我突破？

會議當天恰好是他生日，會後我送給他一個從國內帶去的小禮物，我好奇地問他：Hey, How do you make it ?

他靦腆地對我笑：I write puppet codes except eating and sleeping.

Wow.  我和邊上的人都在驚歎。

他走後，我站在法國國際會議中心的Room 101門口思考了很久。

故事到此就結束了，細節可能不止這些，但這並非本文的重點。我想就此去談談工程師如何去擺脫固定思惟的束縛，突破自我。

圖1:  Emilien Macchi在主持Puppet-Openstack Kilo Design Summit

態度決定一切

有句老話叫做：態度決定一切，你的態度如何，在必定程度上已決定你是失敗仍是成功。我以爲這點在作技術時體現得淋漓盡致，就以Openstack項目爲例，在其中發現一個bug，其實不是難事。那麼在發現某個Openstack服務的bug時，不一樣的工程師有着不一樣的態度：有的人隨意Google一下找到解決方法而後接着幹活，有的人嘗試閱讀源碼後去自行修復bug，有的人會把寫好的bugfix嘗試推送到社區的upstream去。咱們都會以工做太忙爲理由，只以問題的解決做爲目的驅動，從不去細究問題的源頭。所以，這就致使了若干年後，有的工程師還只在原地踏步，有的已經不只深刻掌握源碼，還能快速地作二次開發，還有的人不只養成了良好的代碼風格，還能積極地參與到upstream的開發中去。

記得在剛進入Sina雲計算部門的時候，團隊協做平臺的副標題是28號加粗的一行文字：Develop is not easy。雖然不知道是哪位大牛寫的，直到如今我仍然記憶猶新。Develop不光狹義地指開發，而是囊括了全部的技術崗位，咱們要時刻清晰地認識到把事情作好並不是易事。這裏不只指技術自己，還涉及許多相關的細節，這些細節經常被多數工程師忽略，而正是這些細節才能體現出一個工程師的閃光點。

我常使用業務素質一詞來評論工程師：這個工程師的業務素質很高，指的是他不只在專業技能上出類拔萃，更重要的是在作事上很是認真，事無鉅細，小到代碼格式，註釋，變量名稱，代碼提交信息，文檔等每一個細節都能體現出認真兩字有多麼可貴難得。凡是作過技術的朋友應該都會有所共鳴，而且從腦海中立馬浮現出那些閃閃發光的人名來。

 

保持努力

我不想在努力這一點上舉例來講明努力是多重要的因素，由於咱們從小就開始灌輸努力的重要性。我只想強調在正確技術突破的道路上，你必須不停地更新本身的知識和技能，才能越走越遠。

我認識的另外一位朋友，社區核心開發者，我詢問他聖誕節打算去哪裏過，他給個人回答是：I'm not going anywhere, just writing codes at home. 因此，那些外國工程師之因此如此牛逼，並不是他們生來如此，而是他們的不懈努力。

因此請必定要作到保持這份幹勁，而且時不時買些心靈雞湯激勵一下本身，或者按老羅所說：噁心一下本身，保持大腦亢奮。如今我腦子裏只要一想到Emilien的那句「I write puppet codes except eating and sleeping「，就開始失眠，這雞血的劑量使得個人生物鐘又延時了一個小時。

 

充滿熱情

在我認識的技術人中，作得出色的人大都有一個相同特色：富有激情，他們總以一種積極主動的態度去對待生活和工做。我相信全部剛入IT行業的同窗們都是滿懷對於將來的憧憬，只是這種彌足珍貴的熱量很容易被許多外界的負面因素慢慢磨滅：工做單調乏味，生活壓力太大…但不要所以就把你的熱情埋藏起來，一旦你習慣了埋藏，你將是一個了無生氣的人。若是你失去了對於追逐技術的熱枕，那麼很難在技術的道路上有所突破。激情，在不少時候，每每能點燃咱們創新的本能。有了激情就有了不竭的動力，你的心裏同時也會變化，愈加有信心，別人也會逐漸認識到你不同凡響的價值。

 

善於溝通

工程師們經常把精力放在編碼上，而不多去關注本身溝通能力的培養。我曾遇到過一些大牛，有的不屑寫文檔，有的不會用git等團隊協做工具，還有的連話都說不清。不可否認他們在本身各自的領域中耕耘得很深，可是在分工如此細化的時代，大多數項目都須要團隊協做才能完成，所以溝通是沒法避免的：產品經理和設計師之間的溝通，後端組和前端組之間的溝通，研發部和運維部之間的溝通…爲何有時候對方聽不明白咱們想表達的意思，致使跨部門的工做步履維艱。

TED上有個有趣的演講題目叫做：怎麼說話人們才聽，聲音學專家朱利安給咱們上了生動的一課，列舉了爲何沒人願意聽咱們說話。所以，咱們在與別人打交道的時候，咱們必須明白對方在想什麼，也要讓對方明白咱們想表達什麼。

除此以外，對於工程師而言，溝通能力並不侷限在語言溝通上，還有在協同開發時的溝通，例如對於使用git作版本控制的項目，如果沒有掌握好git工做流，溝通將異常困難。代碼審查系統上的交互，也是溝通方式的一種，你須要理解他人給你的意見，你可以向他人表達清楚你的意思。

 

瞭解本身，把握方向

在大學課堂裏，工做面試和入職培訓時經常能聽到一個詞：職業規劃，就是對職業生涯乃至人生進行持續的系統的計劃過程，它包括職業定位、目標設定、通道設計三部份內容。職業定位主要是指：一是肯定你是誰，你適合作什麼工做；二是告訴別人你是誰，你擅長作什麼工做。人生是應該有一個規劃，這樣能夠對於將來設立一個指望，明白前進的方向。但這類職業規範每每過猶不及，覬覦經過把本身的人生畫在紙上，而後按圖施工的想法是不切實際的。仔細想一想你真的能在剛踏入社會時就能真正瞭解你擅長作什麼工做，適合作什麼工做？

喬幫主說過一句話：「若是你瞭解本身，可以明白地作本身，職業規劃如同虛設」。因此，你只要清楚本身想要什麼，而後朝着這個目標去作本身想作的事，就能夠了，爲何要給人生設限？何不嘗試一下跨界？

前文中我談到了一個網絡工程師的華麗轉身，接着聊一聊咱們運維團隊從UnitedStack成立伊始到如今發生的故事。

從理想國際大廈走出來開始創業的第一天，一個現實擺在了咱們面前：採購服務器和交換機，選擇IDC。在新浪，服務器選型有專門的部門作，採購硬件有專門的部門作，交換機配置有相應的部門作，服務器上架有相應的部門去作，咱們只有基礎運維和業務運維的經驗，原先所擅長的只是一個狹小的領域…

看來惟有本身動手，才能豐衣足食，咱們着手開始調研服務器的選型，交換機的配置，IDC的選擇。經過不斷的摸索，如今咱們制定了一套成熟的機制去根據不一樣業務來選型服務器，造成了一套完善的網絡拓撲去鏈接分佈在全國多個機房的公有云和託管雲集羣，也有了穩定的IDC合做夥伴。

許多朋友可能還記得UnitedStack去年發佈的UOS 1.0發行版，其後端代碼徹底由運維組編寫。當時，咱們轉身從運維變成研發，調研了主流的StackOps, Fuel Web，根據產品設計的需求，開發了一套由Python+Puppet編寫的後端代碼，實現了Openstack集羣的自動化部署；內部的持續集成&持續發佈系統也全由運維組負責，咱們根據研發工程師的實際需求對持續集成工具鏈作了屢次整合以匹配整個研發體系的平常工做；14年初公司業務開始涉足公有云和託管雲，咱們和研發部門共同設計了公有云，託管雲的總體架構。因爲業務量的急劇上升，咱們着手開發了資產管理，節點管理等多套運維平臺。同時，和通常的運維團隊不一樣，咱們還負責虛擬服務器的鏡像自動化製做和維護，參與Openstack最龐大的計算項目Nova的定製開發並一直保持與社區upstream同步，參與puppet-openstack社區的開發，一直在向社區貢獻源碼。

由於咱們清楚所作的一切都是爲了能把「事」作成，所以作什麼並不重要。並且經過這兩年的磨練，咱們在技術上最大的收穫在於你們的視野再也不侷限於各自的一畝三分地裏，在面對新問題時，能夠站在不一樣的角度去思考，這種在大公司裏沒法得到的經驗就顯得彌足珍貴。所以瞭解你本身，明白你本身想要什麼，而後把握好方向。

 

全面 vs. 專精

以部署系統爲例，早先的部署系統徹底爲公有云打造，要求作到細粒度控制，但操做起來比較繁瑣；而如今要求同時管理公有云和數量龐大的託管雲集羣，而且每家在架構上都會有所差別，這就要求部署邏輯解耦，靈活可變，支持不一樣環境，不一樣拓撲，不一樣軟件棧，還要解放實施人員，減小部署時間。

但因爲每一個人的精力都被分散到多個領域，所以很難集中精力把部署系統作好，因而咱們開始從多面手向專注轉變。也正是由於這兩年咱們什麼都作，猛然一回頭你們有些迷茫：本身什麼都懂，但又什麼都作不精。那麼問題來了，學技術究竟是…究竟是精通一種仍是全面發展好？

Take it easy，在技術的道路上看似會有兩種大相徑庭的方向：橫向擴展和縱向深刻。橫向的猶如瑞士軍刀，十八般武藝樣樣精通；縱向的是削鐵如泥的倚天劍，倚天不出，誰與爭鋒。橫向擴展能夠拓寬你的視野，讓你再也不侷限在某一種技術中，並也給你的將來多了一種可能；而縱向擴展，可使用你深入理解一項技術的細節，讓你靜下來思考問題的本質，你可能會驚訝地發現某些原理都是相通的。這兩個方向都沒有對與錯，發展到必定程度都會相互溶合，就比如中國佛家禪修的南頓北漸，其實到了最後，漸悟與頓悟是同樣的，頓由漸中來。

不過哪一個在前，哪一個在後，我我的認爲仍是先作到對某一個領域有較深的理解和掌握後，進而去學習其餘方向，這個道理就如同精通一門語言的程序員再去學習其餘語言時就能駕輕熟路。

關於這兩點的結合，我有很深的印象，如上面提到的狀況，剛開始的時候，運維相關的事情繁雜，每一個人都得是多面手，要去cover多個領域，也由於此只能把每件事情作好而沒法作精。在集羣規模不斷擴大和業務量的增加後，原先不是問題的地方開始暴露出來，這就有精通該領域的工程師來獨擋一面。這是一個自我學習，自我改變的過程，也是自我突破的關鍵。

 

結尾

在互聯網的浪潮下，產品在快速地推陳出新，技術在不停地推陳出新，在這種大環境下，人心趨於浮躁，每每很難靜下心專心作技術，惟有耐得住寂寞，才守得住繁華。

但願諸位在面對機遇和挑戰時，可以發掘自身的瓶頸，實現自個人突破。