左右搖擺——線上測試的成敗案例(2)

　　項目期間我在堪薩斯州，我設法取得一些我感興趣的(那些我正為之開發代碼的)交換機模型的IP地址。讓我很高興的是，我能實際接觸它們而不是呆在無聊的會議室中，這樣我能完成一些測試和開發，伴隨著周遭的龐然大物嘎吱嘎吱地磨動那些裝置。一切運轉得很好，我的代碼發送查詢請求，幾乎得到了期望的所有響應，除了做了一些小改動讓我的代碼更棒。實際上不到幾個小時之后，我們發現這些數百萬美元的交換機，原本設計是每秒處理TB級通信轉換，現在卻有一個有趣的現象……它們本來沒想到會接收到比普通人類更快的TL1指令，而你卻給它們連續發送了和計算機一樣快的命令，奇妙的是那些交換機仍然響應得特別好，只是一段時間之后突然就毫無反應，正是這種現象促使堪薩斯州的電話服務開始改進，并變得更好。(是的，我在堪薩斯州，交換機是服務于堪薩斯州的，因為估摸著他們給我“玩”的交換機就是一個本地的設備)。結果就是道歉聲四起，允許測試什么和何時測試有了新的方法，同時一個很棒的新抑制系統加到我們的產品中。

　　教訓：TiP在這里意義非常。因為購買這些昂貴的交換機，把它們放到測試實驗室中毫無價值。但另外一件有意義的事是關于測試什么和何時測試的方法。我在會議室的各種奇怪行為并不是正確的處理過程(公平地說，過去一直是行得通的)，取而代之的是測試中的，真正生成的，會給客戶帶來各種可能結果的一條清楚的報文。既然這樣，我們在采取進一步行動前，幾乎都要檢查下我們的測試過程是否正確。

　　封閉度：用戶曝光控制

　　前面我曾說過，曝光控制能將用戶完全隔離在你的新服務之外。但要是你需要一些用戶參與怎么辦?如果你正在部署一些新的、危險的東西到你的生產環境中(為了測試)，你需要用戶看到它，否則就不叫真正的用戶測試，但既然影響這么壞，你只希望少量的用戶受到影響。理論上你要從少量用戶開始然后監控，接著再增加一些用戶，再監控，就這樣一直重復，直到所有的用戶都在你的新系統上，直到系統擁有高可信度。

　　在微軟我們有實驗平臺(ExP)，通常用做A/B測試，正好也能用作這種用戶擴大的測試。雖然他們不用ExP，但微軟的新搜索引擎Bing在他們的預發測試中使用了這種曝光控制。在微軟之外，我想我聽到過的這類測試的最嫻熟的運用實例之一是在聊天引擎IMVU，他們已經將這類測試融入到每一次部署中，可參考Timothy Fitz的文章，IMVU的持續部署：不可思議的一天50次

　　回到部署過程， 9分鐘過去，網站的一次提交新鮮出爐。程序員運行IMVU的推送腳本，將代碼同步到集群的數百臺機器。平均負載，cpu消耗，php錯誤和退出等更多內容被推送腳本采樣，作為一個基準線。一個軟鏈接用來切換到小客戶子集上。一分鐘之后，推送腳本再次采樣集群的數據，如果統計出來有顯著差異那么系統將會自動回滾。不然，它會推送到整個集群，然后以相同的方式每隔5分鐘監控一次。這一來代碼活著并全部推送到整個系統。這整個過程非常地簡單，只需要執行幾個shell腳本即可。

　　未完待續

　　好了，我還有非常多的例子，但這需要延長不少時間……讓我了解下你們想些什么，如果我得到一些積極反饋，我會告訴你們更多……

原文轉自：http://blogs.msdn.com/b/seliot/archive/2009/12/14/feeling-tipsy-testing-in-production-success-and-horror-stories.aspx