從QA到EP(2)

　　第二個是教，就是教技術團隊的其他成員，如何測試自己的程序，如何構造環境、構造數據，如何部署和運維自己的產品。這里的自己做，并不是回到蠻荒時期，例如創業初期只有一個程序員的時候，他當然是自己開發自己測試自己部署，但我們到了第二階段的自己做，是自己規范的做，通過我們提供的相對完善和規范的工具做。我們就處于這個階段的初期。

　　第三個階段是獨立，獨立是說 EP 團隊從一個替人做事的下游團隊，到一個教人做事的教練團隊，真正進化為一個提供技術服務的產品團隊。這個產品團隊的產品，大多數應該是以一個標準化的、健壯的服務的形式，而不是人力資源的形式，提供給其他團隊的。當然這是我們的理想，能否達到或者是否切合實際，還需要時間來觀察。

　　EP 團隊和整個技術團隊的關系

　　從這三個階段的描述中，多多少少都提到一些 EP 團隊和整個技術團隊或整個公司的關系，那這個關系是什么呢?

　　前面提過，我們不希望是個下游替人收尾的團隊，我們也有「吃狗食」這樣的原則，所以我想到一個比喻，來說明 EP 團隊和其他技術團隊的關系。

　　我們都知道有一個行業叫做汽車制造業，他們遵循一定的規范和標準，還能巧妙的將創意和標準結合在一起，制造出一些工業奇跡，這些汽車被賣給各式各樣的人，汽車企業并不關心他們的產品用在什么地方，不過他們又發明了一種叫做 4S 店的東西，用來給那些工業奇跡定期維護、修理、還可以收集市場反饋以便改進產品。

　　還有另一個行業叫做物流業，他們的目的就是將貨物從一個地方運到另一個地方，這種空間的轉移，就是他們為客戶創造的價值。在這過程中，他們會利用到汽車制造業產出的汽車，但他們不太關心汽車本身的標準、設計細節，他們只是使用，他們關心的是使用成本、維修方便。出問題，他們會找 4S 店。

　　這兩個行業之間的交集是汽車，汽車制造業的價值是制造出好的汽車，物流業的價值是貨物的到達，汽車制造業不關心你的貨物的目的地，物流業不關心他的汽車的制造工藝。但汽車制造業會很關心你怎么用這個汽車，以及積極的幫助你保養，而物流業也會很關心這個車費不費油，好不好開。

　　說到這里，你可能已經看明白 EP 團隊和其他技術團隊的關系了：EP 團隊就像汽車制造業，提供高效、低耗的工具;產品技術團隊就像物流業，使用工具，快速前進，創造用戶價值。他們之間互相依賴，卻又彼此獨立。

　　EP 都有誰

　　了解了 EP 和周圍團隊的關系之后，來看看我們的 EP 團隊的角色和成員。

　　我們的 EP 團隊，大致分成如下幾個角色(而實際上的工作是混合的，之所以要分開成角色，主要是從招聘的角度出發)：

　　SED，Software Engineer in DevOps。顧名思義，這個角色首先是個軟件開發工程師，其次，面向的領域是 DevOps，DevOps 的概念我們就不必多講了，在實際工作中，SED 工程師是個真正的多面手，他們可能今天在開發一個 Linux server 的自動化上線和回滾的工具，明天就要設計或優化 CDN 的部署，后天又要解決一個 Windows 平臺編譯加速問題，還有還有一個自動性能 benchmark 工具等著他來開發。這個角色目前我們只有兩位，而且這個角色的工程師是最難招聘的，因為新人，或者很小的公司出來的人，很少有受過系統的訓練或有比較先進的軟件工程思想，而從大公司出來的人，已經被大公司條塊分割的工作方式同化，一般只擅長一個領域，而對跨界的或者不懂，或者沒興趣。所以這個崗位的工程師，都是有成熟公司工作經驗的 Geek 型的人。

　　SA，System Admin。系統工程師，和很多公司的運維工程師很想像，實際上我們現在的狀態，做的事情也和大多數公司的運維工程師一樣，處理監控，優化服務部署等等，但不一樣的是我們的目標是將絕大多數應用層面的運維工作交還給開發團隊，所以我們在不斷的將監控系統改造為友好的，自助的，也不斷的將各位上線部署類的工作做成自動的，現在已經有了很多成果，我們的 SA 主要精力可以放在系統以及更底層的部分了。

　　TE，Testing Engineer。測試工程師，其實這個稱呼有點名不符實，我們的唯一一位測試工程師，主要的工作其實是發布和迭代控制，要保證整個交付團隊的迭代節奏，例如在代碼上拉發布分支、觸發發布事件、監控數據等等工作，這個工作要求非常精確，又很繁瑣，因此和 SED 工程師有非常多的交互，他們負責將這個過程自動化。這里插入介紹一下我們的發布過程，可能大家會更理解為什么還有個「發布工程師」：

　　我們有三個發布 Channel：Beta、RC、Release，作用各有不同。例如 Beta Channel，主要用于一些新特性的提前發布，這里面可能會多少有點缺陷，所以一定要控制人數，并且是那些喜歡嘗鮮的用戶，他們會用的比較徹底。而 Beta Channel，可能每天都有版本更新，會有一些用戶喜歡跟著 Beta 版。而這些新的特性如果用戶反饋不錯，并且沒有什么嚴重的問題，就會進入最近一次 RC(Release Candidate)，這個量就很大了，大概能占到我們每日活躍用戶的十分之一到五分之一，這里面的功能在沒有意外的話，就是正式發布的功能了，需要注意的是，不是每個 Beta 都會變成 RC。而 RC 在發布幾天之后，如果一切正常，就會切換為 Release，Release Channel 一般會在一天之內，讓絕大多數活躍用戶升級完畢，這個時候，如果程序有 bug，影響就非常大了。

　　Venders，外包測試團隊。我們有大約六七個人的外包測試團隊(on-site)，主要負責我們主要產品的人工驗收測試。我們對外包測試團隊的工作方式也有一個設想，就是一個項目剛開始的時候，外包測試團隊應當是先上很多人，然后隨著 SED 的介入，讓自動化程度加強，慢慢人少下來，直到下一個新項目開始。但這個設想在國內想實現，卻沒那么容易，主要有幾個原因：1)國內的外包測試的工程師，通常是技術和經驗都比較初級的人來做，外包測試成了一個門檻低天花板也低的行業，技術和經驗缺乏，導致進入新項目以后沒辦法非?？斓纳鲜?，而有經驗有能力的人，很快就會脫離外包行業;2)外包測試的公司，人才儲備不足，很少有人力資源池，都是有需求，現從市場上招，或從競爭對手那里挖，有的人都沒見過，就派到客戶那邊來面試，這也導致了沒辦法幾個月就撤下來，因為他沒辦法跟候選人簽合同。這兩個客觀原因，我們也比較無奈，所以我們的外包測試團隊基本上還是長期 on-site。

原文轉自：http://www.wangyuxiong.com/archives/52072