莫拉克颱風災情支援網 - 救災網站背後技術與技巧 (1)

有鄉民說想看當年八八風災的技術筆記,特此撈出來回憶。這是我 2009 所作,當年 25歲。

=====

[這篇文章是我的投影片文字版]

今天( 2009/8/15 )是 COSCUP 第一天,我在早上九點半有個 Talk,有關於 Ruby Web Framework - Sinatra。不過兩天前,我向大會 submit 了新的 topic,改成了 『莫拉克颱風災情支援網 』。

臨時改題目,大家應該會覺得奇怪,這...網站,說穿了不過是個雙向留言板,到底有什麼好湊成一個講題。

也許大家不知道,在這六天( 8/9 - 8/ 15) handle 網站的期間,我其實從觀察其他網路救災團隊運作,和自己實際運營網站時發生的事件,得到了不少經驗。剛好 8/15 就是COSCUP ,才讓我決定臨時改變主題,整理分享這一些心得。

雖然不知道以後還用不用得上(希望台灣以後不要再發生這種大災難),但我希望的是藉由這次經驗的分享,能讓其他人以後再投入網路救災之時,能更有個脈絡方向,能耗費更少精力但能更有效的投入網路支援救災的部份。

=====

莫拉克颱風災情支援網 ( 以下簡稱支援網 ),到底有什麼特點值得拿出來講呢?

它是這次風災最早上線的手刻系統 ( 8/9 12:18 撰寫完成、8/9 01:03 announce、 )。
網站最穩定(唯一沒被 DDoS 到掛站)
功能相對其他救災網站完整。
善於整合地三方資訊。

我的投影片,就是直接以這次開發支援網的技術、實際經驗,來解釋幾個我覺得經營架設、網路支援救災網最需注意的幾個重點...。

說到架設這類網站,你會想到什麼需要注意的事項?

功能完整
統一資訊
一台不錯機器
一隊負責整理更新的網路志工

大概就這些吧...

鄉民最後的直覺結論就會導出:「用 CMS ( Wordpress / Drupal / Joomla ),找個空間,上網找一隊志工支援...收工!」

要是這麼簡單就好了。真的這樣搞,上線會遇到的第一個問題,就是 被‧打‧爆 ....

====

個人這次針對這次經驗,整理了五個重點,供大家參考。我認為救災支援網站需要的是

儘快上線,功能其次
高流量承載與調校 (被打掛 = 無用)
廣為人知
有效利用第三方外掛與資源
有效防止來亂的

儘快上線,功能其次

也許一些朋友比較知道,我現在的職業是程式設計師,強項就是 Ruby on Rails 敏捷網站開發。Ruby on Rails 不僅是我最熟悉的網頁框架,也是世界上開發網站最快速的框架。也因為這樣的因素,我有時候就比較倒楣的常會被抓去支援作一些臨時性的網站救火。這次支援網也是因為比利潘的召喚,臨時從以前做過的舊網站硬改出一個符合需求的直接上線 -- 改版(15min)+ Deploy( 45min)大概總共只花了一小時。

因為需求很明確,因此我作的就只是一個很簡單的「Google Maps + 刊登版(可留言)」的網站,不需要其他雜功能。這也是沒有選擇現成 CMS,直接用手刻的主要原因。 高流量承載與調校

而在前面提到。支援網是從頭到尾沒有被打爆過的網站。不能被打爆,我認為是身為救災消息集散中心一個很重要的 key point。當災難發生,可預見的是,這一類網站一定會瞬間湧進巨大的流量。伺服器可以反應慢沒關係,但一定要擋的住。因為一旦擋不住癱瘓掉了,甚至癱瘓長達幾個數小時。這要命的幾個小時所造成的後果就等於救命稻草蒸發,所有網友心血白費。

那一定有人會覺得好奇,RoR 不是傳說中以效能不佳的惡名著稱?為什麼這次幾個站台之內,被打掛的反而都是 PHP 的站台...

[網站功能保持簡單]

我要澄清一點的是:其實 RoR 並沒有大家想像中的效能糟,它的效能比一些知名的 PHP Web Framework 來的更佳(qps 高很多)。而且我更想提出進一步的是,如果已經預見會是大流量的 event site,隨便使用不熟悉的 PHP CMS,會造成更糟的下場。這也是前一段為什麼會強調「功能其次」的原因,因為功能越「完整」,可能表示效能越不佳。而那些完整的功能,也許並非能在事件中發揮到很大的功能,甚至這部分的 code (plugin / module)更有可能是超吃系統資源的怪獸。而這些功能如果又不是你開發的,短時間你連 tune 都無從 tune 起。

