有了客戶端，也有了伺服端，服務正式開始工作，接下來我們就會開始討論故障的問題了。
如果有個客戶端故障，比如說你的智慧手機故障好了，那你會怎麼處理？
換手機，故事結束。
但是如果有個伺服端故障了，比如說證券交易伺服器故障好了，該公司會發生什麼事情？
違約條款，好一點就是大家都沒有年終，壞一點就是大家都沒有工作，故事結束。
所以說伺服端是絕對不能故障的。
伺服端的故障是非常恐怖的事情。以 IT 建置來說，具規模的伺服端服務，都會花超過一倍的成本來維持服務的不故障，假設明明整個伺服器服務 100 萬的成本就可以順跑了，他們可能會出 300 萬來保證服務的安全。
故障又有分兩種，一種是資料損壞，另一種是服務掉線。
資料損壞這件事的嚴重性通常高於服務掉線，服務掉線的話，就是當服務從無法使用到恢復使用的時間有『閒置成本』，但資料損壞的話，如果壞到重要資料不可逆的情況，公司是很可能被一波帶走的。
要避免資料損壞，最直觀的步驟稱為『備份』，就是當原始數據或系統遭遇問題，可以使用來恢復這些數據或系統運行的功能。
常見的就是備份 321 了：3 份資料，2 種介質，1 個異地。
『3 份資料』就是所有資料要存三份，至於要如何讓所有儲存的資料都保有一致性，而不會出現版本 1、版本 2、版本 3，這就是軟體工程師該努力的了。
『2 種介質』就是為了因應對介質災難時可以使資料安全。比如說用光碟和磁碟去存同樣的資料，當地球被高強度電磁風暴掃到之時，全世界的磁碟統一報廢的類世界末日之際，光碟裏的資料也不會陣亡。
『1 個異地』就是備份的資料起碼要放在兩個不同的位置 (異地)。有些機構會要求異地 30 公里的物理距離，據說是考慮到被核彈打到後的波及半徑，不要說資料被幹走，就算被一顆核彈打到，資料依然不能陣亡。
好了，做到這一步，縱使其中一個機房被核彈打到，再同時加上被全球性電磁風暴掃到，資料還是可以活著。
你說想太多？
不，IT 沒有所謂想太多，只有「這件事的價值值不值得做這麼多」，所謂 IT 大程度上就是價值與金錢的權衡考量。
我們保證了資料安全，接下來就輪到服務安定了。
要如何保證服務不掉線呢？
基本的策略其實很單純，就是多份。
比如說每台伺服器裏面要有兩顆 CPU，每個伺服器服務程式要有兩個，網路線各自插兩條，硬碟兩個兩個一組 (Raid)，電源供應器兩顆，同樣規格的伺服器要兩台，供電來源要接兩條來自不同供電廠的線，就連工程師都聘用兩個 (所以有些工程師就真的是招進去放著，跟買保險一樣)。
這個步驟稱為『備援』，當主要系統或設備發生故障時，能夠無縫切換到備用系統。正在運作的電腦設備故障時，要有另外一個完全相同的設備可以撐一下，然後發 Alert 給職守的工程師，在備用的電腦設備正在撐一下的時候，偷偷地把故障的部件修好。
當然不見得都是 2 的倍數。
正常可能 5 台工作機配上 2 台備援機之類的，但備援的中心思想就是，假設其中一個單點 (Node，就是說一個設備) 故障了的話，要有另外一個可以工作的單點去無縫切換。
是的，我舉例了『5 台』工作機去當『一個』伺服端的角色。
這種把數台電腦給串聯起來，使其形成一個巨大的電腦單體，把很多台電腦假裝成一台電腦的做法，就叫做『叢集 (Cluster)』，在叢集裡的每台電腦都稱為一個點 (Node)。
叢集結構的大前提就是：「用戶只在意服務是否正常，並不在意是哪台電腦提供服務」，只要可以把商品發貨，管它老闆是老王還是小明。
在這個階段，可以這樣去想像整個伺服器架構：
-----機房--------
人:【客戶端電腦】 -> 伺服端 (叢集) |【電腦 A (物理)】|
|【電腦 B (物理)】|
|【電腦 C (物理)】|
-----------------
【備份資料 B】
【備份資料 C】
客戶端只要去訪問伺服端系統就可以了，至於是哪台伺服器提供服務的，客戶端不管。
你可以想像你的服務其中一個單點可能在美國，另一個單點在南港；或是誠品跟博奕公司的機房搞不好其實是鄰居，AWS 的機房直接圈半層樓的數量，2024 以前大部分的亞洲 AWS 服務都在日本或新加坡嗎？所以是哪台伺服器提供服務客戶端不管，也沒意義。
叢集結構可以擁有以下好處：
1. 電腦 A 燒壞了，B 電腦必須要可以繼續提供服務。
2. 電腦 A 的運算能力滿載，電腦 B、C 可以分擔運算需求。
3. 如果 A、B、C 三台電腦服務不過來龐大的業務量，因為已經是叢集結構了，所以隨時可以增添第四台的電腦 D 去分擔。
可以做到上述的要求，就稱為伺服器系統符合高可用性 (High Availability, HA)。
HA 的目的是最小化停機時間、系統避免因單點故障導致服務中斷、快速故障恢復。主要就是冗餘設計、故障轉移機制以及分散負載，更進一步的還會要求監控與自動化。
啊還是故障了怎麼辦？
是啊，即使做到這個規模了，伺服端系統還是可能掛掉。臉書會掛掉，ChatGPT 會掛掉，Office 365 也會掛掉，你以為臉書的電腦叢集是 3 台 5 台嗎？它們的電腦叢集是 3 『座』 5 『座』樓廠的，但即使如此，服務還是可能掛掉。
這種時候就只能把工程師叫起來了哈哈哈，這就是 on-Call，派人快點把中斷的服務修好，避免閒置成本擴大。
假設公司可以接受的合理閒置成本是 15 分鐘，工程師們就要討論出 15 分鐘內恢復上線的對策；如果不幸地真的發生了伺服端系統掛掉的狀況，使用了恢復對策但卻超過 15 分鐘，就要檢討跟改進。
沒人願意讓服務中斷，但扣掉天災以外，服務中斷也可能是人禍。
之前聽過一個案例，有一間做跨國服務的公司，它們的伺服端大半夜被一個不知道在幹嘛的駭客掃射 (DDoS)，服務癱瘓。那時候第一線的監控人員要做的第一件事就是打電話，把整個公司的人都叫起來開始戰鬥。
這絕對不是很熱血的故事，像極了一塊沒有彈性的肝。
所以服務中斷就……大家體諒一下吧？
然後事情繼續發展。
