技術文化和慘淡命運：懷念中國雅虎(2)

　　國內大部分互聯網公司都是沒有太多技術積累的，因為大部分產品的開發都只追求開發速度，并不會特別追求技術上的極致，就更不要提文檔這種東西了。也正因為如此，從中國雅虎出來看到其它公司的知識庫的時候總有不過癮的感覺，可能也只有像 Google, 微軟和 Facebook 這樣的公司才會有像 Yahoo! 那樣的知識庫吧。在和之前一些同事吃飯聊天的時候，大家也總是會懷念那個無所不包完全開放的 Twiki ，好像少了一個忠實的朋友一樣。我們由衷地尊敬那些在完成工作之余還愿意總結項目經驗并花時間寫 Twiki 的工程師們。

　　四、完善的流程

　　第一次參與項目開發的時候，我的 Leader 領了一個 MM 過來說：“這位是項目的 QA 負責人”，我當時愣了一下：“呃…… QA 是做什么的?” 盡管在大學里我也在實驗室做過一些項目，但那些項目基本上都是我自己負責所有的事情，完全沒有分工和流程的概念，所以也不知道 QA 是負責產品測試工作的。進入中國雅虎之后，我才第一次接觸到商業產品的開發流程，不過由于那個時候中國雅虎已經半死不活，我也沒有受到有關流程的入職培訓，以至于在做了好幾個項目之后才真正熟悉了完整的流程。

　　中國雅虎的開發流程沿襲了 Yahoo! 的開發流程，乍看之下很平常，對于已經熟悉的工程師來說還顯得枯燥，但后來我特別留心了這套流程之后，非常驚奇于它的嚴謹和高效，所以這里要詳細說明一下。Yahoo! 的內部生產線分為三個相互獨立的環境：開發環境、測試環境和生產環境(即線上環境)。這三個環境雖然獨立，但它們的配置都會盡量保持一致，這樣就可以保證開發完成的產品不會因為環境不同而出現問題。在開發的時候，我們會在開發環境中搭建虛擬環境，開發完畢之后開發工程師會自己在虛擬環境里面測試，保證沒有大的問題，然后就會把所有相關文件打包上傳到雅虎全球統一放置產品包的地方。上傳完畢之后，就會發郵件通知 QA 部門相關人員，郵件內容里面要寫明產品在測試環境的部署步驟：需要安裝哪些包、是否需要修改數據庫等等。然后 QA 就會開始測試，如果發現 BUG 就會寫到 bugzilla/' target='_blank'>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 一并改掉，加班也是頗有興致，不是很能明白為什么網上大部分程序員討厭加班討厭得要死?，F在我明白了。

　　五、自動化工具

　　工欲善其事，必先利其器。如果沒有那么多好用的自動化工具，那么 Yahoo! 的流程就不可能如此完善。Yahoo! 內部有很多非常好用的工具，而且這些工具都有非常齊全的文檔，也可以在 Twiki 上找到不少相關資料。這些工具之所以在 Yahoo! 會起到那么大的作用，是因為 Yahoo! 全球所有的技術團隊都在使用它們，Yahoo! 所有的服務器上也是默認安裝了這些工具。這些工具就形成了一套全球 Yahoo! 工程師通用的話語體系，可以想象它們幫助 Yahoo! 節省了多少溝通成本。

　　由于考慮到服務器的安全問題，Yahoo! 的這些工具的使用方法是對外保密的，這里我只簡單說一下 Yinst 這款工具的強大。假如要把軟件包 example_1_1_0.tar.gz 部署到 a1.yahoo.com ~ a10.yahoo.com ，那么只需要下面這樣一行命令：

原文轉自：http://blogread.cn/it/article/2703?f=wb