開首你一定知道近期最熱的IT話題，就是全球大當機事件 2024年7月19日，CrowdStrike發佈了一項錯誤的配置更新 導致全球的Windows系統出現重大當機（藍屏死機） 波及全球多個行業，包括航空、銀行和媒體等 造成了嚴重的業務中斷。 |
|
之後的這段時間，一半的IT人忙於救火修復， 另一半IT人則在抽水，嘲弄，及出Meme圖 我當然也不執輸，也要一起抽水！ 我指手劃腳食花生，直指是CrowdStrike的問題就好了🤨 好像很多受影響的IT部門一樣，責任從來都不是自己的 😤😤 有得賴真方便！ 講笑吧，我就會從雲架構師的角度，系統設計的角度來看這個事件 確實是會有些啟發的，一定要看到最後 作為一個有責任感的雲架構師，最好是能夠可以審視看看 有沒有什麼傳統觀念上的設計盲點 把今次事件作為教訓，將來的設計就可以避免類似問題再發生 很奇怪，在今次的大災難，就算是國際航空大企業也是無法倖存 他們一定不缺優秀的系統和雲端架構師，為何仍會老貓燒鬚？ |
|
你好，我是Alvin，是一名IT雲技術教練與生命教練。幫助有相同志向的同伴走上雲技術的道路 我也幫助自己構建理想IT工作，同時成為我的興趣，做到工作自主， 時間自由 |
|
讓我以局外人的身份，由淺入深嘗試解構雲端架構師的想法和設計 雲端架構師要關注的角度有很多。今次讓我們只專注一點去設想 就是業務連續性(Business Continuity) 架構師會用盡辦法，去確保系統運作來支援業務 設計一： 基本的系統設計最簡單的系統設計，在後端只需要一部伺服器和一個數據庫就能為前端終端機服務
|
設計二： High Availability的系統設計架構師會擔心任何一個伺服器或數據庫運作異常 所以我們有High Availability的設計 就是用兩台伺服器同時運作，前面配合一個Load Balancer 分配工作 當一台伺服器有異常，另一台伺服器就會迎接所有工作 在數據庫方面，則會有一個後備的作準備 當主數據庫有異常時，後備數據庫就已準備就緒 有着主數據庫最更新的資料，出來補上工作 |
設計三： Multi-AZ 的系統設計架構師想多了一想，如果出問題的是Data Centre呢？ 於是，他就會把這個架構分散在不同的Availability Zones (AZ) 在雲端世界， AZ 就是Data Centre 以AWS為例，香港就有3個AZ, 星加坡就有2個AZ 這個架構，如放在香港的其中兩個AZ 就算港島區的AZ有事，新界區的AZ仍能維持服務 業務連續性已升到很高的水平
|
設計四： Multi-region 的系統設計架構師無事做，錢又多，又會再想 我是超大型國際企業，系統是又需要二十四小時運作的 我們不能承受有任何停運作風險 如果香港的所的AZ都壞了，那就不得了 在這個情況，架構師就會設計 Multi-region 就是在星加坡也同樣設立和香港一樣的系統群 當香港的無法運作時，星加坡的就會補上來維持服務 （這個敘述省略了很多細節，我們在這裏就先跳過了吧） |
設計五：Multi-planet 的系統設計你可以想像，這架構是可以繼續無限放大的 如果不限制資金，架構師可以再增加Region的 如果架構師還是不滿意，可以把架構擴展至火星 當地球爆炸了，火星就會補上，不過 … … 用戶在那裏了??… 靜過太空 … |
|
從以上的邏輯，你就可以見到底層的想法 就是要避免 Single Point of Failure （喂, 你講了這麼久，幾時先講到正題？都已經講到上太空了！） 到了到了， 鋪陳已完成 從之前的邏輯， 我們會以向宏觀的方向，多準備後備 來盡可能解決 Single Point of Failure。 可是意料之外，今次問題竟然是在每一部伺服器和終端電腦之中 就算有多少後備都沒有用了！
我叫這個變種做：Distributed Single Point of Failure (哈哈，改個名玩吓啫) |
總結在宏觀下我們難以察覺這個問題的可能性 但是加入了微觀之下， 我們就有新發現了 吸收了今次的教訓，我們下一次應該怎樣重新審視設計？
業務連續性(Business Continuity) 是Information Security 裏很重要的一環 但是不同的方法，適合不同的公司情況和不同的項目 這些方法都不能一概而論 你也有其他想法嗎？ 歡迎繼續討論 與其怪責別人，不如自我進步！ 做到持續改善 Continuous Improvement 才是王道 大家一起努力吧! 今天分享就到這裏 |
【Q&A互動時間】Q&A 互動時間開始！以下是一些常見問題和我的回答： |
|
⭐️⭐️⭐️ 有意進軍雲端和IT行業的鬥士們 如果有任何問題，歡迎大家在下方留言發問🗨，我很樂意與你分享更多經驗 祝好運並保持積極！ |