跳去內容

容錯能力

出自維基百科,自由嘅百科全書
(由容錯性跳轉過嚟)
2008 年加拿大一角有架爆咗呔;條係架車嘅其中一橛,不過就算呢橛仔有故障,架車頂攏郁唔到一陣-架車有咁上下容錯能力。
  提示:呢篇文講嘅唔係容錯原則

容錯能力粵拼jung4 co3 nang4 lik6英文fault tolerance),又叫故障容許度,係一個系統可以有嘅一種特性,指個系統「喺某個或者某啲組成部份故障嗰陣,有幾能夠繼續正常運作」,亦都包埋個系統喺呢種情況下「表現會跌幾多」[1]

  • 冇容錯能力:一旦個系統其中一橛出咗錯,就成個系統軭嗮;
  • 有咁上下容錯能力:一旦個系統其中一橛出咗錯,佢依然行到,但表現會明顯變差;
  • 「得體」嘅容錯能力(得體降級):隨住系統越來越多出錯,佢依然行到,表現只會細微噉變差。

舉個例說明,想像家陣有隻電腦軟件(系統),佢會接收由用家等來源嚟嘅 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]
  • 系統工程可靠度工程
  • 控制理論
  • 順應力
  • 平均故障間隔

拉雜相關

[編輯]

註釋

[編輯]
  1. 「大型」表示「出起事上嚟死得人多」,所以工程師有強烈誘因同呢啲船同飛機落容錯設計。
  2. 例如其中一部機計到同其餘啲機唔同嘅結果,就攞其餘嗰 4 部機計到嗰個結果去用。

引咗

[編輯]
  1. Adaptive Fault Tolerance and Graceful Degradation, Oscar González et al., 1997, University of Massachusetts - Amherst
  2. 2.0 2.1 Laprie, J. C. (1985). "Dependable Computing and Fault Tolerance: Concepts and Terminology" (PDF), Proceedings of 15th International Symposium on Fault-Tolerant Computing (FTSC-15), pp. 2-11.
  3. Software Fault Tolerance. Carnegie Mellon University.
  4. Randell, B. (1975). System structure for software fault tolerance. Ieee transactions on software engineering, (2), 220-232.
  5. 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).
  6. Python Try Except.
  7. Exceptions in Java. GeeksForGeeks.
  8. 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)
  9. Blue Gene/L tops its own supercomputer record. Cnet.
  10. Dubrova, E. (2013). Fault-tolerant design (pp. 55-65). New York: Springer.
  11. "When Failure Is Not an Option: The Evolution of Fail-Safe Actuators". KMC Controls. Retrieved 12 April 2021.
  12. Scott, Len (2000). Planning Armageddon. Amsterdam: Overseas Publishers Association. p. 301.
  13. Senders, J.W. and Moray, N.P. (1991) Human Error: Cause, Prediction, and Reduction. Lawrence Erlbaum Associates, p.25.

[編輯]