從「蘇伊士運河」事件，檢視網路中是否有「單點故障、全體故障」缺陷

就在三天前，2021年3月23日，當地時間大約7:40 (5:40 UTC)，台灣的長榮海運公司的貨櫃輪「長賜輪」(EVER GIVEN)，在「蘇伊士運河」的航道上意外擱淺，正好將整個通道阻塞。因此，「蘇伊士運河」完全停止服務，任何輪船都無法穿越，一直到影片製作的現在。

我從「維基百科」、「Google地圖」的觀察，我發現，「蘇伊士運河」本身存在著「單點故障、全體故障」的問題，也就是Single Point of Failure, SPOF。因為開鑿運河本身，就是一個極為昂貴的工程，我的重點不是在指出「蘇伊士運河」的設計規劃有問題。我只是藉由這個例子，來說明任何網路系統的設計，如果存在著「單點故障、全體故障」的服務停止缺陷，雖然發生的機會很小，只要機會不是零，我們就必須預先規劃好，如何降低發生的機率；或是當這個狀況發生的時候，所產生的代價，我們是否可以承受；還有，我們必須花費多久時間，才能修復回正常服務的狀態。

「蘇伊士運河」事件的摘要

我先將視野，站在「蘇伊士運河」業主本身。

我從報導得知，「蘇伊士運河」在2020年一整年的過路費收入，大約是56 億美元 (5.6 Billion USD)。我假設運河本身365日每天都營運，平均每一天的收入，大約是一千五百萬美元 (15 Million USD)，這個數字大約是超過新台幣四億元。因此每停止服務一天，過路費收入的損失就是一千五百萬美元。

到目前為止我的觀察，「蘇伊士運河」業主本身能夠做的手段，還沒有看到明顯的效果，包括使用拖船、挖開擱淺岸邊的砂土。目前已經尋求外部救援公司的協助。如果最後真的需要外部救援公司才能解決，我的估計，光是移動外部救援公司的機具到現場，可能就要好幾個星期，因此，這個阻塞問題需要更多的日子，才能夠解決。

光是過路費的收入，就是一筆好大好大的數字。

我將視野，拉回到網路系統。萬一我們的網路規劃，還存在著類似的「單點故障、全體故障」的SPOF問題，我提出下面幾個思考的切入點，來避免我的工作網路遇到，跟進行中的「蘇伊士運河」事故一樣糟糕的結果。

停止服務事件，發生的機率有多大？

雖然我沒有具體的統計數字，但是，經驗上告訴我，纜線、路由器、交換器、防火牆，任何可單獨安裝的硬體單位，一年內完全沒有任何故障的機率，幾乎是零。就算完全沒有故障，也只能算是運氣好。

我必須預期，一條纜線，一個路由器，一個交換器，一個防火牆，就在未來的一年內，一定會產生故障的事件。在這個情境下，來進行我的網路規劃。

因此即使發生單一硬體故障，也不會造成服務停止的冗餘設計(Redundancy)，非常重要。例如，多重冗餘路徑、多重冗餘硬體的加入，都能夠減少停止服務的機率。

即使最後因為不敷成本不採用冗餘設計，這些冗餘設計的選項，我也必須列入考慮清單中。未來如果條件改變，我可以快速知道，我還有哪一些備案可以選擇。

停止服務事件，發生後的代價有多大？

地點不同，代價也不相同。如果某個網路連線，只服務一個時間要求不高的使用者，例如，單一普通員工的座位電腦、小群組印表機，代價也許不明顯。

但是如果是主幹道上面的網路，停止服務後，損失一定很可觀。如果可能，將預期的損失用金錢來估算，這樣會比較有感覺，同時，這個數字也能夠幫助我評估，我能夠投入的合理預算，有多少。

停止服務事件，發生的時候，要花多久時間修復？

在網路系統距離不遠處，準備一些多餘的可能故障的備用品，例如網路線、光纖收發器(Transceiver)，甚至是交換器，都可以減少停止服務的時間。

尋求外部公司的協助，也是可行的選項。例如資訊系統另外付費的「保證四小時內到場維護」等級的硬體服務。

結論

前面三個切入點的問題，每個企業內的系統的情境、取捨，可能都不一樣。重點是，我都必須隨時準備好，我要如何去回答。

One more thing…

雖然我的視角只是網路系統，事實上，前面全部的檢視，也適用於任何的資訊系統。

回到「蘇伊士運河」。

誰能事先想得到，竟然會這麼剛好，擱淺意外，發生在「蘇伊士運河」單向、單通道的航道段，而且主角是總重量超過二十萬噸的、世界最大型的貨櫃船。

如果能回到過去，改成發生在雙通道航道段，或者是主角不是如此笨重的輪船，一切就不會演變成整個「蘇伊士運河」完全阻塞。

只要機率不是零，我都必須假設，這種事故真的會發生。我不能只靠運氣好。

我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！