[容易 Scale]

Ruby on Rails Application 較為人熟知的架設方式,是跑好幾隻 mongrel 起來,再用 apache 或 nginx 當 reverse proxy 跑在前面擋。但這次跟往常比較不同的地方是,支援網架構在 Rails 雲端(Heroku)之上。也因為這層關係,網站變得比較好 Scale,幾乎不必再分神去監控系統是否會垮掉。(雖然我當初只是因為懶得管機器...deploy 在雲端)

支援網最高峰那日大概整天是快 40 萬 pageview( Google Analytics),開了 3 台 Heroku 的 dyno。如果當初是拿 VPS 或 dedicated server 跑,大概會陷入一直監控它是不是會掛掉,或者是機器不夠撐要搬家重弄的惡夢...。現在只要信用卡刷下去就...

[Web Performance Tunning ]

雖然個人在網路公司服務的關係,也熟悉 Backend Performance Tunning 的一些技巧。但我深知我的長項是網站敏捷開發,因此頭兩日幾乎是把心力都投注在寫 Code 之上。功能寫的差不多,才回頭改善開啟網站的速度。

調校網站大概抓了幾個重點去作:

改善 db query

打開 YSlow ,依照 High Performance Web Sites 的 tips 去 tune。

(a) 靜態檔案壓縮 - rails 的 靜態檔案 helper 有個很棒的功能,就是指定 :cache => true,就會自動把所有需要用到的 css / js ,combine 成單一檔案。這樣的好處就是可以降低 request 數,減輕對 httpd 的壓力。

(b) CSS 擺上面,JS 擺下面。

(c) 後來多開 dyno 並沒有太大的速度改善,而 Heroku 的底層是 EC2,很明顯的問題就出在卡頻寬。而 YSlow 更告訴我一件驚人的事,html 只有 19k,但我使用的 js framework 有 150k。這時候隨即下的判斷,就是向公司同事 @gslin 求援,把靜態檔案通通丟上 CDN(CDN 費用由公司 PIXNET 贊助)。上 CDN 帶來很明顯的好處:提供 delivery 檔案的速度品質、有的廠商會幫忙上 gzip(甚至多幫忙處理 IE6 下 gzip 的問題)、減輕對 httpd 的壓力。

這幾個措施一做完,網站開起來就變得很快,同樣資源也能撐更多上線人數... 廣為人知

網站上線了。再來的問題:要怎麼讓別人知道有這個網站?我個人因為是比較著名的部落客,噗浪、推特有相對比別人多的 follower (各約一千多人),廣播的廣度夠大。但只有我一個人負責廣播,效力是不會持久的。重要的救災訊息中心的位址,除了迅速傳播還要持久傳播。

因此我在網站上線時也作了兩件事:

(1) 製作推噗按鈕:

噗浪現在是台灣當紅的微網誌。因此要做的是就是讓這個網站在噗浪上燒起來,燒越久越好……。如果現在在噗浪搜尋 "http://disastertw.com" 的話,應該會驚奇的發現一件事,河道上無時無刻幾乎洗滿了眾網友廣告這個網站的噗。 怎麼做到的?我製作了一個推噗按鈕…… 推噗按鈕 網友大多是懶惰的,作公益有時只是順便而已。而在噗浪貼連結,是有特殊語法的,沒有人有美國時間幫你弄好連結...何況 ReP 也沒有辦法直接 copy 效果。即使訊息傳的快,恐怕也無法持久。 為了解決這個問題,想到的簡單的方式就是直接幫網友生好連結與敘述,輕鬆一按 Enter 就噗出去了,完全不費力。之前在 Dell 之歌的事件時,我跟 EvenWu 在當時就順便測了一下這個按鈕的行銷效果,嗯,流量大概成長了三倍以上吧.... 支援網在噗浪上面,延燒這麼久完全是有原因的。

(2) 針對搜尋引擎作有效的 SEO

再來,就是 SEO 的技巧。一般網友,在災情一發生時,不一定會知道有這個支援網站。也許他想幫忙,但是很有可能也無從幫起。這時候變成要向搜尋引擎下手,讓網友一搜尋「莫拉克」,馬上就知道有這個支援網站的存在。

為此,我也做了幾件事:

(a) 經過上面的噗浪宣傳,還有噗浪同步 twitter 的效果,可以導入非常多的 inbound link,有益分數。
(b) meta keywords 塞關鍵字
(c) 調整 Page Title ...

搜尋引擎排名就會有非常顯性的提昇,都在搜尋引擎結果第一頁的前幾名。

results matching ""

    No results matching ""