生命關鍵系統的創新

每個企業都有一個“關鍵”基礎設施。 一般來說，這意味著如果系統下線，部分（或全部）業務將陷入停頓，直到技術人員可以讓它再次運行。 這通常發生在需要進行大型軟件、硬件或網絡升級時：新部署的系統包含導致系統故障的意外錯誤，或者用戶因為不熟悉新系統而在使用新系統時出錯，並且生產力停止，直到技術人員能夠解決部署錯誤或培訓用戶。 在大多數情況下，一段時間的停機或生產力降低是可以接受的風險，以換取提高新技術性能和效率的承諾，但這並不普遍。 大多數企業可以承受一定的停機時間，而不會冒太多收入或激怒客戶的風險。

但是，當您需要修改的系統是生命攸關的系統時會發生什麼，而生命安全取決於能否可靠地使用該系統？

本文遠離我們花費大部分時間的更傳統的軟件開發，而是著眼於生命關鍵系統中的人為因素。 我對這個話題的想法源於我作為 911 救護車服務信息技術總監、國際人道主義災難響應組織的技術專家以及我的博士學位的經歷。 在麻省理工學院完成了人類系統集成。

在我們開始之前，我想解釋一下為什麼這可能與您有關。 雖然您的項目實際上涉及到一個生命攸關的系統可能並不明顯，但它的可能性比您想像的要大得多。 以下所有符合條件的，以及無數更多的主題：

• 汽車。 與汽車製造商或其任何供應商合作開展項目？ 被自動駕駛汽車初創公司從大學招聘？ 自動制動、巡航控制、車道控制、計算機視覺、障礙物識別、電子發動機控制模塊等。每一個都是生命攸關的系統，其中的故障可能是致命的。
• 航空。 當您在空中飛行 30,000 英尺時，幾乎任何系統故障都可能危及生命。 考慮到最近波音 737 MAX 發生的事件，自動駕駛儀和計算機化飛行控制等明顯的生命關鍵系統，但也有很多你可能沒有想到的事情。 在家裡，如果您的暖通空調系統中的風扇出現故障並產生一點煙霧，您可以打開窗戶或走到外面呼吸新鮮空氣。 你有沒有試過在跨大西洋飛行時打開窗戶走出去？ 即使是最基本的系統，從廚房的電源插座到飲料車車輪上的製動器，在飛機上也可能對生命至關重要。
• 通訊。 大多數開發人員或工程師會在其職業生涯的某個階段以一種或另一種身份從事通信系統項目。 對許多人來說，電信最初似乎並不對生命至關重要。 畢竟，在電話和互聯網出現之前，文明的表現還不錯。 作為一個部署到電信基礎設施被破壞的災區的人，讓我告訴你實際發生的事情：人們生病或受傷，無法撥打911； 老年居民不能打電話給他們的孩子讓他們去藥房取藥； 應急響應人員無法與其調度員或彼此溝通； 無法聯繫到家人的人開始擔心，並把自己置於極其危險的境地試圖找到他們。 通信系統對生命至關重要。

在當今嚴重依賴技術的世界中，您從未認為甚至是半重要的項目最終可能成為生命關鍵系統的重要組成部分。

但如果它沒有壞，就不要修復它

您是否聽說過或使用過與技術系統相關的“遺產”一詞？ 這是一個強有力的詞，喚起了人們對悠久傳統、血統和過去困難時期的思考。 在工程界，它用於表示已經存在了很長時間並且已被證明可靠工作並且通常被視為降低風險的理想特徵的設計。 實際上，這是對由於風險規避而從未更新過的古老技術的委婉說法，並且在系統故障可能導致可怕後果的行業中普遍存在。

這種對傳統軟件和硬件的親和力背後有充分的理由。 它是眾所周知的，它不太可能出現未知的錯誤，並且它的成本是穩定和可預測的。 航天工業就是一個很好的例子：俄羅斯聯盟號宇宙飛船已經將宇航員送入太空超過 50 年，在此期間只進行了微小的修改，並且由於可靠和安全而繼續使用。 不幸的是，這意味著與現代設計相比，它的效率也極其低下：雖然聯盟號的每個座位花費 8100 萬美元來使用其傳統硬件將宇航員運送到空間站，但 SpaceX 和波音預計每個座位的價格為 5800 萬美元使用他們的現代火箭設計。

