說起單點(diǎn)故障(Single Point of Failure，SPOF)，倒是可以想起電影 《2012》中，一把焊槍把齒輪卡住，從而導(dǎo)致整個(gè)艙門無法關(guān)閉，進(jìn)而整個(gè)引擎無法發(fā)動(dòng)。這是個(gè)有點(diǎn)生動(dòng)的例子–如此龐大的一個(gè)系統(tǒng)，居然因?yàn)橐话研⌒〉暮笜尪U(xiǎn)些毀于一旦。投入巨大人力物力生產(chǎn)的救命方舟居然做不到高可用(High availability)，這是致命的事情。

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

一般來說，只要系統(tǒng)能夠比較清楚的分出層次來，要消除單點(diǎn)故障還是有章可循的事情。比如，一個(gè)網(wǎng)站，從基礎(chǔ)的硬件層，到操作系統(tǒng)層，到數(shù)據(jù)庫層，到應(yīng)用程序?qū)?，再到網(wǎng)絡(luò)層，都有可能產(chǎn)生單點(diǎn)故障。如果要有效的消除單點(diǎn)故障，最重要的一點(diǎn)是設(shè)計(jì)的時(shí)候要盡量避免引入單點(diǎn)，而隨著架構(gòu)的變化，定期審查系統(tǒng)潛在單點(diǎn)也是有必要的。

有人或許會(huì)問，假設(shè)一個(gè)起步中的站點(diǎn)，只有一臺(tái)服務(wù)器，什么東西都在一個(gè)盒子里，到底要怎么做呢? 這里的建議是先拋開主板、CPU 、內(nèi)存這些，首先必須考慮硬盤(存儲(chǔ)層)的問題，如果機(jī)器只有一塊硬盤，即使你備份計(jì)劃再完善(不要說你的備份也是備份在這塊硬盤上的)，還是建議你起碼再弄一塊。做鏡像，讓出錯(cuò)的概率降低，這是劃算的投入，當(dāng)然消除單點(diǎn)，成本幾乎不可避免的要增加。如果硬盤多，或者有其他備份機(jī)制，可選的方法就更多，別刻舟求劍。

第二個(gè)要考慮網(wǎng)卡與網(wǎng)線的單點(diǎn)問題。先說網(wǎng)線，如果要問一個(gè)系統(tǒng)里面最容易物理損壞的是哪個(gè)組件，答案恐怕非網(wǎng)線莫屬，對(duì)于網(wǎng)線這樣多數(shù)時(shí)候因?yàn)榫嚯x需要定制的東西，總是購買成品還是有成本的，從我觀察到的情況來看，各個(gè) IDC 的網(wǎng)線使用手工制作的比例不小，這個(gè)質(zhì)量幾乎很難控制，一根線，兩個(gè)水晶頭，哪一個(gè)出問題都不能正常傳輸。怎么辦? 想辦法提升網(wǎng)線整體質(zhì)量還是弄兩根網(wǎng)線放在那里? 解決辦法早都有了，網(wǎng)卡綁定 (NIC bonding)一個(gè)很簡單很通用的辦法(refer)，但是問題是并非很多人在用。多數(shù) PC 服務(wù)器應(yīng)該都是配置了多塊網(wǎng)卡，如果是自己攢服務(wù)器，記得網(wǎng)卡多一塊成本沒多大，但是用處會(huì)有很多。如果耐著性子看到這里，先別急著去 Google，還有問題呢，兩根網(wǎng)線如何接到上行交換機(jī)，什么樣的交換機(jī)支持綁定，如何確定綁定是真正生效的? 答案是，嘗試一下。

然后是什么? 是跑多個(gè)數(shù)據(jù)庫，還是跑兩個(gè) Web 服務(wù)器，一個(gè)不行用另一個(gè)頂? 對(duì)于單臺(tái)服務(wù)器，其它能消除單點(diǎn)的地方恐怕收效也不會(huì)特別大，現(xiàn)在少做無用功，或許要重點(diǎn)考慮如何備份，如何優(yōu)化，以及出現(xiàn)問題的時(shí)候如何做到快速恢復(fù)。有一個(gè)或許會(huì)引起爭議的建議是，除了 SSH 登錄之外，要不要留一個(gè) Telnet 登錄的服務(wù)呢? 畢竟 SSH 服務(wù)器端守護(hù)進(jìn)程不是百分百靠譜的事兒，如果 IDC 距離較遠(yuǎn)，需要斟酌一下。好吧，網(wǎng)站有了一點(diǎn)發(fā)展，用戶量也增加了，感覺需要增加服務(wù)器了。再增加一臺(tái)服務(wù)器，抗風(fēng)險(xiǎn)能力一下子加強(qiáng)了許多，畢竟一臺(tái)機(jī)器質(zhì)量再好，也有出錯(cuò)的時(shí)候。現(xiàn)在，Web 服務(wù)器、DB 服務(wù)器可以考慮引入 HA 的方案，如果單臺(tái)服務(wù)能力夠，主備模式也不錯(cuò)。隨著網(wǎng)站的發(fā)展，服務(wù)器數(shù)量繼續(xù)增加…

隨著服務(wù)器數(shù)量的增加，到了必須要自己購買網(wǎng)絡(luò)設(shè)備的時(shí)候了。同樣的設(shè)備，一買恐怕就要買雙份，原因無它–一臺(tái)總要出錯(cuò)，哪怕是電源被拔錯(cuò)–而這樣的情況實(shí)際上并不少見。如果預(yù)算不夠，那就再等等，但是要記住，定期審查，有可能的話，進(jìn)行彌補(bǔ)總不會(huì)錯(cuò)。

到現(xiàn)在，所有的服務(wù)器都還在一個(gè) IDC 呢，IDC 本身也是個(gè)單點(diǎn)啊，服務(wù)器被黑怎么辦? 機(jī)房光線被施工工人挖斷怎么辦? 機(jī)房停電怎么辦? 找第二個(gè)機(jī)房吧。現(xiàn)在選 IDC 首先要考慮什么? 中國特色的互聯(lián)網(wǎng)問題總要考慮吧，”南北互通”怎么樣…或許在選擇第一個(gè)機(jī)房的時(shí)候已經(jīng)遇到了類似的問題，或許現(xiàn)在正在受到這個(gè)問題的困擾。選好 IDC 之后，首先計(jì)劃一下數(shù)據(jù)如何備份過來，然后，網(wǎng)站的配置信息如何同步或備份過來(這是保證第一個(gè) IDC 出了致命問題之后的最基本的恢復(fù)要求)。多個(gè) IDC 之后不得不提上議程的要算 DNS 這個(gè)事兒了。你的 DNS 解析商靠譜么? 如果域名提供商遭受攻擊，對(duì)自己的網(wǎng)站影響能承受么?

更多的服務(wù)器，提供更多的應(yīng)用，更多的用戶，更多的收入… 接下來該怎么辦呢? 現(xiàn)在，您所面對(duì)的已經(jīng)不是一個(gè)小型 Web 站點(diǎn)了，可以不用看這篇文章了。

到現(xiàn)在，我還沒說人的問題，如果這些信息只有一個(gè)人知道，萬一這個(gè)人出了點(diǎn)事情怎么辦? 作為老板，還要考慮人的單點(diǎn)問題。

Updated: DNS 的健康程度檢查重要性應(yīng)該提升一些。如何檢查？有很多在線的工具可供使用，簡單直接。