消除小型 Web 站點單點故障(Single Point of Failure)

說起單點故障(Single Point of Failure，SPOF)，倒是可以想起電影 《2012》中，一把焊槍把齒輪卡住，進而導緻整個艙門無法關閉，進而整個引擎無法發動。這是個有點生動的例子--如此龐大的一個系統，居然因為一把小小的焊槍而險些毀于一旦。投入巨大人力物力生産的救命方舟居然做不到高可用(High availability)，這是緻命的事情。

大腦對與人來說，就是一個單點，大腦損壞，人也完蛋；手是不是單點? 一隻沒了，另一隻還能日常生活，從這個角度來說，不是單點。消除單點的最常見的做法：增加備援。比如，人有兩隻手。其次，階層化。當然，分層的目的是便于隔離問題。電影 《2012》 中的這個問題，不知道誰是總架構師，看起來，隔離做得不太夠 :)

一般來說，隻要系統能夠比較清楚的分出層次來，要消除單點故障還是有章可循的事情。比如，一個網站，從基礎的硬體層，到作業系統層，到資料庫層，到應用程式層，再到網絡層，都有可能産生單點故障。如果要有效的消除單點故障，最重要的一點是設計的時候要盡量避免引入單點，而随着架構的變化，定期審查系統潛在單點也是有必要的。

有人或許會問，假設一個起步中的站點，隻有一台伺服器，什麼東西都在一個盒子裡，到底要怎麼做呢? 這裡的建議是先抛開主機闆、CPU 、記憶體這些，首先必須考慮硬碟(存儲層)的問題，如果機器隻有一塊硬碟，即使你備份計劃再完善(不要說你的備份也是備份在這塊硬碟上的)，還是建議你起碼再弄一塊。做鏡像，讓出錯的機率降低，這是劃算的投入，當然消除單點，成本幾乎不可避免的要增加。如果硬碟多，或者有其他備份機制，可選的方法就更多，别刻舟求劍。

然後是什麼? 是跑多個資料庫，還是跑兩個 Web 伺服器，一個不行用另一個頂? 對于單台伺服器，其它能消除單點的地方恐怕收效也不會特别大，現在少做無用功，或許要重點考慮如何備份，如何優化，以及出現問題的時候如何做到快速恢複。有一個或許會引起争議的建議是，除了 SSH 登入之外，要不要留一個 Telnet 登入的服務呢? 畢竟 SSH 伺服器端守護程序不是百分百靠譜的事兒，如果 IDC 距離較遠，需要斟酌一下。好吧，網站有了一點發展，使用者量也增加了，感覺需要增加伺服器了。再增加一台伺服器，抗風險能力一下子加強了許多，畢竟一台機器品質再好，也有出錯的時候。現在，Web 伺服器、DB 伺服器可以考慮引入 HA 的方案，如果單台服務能力夠，主備模式也不錯。随着網站的發展，伺服器數量繼續增加...

随着伺服器數量的增加，到了必須要自己購買網絡裝置的時候了。同樣的裝置，一買恐怕就要買雙份，原因無它--一台總要出錯，哪怕是電源被拔錯--而這樣的情況實際上并不少見。如果預算不夠，那就再等等，但是要記住，定期審查，有可能的話，進行彌補總不會錯。

到現在，所有的伺服器都還在一個 IDC 呢，IDC 本身也是個單點啊，伺服器被黑怎麼辦? 機房光線被施工勞工挖斷怎麼辦? 機房停電怎麼辦? 找第二個機房吧。現在選 IDC 首先要考慮什麼? 中國特色的網際網路問題總要考慮吧，"南北互通"怎麼樣...或許在選擇第一個機房的時候已經遇到了類似的問題，或許現在正在受到這個問題的困擾。選好 IDC 之後，首先計劃一下資料如何備份過來，然後，網站的配置資訊如何同步或備份過來(這是保證第一個 IDC 出了緻命問題之後的最基本的恢複要求)。多個 IDC 之後不得不提上議程的要算 DNS 這個事兒了。你的 DNS 解析商靠譜麼? 如果域名提供商遭受攻擊，對自己的網站影響能承受麼?

更多的伺服器，提供更多的應用，更多的使用者，更多的收入... 接下來該怎麼辦呢? 現在，您所面對的已經不是一個小型 Web 站點了，可以不用看這篇文章了。

到現在，我還沒說人的問題，如果這些資訊隻有一個人知道，萬一這個人出了點事情怎麼辦? 作為老闆，還要考慮人的單點問題。

--EOF--