很少有人願意升級仍然有效的舊系統，這是可以理解的。 高管不想冒風險，技術人員不想處理機櫃中運行時間為 12 年的神秘服務器，客戶不想學習新設計。 不幸的是，風險最小化和成本節約之間存在一個臨界點：傳統設計最終需要升級，即使在高風險環境中也是如此。

本文的其餘部分將介紹當您的系統對生命至關重要時執行此操作過程中的一些更重要的步驟，例如急救人員、軍事單位或飛機使用的系統。

說服黃銅

根據我的經驗，這個過程中最困難的一步可能是讓決策者和利益相關者相信需要升級。 在生命攸關的環境中運行的系統通常受到廣泛的法律法規和組織政策的約束，這意味著您必須說服他們，他們不僅應該承擔風險和花錢，而且還應該參與可能很容易發生的幾個多年的官僚剪裁。 您將面臨的最強烈反對可能來自法律團隊，他們將詳細列出您通過引入新技術而使組織面臨的潛在責任。 他們是對的：責任是一個主要問題，如果有什麼東西壞了，有人受傷或死亡，這可能是一個巨大的道德、聲譽和經濟負擔。

無論您是與財富 500 強公司合作還是與當地的志願消防部門合作，它總是歸結為同一件事：金錢。 公司不想失去它，而非營利組織一開始就沒有太多可合作的地方。 我發現說服一個組織的領導層冒險改變一個對生命至關重要的系統的唯一可靠方法是證明，從概率上講，他們要么更有可能賺錢/存錢而不是賠錢，或者他們可以通過技術現代化和提高安全性來減少他們的責任。

這意味著您需要進行數學計算。 由於錯誤（基於您組織中以前的部署或來自其他組織的數據）而導致停機時間延長或未來崩潰的可能性有多大？ 如果它確實失敗了，預期的影響是什麼？成本是多少？ 相反，預期的性能或可靠性增益是多少，它們的價值是多少？ 如果你能證明你很有可能會領先，那麼你很有可能會獲得綠燈。

這不是關於你

您可能熟悉“工程師為工程師”這個短語，這是一個成語，暗示工程師構建的東西是為具有與他們自己相似資格的人使用的。 這是一個極其常見的事件，並且是 1990 年代初期計算機可用性研究興起的主要促成因素之一。 作為工程師，我們通常對技術系統如何工作有與普通最終用戶不同的心智模型，從而導致在設計系統時假設最終用戶已經知道它是如何工作的。 在傳統系統中，這會導致錯誤和不滿意的客戶； 在生命攸關的系統中，它可能導致死亡。

以法航 447 航班為例。2009 年 6 月 1 日，空中客車 A330 在從里約熱內盧飛往巴黎的途中飛越大西洋。 冰晶阻塞了皮託管，導致空氣速度測量值不一致。 飛行計算機脫離了自動駕駛儀，認識到它無法可靠地駕駛飛機本身，因為它的空速數據不正確。 然後它將自己置於“擴展飛行包線”模式，允許飛行員執行計算機通常不允許的機動。 您可以想像構建系統的工程師認為“如果自動駕駛儀自行脫離，可能是因為飛行員可能需要額外的控制！ ”

這是工程師的自然思路，他們了解什麼樣的事情可能導致自動駕駛儀脫離。 對於飛行員來說，情況並非如此。 他們無視“失速”警告，迫使飛機陡峭地向上爬升，直到它失去所有空速並墜入大海。 228 名乘客和機組人員全部遇難。 雖然關於他們行動的確切動機有多種想法，但普遍的理論是飛行員認為飛行計算機會阻止使飛機失速的控制輸入（這對於正常的飛行包線來說是正確的），並且沒有意識到它已切換到擴展包絡模式，因為他們沒有共享工程師對驅動計算機決策的邏輯的心理模型。

