阿里妹導讀：18年前，200家企業由于在事故中信息系統遭到嚴重破壞而永遠地關閉了。這樣的事故引發了后人深思，對于工程師而言，不僅要求設計的系統足夠強壯，還需要具備考慮失敗的能力，當失敗場景悉數被考慮周全、并且結合充分的演練，一切會不會不一樣？我們熟知面向對象設計和面向程序設計，阿里巴巴資深技術專家游驥洞悉行業現狀，拋出了一個新模式——面向失敗設計。今天，聽他娓娓道來，如何在一開始的系統設計階段就考慮到各種失敗場景，把面向失敗當成是系統設計的一部分，準備好從失敗中恢復的策略。

引言

一個優秀的架構師通常都是一個悲觀主義者，除了設計好能夠支撐業務持續發展的優雅架構，另一個容易被忽略的重要能力在于充分考慮失敗場景。如果對失敗場景考慮不夠充分，輕則出現業務不可用，影響用戶體驗和企業聲譽；重則導致數據永久丟失、業務再無恢復可能。

2001 年 9 月 11 日,美國世貿中心雙子大廈遭受了誰也無法預料的恐怖打擊，災難發生前約有 350 家企業在世貿大廈中工作，事故發生一年后,重返世貿大廈的企業變成了 150 家,有200 家企業由于重要信息系統的破壞,關鍵數據的丟失而永遠關閉、消失了，其中的一家公司聲稱自己要恢復到災難前的狀態需要 50 年的時間。

“Everything fails, all the time”，無論是在傳統軟件時代還是在互聯網、云時代，系統終究會在某個時間點失敗，面向失敗的設計理念數十年來并沒有多大的變化，不同的是在分布式、云架構的互聯網時代：失敗將由小概率偶發事件變成常態，同時應對和處理失敗的具體實現方式也大相徑庭。

無所不在的失敗場景

單個技術點在絕大部分時間都能按照設想正常工作，但是當規模和復雜度到達一定程度，失敗其實無所不在。當你的業務場景從服務企業內部的幾百號員工變成面向上億的外部用戶，你不確定你的用戶群會有些什么樣的角色，也不知道他們會在你的系統平臺上創造出什么樣的業務行為；當你的技術框架從單機、一體機演進到分布式的多層、多組件架構，原本5個以內的技術組件可能變成了今天的500個，并且為了用較低的成本保持服務能力的擴展能力，你可能放棄了穩定性更好但也昂貴的商業技術、轉而用開源自建來替代。

互聯網業務快速發展不僅直接帶來了流量、安全等不確定性，同時促使了技術架構的快速演進，使架構變得越來越復雜，這些因素都將導致失敗發生的概率大幅提升。當人類的工作、生活越來越依賴互聯網，一旦出現失敗，造成的影響和損失將是空前巨大的。在遠古時代，人類沒有自來水也沒有電，一切都很好；今天如果停電停水一段時間，相信很多人都會無法適應，而互聯網正在逐步演變成跟水和電一樣的基礎設施。失敗的原因多種多樣，抽象來看可以分為以下幾類：

硬件問題

首先，硬件是有生命周期的，它一定會老化，并且你不知道它會在什么時候壞；其次，硬件是一個實體，它存在于客觀環境當中，它的狀態會受外部環境干擾，比如火災、地震等外力因素都可能導致硬件損壞；最后，所有硬件都會存在殘次品，你很可能就是那個不幸者。通常情況下單個硬件出問題的概率不高，但是當有幾十萬的硬件設備，硬件的失敗問題每天都會發生。

軟件bug

即便是最優秀程序員寫出來的程序，經過最優秀測試同學的嚴格測試后的代碼，上線依然無法做到完全沒有bug。互聯網業務迭代往往講究一個“快”字，以往幾個月或者幾年升級一次的軟件程序，現在一周就需要升級一次或者多次，這大幅提升了軟件出錯的可能性。

配置變更錯誤

系統運行態的日常運維過程當中，難免會因為疏忽或者考慮不周全導致災難。當上萬名技術同學跟上百個變更系統做笛卡爾積，哪怕是6個9的可靠性，依舊無法做到萬無一失。全局的流量入口、權限與安全驗證體系、統一網關與接口平臺等技術環節是可能促發全站不可用的重要風險點，對于影響面大的配置的變更需要尤為謹慎。

系統惡化

原本工作得很好的程序隨著時間的推移可能有一天不再正常工作，舉幾個常見的例子：自增變量運行了很長一段時間后出現越界、緩存隨著數據量的逐漸變大而出現空間不足、數據庫連接池隨著機器的擴容而不夠用等等。千萬不要認為運行良好的系統是不會出問題的，它的代碼里面可能藏了定時炸彈，只是你不知道會在什么時間點爆炸。

超預期流量

某一天你的系統可能突然會承受遠超過預期的每秒請求數，特別是在“中國特色”的互聯網場景之下，你很難精確預估系統各個時間點的業務訪問量。

外部攻擊

你需要考慮各種攻擊行為，包含流量攻擊和安全攻擊。你的系統可能隨時會面臨著DDOS和CC類攻擊，你傳輸的數據可能會被盜取或者篡改。

依賴庫問題

你的系統很可能會用大量的二方庫或者三方庫，它們對你來說是黑盒子，你不了解它們存在哪些風險，并且你無法掌控。這些庫可能會存在漏洞、可能會有bug，可能會大量消耗你的系統資源，總之不要太信任它們。

