|
|
|
#1
2012-01-31, 01:37 PM
|
||||
|
||||
「iCook 愛料理」如何善用雲端服務，加速網站產品開發
好資訊，與大家分享！
原文連結 LAWRENCE LIN 30 JANUARY 2012 三個月前我離開上一間公司，投入 iCook 食譜社群網站的建設與營運工作，從我們正式開工、上線到目前短短幾個月，我們一路跌跌撞撞，學了很多經驗，想藉由這篇文章分享一下我們如何善用各種雲端服務來加速我們的網站開發，讓我們可以專注在網站產品開發與社群的營運上，我們可以說是只花了不到兩個月的時間就讓網站從無到有並且上線。雖然網站目前流量還不是挺大，沒有太多數據可以拿出來分享，不過我們在有限的人力做了滿多看得到與看不到的事情，我個人認為真的要感謝現在許多現成的雲端服務。我個人的 Twitter 是 twitter.com/deduce ，歡迎在 Twitter 上與我交流。 首先要簡短說明一下我們整個公司的編制，我們目前共有 8 位夥伴，一位是 Fox，從行銷、社群經營、業務合作到開發票、發薪水都是他在負責；一位是 Leo，是我們的首席設計師，主導產品的視覺設計與UI/UX設計；另外有三位 iOS developer（或說是 App developer）；剩下的三位就是 Web developer 了。 Web developer 的組成則是一位因為被騙進來至今仍無法畢業還在讀研究所的年輕人（就是我本人，對，還是個年輕人），一位剛從政大資科畢業就被我們騙進來的資優生（第一名畢業）還有一位還在讀政大資管就被我們騙進來的實習生。 Web team 雖然有三個人，但我們不是葉問，無法一個打十個，尤其被騙進來的年輕人，我們要多花一些時間與耐心陪伴他們與產品一同成長。這樣的編制，我們無法像很多公司一樣把前端、後端、系統管理、測試等角色明確的分開。考量到人力運用的效率，我們在最初的產品發展規劃時，不得不做了兩個決定： 我們要大量運用各種現成的服務，盡可能透過租用的模式，節省人力的運用，讓大家的心力是專注在產品本身的核心價值、體驗設計與功能的實現。 我們要跑得比平常更快一點，即使是還有許多沒有寫完的功能、模組，也要儘快上線，每天都要前進。 每天都發佈新版的網站程式，持續改善，讓社群來協助我們決定下一步該做什麼，並且盡可能將上線前還沒完善的功能儘快做完。我常說「產品上線後才是真正的開始」，所以即使到今天，我們都還有一堆沒做完的功能、沒改完的臭蟲、沒調整完的介面，不過沒關係，我們就每天改。我們跑得快的方法是每天持續的優化，今天要比昨天更好，這禮拜要比上禮拜更好。 打造一個食譜社群網站，乍看之下沒什麼困難的，不過我可以舉幾個實際的案例，來說明為何我會特別強調，我們有限的人力必須更專注在產品的核心上： 我們網站同時支援 IE7/IE8/IE9、Firefox、Google Chrome 以及 Safari 瀏覽器，同時還有專門支援手機版的頁面（目前僅對 iPhone 最佳化， Android 跟 Windows Phone 也可以看到手機頁面，不過某些小細節可能會爆炸），我們目前幾乎確保了 97% 的用戶看到的介面、編輯的介面盡可能是一致的（IE7還是小有問題，不過今年底我們就會捨棄 IE7 了） 我們的介面設計上有一些很刁鑽的需求，流程的規劃也預留了未來發展行動版應用的空間（例如 iOS apps），我們可以說是在打造網頁版應用的同時，也必須考慮到未來發展手機應用時的使用流程以及 API 的規劃，這一點是相當耗費心力的 我們在數據的統計、資料的分析上下了很多功夫，理論上一年內我們的食譜數量就會成長到將近10,000筆，屆時如何可以讓使用者輕鬆的找到喜歡的食譜，或是透過食材的組合找到正確的食譜，光是食材資料庫的建置、推薦機制的設計，就會花掉許多時間（簡單來說，我們在進行簡單的 text mining 與 data mining 來建置 recommendation system），這是網站的核心價值之一，也是未來我們可以確保產品營運上可以有良好基礎的關鍵 在大家都不是葉問的情況下，又想要追求卓越、打造一個體質良好、得以長久經營的網站，顯然我們需要強大的火力支援才能確保我們的網站開發能達到我們的最低要求。而針對運用各種現成的服務方面，我簡短分享我們一共用了哪些現成的資源，以下的順序就是看心情，想到什麼寫什麼  與網頁技術無關的服務 Google Analytics 我們利用 Google Analytics 來追蹤使用者在我們網站上的讚數、留言數、收藏數，另外我們也用來追蹤每日登入的會員數還有一部分的電子商務營收數據。使用 Google Analytics 的好處是它提供了強大的多維度報表分析功能，我們可以透過許多方式來檢討我們每天、每週的經營成效。 另外，透過即時線上人數的統計，我們可以很直接的觀察到各類行銷活動的成效，這也非常有趣，當你看到同時在線人數有上百人的時候，真的會有一種既感動又興奮，同時願意再多熬夜拼個幾天的感覺XD Mailchimp 這是另外一個發信服務，Mailchimp 的好處是有完整的後台可以讓行銷人員自行編輯信件的內容，進而發送電子報。換句話說，我們目前不花費任何開發者的時間開發相關的功能，先外包出去，以後有時間、有更進階的需求，才拉回來自己做。 Mailchimp 同樣也會提供統計數據，讓你了解發信量、開信量等，你甚至可以看到是哪些人有點開你的電子報，進而將這些人依不同的維度劃分成不同的群組，未來可以進行簡單的客製化電子報派送。就小規模的團隊與服務來說，這是顧客關係管理的第一步。 Uservoice Uservoice 是一個非常重要的服務，我們從開站以來，我們幾乎每天都會透過 Uservoice 收到來自我們訪客的建議與問題回報，Uservoice 透過簡單的介面讓訪客可以輕鬆的發信告訴我們他的想法。我們透過 Uservoic 來掌握使用者對於我們網站產品的看法，也藉此可以更加深入的了解我們社群。 我們可以透過後台清楚的看到目前所有尚未回應的問題，或是誰已經回應了哪些問題，甚至可以建立罐頭訊息，還有積分的設計，客服人員每當回答了問題，就會得到額外的積分。（不過其實我們目前是共用帳號、共享積分XD） Google Web Master 除了 Google Analytics 之外，我們會透過 Google Web Master 來觀察網站目前在 Google 上的搜尋成效與排名。不過畢竟我們網站才上線兩個多月，這部份我們其實還沒有太高的期待XD 與網頁技術相關的服務 Ruby on Rails 這是我們網站主要使用的框架，近年來有滿多網站選擇使用的，使用 Rails 最大的好處是 Rails 目前有相當成熟的 ecosystem，有許多現成的套件可以讓我們很快實現許多功能，讓我們可以專注在打造網站產品。 另外，使用這類框架最大的好處是，這些框架都由非常資深的前輩們用心打造而成，可以替我們這些後輩們避開許多問題，我們可以說是站在巨人的肩膀上、善用前輩的智慧、心血結晶在打造我們心目中卓越的產品。 如今要打造一個網站，你能選擇的框架越來越多，像是 ASP.NET MVC、Django、CodeIgniter、Node.js，都漸漸有越來越多的資源可以運用。當然，我建議撰寫網頁還是要從基礎練起，不然這些框架很多時候會讓你感到非常痛苦，因為你不會知道它背後到底幫你做了哪些事情，反而會讓你綁手綁腳的。 Heroku 這是我們放置網頁應用程式的空間，這是一個號稱「雲端」的網頁空間，我曾經寫過幾篇文章介紹 Heroku： Ruby語言的雲端運算平台：Heroku Salesforce.com收購雲端服務提供商Heroku：宣告Java與Ruby才是「雲端2.0語言」 PaaS遍地開花！整理各種平台的Heroku-like解決方案 簡單來說，Heroku 提供了簡單的資源動態調配的選項，你可以視網站流量、負載隨時調整投入的資源（與資金），幾乎可以不必修改你的程式。像是東森新聞在總統大選時也是運用了類似的平台來應付超過 2,400 萬個網頁讀取。除了 Heroku 之外，現在有非常多類似的平台，像是 Google App Engine, Gondor, no.de, nodecloud, nodester, , Microsoft Azure。 AWS RDS AWS 是由全球最大網路書店 Amazon 提供的雲端服務，RDS 簡單來說就是他們提供的一個雲端資料庫，說穿了就是一個不用自己架設的 MySQL。RDS 算起來其實非常昂貴，但是初期我們為了直接跟 Heroku 搭配，就毫不猶豫的選購了。RDS 的好處是它的效能很好（相對於我們自己的小機器）、穩定度超高、有定時的備份機制。 Airbrake 這是我們的應用程式例外處理服務，每當應用程式出錯時，應用程式會主動將錯誤發生時的所有資訊發送到 Airbrake，網站營運的相關人員也會在第一時間收到錯誤發生的訊息。藉此，我們可以掌握每天發生的錯誤，並且儘早處理。我個人認為，網站發生錯誤經常是不可避免的，但應該透過各種方式在第一時間掌握並且迅速回應。 Redis Redis 不是第三方服務，而是一個 NoSQL 資料庫。我們利用 Redis 來存放幾種資料：所有的統計數據（例如每小時、每天的流量）、與搜尋相關的數據，以及某些特別的應用。選用 Redis 的理由也很簡單，有些事情不太適合用關聯式資料庫處理，Redis 剛好滿適合的，包括統計或是索引方面的功能。 Redis To Go 這是一個 Redis 雲端服務，方便歸方便，但是當你的應用程式吞吐量較大的時候，經常會出現錯誤訊息。此外，他們沒辦法提供用戶自訂維修的時間，因此如果你的網站時區與他們不一樣，那很可能會導致你在某些奇怪的時段無法正常使用。 Websolr Solr 是一個 Apache 基金會底下的開放原始碼搜尋引擎專案，我們利用 Solr 作為我們的搜尋引擎。Websolr 則是一個雲端 Solr 服務。Websolr 也是滿不給力的，無法正確回應的頻率頗高，不過我們現在搜尋量也還不大，所以之前都還得過且過。（不得不說，Websolr 效能算是挺好的） Resque 講 Resque 其實是太偏了，比較好的說法是我們有使用 Message Queue 在處理我們某些需要進行排程的工作。我遇過很多網站經營團隊，在網站營運時是完全不用 message queue 的，使用 message queue 的理由很簡單，某些工作如果會吃到比較多的資源，或是沒有急迫性，或是例行性的工作，應該排進 Message queue，除了可以確保這些工作的完成度之外，也可以在流量突然變大時將工作分散到不同的機器上處理。 New relic New relic 是一個應用程式的監控服務，簡單來說它可以讓你清楚的看到目前應用程式運行的效率、資料庫的吞吐量之類的，比較好的是它可以提供精確的報表，讓你掌握究竟是哪一段程式執行時間特別久，讓你可以更有效率的進行改善。New Relic 會在應用程式負載過高時主動通知，這一點也是非常實用的。 AWS S3 我們利用 AWS S3 來存放所有的照片，使用 S3 的好處是我們不需要自己處理儲存空間與備份的問題，也不需要負擔圖片的流量。 AWS Cloudfront Cloudfront 是 AWS 提供的 CDN 服務，簡單來說，CDN 是分散於全球各地的內容發佈網路，假設你有一個台灣網站，有一個人從美國上了你的網站，若你有使用 CDN，這位訪客有很大的機會可以就近在美國的伺服器下載你網站的內容，如此瀏覽你網站的速度與體驗就會大幅的提升。我們網站目前有超過 10% 的海外用戶，我們幾乎可以確保這些海外用戶跟台灣用戶可以擁有差不多的瀏覽速度。 Sendgrid Sendgrid 是一個專門用來發信的服務，Sendgrid 的好處是提供了一些統計數據，讓你了解每日的發信量、開信量、信件點擊率。目前我們的發信量還小，倘若以後再大一點，或許我們會自建發信服務。 結語 你可以看到，我們運用了大量的第三方服務，有些是與網頁技術比較有關的，有些則是非技術人員就可以迅速套用並且上手的網路服務。 說穿了，除了我們真的沒有多餘的人力投入在這方面的建置之外，我們也滿懶的。此外，現階段比較現實的是，我們必須專注在網站的核心價值上，寶貴的人力、寶貴的時間都是成本，應當投入在最重要的地方，至於其他次要的事情，我們先花錢外包。 而且，就我個人而言，我更有興趣的是讓產品可以穩定的營運與成長，因此我們目前利用了成本比較低的方式來建置資訊技術上的基礎架構，有些服務我們在不久的將來會開始投入資源開始建置自己的版本，有些服務則會轉移到別的廠商，這部份的經驗與決策的原因，就留待下一篇文章分享了。 目前說起來，我們終究還是個小網站，等過陣子我們流量大一點了，我會再進一步分享許多營運上、費用與成本相關數據，希望可以藉此與讀者們多多交流。 
|