雖然有點迂迴，但這引出了我的主要觀點：您希望用戶在特定條件下採取的行動必須是用戶感覺自然的行動。

可以指示用戶遵循特定的程序，但他們並不總是會記住正確的做法或了解在高壓力條件下發生的事情。 您有責任以直觀的方式設計軟件、控件和界面，讓用戶天生想做他們應該做的事情。

這意味著最終用戶參與設計和開發過程的每個階段是絕對關鍵的。 不能假設用戶可能會做什麼； 這一切都必須以證據為基礎。 當您設計界面時，您必須進行研究以確定它們在用戶中引發的思維模式並根據需要進行調整。 當你測試你的新系統時，你必須在真實的環境中和真實的用戶一起測試它們。 不幸的是，當您更改設計時，您必須重新執行這些步驟。

儘管每個複雜系統都是獨一無二的，但我想特別提及三個設計注意事項，它們應該被普遍應用：

• 控件應該代表它們調用的操作。 幸運的是，這種方式相當普遍，通常表現為為 GUI 按鈕選擇相關圖標或為物理控件選擇相關形狀。 “新文件”按鈕使用一張白紙圖標，飛機上的起落架桿有一個輪子形狀的旋鈕。 但是，很容易變得自滿。 為什麼我們仍然看到“保存”按鈕的 3.5 英寸軟盤圖標？ 25歲以下的人都知道軟盤是什麼嗎？ 我們繼續使用它，因為我們認為它具有代表性，但實際上已經不是了。 它需要不斷努力以確保控件的表示對用戶有意義，但平衡它與連續性也是必要且困難的。
• 如果警告系統發生故障，它必須是可檢測的。 我們經常使用在出現問題時激活的警告燈，例如閃爍的紅色指示燈。 這對於吸引用戶的注意力非常有用，但是如果燈燒壞了怎麼辦？ 阿波羅登月任務中使用的航天器有幾十個警告燈，用於各種系統，但它們並沒有以常規方式運行。 它們不是在出現問題時點亮，而是在一切正常時保持點亮，並在出現問題時關閉。 這確保了燒壞的警告燈不會導致宇航員錯過潛在的致命系統錯誤。 我並不是說您應該使用這種設計，因為自 1960 年代以來，燈泡在可靠性方面已經取得了長足的進步，但它可以讓您了解您的一些計劃必須有多深入。 有多少次系統崩潰但您不知道，因為日誌記錄或通知無法正常運行？
• 模式轉換對用戶來說必須是顯而易見的。 如果空客 A330 在用戶沒有註意到的情況下從正常控制模式轉換到高級控制模式，突然飛機做了用戶認為它做不到的事情，會發生什麼？ 如果自動駕駛汽車脫離其自動駕駛儀，讓用戶意外地完全控制會發生什麼？ 當模式或功能發生任何重大轉換需要立即更改用戶的操作，但用戶需要一兩分鐘才能弄清楚剛剛發生了什麼時，會發生什麼情況？ 雖然在復雜系統中可能需要多種操作模式，但在沒有足夠的通知、解釋和與用戶交互的情況下，模式無法轉換。

將生命攸關的系統滾出車間

根據行業最佳實踐，測試階段對於部署新的生命攸關係統至關重要。 新技術的測試可能已經幫助您糾正了大多數錯誤和可用性問題，但是當它必須與現實環境中的其他系統一起使用時，可能會出現隱患。 在系統工程學科中，這被稱為“湧現”。 緊急屬性是“源於應用程序組件與其環境之間的交互的意外行為” ，就其本質而言，在實驗室環境中基本上不可能檢測到。 通過邀請一組有代表性的最終用戶在仔細監督下試用您的新系統，可以檢測和評估其中許多屬性，以了解可能在全面部署中出現的負面後果。

在與我的客戶進行架構討論時經常出現的另一個主題是分階段推出。 這是在用新系統的元素逐漸替換現有系統的元素直到最終所有內容都被替換與一次更改所有內容之間的選擇。 每種都有優點和缺點：分階段推出允許用戶逐漸適應新設計，確保更改以可管理的數量進行，並且不會讓用戶不知所措； 另一方面，它可以將過程拖出很長一段時間，並導致持續的過渡狀態。 立即推出是有益的，因為它們“撕掉了創可貼”並加快了速度，但突然的劇烈變化可能會讓用戶不知所措。