依賴服務問題

你依賴的服務也一定不會100%可用，它們可能會超時，可能會失敗。當依賴服務超時的時候，如果你沒有很好地處理，可能會導致你自己的系統無法工作，在分布式場景下，這種失敗狀態會持續輻射，最終導致大面積的不可用。

如何面向失敗設計

作為一個悲觀主義者，你需要在一開始的系統設計階段就考慮到以上各種失敗場景，把面向失敗當成系統設計的一部分，并且準備好從失敗中恢復的策略，這有助于更好地提升整個系統的可用性。只有你意識到事情會隨著時間的推移而失敗，并將這種思想融入到體系結構中，那么在失敗發生的時候你才能完全不受影響或者將失敗損失降到最低。面向失敗的設計理念數十年來并沒有多大的變化，一些好的經典原則在今天依舊被廣泛運用。

冗余設計避免單點故障

硬件和軟件都不可靠，環境和人都存在極大的不確定性，雖然無法避免失敗場景的發生，但是可以通過冗余設計來規避局部失敗對系統的影響。冗余設計避免單點故障這一策略在互聯網技術架構中處處可見，比如重要的服務通常都會部署多個、數據庫的主備結構、服務調用的重試機制、存儲的多副本等概念都屬于這一范疇。

面向失敗的宏觀多活架構

除了局部失敗場景，你的系統可能還面臨著大范圍的失敗場景。大范圍的原因有兩個：天災，比如火災、地震、臺風、雷電等大的自然災害可能導致大面積的基礎設備被毀壞；人禍：人的失誤或者刻意破壞行為有時候也會釀成大禍，如操作錯誤、破壞、植入有害代碼和恐怖襲擊。“面向失敗的宏觀多活架構”從宏觀架構的高可用層面來解決系統的整體可用性問題，隨著技術的演進，冷備、熱備、兩地三中心、異地多活等應對大范圍失敗場景的技術體系這些年頻頻被提起。

服務能力與依賴調用自我保護

如何來衡量一個軟件系統的設計是否優良？一條很重要的衡量標準——在任何情況之下你的軟件系統都應該工作在當前環境的最優狀態。每個人都知道機翼是飛機的重要部件，一旦機翼出現問題，飛機很可能就會墜落。然而在二戰當中，許多戰斗機即便機翼千瘡百孔了，依然保持著最佳戰斗能力；甚至還有更夸張的情況：1983年的一次戰斗機演習當中，一架飛機由于事故損失了一個機翼，這架缺少一個機翼的飛機依然保持了飛行能力、最終完成安全著陸。

軟件系統由兩部分構成：系統自身的代碼和依賴的庫以及服務。“服務能力與依賴調用自我保護”需要從這兩塊分別切入構建系統在任意情況都始終工作在最佳狀態的能力。服務限流、系統負載保護、給依賴的服務設置超時或者資源限制等都是相應的應對策略。

為一切不可預料的情況備好預案

能夠抵抗失敗和從失敗中快速恢復是面向失敗設計的核心思想，然而即便已經做了萬全的設計，也并非所有的失敗場景都是系統能夠自動抵御的。你需要考慮到所有的失敗場景，并準備好相應的應對預案。為一切不可預料的情況備好預案才能在失敗場景真正發生時做到有條不紊。做好預案需要對失敗場景有全面的考慮：會發生哪些失敗？失敗會帶來什么問題？應對策略是什么？預期的恢復時間多久？恢復后的影響面有多大？需要通知到哪些角色？等這一系列的因子構成了一個完整的預案體系。

自動化運維管控

大量的系統故障是因為人的失誤造成的，即便讓一個優秀的運維工程師進行一萬次同樣的運維操作也難免不出錯。唯一的解決辦法便是在運維過程當中盡可能降低人為操作的比重。系統化、白屏化是第一個階段——將人為的操作步驟固化成系統程序，避免操作失誤；自動化以及智能化是第二個階段——將正確的決策過程也固化成智能程序，避免決策失誤。同時所有的運維動作都需要遵循灰度原則，做到可灰度、可監測、可回滾，即便出現了失誤也能控制好爆炸半徑，并且做到快速恢復。

精細化的監控體系

面向失敗設計不僅要求你的系統足夠健壯，同時要求你能夠在第一時間感知到失敗的發生。無論是自動化的系統恢復，還是人為介入，如果你壓根都不知道是哪里出問題了，一切都將束手無策。精細化的監控體系一方面能夠在出現問題的時候以最快的速度將最準確的信息傳遞到人或者運維系統，同時它還能夠展現趨勢、進行提前預警。AI技術的結合使得監控領域在近幾年得到了新的發展驅動力：智能監控報警、根因定位、智能預測、智能決策等能力都是學術界和工程界非常熱衷的課題。

故障與攻防演練錘煉容災應急能力

最后，即便以上工作都做好了，你也不能高枕無憂去等待失敗到來。你的設計、系統、流程、技術人員等需要通過不斷演練，來保障能力和進化升級。對于代價非常巨大的事件，做好前期的充分演練是非常有必要的，比如軍事演練、消防演練等都屬于這一范疇。而系統不可用的代價對于企業來講很可能是無法承受的，因此需要在平時做好充分的演練：通過故障與攻防演練錘煉容災應急能力，對面向失敗的設計做好充分驗證。只有當所有的失敗場景都被提前演練過，當失敗真正來臨時才能做到胸有成竹。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的为什么说优秀架构师往往是一个悲观主义者？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。