中國雅虎前員工講述雅虎的工程師文化
51CTO編者前言：本篇文章節選自一位中國雅虎前員工的博客：《技術文化和慘淡命運——懷念中國雅虎》。顧名思義，全文講述的是中國雅虎的技術文化 + 慘淡命運。慘淡命運先不提了，作者對于中國雅虎的技術文化的描寫，對于各個領域的IT工程師——前端開發、測試、運維——都是有所啟發的。雅虎畢竟是老牌互聯網公司，其中的很多技術方法和流程，都很有了解的價值。下面我們就從原文中節選了“技術文化”的部分。如果你是一位系統運維，可能對雅虎內部的Linux文化、知識庫、產品上線流程、以及自動化工具的部分都會感興趣。
中國雅虎***的一個地方就是它和 Yahoo 全球共享同一個技術平臺，那是一個有十幾年歷史的技術平臺。Yahoo 的技術文化不如 Google 的工程師文化那么有名，但 Yahoo 在相當長的一段時間內都是互聯網的旗幟，吸引了全球大量的技術牛人加入，Yahoo 的技術平臺就是他們的知識、經驗和心血日積月累的成果。盡管阿里巴巴收購了中國雅虎，但是在技術方面并沒有對中國雅虎做出太大的改造（幸好沒有改造），所以就工程師來說，每天更多接觸到的還是 Yahoo 的東西，而不是阿里巴巴的東西，對我影響***的也正是這些東西。
一、Linux 和開源文化
之前一個中國雅虎的同事，他是工作了幾年之后才來中國雅虎，有一次他說：“雅虎是我見過的最尊重 Linux 的一家公司”。什么叫做尊重 Linux 呢 ？ 不是在服務器上裝個 Linux 跑 Apache 就叫做尊重 Linux 。在雅虎很多同事日常都使用 Linux 操作系統辦公，即使有一些人使用 Windows, 也都是使用 pietty 或者 Xshell 等工具遠程連接到開發機器上使用 VIM 做開發。不只是日常工作，在雅虎全球的技術體系中，產品的上線和發布也都借鑒了 Linux 包管理的方式：所有的產品都會被打成包放在一個專門的服務器上，產品的部署和升級就變成了簡單的裝包操作，絕對不會出現***上線的時候文件路徑出錯等低級問題。Yahoo 的技術平臺是深深扎根于 Linux 和開源文化的。
大型互聯網公司一般都會使用開源的產品，同時也向社區貢獻代碼。Google 和 Facebook 經常將自己研發的成熟產品開源，Yahoo 當然也不例外。而且 Yahoo 不僅僅給社區貢獻代碼，它在設計方面也擁抱了開源文化，將多年研究總結的設計模式庫共享了出來。在 Yahoo 內部，很多代碼都是存放在 CVS 里面的，并沒有限制讀的權限，任何員工都可以查看里面的代碼，這對于那些小團隊內部代碼都不敢共享防員工如防賊的公司來說應該是非常不可思議的。另外， Yahoo 的工程師也經常出現在各種技術會議上，分享自己項目的架構、流程和經驗。雖然這些更多都是 Yahoo 全球技術團隊做的事情，但是對于他們那種開放共享的精神我們是非常認同并且向往的，你會覺得做一個工程師很自豪，而不會覺得自己是民工、做技術沒前途。這種認同感和成就感乍看上去沒什么，但實際上它決定了你對技術的追求和態度，也會影響你以后在職業上的選擇。
二、濃厚的技術氛圍
雖然2008年的時候中國雅虎已經被折騰得快不像樣了（這點后面細說），不過那個時候還是有濃厚的技術氛圍的。讓我印象深刻的一件事情是 Google Chrome 瀏覽器剛發布的時候，大家都立刻下載下來使用，但由于公司內網的一些問題無法打開網頁。當我正打算把 Chrome 卸載了的時候，忽然發現公司郵件列表里面已經有人發郵件給出了詳細的解決方案。從這件小事可以看出公司大部分工程師都不是那種只知道完成工作的人，而是隨時關注新技術和業界動態的人。當時中國雅虎還是有很多牛人沒有離開，大家也喜歡在郵件列表里面談論技術，經常能看到精彩的討論和解答。最讓我興奮的是，無論我遇到什么技術問題都不用慌張，即使無法 Google 到答案也可以從同事那里獲取到幫助，而且大家也愿意回答技術問題，這對于我這樣一個基礎很差技術又爛的菜鳥來說真是天大的福氣。
中國雅虎還有做技術分享的文化，如果有哪位同事想要分享一下最近學習到的技術，就可以自己預訂一個會議室然后向所有的工程師發送會議邀請，有時候還會有一系列非常系統的課程，我就參加過長達十幾個課時的 UED 培訓，完全改變了我對 Web Develop 的認識。很多公司應該都鼓勵員工做技術分享，但在中國雅虎幾乎每次技術分享都會把會議室坐的滿滿當當，可見大部分工程師都還是想要不斷提高自己的技術能力。直到離開雅虎之后我才明白這種普遍的學習熱情有多么難得。我想，業界之所以到處流傳著“程序員做到30歲***轉管理”之類的忠告，應該就是因為大部分公司都缺乏這種良好的技術氛圍吧。
三、龐大的知識庫
入職的前幾天，我每天的工作就是看文檔，不是類似“PHP技術手冊”那種文檔，而是一些 Yahoo 內部的工具手冊。Yahoo 內部的文檔非常齊全和詳細，光是 Yinst 這款工具的使用手冊就長達幾十頁。Yahoo 內部是用 Twiki 做知識管理的，這個知識庫經過十多年的積累已經非常龐大，從入門到提高，從 PHP 到 C ，從前端到后端……應有盡有，而且幾乎 Yahoo 全球所有子公司的技術資料都是開放瀏覽的，沒有任何亂七八糟的權限設置和保密限制。有這么一個寶藏在，再加上好的學習氛圍，如果你想要提高自己的能力的話，總是可以提高。當初我想從 PHP 工程師轉做 Web Developer 的時候，就先把 Twiki 上 UED 部門的所有資料看了一遍，受益匪淺。
國內大部分互聯網公司都是沒有太多技術積累的，因為大部分產品的開發都只追求開發速度，并不會特別追求技術上的***，就更不要提文檔這種東西了。也正因為如此，從中國雅虎出來看到其它公司的知識庫的時候總有不過癮的感覺，可能也只有像 Google, 微軟和 Facebook 這樣的公司才會有像 Yahoo 那樣的知識庫吧。在和之前一些同事吃飯聊天的時候，大家也總是會懷念那個無所不包完全開放的 Twiki ，好像少了一個忠實的朋友一樣。我們由衷地尊敬那些在完成工作之余還愿意總結項目經驗并花時間寫 Twiki 的工程師們。
四、完善的流程
***次參與項目開發的時候，我的 Leader 領了一個 MM 過來說：“這位是項目的 QA 負責人”，我當時愣了一下：“呃…… QA 是做什么的？” 盡管在大學里我也在實驗室做過一些項目，但那些項目基本上都是我自己負責所有的事情，完全沒有分工和流程的概念，所以也不知道 QA 是負責產品測試工作的。進入中國雅虎之后，我才***次接觸到商業產品的開發流程，不過由于那個時候中國雅虎已經半死不活，我也沒有受到有關流程的入職培訓，以至于在做了好幾個項目之后才真正熟悉了完整的流程。
中國雅虎的開發流程沿襲了 Yahoo 的開發流程，乍看之下很平常，對于已經熟悉的工程師來說還顯得枯燥，但后來我特別留心了這套流程之后，非常驚奇于它的嚴謹和高效，所以這里要詳細說明一下。Yahoo 的內部生產線分為三個相互獨立的環境：開發環境、測試環境和生產環境（即線上環境）。這三個環境雖然獨立，但它們的配置都會盡量保持一致，這樣就可以保證開發完成的產品不會因為環境不同而出現問題。在開發的時候，我們會在開發環境中搭建虛擬環境，開發完畢之后開發工程師會自己在虛擬環境里面測試，保證沒有大的問題，然后就會把所有相關文件打包上傳到雅虎全球統一放置產品包的地方。上傳完畢之后，就會發郵件通知 QA 部門相關人員，郵件內容里面要寫明產品在測試環境的部署步驟：需要安裝哪些包、是否需要修改數據庫等等。然后 QA 就會開始測試，如果發現 BUG 就會寫到 Bugzilla 中，指派給相應的開發工程師，開發工程師就會在開發環境中定位BUG并修正，修正一些BUG之后就會再次打包升級產品的版本，然后QA 會將新的軟件包部署到測試環境驗證之前的 BUG 并報告新的 BUG 。整個測試過程中可能要發布好多個版本，直到所有 BUG 被修正為止。修正完畢所有的 BUG 之后，開發工程師就會填寫上線申請，Ops 看到申請之后就會安排一個時間把產品部署到生產環境。一般來說，生產環境不止會有一臺機器，所以 Ops 會先從生產環境摘下一臺機器部署，部署完畢之后會告知 QA 和開發工程師，然后 QA 和開發工程師就會修改 Hosts 文件，配置域名指向那臺機器進行線上的測試，如果測試沒有問題，那么就會把軟件包部署到生產環境中所有的機器上，完成上線；否則就進行回滾，取消這次上線，也不會影響到線上的用戶。
整個流程大概就是這樣，但是要特別注意的是以下幾點：1. 開發工程師只能接觸開發環境。他所能做的就是在開發環境中開發、改 BUG 和打包上傳。如果他去測試環境中修改 BUG，就很有可能忘記修改開發環境中的相應代碼，這可能會導致產品測試通過但是上線之后卻發現大的問題。 2. 產品“封版”之后就不可以做任何改動，如果有改動，即使只改動了一點所有功能也要重新測試一遍。所有的 BUG 都修改完畢之后的那個版本就會進行“封版”，那就標志著這個產品隨時可以準備上線了。如果真的發現了新的 BUG 要修改的話，那么修改之后就需要重新打包重新走一遍完整的測試流程，只有這樣才能夠保證就算修改代碼過程中引入了新的 BUG 也不會被遺漏。 3. 上線手冊要詳細。開發工程師要詳細寫明每一個步驟，不只是說明性的文字，還要把具體的安裝和修改命令完整地放上去，如果寫得好的話，那么 Ops 的同事只需要把上線手冊里面的命令逐行復制到服務器上運行就可以完成上線。
這樣的流程有什么好處呢？ 首先，它***地降低了上線風險。因為開發工程師不能接觸到測試環境，只能打包讓QA測試，所以完整經過測試的產品上線之后基本不會有什么問題，況且上線的時候我們也要先部署到一臺機器上進行測試之后才會決定是否上線，即使上線不成功也可以在不影響用戶的情況下回滾。中國雅虎的上線極少會出現問題，很多時候我們上線到半夜只是因為那個時間段用戶訪問量最小，而不是說焦頭爛額地忙活幾個小時一直到半夜才上線成功。其次，它使得各個部門職責分明。開發工程師和 QA 通過 Bugzilla 溝通，和 Ops 通過上線手冊溝通，因為溝通渠道唯一而且清晰，所以就可以完全責任到人，出了問題也很容易定位到具體環節。比如說，如果產品測試通過之后在上線的時候出現了問題，那么基本就可以確定是 Ops 操作失誤或者上線手冊沒有寫好。職責分明之后很多事情也變得有條理，大家就可以各司其職、專注本職工作并且合作愉快，開會的時候也可以明確知道需要哪些人參加。
完善、清晰的流程從根本上解決了一些問題，創建了一個非常好的環境，這樣我們就可以把心思都放在如何開發和測試上面，而不用擔心諸如“如何上線才能不出錯”等瑣碎的事情。所以盡管中國雅虎的高層那么不靠譜，我工作得還是很開心，因為這個流程保證了管理層再怎么亂開發也不會亂。記得那時候很喜歡改 BUG ，有時候改得興起會把之前版本遺留的 miss BUG 一并改掉，加班也是頗有興致，不是很能明白為什么網上大部分程序員討厭加班討厭得要死。現在我明白了。
五、自動化工具
工欲善其事，必先利其器。如果沒有那么多好用的自動化工具，那么 Yahoo 的流程就不可能如此完善。Yahoo 內部有很多非常好用的工具，而且這些工具都有非常齊全的文檔，也可以在 Twiki 上找到不少相關資料。這些工具之所以在 Yahoo 會起到那么大的作用，是因為 Yahoo 全球所有的技術團隊都在使用它們，Yahoo 所有的服務器上也是默認安裝了這些工具。這些工具就形成了一套全球 Yahoo 工程師通用的話語體系，可以想象它們幫助 Yahoo 節省了多少溝通成本。
由于考慮到服務器的安全問題，Yahoo 的這些工具的使用方法是對外保密的，這里我只簡單說一下 Yinst 這款工具的強大。假如要把軟件包 example_1_1_0.tar.gz 部署到 a1.yahoo.com ~ a10.yahoo.com ，那么只需要下面這樣一行命令：
yinst install example_1_1_0.tar.gz -h a[1-10].yahoo.com
就可以完成整個上線過程。由于好奇的緣故，在上線的時候我比較喜歡跑到 Ops 那邊看他們是如何操作的，然后發現其實他們在上線過程中執行的命令很少。因為工具好用，所以產品極少因為 Ops 這個環節出現問題，上線就變成一件比較輕松的事情。
中國雅虎的產品和業務確實不好，搜索不如百度，新聞不如三大門戶，“雅虎助手”是人人皆知的流氓軟件，郵箱也出過丑聞，而且被 Gmail 和 QQ 郵箱遠遠拋在后面。中國雅虎最廣為人知的也都是這些不光彩的事情，但這里我想讓很多人知道，對于一個對技術還有追求的工程師來說，當時的中國雅虎真的是一個很好的工作環境。至少對于我自己來講，我從 Yahoo 學到了太多太多的好東西，而且這些東西還只是 Yahoo 精華中的一小部分，如果不是阿里巴巴集團戰略調整，我一定會在中國雅虎多呆兩年。
編者后記：原文后面還有很長的篇幅講述中國雅虎的死亡，如果感興趣，可以到原文觀看：
http://www.zhuoqun.net/html/y2010/1535.html
現在我們說起互聯網公司、世界***的運維技術，想到的大多是Google、Facebook，以及阿里巴巴等；但是真正了解才發現，老牌的互聯網企業的技術文化，的確有其獨到之處。現在國內把互聯網僅僅當作工具的環境，對于技術人而言的確是極大的悲哀。平心而論，相對于國內大多數企業而言，其實阿里巴巴在技術文化的營造上做的已經好很多了。整個市場環境的轉變，一個尊敬技術的大環境，還需要很長時間來培養。
【編輯推薦】
