系統安全軟體健壯性

最近一年，飛機失事的事情發生了好多起。於是乎，飛機是否是一種安全的出行工具的討論又再一次燃起了戰火。

我無意對該話題展開討論，只是可以舉個例子說明一下。

如果a城市一年出了10次搶劫事件，b城市一年出了1次殺人事件。那麼可能會有很多人覺得b城市相對更不安全。

正是因為飛機失事一般會帶來非常嚴重的後果，所以飛機的設計比其他的交通工具要優秀的多。

這裡，我們參考一下傳統工程的設計思想，來看看我們的系統是否安全。

先說明一下，在本文中，安全的定義比較廣義，即是系統不會被災難性的破壞。

比如：汽車自動駕駛系統不會突然指令錯誤，賬務系統不會出現計算錯誤而對使用者造成資金損失。

所以可以認為是一種健壯性。

那麼，首先看乙個案例——法航447號航班空難

簡單介紹一下官方公布的失事原因

飛機在夜晚啟用自動駕駛模式後，進入亂流區域，然後皮託管結冰。皮託管是安置在飛機外面，根據氣流經過的速度而取得飛機速度的一種裝置。所以皮託管結冰後，飛機無法得知當前速度，系統解除了自動駕駛模式並開始報警。

駕駛員接手開始手動駕駛飛機。而突然聽到報警有些緊張的駕駛員由於無法得知當前速度，所以拉公升飛機。（人們只是猜測他可能是出於本能）

抬公升角過高，所以導致飛機失速。想象一下，飛機如果水平向前，將獲得向前的動力，如果機頭過高，則水平方向的速度將會降低，最終失速而往下掉。

最終掉入大海。

皮託管，右邊進氣左邊出氣，根據氣流測速

這個案例其實給我們乙個非常深刻的教訓，除了飛行員駕駛失誤意外，系統設計不足也占有非常重要的原因。

在設計中，barrier是乙個非常重要的考慮因素。barrier是防止系統出錯，或者說是當系統出現異常的時候的一種自我防禦機制。

例如：家庭用電時要考慮空氣開關。

自動扶梯要考慮緊急制動。而不是設定乙個警示牌教導人遇到情況怎麼從扶梯上跳下來。

房間要考慮煙霧報警器並連線消防局。而不是安排乙個人敲鑼高呼天乾物燥小心火燭。

汽車要安裝安全帶。

而本案例中，皮託管會結冰，並且結冰後無法測速這個難題在設計的時候確實有過考慮，而它的防禦機制則是：系統報警。

恰巧，接手處理報警的飛行員經驗不足，而最終導致失事。

當我們在設計系統的時候，需要考慮怎麼設定乙個良好的barrier，盡最大可能去解決問題，而盡可能少的將問題拋給愚蠢的人類去處理。

對於關鍵的元件，必要的 barrier 則是為它建立乙個基於完全不同實現的備用元件。假如元件a失效的可能性為1%，而備用元件b失效的可能性為2%，那麼由元件a元件b組成的新元件失效的可能性就只有1%*2%為0.02%了。大大降低了故障可能發生的機率。

例如：

如圖所示，如果barrier是基於相同的演算法或者實現方式，那麼它們可能會有同樣的漏洞，無法起到真正的防禦作用。

法航失事的案列正好也說明了空客a330-203的測速裝置設計不足。如果再配有另外一種不基於氣流測速的裝置，可能不會導致無法測速，也不會最終導致系統報警。

所以當我們在設計關鍵的模組或者演算法的時候，需要增加一種或者多種不同實現，進行交叉校驗。以保證模組或者演算法輸入輸出正確。

如圖，模組1與模組2的結果核對相同後，才確定最終輸出

曾經看到過乙個案例，有位先生開著汽車出去兜風，發動機突然熄火。結果剎車和方向盤同時失靈，因為發動機熄火後沒有助力提供了。

所以，我們的功能必須首先高內聚，形成乙個模組乙個元件，這樣才能對它新增barrier。而模組間的聯絡越少，則它的barrier更容易實現且更堅固。

前面那個剎車失靈的例子也正說明了發動機、剎車和方向盤這些部件之間的關係過於緊密而導致互相影響，乙個失效而帶來了連鎖反應。

從程式的角度來看，可以舉個例子，如果乙個vo從前端經過各個功能模組最終傳遞到資料庫，那這樣無法避免模組間的互相干擾——假如變更了vo中的乙個變數，則可能模組a、b、c可能同時受到影響。同時，為模組a、b、c設定的barrier可能也無法正常工作。從測試的角度來看，這也是一種災難。

反思我們的系統，是不是有這樣的情況：

乙個好的軟體系統，需要**的功能內聚，職責單一，模組間低耦合，並且需要每個重要的功能設定合理和必要的barrier以保證輸入輸出正確。

因為彼此不信任，所以安全。

系統安全 軟體健壯性