每個初創(chuàng)公司都夢想一夜之間獲得數(shù)百萬用戶，但是很少有公司聲稱做到了這一點——將基礎設施近乎完美的擴展以通往成功之路。
廣為流行的移動應用Mailbox開發(fā)者Orchestra面臨了每個應用開發(fā)者夢想遇見的難題：負載太高，迫使他們不停的擴展，并且要在最短的時間完成擴展。然而在這個擴展的過程中，很少有機構可以在6周內完成從零到百萬用戶的擴展，并且?guī)缀跷从鲆娙魏纹款i。
近日Mailbox工程主管Sean Beausoleil接受了ReadWrite的采訪，就基礎設施擴展在Mailbox的實踐進行了分享。區(qū)別于隨處可見的迭代應用，Beausoleil還分享了一些成功的秘訣，比如嚴格控制基礎設施可替代組件的數(shù)量，以及該公司的Rservation System（預約系統(tǒng)）。
擴展的規(guī)劃
記者：Mailbox在6個月內實現(xiàn)從0到百萬用戶的支持，你們是否預見到了這個輝煌的勝利？
Beausoleil：我們從開始就有做大型系統(tǒng)的規(guī)劃，因為電子郵件是個牽扯到龐大數(shù)據(jù)體積的應用，但是我們并沒有預見到現(xiàn)在的規(guī)模。早在2012年12月份發(fā)布我們視頻的時，我們發(fā)現(xiàn)收獲的遠不止所期待的10萬瀏覽；可實際情況是，僅僅4個小時就達到了我們的預期。這個狀況說明，Mailbox上大有可為。而從那時起，我們就踏上了不斷擴展之路。
圖：Mailbox第一周數(shù)據(jù)
記者：應對如此增長，你是如何規(guī)劃的？我們相信自Mailbox發(fā)布到今天這個規(guī)模，是不能離開你們的精心規(guī)劃，請帶我們回憶一下Mailbox背后的基礎設施擴展過程。
Beausoleil：我認為在Mailbox擴展到當下的規(guī)模主要經歷過3個關鍵階段：
- 設計，針對規(guī)模進行謹慎的擴展，不停的迭代
- 規(guī)模模擬，竭盡所能的對項目擴展到大規(guī)模后的情景進行模擬
- 對產品負載迅速反應，開發(fā)并迅速的賦以實踐
鑒于Mailbox處理的是電子郵件，而電子郵件的要求又比較苛刻，我們使用擴展、有效及精準的理念來設計系統(tǒng)。我們的目標就是設計一個擴展系統(tǒng)，讓我們可以不斷的完善并迭代我們的系統(tǒng)和產品。為了達到這一點，我們構建了一個模塊化系統(tǒng)，并對每個組件持續(xù)的迭代。
為了發(fā)布之前能盡可能的避免錯誤和瓶頸，我們建立了一個克隆系統(tǒng)以及IMAP協(xié)議，用以模擬產品將要面臨的負載。這將讓我們發(fā)現(xiàn)后端的局限性及存在的問題，而這些問題如果在產品發(fā)布后去修補將是非常令人頭疼的。
當然，我們清楚不可能在第一天就建立一個完美的系統(tǒng)。所以在軟件建立后，隨著階段性問題的頻繁出現(xiàn)，以及你對這些問題解決方案的理解，設想和約束也在迅速改變，所以你需要不停的學習，并合理的分配時間。而在收到視頻所反饋的信息后，我們認識到系統(tǒng)還需要進一步的打磨；其中之一就是需要建立一個Rservation System，用以幫助我們控制系統(tǒng)上的負載。
對于我們來說，用戶體驗是最重要的。在產品發(fā)布后，我們的工程師團隊日以繼夜的在發(fā)現(xiàn)問題并進行修復，目的就是保證越來越多的人可以擁有一個很好的用戶體驗。這個階段擴展的非常迅速；而在理解了我們數(shù)據(jù)和用戶需求后，基礎設施的各個核心部分要么修改，要么被分解，要么完全的拋棄。
限制技術數(shù)量
記者：你是如何為你的基礎設施選擇組件的？這些技術在to-do App中就以已經使用了嗎？
Beausoleil：我們基礎設施組件同樣是一個迭代和進化的故事。鑒于Mailbox本身就是我們to-do App的迭代，這個技術同樣衍生于我們的Orchestra To-Do后端。我們幸很運的得到了許多初創(chuàng)公司不曾擁有的機會——重寫整個系統(tǒng)的機會，讓整個系統(tǒng)活了起來。
當然Mailbox開發(fā)的準備階段，花去了我們大把的時間去重思原有的組件。舉個例子，我記得有一個星期，我們做了一個非常大矩陣，列舉了可選擇數(shù)據(jù)的優(yōu)缺點。這允許我們?yōu)橄到y(tǒng)做最好的選擇，之后只需要付諸行動了。
這樣就由Orchestra完美衍生了iPhone應用，我們選取了之前為Orachestra To-Do建立的數(shù)據(jù)分析和用以實時傳遞消息的網絡框架，并對需要完善的地方進行了迭代。我們同樣學習了如何去建立一個高效、響應式iOS UI，并將這些運用到前端框架的搭建，這讓App運行的更快更流暢。
其中有個一直在堅持的就是限制不同技術的數(shù)量，讓其保持最低，因為我們不想在應用打造過程中變成20個不同領域的專家。我們只想在3個領域內走的更精，竟可能的專注產品的開發(fā)。
記者：Mailbox現(xiàn)在所使用的是云服務，你是否有考慮過在自己的數(shù)據(jù)中心建立基礎設施？或者是隨著業(yè)務的增長，移動到更專注的數(shù)據(jù)中心。
Beausoleil：一個專用的數(shù)據(jù)中心需求大把的資源以及前期兌現(xiàn)。我們只是一個想建立大型后端的小團隊，我們沒有資源去管理一個專用的數(shù)據(jù)中心。AWS是一個令人敬佩的合作伙伴，給我們系統(tǒng)擴展及迭代帶來了非常大的靈活性。對我們團隊來說，這個平臺更加的有成本效益及高效，這為我們有限的資源和時間打下了堅實的基礎。
未雨綢繆
記者：我們記得產品剛發(fā)布時并不是沒有問題。有個階段，信息甚至不能加載，Orchestra將問題推給了“服務器異常問題”?；厥滓幌拢@是不是你可以預料的情況？如果您有預期的話，那么是否是一個已知的意外？
Beausoleil：我認為這些都是后見之名。當你去回顧自己所寫代碼出現(xiàn)的任何問題時，你可能就會認為你完全可以阻止這個問題的發(fā)生，并且抓住bug引起的原因。然而這些都是建立在你對這些問題有所理解，或者是理解了這些之前不曾明白的代碼路徑。然而在你剛開始嘗試時，你是不可能寫出完美的代碼。雖然我們做足了前期準備，但是我也有一些問題是突然出現(xiàn)的。不管你發(fā)布任何規(guī)模的應用，總有一些失敗是必然會出現(xiàn)的，并且需要去做修復。
記者：如果你再重新發(fā)布，那么有什么做法會區(qū)別之前的地方？你是否發(fā)現(xiàn)你堆棧中的3個組件會有表現(xiàn)不如你預期的地方，并且你希望去取代的？
Beausoleil：這些同樣是些后見之名。即使發(fā)現(xiàn)也是我們現(xiàn)在才了解的。如果事先知道哪個組件需要被置換，哪些可以被修復，那么我們將可以清楚的提升一些地方。但是我們就失去了這個親身體驗建立和擴展系統(tǒng)的機會。最終結果必然是值得關注的，但是這個過程同樣很重要。
我們一直在不斷的改善，并且嘗試讓系統(tǒng)給終端用戶帶來更加的高效和快速體驗。我相信這是一個長遠的努力，有一些地方仍然需要不斷的改進，有一些地方的實現(xiàn)的途徑總會走了彎路。
給后學末進的經驗之談
記者：有什么其它的建議給一些想達到Mailbox規(guī)模的初創(chuàng)公司？
Beausolei：迭代，迭代，迭代。不管你現(xiàn)在的狀況是什么樣，它都可以更好。這里需要做的就是一直的關注它，讓它變的更好。隨著構思設想不斷變化，掌握更多的數(shù)據(jù)，你的產品的整體框架設計將更加合理、系統(tǒng)的擴展性將更強。
關于細節(jié)問題。注重細節(jié)，但是別讓他們妨礙執(zhí)行的速度。實現(xiàn)這一點需要很多艱苦的努力，但是每一份努力都是有價值的。
采訪中學到的知識
1. 對產品發(fā)布后的信息提前進行收集。預熱視頻可以讓用戶對產品產生興趣，同時也可以讓你初窺產品發(fā)布后的效果，并得到反饋信息，從而提前做出準備。
2. 擁有一些獨一無二的特性。有特別之處才可以吸引用戶，將創(chuàng)新之處列出清單，并逐個實現(xiàn)。
3. 了解產品背景。比如電子郵件業(yè)務非常對資源的需求就很高，并且對產品要求苛刻，所以盡快的擴展。
4. 給產品設定目標。Mailbox初始只針對Gmail以及iPhone，清晰狹窄的目標可以讓你在產品設計上投入更多精力，做出更針對性的項目。
5. 修改和迭代。他們有一個非常好的用戶體驗，因為初期設計就是一個模塊化系統(tǒng)，這樣就可以根據(jù)需求對不同的組件進行迭代。
6. 大規(guī)模下的模擬。建立模擬系統(tǒng)用以發(fā)現(xiàn)問題，這些測試解決了許多項目在運行過程中難以解決的問題，而這個重要的步驟一般被許多初創(chuàng)公司所跳過。
7. 將技術的數(shù)量限制到最小。因為精力是有限的，誰都不可能成為許多領域的專家，專注自己的產品開發(fā)才是王道。
8. 關注用戶行為。核心基礎設施的調整、分解或者刪除宗旨在于適應用戶的使用模式。
9. 通過Rservation System限制新用戶的訪問速度。早期Mailbox的Rservation System比產品更加出名，有些類似于“饑餓營銷”；不僅刺激了用戶，還以一種可控制模式有效的引導負載。這里的關鍵在于用戶體驗，而不是吸引新用戶。
10. 瘋狂的投入。開發(fā)者不斷的修復故障并完善系統(tǒng)，在早期的開發(fā)中應該著重對待，這也是項目整個周期最高效的一個階段。
11. 應用不可避免會發(fā)生故障并且進行修復。任何測試都是有條件的，許多未知的問題在特定的環(huán)境下就會爆發(fā)出來。迭代，不停的迭代，你將更加了解你的系統(tǒng)、數(shù)據(jù)和用戶行為。
12. 如果你現(xiàn)存的技術、堆棧不再適合當下的環(huán)境，果斷使用可替代方案去替換。花時間去做新的技術選擇，然后在這些技術上下功夫。
13. 云具有成本效益和高效兩大特性，云是快速和有限資源構建應用的最佳搭檔。
14. 過程的重要性。經歷整個產品周期，這是團隊和產品磨合的重要組成部分?？梢缘脑?，切勿拔苗助長。
14. 擇木而棲。在Mailbox產品發(fā)布的一個月后就被Dropbox收購，原因是Dropbox可以幫助他們增長的更快、更大。
15. 良好的溝通。如果你關注Mailbox的博客，你就會發(fā)現(xiàn)他們在解釋發(fā)生事件上做了很多的努力，足夠多的細節(jié)讓用戶感到的是安慰而不是迷惑。 （編譯/仲浩 審校/王旭東）