對於生命攸關的系統，我發現分階段推出通常更安全，因為它們允許在生產環境中對單個組件進行增量評估，並在需要回滾某些內容時允許較小的回滾。 但是，這需要根據具體情況進行評估。

偏差歸一化

好的，所以您的用戶測試幫助您設計了一個直觀的系統，您的 beta 階段識別了緊急問題，您的分階段推出讓用戶對設計感到滿意，並且一切運行順利。 你完成了，對吧？ 不幸的是沒有。

您的系統將不可避免地出現問題，這是無法解決的。 當用戶遇到這些問題時，他們通常會制定解決方法，而不是向技術團隊報告問題。 這些變通辦法將成為標準做法，作為從老手到新秀的“技巧”分享。 社會學家黛安·沃恩（Diane Vaughan）創造了一個詞來描述這種現象：“偏差正常化”。 用戶變得如此習慣於異常行為，以至於他們忘記了它實際上是異常的。

經典的例子是挑戰者號航天飛機：固體火箭助推器中的一個部件在發射過程中經常被觀察到腐蝕，雖然每個人都知道腐蝕火箭部件是一件壞事，但這種情況經常發生，以至於定期發出豁免並被認為是普通的。 1986 年 1 月 28 日，原本大家都知道不應該被允許，但已經正常化的問題，導致了挑戰者號的爆炸和七名宇航員的死亡。

作為生命攸關係統的管理員，您有責任防止此類事件的發生。 研究您的用戶如何與系統交互。 跟踪他們幾天，看看他們是否使用了意想不到的解決方法。 定期發送調查以徵求建議的更改和改進。 在您的用戶找到在沒有您的情況下解決問題的方法之前，花時間和精力來改進您的系統。

壓力下的表現訓練

當用戶遭受壓力、腎上腺素激增和視野狹窄時，通常會發生生命關鍵系統的故障。 它發生在法航 447 的飛行員身上，發生在不記得如何對第一個心臟驟停患者操作心臟監護儀的護理人員身上，發生在士兵在受到攻擊時無法正常操作無線電的情況。

通過使用前面討論的直觀設計可以減輕部分風險，但僅此一項是不夠的。 特別是在高壓力場景確實發生但很少發生的環境中，不僅要培訓用戶如何操作系統，還要培訓用戶在這種情況下如何清晰思考。 如果用戶記住了與操作設備相關的動作，他們就無法應對意外故障，因為他們學到的動作可能不再適用； 如果他們訓練在壓力下邏輯清晰地思考，他們可以對不斷變化的環境做出反應，並在出現問題時幫助您的系統保持活力。

結論

顯然，開發、部署和維護對生命至關重要的軟件比在一篇文章中詳述的要復雜得多。 但是，這些考慮的領域可能會幫助您更好地了解在考慮從事此類項目時會發生什麼。 總之：

• 創新是必要的，即使一切順利
• 很難讓高管相信風險是值得的，但數字不會說謊
• 最終用戶必須參與流程的每一步
• 在現實條件下，在真實環境中與真實用戶一起進行測試和重新測試
• 不要以為你第一次就做對了； 即使它正在工作，也可能存在您的用戶沒有告訴您的未檢測到的問題。
• 不僅要培訓用戶如何使用系統，還要培訓用戶如何清晰地思考和適應壓力。

最後，我想指出，在復雜的安全關鍵系統中，無論您進行多少計劃、測試和維護，事情都會在某個時候出錯。 當這些系統對生命至關重要時，故障很可能會導致生命或肢體喪失。

萬一發生這樣的悲劇發生在你要負責的事情上，這將是你良心的沉重負擔，你可能會認為如果你多加註意或努力工作，就可以避免它。 也許這是真的，也許不是，但不可能預見每一種可能發生的事情。

一絲不苟地工作，不要自大，你會讓世界變得更美好。