容錯能力 (粵拼 : jung4 co3 nang4 lik6 ;英文 : fault tolerance ),又叫故障容許度 ,係一個系統 可以有嘅一種特性,指個系統「喺某個或者某啲組成部份故障 嗰陣,有幾能夠繼續正常運作」,亦都包埋個系統喺呢種情況下「表現會跌幾多」[1] :
冇容錯能力:一旦個系統其中一橛出咗錯,就成個系統軭嗮;
有咁上下容錯能力:一旦個系統其中一橛出咗錯,佢依然行到,但表現會明顯變差;
「得體」嘅容錯能力(得體降級 ):隨住系統越來越多出錯,佢依然行到,表現只會細微噉變差。
2008 年加拿大 一角有架車 爆咗呔 ;條呔 係架車嘅其中一橛,不過就算呢橛仔有故障 ,架車頂攏郁唔到一陣-架車有咁上下容錯能力。
舉個例說明,想像家陣有隻電腦軟件 (系統),佢會接收由用家 等來源嚟嘅 input ;想像有吓 input 嘅數值異常,搞到隻軟件其中一部份計錯數(出錯);如果隻軟件完全冇容錯能力,就會輕機 ;現實世界嘅軟件工程師 多數都會將隻軟件設計 成有些少容錯能力,即係例如就算其中一橛計錯數,隻軟件都唔輕機,而係揼咗個錯嘅數,用第個用得(但未必最理想)嘅數頂替,再彈條信息 出嚟話俾用家知出咗問題-隻軟件表現差咗,但仲行得到[2] [3] 。容錯能力嘅概念喺電腦 以外嘅工程學 領域都用得著-例如一架車 其中有條呔爆咗 ,用家換條新呔 (一段相對易嘅工序)架車就可以繼續行,唔會進入完全郁唔到嘅狀態-架車有一定嘅容錯能力。
喺廿一世紀初嘅工程學上,容錯能力一般俾人認為係一個理想嘅特徵:工程師 設計產品 嗰陣-包括軟件工程師 寫軟件,或者汽車工程師 設計汽車 呀噉,都會想自己設計件嘢有返咁上下容錯能力。有唔少做工程學學術研究 嘅人,仲會深入噉諗同討論「啲系統要點設計,先可以容錯能力高」噉嘅問題[4] 。
喺呢個電腦網絡 裏面,一旦部路由器 壞咗,成個網絡就喪失通訊嘅能力。
一個系統要算得上係「有容錯能力」,起碼需要滿足以下呢啲條件[5] :
冇故障單點 (single point of failure,SPOF):一個系統嘅故障單點係指一個「一旦軭咗,就成個系統軭嗮」嘅部份,例如附圖嗰個電腦網絡 ,成個網絡啲訊號 都要經部路由器 ,先可以由一部電腦傳去第部電腦度,噉部路由器一軭,成個網絡就通唔到訊-個路由器就係個系統嘅通訊嘅故障單點;一個容錯嘅系統最理想係冇故障單點。
故障隔離 (isolation):當個系統出問題嗰陣,個系統需要能夠探測 個問題,並且話俾用家 知「出錯嘅係個系統邊一橛」;例如機械工程 上好興喺機械 上面裝感應器 ,俾用家知部機邊一忽(喺溫度 同壓力 等方面)有唔妥;
故障壓制 (containment) :當個系統出問題嗰陣,個系統要能夠確保個問題唔會「傳播開去」-軭咗嗰忽可以繼續軭,但唔可以拖累個系統嘅其餘部份,搞到淨低嗰啲部份跟住佢一齊軭。
好似噉嘅系統能夠做到得體降級 (graceful degradation)-就算有嘢出咗故障,個系統都能夠或多或少噉繼續運作-「表現會降級 ,但降起級上嚟得體 」噉解。要留意嘅係,上述呢度係講緊「個系統最理想要有呢啲特性」-喺現實世界嘅某啲情況下,呢啲特性好多時一係冇可能達到,一係有可能達到但要花費嘅資源 量大得滯,所以設計者唔會嘗試追求。
設計技巧
喺實際應用上,工程師有唔少方法可以提升個系統嘅容錯能力:
冗餘 (redundancy):指同個系統加啲「多餘」嘅功能,呢啲「多餘」功能喺冇故障嘅世界入面係唔必要;攞住「要提升佢容錯力」嘅系統部份,設計者可以將個系統部份複製幾次,啲複製品用嚟做後備;噉一旦個系統部份軭咗,個系統就可以即刻改為用啲後備部件頂替;舉例說明,啲大型[註 1] 嘅船 同飛機 好興設計成有多過一部發動機 (將發動機複製咗幾次);噉如果架嘢嘅主發動機出咗故障,佢哋就可以改為用後備發動機嚟推動架嘢,等架嘢仲可以繼續行,或者起碼有足夠時間駛去安全嘅地方[2] 。
又例如程式編寫 噉,控制流程 上就有所謂嘅例外處理 (exception handling),好似以下呢段 Python 源碼 噉[6] :
try : #「試吓行 try 嘅碼先。」
print ( x )
except : #「如果 try 段碼出錯,噉就行 except 嘅碼。」
print ( "An exception occurred" )
當中 except:
入面嗰段碼就係冗餘嘅部份-喺冇出錯嘅世界入面,嗰段碼係冇需要存在嘅,但有咗 except:
段碼喺度,就可以喺 try:
段碼出事嗰陣有個後備保障。Python 以外嘅多種程式語言 (好似係 C++ 同 Java 呀噉)都有例外處理嘅功能[7] 。
一條懸索橋 嘅抽象圖解;條橋搵好多條纜吊住,查實條橋就算唔用咁多條纜都一樣吊得起(冗餘)-不過一旦條橋嘅纜出咗問題,搞到成條橋向下跌,會造成嚴重人命財產傷亡,所以工程師就同條橋落大量嘅冗餘,想確保條橋夠嗮安全。
複製 (replication):一種提升電腦 軟 硬件 系統容錯能力嘅技巧;「複製」係指將一個系統部份複製幾次,不過唔係攞嚟做後備,而係要求呢幾件複雜品冚唪唥一齊平行 噉計數,等到要攞個運算結果去用嗰時,就睇勻嗮嗰幾件複雜品嘅運算結果先做決定;例如想像家吓想叫電腦計條好複雜嘅數,研究者可以要 5 部機分別計一次,再攞 5 部機之間嘅主流[註 2] 結果去用,理由係「5 部機冚唪唥都計錯數」嘅機率 細過「其中一部計錯數」嘅機率[8] 。
... 呀噉。
2007 年嘅超級電腦 藍色基因 (IBM Blue Gene);好似藍色基因噉嘅電腦各部份能夠各自噉做大量嘅運算,例如 2005 年嘅藍色基因就可以喺 1 秒內做超過 280 兆 吓運算 [9] ,用家想計複雜嘅數嗰陣,可以教部機同一條計幾次,跟住將主流結果攞去做 output 。
現實考量
2011 年寧波 一條裝配線 喺度組裝汽車 ;汽車係要量產 嘅,所以一架車嘅造價貴咗少少,都可以令總生產成本勁升。
喺實用嘅工程學 上,通常淨係得一小部份嘅部件會有容錯設計:特登加容錯設計係要成本 嘅;例如一架車要整得硬淨,就梗要用更多或者更貴嘅材料 整;而一隻電腦軟件要加啲容錯設計就要落更多行嘅源碼,教部電腦做例外處理,就實令到隻軟件最後大咗 。因為噉,工程師決定「好唔好同呢個部件加容錯設計」嗰時,有諸多考量要諗[10] :
故障可能性 :假設第啲因素不變,一個系統部份愈有大機率 會出故障,就愈有需要同佢落容錯設計。
重要 :假設第啲因素不變,一個系統部份愈重要,工程師就愈大機會想加容錯設計-當中「重要」係指「嗰部份一故障就會搞到個系統喪失功能,或者引致人命財產損失」;例如一架私家車 上面嘅收音機 對架車嘅功能唔係咁必要(冇咗都唔會搞到架車做唔到主要功能,亦唔會引致咩人命財產損失),所以工程師正路唔會專登同架車嘅收音機落容錯設計;相比之下,架車嘅發動機 (冇咗發動機,架車就完全郁唔到)嘅重要部份,就比較有可能會落容錯設計。
成本 :假設第啲因素不變,一款容錯設計嘅成本愈高,工程師就愈細機會會想採用隻設計;例如想像而家要同架車嘅發動機落容錯,原則上,工程師可以索性加多部發動機落去做後備(冗餘 ),但現實表明,要同架車加多部發動機成本極高-汽車係要量產 嘅(相比之下,例如大型郵輪 就唔使量產),所以吓吓都加後備發動機要使多好錢,而且架車個殼又裝唔落兩部發動機(將架車設計到大啲又係令成本大增);所以工程師想同架車嘅發動機做容錯設計,唔會用「加多部發動機做後備」呢種做法。
... 等等。
失效安全 (fail-safe)同失效致命 (fail-deadly):如果話一個系統係特登設計到「失效安全」,即係指佢有故障局部或者完全喪失功能嗰陣,都仲能夠做到保護人 、財產 同數據 免受傷害[11] ;例如一架車,架車設計到有返咁上下硬淨,架車就算失控撞車(故障局部或者完全喪失功能),架車都唔會變形變得太犀利,坐喺入面嘅人同財產唔會受大傷害-就算係達致失效安全;失效致命可以話係失效安全嘅相反,指就算個系統故障局部或者完全喪失功能,佢都能夠成功傷害或者殺死目標-呢種設計喺武器 嘅設計上成日見到[12] 。
人為錯誤 (human error):指若干個人冇意圖噉做咗啲嘢,搞到個系統出現故障,例如一架車失控可以係因為揸嗰個人揸車 技術唔好;人為錯誤喺工程學上廣受關注,因為對工程師嚟講呢種錯誤難以控制;亦都可以睇吓人因工程 同相關領域上對「點樣設計到個系統一睇就知點用 」嘅思考[13] 。
系統工程 (可靠度工程 )
控制理論
順應力
平均故障間隔
「大型」表示「出起事上嚟死得人多」,所以工程師 有強烈誘因 同呢啲船同飛機落容錯設計。
例如其中一部機計到同其餘啲機唔同嘅結果,就攞其餘嗰 4 部機計到嗰個結果去用。
Randell, B. (1975). System structure for software fault tolerance. Ieee transactions on software engineering , (2), 220-232.
Wahbe, R., Lucco, S., Anderson, T. E., & Graham, S. L. (1993, December). Efficient software-based fault isolation. In Proceedings of the fourteenth ACM symposium on Operating systems principles (pp. 203-216).
Mansouri, Najme, Gholam, Hosein Dastghaibyfard, and Ehsan Mansouri. "Combination of data replication and scheduling algorithm for improving data availability in Data Grids", Journal of Network and Computer Applications (2013)
Dubrova, E. (2013). Fault-tolerant design (pp. 55-65). New York: Springer.
Scott, Len (2000). Planning Armageddon . Amsterdam: Overseas Publishers Association. p. 301.
Senders, J.W. and Moray, N.P. (1991) Human Error: Cause, Prediction, and Reduction . Lawrence Erlbaum Associates, p.25.