乙個優秀的架構師通常都是乙個悲觀主義者，除了設計好能夠支撐業務持續發展的優雅架構，另乙個容易被忽略的重要能力在於充分考慮失敗場景。如果對失敗場景考慮不夠充分，輕則出現業務不可用，影響使用者體驗和企業聲譽；重則導致資料永久丟失、業務再無恢復可能。
2023年9月11日，美國世貿中心雙子大廈遭受了誰也無法預料的恐怖打擊，災難發生前約有350家企業在世貿大廈中工作，事故發生一年後,重返世貿大廈的企業變成了 150家,有200家企業由於重要資訊系統的破壞,關鍵資料的丟失而永遠關閉、消失了，其中的一家公司聲稱自己要恢復到災難前的狀態需要50年的時間。
「everything fails, all the time」，無論是在傳統軟體時代還是在網際網路、雲時代，系統終究會在某個時間點失敗，面向失敗的設計理念數十年來並沒有多大的變化，不同的是在分布式、雲架構的網際網路時代：失敗將由小概率偶發事件變成常態，同時應對和處理失敗的具體實現方式也大相徑庭。
一、無所不在的失敗場景
單個技術點在絕大部分時間都能按照設想正常工作，但是當規模和複雜度到達一定程度，失敗其實無所不在。
當你的業務場景從服務企業內部的幾百號員工變成面向上億的外部使用者，你不確定你的使用者群會有些什麼樣的角色，也不知道他們會在你的系統平台上創造出什麼樣的業務行為；當你的技術框架從單機、一體機演進到分布式的多層、多元件架構，原本5個以內的技術元件可能變成了今天的500個，並且為了用較低的成本保持服務能力的擴充套件能力，你可能放棄了穩定性更好但也昂貴的商業技術、轉而用開源自建來替代。
網際網路業務快速發展不僅直接帶來了流量、安全等不確定性，同時促使了技術架構的快速演進，使架構變得越來越複雜，這些因素都將導致失敗發生的概率大幅提公升。
當人類的工作、生活越來越依賴網際網路，一旦出現失敗，造成的影響和損失將是空前巨大的。在遠古時代，人類沒有自來水也沒有電，一切都很好；今天如果停電停水一段時間，相信很多人都會無法適應，而網際網路正在逐步演變成跟水和電一樣的基礎設施。失敗的原因多種多樣，抽象來看可以分為以下幾類：
1、硬體問題
首先，硬體是有生命週期的，它一定會老化，並且你不知道它會在什麼時候壞；其次，硬體是乙個實體，它存在於客觀環境當中，它的狀態會受外部環境干擾，比如火災、**等外力因素都可能導致硬體損壞；最後，所有硬體都會存在殘次品，你很可能就是那個不幸者。通常情況下單個硬體出問題的概率不高，但是當有幾十萬的硬體裝置，硬體的失敗問題每天都會發生。
2、軟體bug
即便是最優秀程式設計師寫出來的程式，經過最優秀測試同學的嚴格測試後的**，上線依然無法做到完全沒有bug。網際網路業務迭代往往講究乙個「快」字，以往幾個月或者幾年公升級一次的軟體程式，現在一周就需要公升級一次或者多次，這大幅提公升了軟體出錯的可能性。
3、配置變更錯誤
系統執行態的日常運維過程當中，難免會因為疏忽或者考慮不周全導致災難。當上萬名技術同學跟上百個變更系統做笛卡爾積，哪怕是6個9的可靠性，依舊無法做到萬無一失。全域性的流量入口、許可權與安全驗證體系、統一閘道器與介面平台等技術環節是可能促發全站不可用的重要風險點，對於影響面大的配置的變更需要尤為謹慎。
4、系統惡化
原本工作得很好的程式隨著時間的推移可能有一天不再正常工作，舉幾個常見的例子：自增變數執行了很長一段時間後出現越界、快取隨著資料量的逐漸變大而出現空間不足、資料庫連線池隨著機器的擴容而不夠用等等。千萬不要認為執行良好的系統是不會出問題的，它的**裡面可能藏了定時炸彈，只是你不知道會在什麼時間點**。
5、超預期流量
某一天你的系統可能突然會承受遠超過預期的每秒請求數，特別是在「中國特色」的網際網路場景之下，你很難精確預估系統各個時間點的業務訪問量。
6、外部攻擊
你需要考慮各種攻擊行為，包含流量攻擊和安全攻擊。你的系統可能隨時會面臨著ddos和cc類攻擊，你傳輸的資料可能會被盜取或者篡改。
7、依賴庫問題
你的系統很可能會用大量的二方庫或者三方庫，它們對你來說是黑盒子，你不了解它們存在哪些風險，並且你無法掌控。這些庫可能會存在漏洞、可能會有bug，可能會大量消耗你的系統資源，總之不要太信任它們。
8、依賴服務問題
你依賴的服務也一定不會100%可用，它們可能會超時，可能會失敗。當依賴服務超時的時候，如果你沒有很好地處理，可能會導致你自己的系統無法工作，在分布式場景下，這種失敗狀態會持續輻射，最終導致大面積的不可用。
二、如何面向失敗設計
作為乙個悲觀主義者，你需要在一開始的系統設計階段就考慮到以上各種失敗場景，把面向失敗當成系統設計的一部分，並且準備好從失敗中恢復的策略，這有助於更好地提公升整個系統的可用性。
只有你意識到事情會隨著時間的推移而失敗，並將這種思想融入到體系結構中，那麼在失敗發生的時候你才能完全不受影響或者將失敗損失降到最低。面向失敗的設計理念數十年來並沒有多大的變化，一些好的經典原則在今天依舊被廣泛運用。
1、冗餘設計避免單點故障
硬體和軟體都不可靠，環境和人都存在極大的不確定性，雖然無法避免失敗場景的發生，但是可以通過冗餘設計來規避區域性失敗對系統的影響。
冗餘設計避免單點故障這一策略在網際網路技術架構中處處可見，比如重要的服務通常都會部署多個、資料庫的主備結構、服務呼叫的重試機制、儲存的多副本等概念都屬於這一範疇。
2、面向失敗的巨集觀多活架構
除了區域性失敗場景，你的系統可能還面臨著大範圍的失敗場景。大範圍的原因有兩個：
「面向失敗的巨集觀多活架構」從巨集觀架構的高可用層面來解決系統的整體可用性問題，隨著技術的演進，冷備、熱備、兩地三中心、異地多活等應對大範圍失敗場景的技術體系這些年頻頻被提起。
3、服務能力與依賴呼叫自我保護
如何來衡量乙個軟體系統的設計是否優良？一條很重要的衡量標準——在任何情況之下你的軟體系統都應該工作在當前環境的最優狀態。
每個人都知道機翼是飛機的重要部件，一旦機翼出現問題，飛機很可能就會墜落。然而在二戰當中，許多戰鬥機即便機翼千瘡百孔了，依然保持著最佳戰鬥能力；甚至還有更誇張的情況：2023年的一次戰鬥機演習當中，一架飛機由於事故損失了乙個機翼，這架缺少乙個機翼的飛機依然保持了飛行能力、最終完成安全著陸。
軟體系統由兩部分構成：系統自身的**和依賴的庫以及服務。「服務能力與依賴呼叫自我保護」需要從這兩塊分別切入構建系統在任意情況都始終工作在最佳狀態的能力。服務限流、系統負載保護、給依賴的服務設定超時或者資源限制等都是相應的應對策略。
4、為一切不可預料的情況備好預案
能夠抵抗失敗和從失敗中快速恢復是面向失敗設計的核心思想，然而即便已經做了萬全的設計，也並非所有的失敗場景都是系統能夠自動抵禦的。
你需要考慮到所有的失敗場景，並準備好相應的應對預案。為一切不可預料的情況備好預案才能在失敗場景真正發生時做到有條不紊。做好預案需要對失敗場景有全面的考慮：會發生哪些失敗？失敗會帶來什麼問題？應對策略是什麼？預期的恢復時間多久？恢復後的影響面有多大？需要通知到哪些角色？等這一系列的因子構成了乙個完整的預案體系。
5、自動化運維管控
大量的系統故障是因為人的失誤造成的，即便讓乙個優秀的運維工程師進行一萬次同樣的運維操作也難免不出錯。
唯一的解決辦法便是在運維過程當中盡可能降低人為操作的比重。系統化、白屏化是第乙個階段——將人為的操作步驟固化成系統程式，避免操作失誤；自動化以及智慧型化是第二個階段——將正確的決策過程也固化成智慧型程式，避免決策失誤。
同時所有的運維動作都需要遵循灰度原則，做到可灰度、可監測、可回滾，即便出現了失誤也能控制好**半徑，並且做到快速恢復。
6、精細化的監控體系
面向失敗設計不僅要求你的系統足夠健壯，同時要求你能夠在第一時間感知到失敗的發生。無論是自動化的系統恢復，還是人為介入，如果你壓根都不知道是**出問題了，一切都將束手無策。
精細化的監控體系一方面能夠在出現問題的時候以最快的速度將最準確的資訊傳遞到人或者運維系統，同時它還能夠展現趨勢、進行提前預警。
ai技術的結合使得監控領域在近幾年得到了新的發展驅動力：智慧型監控報警、根因定位、智慧型**、智慧型決策等能力都是學術界和工程界非常熱衷的課題。
7、故障與攻防演練錘煉容災應急能力
最後，即便以上工作都做好了，你也不能高枕無憂去等待失敗到來。你的設計、系統、流程、技術人員等需要通過不斷演練，來保障能力和進化公升級。對於代價非常巨大的事件，做好前期的充分演練是非常有必要的，比如軍事演練、消防演練等都屬於這一範疇。
而系統不可用的代價對於企業來講很可能是無法承受的，因此需要在平時做好充分的演練：通過故障與攻防演練錘煉容災應急能力，對面向失敗的設計做好充分驗證。只有當所有的失敗場景都被提前演練過，當失敗真正來臨時才能做到胸有成竹。
如何成為乙個優秀的SOA架構師
什麼是soa架構設計師的職責?那什麼是企業級soa架構設計師的具體角色呢?什麼是soa架構設計師與設計和開發人員之間的差別呢?相信這些都是使大家最容易產生迷惑的問題。舉個實際的例子來說，當構建乙個基於soa架構的系統的時候，針對乙個具體的 service，系統設計人員主要應該關注的是這個servic...
如何成為乙個優秀的系統架構師
老男孩linux高階架構師第四節課程課前思想講解分享 1 學習心態的轉變 大家不是來學習，而是工作，老男孩老師就是你們的領導。領導分配了任務，又給大家詳細講解了。那現在，咱們公司要上這個專案，讓你去搞，你沒有理由不搞定。工作中老大給你講解細節，這個是不會有的。所以，從需求分析開始，到出一套專業可實施...
乙個移動架構師是如何煉成的 一
乙個軟體開發專案，能否在有限的時間和人力 物力下達到客戶或者內部的要求，最重要的是有乙個稱職的架構師。架構師聽起來很高大上，但是其實每個開發員都可以稱為架構師，只不過是對自己開發的小模組的架構。每個模組怎麼開發，用到哪些技術，這些開發人員要考慮的問題也正是架構師所要考慮的問題。所以，小專案，乙個人可...