作者丨Glenn Fleishman
譯者 | Sambodhi
編輯 | Tina
導讀：對很多人來說，NASA 非常神秘。NASA 即美國國家航空航天局，是美國聯邦政府的一個行政機構，負責制定、實施美國的民用太空計劃，以及開展航空科學暨太空科學的研究。NASA 負責美國的太空探索，例如登月的“阿波羅”計劃，太空實驗室，以及隨後的太空梭。特別值得一讚的是，NASA 也熱烈擁抱了開源：在航天領域中，NASA 在開源方面走在前列，已開源了大量軟體、設計工具，涵蓋了航天器整個研製和應用過程。眾所周知，NASA 每次太空任務都離不開先進的軟體程序。可能大多數人不清楚的是，今天的“軟體工程”這一概念，正是發軔於 NASA。由此軟體架構的重要性可見一斑。Glenn Fleishman 和我們分享了 NASA 的軟體架構的演變等方方面面，可讀性非常高。InfoQ 中文站將其翻譯出來，只是為了不忘初心：我們的征途是星辰和大海！
當你在離家數百萬英裡的太空時，如果伺服器崩潰了，可沒有人能聽見你恐慌的呐喊！所以對 NASA 來說，冗余特別重要，既然可以發送五台伺服器到平流層外，他們就必定不會隻發送一台。
在太空裡，宇宙射線、磨損、突發故障各種不確定因素都會對設備造成影響，軟體架構必須非常健壯。軟體架構領域的創始人、NASA 噴氣推進實驗室的傑出訪問科學家 David Garlan 說，航天器系統尤其需要一個故障保護層，使它們在沒有地球方面的直接乾預下能夠切換到緊急狀態。
相對地面的軟體，航天軟體的設計更難。
在地面，如果一台數據中心的伺服器性能過於緩慢，可以不斷增加伺服器來解決問題，但航天器的計算能力短缺問題卻不能靠增加機器的方式解決。航天器的算力在整個任務期間保持不變，系統必須設計成能自動丟棄某些給定的任務。
如果是一台地面上的數據庫伺服器，無法實時插入數據也不會造成太大的影響。但是，一艘飛奔火星的宇宙飛船，如果其運行周期沒有得到完美的控制，可能會與火星完全失之交臂。
持續運行 2700 天，靠的就是自恢復策略。
航天器能用的計算機台數是有嚴格限制的。增加物理備份，會讓航天器的軟體變得更具彈性。對於 1972 年至 2011 年的 NASA 太空梭項目來說，僅有三到四台計算機是不夠的，那時共有五台飛行控制計算機，再多增加一台是需要設計人員反覆考慮的事情。
此外，NASA 還制定了一項策略，允許軟體在最壞的情況下恢復。這一策略在 1961 年至 1972 年的“阿波羅”（Apollo）計劃中途首次實施，它是為了出現問題時而明確設計的。如果沒有這一策略，一項又一項的任務將不得不放棄。
在 1977 年的發射期間，NASA 太空探測器“旅行者 2 號”（Voyager 2）記錄了一些抖動，這些抖動很可能導致伺服器“宕機”，科學家也無法預料程序將如何解讀這些抖動，但是探測器最終還是正確地進入了恢復模式。
“機遇號”（Opportunity）火星車於 2003 年發射，原計劃在火星上運行 90 天，但實際上，到 2018 年中，它仍在運行，總共 5111 天。這台火星車本來設計壽命為 90 天，但卻超額服役 15 年，中間曾經根據采集的移動數據重寫代碼，來繞過一條電纜短路造成的故障。
“好奇號”（Curiosity）於 2011 年發射，最初計劃在火星上運行 687 天，但它到今天仍然運行，截止本文寫作時，已超過 2700 天。“好奇號”火星車在火星上的第一年和第五年，其兩台主計算機曾出現過故障，差點造成任務失敗。
有時候，冗余也能增加機會。
“旅行者 2 號”在 1986 年經過天王星，1989 年經過海王星時，要不是“旅行者 2 號”有一套備用的計算機，再加上任務控制中心能夠上傳新的軟體來利用這些備用計算機，否則，“旅行者 2 號”能夠拍攝到的天王星和海王星的照片就會少得很多。
能打敗墨菲定律的只有備份
允許有幾分鐘“停服”時間，還是擁有故障轉移解決方案，這是需要權衡利弊的。在地球上計算的硬體已經從單一業務大型機發展到功能強大的伺服器冗余陣列，這種陣列允許其中一個或多個伺服器出現故障，但並不會因此中斷業務。出於必要，NASA 也決定讓太空中多台計算機運行重複功能。
就算是完美的軟體、完美的硬體，仍然也有可能在太空中崩潰：能夠打敗墨菲定律和宇宙射線的只有備份。在“阿波羅”計劃期間，NASA 曾致力於確保每個部件和系統都經過測試，直到確定它是完美的。然而，此舉既昂貴又脆弱。
“完美“解決不了問題
有兩個著名的例子說明了依賴完美的問題。女工程師 Margaret Hamilton 是麻省理工學院在 20 世紀 60 年代末開發“阿波羅”計劃軟體的團隊負責人，她經常在深夜和周末帶著蹣跚學步的女兒 Lauren 到辦公室加班。在 1968 年底執行的“阿波羅 8 號”任務將標誌著宇航員首次繞月飛行，在此之前，小女孩 Lauren 通過“阿波羅”計算機 DSKY，即一個鍵盤和顯示器的組合，來玩指令艙模擬器。她出人意料地觸發了預發射順序，從而使飛行模擬發生崩潰。
Hamilton 試圖說服 NASA 允許她引入錯誤檢查，以防止宇航員在執行任務時犯下同樣的錯誤，儘管這種錯誤不太可能會發生。但 NASA 駁回了她的請求，堅稱宇航員將會完美地完成任務。不得已，Hamilton 在手冊上標注了有關這一問題的可能性。
然後，宇航員 Jim Lovell 在“阿波羅 8 號”的飛行中恰巧也選擇了相同的順序，結果，從飛船的記憶體中擦除了返回地球所需的導航數據。在“阿波羅 13 號”在發生爆炸的時候曾對休斯頓指揮中心回報了一句非常著名的話：“休斯頓，我們有麻煩了”（Houston, we have a problem），萬幸的是，“阿波羅 13 號”成功地處置了這一險境，與其說是跳上一艘臨時救生艇，不如說是找到備用磁帶：Hamilton 和她的團隊能夠從地球上傳輸導航數據，因為該系統足夠靈活，可以在傳輸過程中接受這些輸入。
Hamilton 將系統設計為具有彈性，可以在出現不堪重負的情況下，系統仍然可以不受干擾地恢復正常運行，並允許它報告錯誤，同時提供足夠的信息以做出判斷。在這種情況下，計算機的負載管理軟體專注於更高優先級的任務，包括雷達輸入，並按預期執行。在任務控制中心經過緊張而迅速的磋商之後，宇航員在月球著陸器的燃料耗盡前幾秒鐘獲得了批準。
1994 年，Hamilton 告訴《航空航天》（Air & Space）雜誌：“我們的軟體挽救了這次任務，因為它是異步的，因為它會跳過低優先級的任務，如果沒有它，這次任務就會失敗，或者在月球上墜毀。”
計算機已經變得越來越強大，軟體工程，Hamilton 為航天飛行創造的這一術語，經過幾年的發展已經趨於成熟。因此，太空梭的設計沒有考慮主系統和備份系統，甚至也沒有考慮幾個備份系統，而是依靠四台獨立的計算機運行相同的導航和製導軟體，並接收相同的數據輸入。
這四台計算機作為民主的縮影而運作。它們中的三台計算機必須就它們所衡量的內容達成共識，才能采取行動。如果三台計算機同意，而第四台計算機不同意，那麽出現這種情況宇航員就會關機或重新啟動它。這就使得避免災難或代價高昂的停頓所需的快速決策成為必要。
如果多台計算機出現故障，或者無法達成共識，那麽一台同樣可以訪問太空梭控制系統的額外計算機就可以接管。它可以進行預編程的粗略（但安全）的上升、中止和再入。
冗余之上再冗余
1964 年，噴氣推進實驗室的科學家 Gary Flandro 計算出，到 20 世紀 70 年代末，木星、土星、天王星和海王星將排成直線，允許探測器利用重力助推（gravity assists，亦稱重力彈弓效應、繞行星變軌）來訪問這幾顆行星，圍繞行星旋轉以獲得加速度。這樣的排列，每 175 年發生一次。“旅行者號”被派往太空執行探測任務。
“旅行者號”任務的許多方面都有冗余性，它的兩個探測器是在不同的地點分別發射的。其中“旅行者 1 號”和“旅行者 2 號”又都配備了兩個並行的計算機系統。如果三台 A 計算機（分別用於指令、數據管理和姿態控制）中的一台出現故障或崩潰，探測器可以自動切換或通過指令切換到 B 系統。
“旅行者號”探測器也是 NASA 第一個使用軟體檢測故障的探測器，可以分析各種事件，並在沒有指示的情況下能夠做出相應的反應。正如任務發射前項目經理 John Casini 在《旅行者號的故事》（Voyager Tales）一書中的採訪中指出的那樣：我個人對“偉大航路”（Planetary Grand Tour）的看法是：“運載火箭的轉動速度比宇宙飛船在太空中的轉動速度要快得多。”然而，在這種速度下，“旅行者 2 號”還是遇到了意外情況，幸運的是它自己判斷到了，並將自己重新置於安全模式。
Casini 說，甚至在地面讓工作人員弄清楚發生了什麽事之前，“宇宙飛船與運載火箭分離後就自行恢復了。”項目人員隨後在發射前更新了“旅行者 1 號”的軟體，探測器設法正確處置了旋轉和抖動。
如今，“旅行者號”已經離開了太陽磁泡的範圍，但還沒有離開太陽系，而是所謂的太陽圈（heliosphere），現在，正在星際物質中遨遊。但是，即使距離如此之遠，“旅行者號”仍然可以傳回數據，並且仍能讓繼續管理這些數據的小團隊感到驚訝。到了 2010 年，“旅行者 2 號”開始發回一些無意義的信息，而不是科學數據。於是，科學家們將探測器切換到待機模式，這種模式的代碼是經過幾十年的改進形成的，同時他們也發現了問題所在。他們將程序恢復到了之前的狀態，再次使用每秒 160 比特的速率把數據發回地球。
冗余也會引發問題
在太空中，系統並不容易進行升級。對於不可能進行硬體升級的任務來說，“冗余”是個正確的選擇，但它也可能會導致其它問題。麻省理工學院航空航天系的 Nancy G.Leveson 教授在一篇題為《軟體在航天器事故中的作用》（The Role of Software in Spacecraft Accidents）中寫道：
NASA 對一架裝有兩個版本的控制系統的實驗飛機進行了研究，發現在飛行測試期間中出現的所有軟體問題，都是由於冗余管理系統中的錯誤造成的，而不是控制軟體本身，控制軟體運行正常。我們需要為軟體設計保護功能，以反映軟體的“故障”模式。
另一個重要的問題是，現代航天器系統比它們的前身要複雜得多。隨著更多的算力和更多的任務可以在任務期間處理，驅動當今飛船的代碼變得異常複雜：不可避免的是將會出現一些錯誤。如果缺乏標準的軟體架構，會加劇引發故障。但即使是現今計劃中最先進的航天器，在一定程度上也依賴於較舊的軟體架構概念。“獵戶座”飛船的設計目的是在未來的載人航天任務中將宇航員送上月球，它將搭載四台計算機，每台計算機都有兩個並行工作的處理器，其結果必須一致。每台計算機的軟體都表現得就像它在獨立駕駛航天器一樣。
這些計算機不是民主主義者（Democracy），而是唯我論者（Solipsist），每台計算機都認為自己是“宇宙中唯一的計算機”。如果一台計算機未能在正確的時間提供正確的指令，系統被設計成在系統故障時重新啟動，並接受來自下一台計算機的指令。與太空梭一樣，“獵戶座”飛船也將配備一台備用飛行計算機。
距離人類首次登月已經過去 50 多年了，月球是地球唯一的天然衛星，安全返回依然需要付出巨大的努力。
作者介紹
Glenn Fleishman，家住華盛頓州西雅圖市，曾撰寫了關於 19 世紀的美國、比特幣和小衛星（nanosatellites）的文章。他最新的著作《London Kerning》，講述了到目前為止的倫敦印刷排版的歷史探索。
本文最初發表在 Increment，經原作者 Glenn Flsishman 授權，InfoQ 中文站翻譯並分享。
https://increment.com/software-architecture/in-space-no-one-can-hear-you-kernel-panic/
香港九龍灣馬來街興發大廈15樓D室