有鄉民說想看當年八八風災的技術筆記，特此撈出來回憶。這是我 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 ...
搜尋引擎排名就會有非常顯性的提昇，都在搜尋引擎結果第一頁的前幾名。
