1990年ACM圖靈演講:論建造會失敗的系統

致 Fernando J. Corbato 感謝他在組織概念並領導開發通用大型分時及資源共享電腦系統 CTSS 和 MULTICS 方面所做的貢獻。

接受 Alan Turing Award 是我的榮幸和樂趣。我自己的工作是關於電腦系統的，這將是我今天的主題。系統的本質在於它們是整合性的努力，需要對待解決的問題領域有廣泛的知識，而所需的詳細知識很少由一個人掌握。因此，系統的工作通常是由團隊完成的。因此，我接受這個獎項，既是為了我自己，也代表了與我共事的許多人。要點出所有貢獻者的名字並不實際。儘管如此，我還是要特別提及 Marjorie Daggett 和 Bob Daley 在 CTSS 誕生的部分工作，以及 Bob Fano 和已故的 Ted Glaser 在 Multics System 開發中的關鍵貢獻。

現在讓我來談談今天演講的標題：「論建造會失敗的系統」。當然，我選擇這個標題是為了吸引注意力。我考慮過並放棄了一些替代標題：「論建造雜亂無章的系統」，但這顯得太輕浮，並暗示沒有系統性的方法。「論掌握系統複雜性」聽起來像是掌握了所有答案。最接近的標題「論建造可能會有失敗的系統」沒有我想要表達的必然性細微差別。

我真正想談論的是一類系統，由於找不到更好的說法，我將稱之為「雄心勃勃的系統」(ambitious systems)。幾乎不用說，雄心勃勃的系統從來沒有完全按照預期運作。事情通常會出錯——有時是以戲劇性的方式。這引出了我的主要論點，即在設計這類系統時要問的問題不是：「事情會出錯嗎？」，而是「事情何時會出錯？」

例子

現在，雄心勃勃但會失敗的系統實際上比我們想像的要普遍得多。事實上，在某些情況下，我們甚至會追求它們，並陶醉在意想不到的刺激中。例如，讓我提醒大家我們的國家運動——美式足球。這項運動的整個目標就是讓每個團隊都在其能力的極限下比賽。除了所需的純粹體能技巧外，還有戰術上的錯綜複雜，以及在意外情況下調整指令和快速反應的能力——這些都是比賽的深層部分。當然，偶爾一支球隊會接近完美，所有的戰術都奏效，比賽就變得無聊了。

另一個過於雄心勃勃而無法達到完美的系統例子是軍事戰爭。雙方都有相同的元素，必須不斷地即興應變並處理意外情況。事實上，我們從軍隊那裡得到了一個美妙的縮寫 SNAFU，委婉地翻譯為「情況正常，一團糟」(situation normal, all fouled up)。如果你仍然懷疑，請考慮敵對行動一開始，那些「精確轟炸」(precision bombing)和「外科手術式打擊」(surgical strikes)等詞語是多快被「戰爭迷霧」(the fog of war)和「友軍誤傷」(casualties from friendly fire)所取代的。

再稍微輕鬆一點，讓我以在 Boston 開車作為會失敗的系統的一個例子。汽車交通是一個極好的分散控制案例，它有一套稱為交通規則的共同協議。Boston 地區以司機對這些惱人的規則進行自由解釋而聞名，而其縮影或許就發生在交通環島（rotary）中。環島有其優點。它們效率高。無需等待遲緩的交通信號燈。它們直接。它們也為富有創意的即興應變提供了絕佳機會，從而為駕駛這項運動增添了樂趣。

最有效的策略之一是，司機接近環島時會僵硬地固定頭部，當然是直視前方，暗地裡則將周邊視覺用到極致。如果司機在進入環島時加速，效果會更好，有些司機還會在最後一步加上一副狂躁的表情。其效果當然是恐嚇，並迅速形成一種階級秩序。之所以沒有發生更多事故，唯一的理由是大多數司機還有一層策略，那就是他們假設其他人可能都是瘋子——他們通常都是對的——而每個司機實際上都準備好在僅剩幾英寸的距離時停車。我們再次看到一個雄心勃勃的策略與審慎的謹慎結合，最終導向有效解決方案的系統例子。

到目前為止，我給的例子可能暗示雄心勃勃系統的失敗來自人為因素，而至少系統的技術部分是可以正確建造的。特別是，回到電腦系統，這似乎只是除錯程式碼的問題。有些人認為嚴格的測試就能搞定。有些人把希望寄託在證明程式正確性上。但不幸的是，在許多情況下，這些技術都無法總是奏效[1]。讓我提供一個如 Figure 1 所示的簡單例子。

考慮一個精密的數值計算案例，其中變數 f 代表某個物理值，它在參數 t 的一個範圍內，針對一系列點進行計算。物理變數的特性是它們通常不會呈現突然的變化或不連續性。

那這裡發生了什麼？如果我們看看 f 的表達式，我們看到它是常數 k 加上另外兩個函數 g 和 h 的乘積。再看下去，我們看到函數 g 的行為隨著 t 的增加而呈指數級增長。另一方面，函數 h 隨著 t 的增加而呈指數級衰減。函數 g 和 h 的乘積隨著 t 的增加幾乎保持恆定，直到發生一個突然的跳躍，並且 f 的曲線變平。

Figure 1 一個微妙的錯誤 (A Subtle Bug) 其中 f(t) = k + g(t)h(t) g(t) = exp(at) (a > 0) h(t) = exp(-bt) (b > 0) t -----> | ..... 曲線顯示f在某個t值處突然下降變平) ....

Figure 2 偵錯程式碼 (Debugging the Code) 非收斂迭代法導致根值不良 (Nonconverging Iterative Method Caused by Poor Root Value) (圖示立方體方程可能有不良根值的圖)

出錯的地方是什麼？答案是，在曲線的關鍵點發生了浮點數下溢 (floating-point underflow)，即負指數的表示超出了此特定電腦浮點數表示中的欄位大小，並且硬體自動將函數 h 的值設為零。這通常是合理的，因為小數值可以被正確地近似為零——但在這個情況下卻不是，我們的結果會嚴重錯誤。更糟的是，由於 f 的計算可能是內部進行的，很容易想像 Figure 1 所示的失敗可能不會被注意到。

因為正確處理這個例子所代表的病態情況是一個額外的工程麻煩，所以下溢問題經常被忽略也就不足為奇了。但從這個例子學到的更大教訓是，微妙的錯誤非常難以避免，並且在某種程度上是不可避免的。

我遇到的下一個例子發生在我作為研究生在開創性的 Whirlwind 電腦上編程時。一天晚上，當我等待使用電腦時，在我前面的研究生開始抱怨他的一些計算有多「艱難」。他說他正在計算某個機翼結構在一系列情況下的振動頻率。事實上，他的方程式是三次方程式，他使用的是迭代的 Newton-Raphson 方法。出於他不理解的原因，他的方法找到了其中一個根，但其他根卻沒有「收斂」。他正試圖通過修改他的程式來解決這個問題，以便當他遇到這些「艱難」的根時，程式會在固定次數的嘗試後放棄迭代。

當時有幾件事出了問題：首先，他的三次方程式係數是基於實驗數據的，有些點根本就不對。因此，正如 Figure 2 所示，他只有一個實根和一對虛根。因此，他的迭代方法永遠無法收斂到第二和第三個根，而他計算的第一個根值完全是垃圾。其次，三次方程式有精確的解析閉式解，所以完全沒有必要使用迭代方法。第三，基於他不完整的模型和對正在發生的事情的理解，他在修補程式時做出了非常糟糕的判斷，忽略了那些看似難以計算的值。

雄心勃勃系統的特性

接下來，讓我談談雄心勃勃系統的一些一般特性。首先，它們通常非常龐大，並且具有超出簡單複製的顯著組織結構。其次，它們通常複雜或精巧，即使是小團隊也難以開發。第三，如果它們確實雄心勃勃，它們就是在挑戰人們已知的能力極限，因此關於何時能夠完成總是存在一定程度的不確定性。由於要開始一個雄心勃勃的專案必須是樂觀主義者，所以低估完成時間是常態也就不足為奇了。第四，雄心勃勃的系統一旦奏效，通常會開創新的領域，提供新的服務並很快變得不可或缺。最後，雄心勃勃的系統通常會通過開闢新的使用領域，引來大量的改進和變革。

現在有人可能會爭辯說，雄心勃勃的系統只有在第一次或第二次時才困難。這實際上只是學習如何去做的事情。一旦學會了，就只需制定適當的 PERT 圖表，僱用優秀的經理，確保充足的預算，然後繼續進行。也許有些情況下這是奏效的，但至少在電腦系統領域，有一個根本原因使得這無法實現。

科技變革的角色

我們似乎無法把雄心勃勃的系統做對的一個關鍵原因是變革。電腦領域沉醉於變革之中。我們看到了四十年間的飛速增長，而且這種增長似乎仍在持續。這個領域尚未成熟，但已經直接或間接佔國民生產總值的很大一部分。更重要的是，電腦革命——這第二次工業革命——已經改變了我們的生活方式，並催生了無數新的應用領域。而所有這些變革和增長不僅改變了我們生活的世界，還提高了我們的期望，在航空公司預訂、銀行業務、信用卡和空中交通管制等不同領域催生了越來越雄心勃勃的系統。

電腦產業令人難以置信的增長背後，當然是數位邏輯原始性能同樣令人咋舌的變化。Figure 3 所示，雖然不精確且許多人之前可能以某種形式見過，但它顯示了頂級電腦在每個十年的性能。正如你所見，縱坐標以 MIPS 為單位採用對數刻度。特別是在最近的十年裡，圖形變得依賴於具體問題，因此線的右上角部分應該分散成某種鬚狀，因為越來越多的電腦是為特殊應用和並行處理量身定制的。

Figure 3 性能 (Performance) 頂級電腦在每個十年的性能 (Performance of a Top-of-the-Line Computer by Decade) MIPS 100 10 1 0.1 1950 1970 1990 年份 Year (圖表顯示性能從1950年的0.1 MIPS左右，到1990年達到100 MIPS，對數刻度呈現近乎直線增長)

使得問題複雜化的是，並行處理並非解決所有問題的方法。某些本質上是串行的計算，例如火箭軌跡，從並行計算機中獲得的好處非常有限。這讓人想起關於陸軍如何通過讓九名婦女花一個月來加速懷孕的老笑話。

正如 Figure 4 清楚顯示的，推動增長的不是性能本身，而是性價比(cost/performance)，或者簡單地說，有利的經濟效益。這個圖表是一種過度簡化，但代表了過去四十年來具有特定性能的電腦模型的成本。縱坐標再次採用對數刻度，從 1950 年的 1000 萬美元降至 1990 年的 1000 美元。隨著我們接近現在，對應於個人電腦，圖形實際上應該變得更複雜，因為電腦變得超級便宜的一個結果是，它們越來越多地被嵌入其他設備中。現代汽車就是一個例子。而目前這波掌上電腦及其手寫筆輸入將有多麼通用，還有待觀察。

Figure 4 性價比 (Cost/Performance) 具有特定性能的電腦模型在四十年內的成本 (Cost for Given-Performance Computer Model over Four Decades) $10M 100K 1K 1950 1970 1990 年份 Year (圖表顯示具有特定性能的電腦成本從1950年的1000萬美元，到1990年降至1000美元，對數刻度呈現急劇下降)

此外，當我們看一張攝於 1960 年代左右的「機房」照片，裡面只有一位孤獨的操作員時，我們就會想起電腦技術發生的驚人變化。那些箱子巨大，浴室淋浴間大小，整體印象就像是個小工廠。你應該會感到印象深刻，而操作員則應該通過打領帶來維持禮儀。即使他不打，至少可以確定 IBM 維護工程師會打。

另一個提醒我們巨大技術變革已經發生的例子是電腦主記憶體的物理尺寸。例如，如果查看攝於 1950 年代中期的核心記憶體系統舊照片，通常會看到一個大約網球拍頭大小的核心記憶體平面，可以容納約 1000 位元的信息。與之形成對比的是，今天的 4 兆位元記憶體晶片比一個大拇指還小。

今天頒發這個獎項主要是因為我在兩個開創性分時系統 CTSS [5, 6] 和 Multics [7, 9] 上的工作。事實上，正是我參與這兩個系統的工作，讓我獲得了今日我所提出的系統建造觀點。因此，簡要回顧這兩個系統作為雄心勃勃系統的例子，並探討為何所涉及任務的複雜性使得第一次就將系統建造正確幾乎是不可能的[2]，這似乎是很恰當的。

CTSS，兼容分時系統

首先來看 CTSS，讓我們回想一下當時的黑暗時代。那是 1960 年代初期。當時的電腦又大又貴，計算中心的管理員覺得有義務珍惜這個寶貴的資源。用戶，即程式設計師，被要求提交一份以打孔卡片疊形式呈現的計算作業。這些卡片會與其他作業一起打包成磁帶，然後由電腦操作系統處理。這感覺就像把衣服送到洗衣店一樣毫無吸引力。

問題在於，即使是微不足道的輸入打字錯誤，作業也會被中止。如你們大多數人所知，分時解決了無法與電腦互動的問題。現代分時的總體願景主要是由 John McCarthy 闡述的，我很高興他今天也是本次會議的特邀演講者。在 England，Christopher Strachey 獨立地提出了一種有限的互動計算形式，但主要用於偵錯。很快，全國各地有許多小組正在開發各種形式的互動計算，但幾乎在所有情況下，由此產生的系統都有顯著的局限性。

正是在這種背景下，我自己的團隊開發了我們版本的分時願景。我們稱之為 The Compatible Time-Sharing System，簡稱 CTSS。我們最初的期望很低調。首先，這個系統被 intended 為一個示範性原型，以便其他人正在嘗試的更雄心勃勃的設計可以隨後實現。其次，它 intended 處理通用程式設計。第三，它 intended 使在批處理環境下多年來開發的大量軟體成為可能運行。因此得名。

CTSS 的基本運行方案很簡單。駐留在主記憶體中的 supervisor program 會在用戶程式之間切換，藉助定時器，每次運行一段很短的時間。正如 Figure 5 所示，用戶程式可以通過類似打字機的終端以及磁碟存儲設備進行輸入/輸出。

Figure 5 CTSS: 架構 (Architecture) 使用者程式的輸入/輸出 (Input/Output of User Programs) P1 --> (I/O) --> 記憶體 (Memory) --> (I/O) --> Supervisor P2 --> (I/O) --> 記憶體 (Memory) --> (I/O) --> Supervisor (圖表簡化視圖顯示使用者程式透過Supervisor與記憶體及I/O互動) 一個簡化的視圖 (A Simplified View)

但這張圖過於簡化了。關鍵的困難是主記憶體供給不足，而且所有活動用戶的程式不可能同時留在記憶體中。因此，supervisor program 不僅必須將程式從磁碟存儲單元移入移出，還必須作為所有由用戶程式發起的 I/O 的中間人。因此，所有 I/O 線路都應該只指向 supervisor program。

更複雜的是，supervisor program 必須阻止用戶程式相互踐踏。為此，需要對處理器進行特殊的硬體修改，使得存在只能由 supervisor 設定的記憶體邊界暫存器 (memory bound registers)。然而，儘管如此複雜，最初的 supervisor program 的簡單性使其佔用了大約 22 Kbytes 的存儲空間——比本文的文本所需的空間還要少！

創建 CTSS 的主要戰鬥涉及解決當時沒有標準解決方案的問題。例如：沒有標準的終端。沒有簡單的數據機。與電腦的 I/O 是按字而不是按字元進行的，更糟糕的是，它不支援小寫字母。當時的電腦既沒有中斷計時器也沒有日曆時鐘。沒有辦法阻止用戶程式隨機發出原始 I/O 指令。沒有記憶體保護方案。而且，沒有簡單的方法來存儲大量數據並進行相對快速的隨機存取。

建造 CTSS 的總體結果是改變了計算的風格，但有幾點效果值得注意。其中最重要的一點是，我們發現編寫互動式軟體與批處理操作的軟體大相徑庭，即使在個人電腦時代的今天，互動式介面的演進仍在繼續。

回想起來，有幾個設計決策促成了 CTSS 的成功，其中兩個是關鍵。首先，我們可以進行通用程式設計，特別是使用系統本身來開發新的 supervisor 軟體。其次，通過使系統能夠兼容舊的批處理程式碼，我們繼承了大量現成的舊軟體。

開發 CTSS 的一個重要後果是，用戶第一次擁有程式和數據的持久線上存儲。隱私、保護和信息備份的問題 suddenly 必須面對。開發的另一個副產品是，因為我們通過數據機操作終端，遠端操作成為常態。此外，將信息線上保存在中央檔案系統中的新發現的自由，突然使得用戶之間共享和交換信息變得特別方便。

而且也有驚喜。令我們沮喪的是，那些曾經忍受數小時批處理作業等待的用戶，當回應時間超過一秒時 suddenly 變得煩躁不安。此外，許多允許 CTSS 如此簡單地建造的簡化假設，例如單層檔案系統，突然開始令人不適。似乎我們做的越多，用戶想要的就越多。

關於 CTSS 系統還有另外兩個觀察。首先，它的壽命比我們預期的要長得多。儘管 CTSS 在 1961 年 11 月以原始形式展示過，但直到 1963 年，它才作為 Project MAC 夏季研討會的載體得到廣泛使用。當時有兩個系統的硬體拷貝，但到 1973 年，最後一個拷貝被關閉並報廢，主要原因是 IBM 7094 硬體的維護成本變得高得令人望而卻步，而直到最後一刻，仍有用戶拼命想再使用幾個小時。

其次，當時新出現的電晶體和大型隨機存取磁碟文件對於分時的成功絕對至關重要。上一代的真空管對於持續的即時操作來說太不可靠了，當然，大型磁碟文件對於用戶程式和數據的中央存儲至關重要。

一個意外事件

我的中心主題是試圖說服你們，當你們在建造一個系統時必須處理 multitude 的新穎問題時，錯誤是不可避免的。事實上，我們在使用 CTSS 時就發生了一個美麗的意外事件。讓我描述一下：

當時的情況是，一個下午在 Project MAC，CTSS 被用作主要的分時工作站，任何登入的用戶都發現，他們終端上沒有出現 usual 的今日訊息，而是出現了整個用戶密碼檔案。這種情況持續了 15 到 20 分鐘，直到一位特別 conscientious 的用戶打電話給系統管理員，開始對話說「你知道 Project MAC 的……嗎？」不用說，這種 colossal 的安全漏洞引起了普遍的 consternation，系統被匆忙關閉，接下來的十二個小時都在英勇地更改所有人的密碼。問題是這怎麼會發生？讓我解釋一下。

Figure 6 CTSS: 一個意外事件 (A Mishap) 系統密碼檔案變成了今日訊息 (System Password File became the Message-of-the-Day) (圖示檔案變成今日訊息的流程) CTSS 充滿驚喜 (CTSS Is full of Surprises)

為了簡化最初 CTSS 系統的組織結構，做了一個設計決定，讓每個終端用戶擁有自己的檔案目錄。此外，系統本身也組織成一種準用戶，擁有自己的目錄，其中包括大量的支援應用程式和檔案，包括今日訊息和密碼檔案。到目前為止，一切順利。通常，一個單一的系統程式設計師可以登入到系統目錄並進行任何必要的更改。

但系統程式設計師的人數已增長到約十二人，而且當時系統幾乎不間斷運行，因此對系統檔案進行現場維護變得 essential。毫不奇怪，系統程式設計師認為每個目錄只能供一個用戶使用的限制對他們來說是一個巨大的瓶頸。於是他們開始說服我，讓系統目錄成為例外，以便允許多人同時登入。他們向我保證他們會小心不犯錯。

但錯誤當然還是發生了。標準系統文字編輯器中的一個軟體設計決策被忽略了。它假設編輯器只會由一個用戶在一個目錄中同時使用，這樣臨時檔案就可以有相同的名稱用於編輯器的所有實例。但是當兩個系統程式設計師同時在系統目錄中編輯時，編輯器的臨時檔案發生了交換，災難就發生了。從這件事中可以學到兩個教訓：首先，設計錯誤往往是微妙的，並且隨著新功能或用途的增加，早期假設會被遺忘，從而演變出來。其次，即使是熟練的程式設計師也會犯錯。

Multics

現在讓我轉向 Muhics [12] 的開發。我會簡短一點，因為這個系統已經有很好的文檔記錄，並且已經有兩篇回顧性論文[3, 4]。Muhics 系統旨在「正確地」實現分時，並取代 CTSS 等先前的臨時系統。它最初是 MIT 的 Project MAC、Bell Telephone Laboratories 和 General Electric（後來被 Honeywell 收購）電腦部門之間的合作努力。在我們宏大的目標下，我們列出了長長一串的創新。

其中最重要的創新如下：首先，我們在處理器硬體中引入了分頁和分段機制，以及精密的存取控制方案。其次，我們引入了在 supervisor software 周圍建立保護環層級 (rings of protection) 的概念。第三，我們從一開始就計劃系統將由可互換的多個處理器、記憶體模組等組成。第四，我們決定使用新定義的編譯器語言 PL/I 實現幾乎所有的系統功能。

讓我分享一些我對 Muhics 經驗的觀察。我們委託開發的新穎硬體意味著系統必須從頭開始建造，這使得我們面臨巨大的任務。

使用編譯器來實現系統軟體是一個好的決定，但我們沒有意識到新語言 PL/I 給我們帶來了兩個主要困難：首先，該語言包含本質上複雜的結構，系統程式設計師需要一段時間的學習才能學會避免它們。其次，沒有人知道如何很好地實現這個編譯器。最終我們克服了這些困難，但這耗費了寶貴的時間。

Muhics 的成功是顯著的，因為它是三個高度獨立組織合作的成果，並且沒有統一的行政領導。這意味著決策是通過說服和共識達成的。因此，在投入大量時間和精力之前，很難拒絕不成熟的想法。

Muhics 系統確實成為了一款商業產品。它的一些主要優勢包括虛擬記憶體系統、檔案系統、對安全的重視、線上重新配置的能力以及檔案系統的信息備份系統。

而且，就像 CTSS 一樣，許多 Multics 開發的校友在計算領域扮演了重要角色[11]。

關於雄心勃勃的 Multics 經驗，還可以再做一些觀察。特別是，我們被我們之前系統（如 CTSS）的成功誤導了，在 CTSS 中，我們能夠「一磚一瓦」地建造系統，在已有的大量工作軟體基礎上增量地添加想法。

我們也對無法為專案不同階段的完成設定和達成準確的時間表感到尷尬。回想起來，我們不應該如此，因為我們以前從未做過類似的事情。然而，在許多情況下，我們的估計應該被稱為猜測。

Unix 系統[15] 是對 Multics 的反應。連名字都是個玩笑。Ken Thompson 是 Bell Laboratories Multics 團隊的一員，對試圖控制大型系統開發感到沮喪，於是決定從頭開始。他的策略很明確——從小型開始，並在他知道如何良好實現想法時，逐一建立起來。眾所周知，Unix 已經演進並成為工作站的首選系統，取得了巨大的成功。儘管如此，Multics 的某些方面在 Unix 中從未被複製過。

作為 Honeywell 和 Bull 的商業產品，Multics 擁有忠實的追隨者。在鼎盛時期，全球約有 77 個站點，即使在今天，由於缺乏替代品，許多站點仍頑固地繼續使用。

複雜性的來源

雄心勃勃系統的普遍問題是複雜性。接下來，讓我試著抽象出一些主要原因。最明顯的複雜性問題源於規模。特別是，所需人員越多，管理層級也會越多。即使我們使用簡單的計算，也能看到這個問題。因此，如果我們假設一個固定的監管比例，例如六，那麼管理層級將隨著人員數量的對數增長。困難在於，管理層級越多，最高層級就越脫離相關的底層問題，隨機巧合溝通的可能性就會降低。

組織的另一個問題是下屬討厭匯報壞消息，有時是因為害怕「被當作信使槍斃」，有時是因為他們可能有與高層管理不同的目標。最後，大型專案鼓勵專業化，使得很少有團隊成員能理解整個專案。誤解和溝通不暢開始出現，很快專案的大部分資源都花在了內部混亂的鬥爭上。當然，錯誤也會發生。

我的下一個複雜性類別源於新的設計領域。最生動的例子來自物理系統的世界，但軟體也受到相同的問題影響，儘管通常以更微妙的方式。

考慮 Tacoma Narrows Bridge 於 1940 年 11 月 7 日在 Washington State 倒塌的事件。這座橋在約四個月前才驕傲地開放。你們許多人可能已經看過幸運地拍攝到倒塌過程的業餘影片。當時發生的是，那天刮起了強勁但不尋常的橫風。很快，由主跨橋索懸吊的橋面開始像蘆葦一樣振動，而且彎曲得越多，它呈現給風的橫截面就越好。結果是，隨著振盪變得巨大而劇烈，大橋自己撕裂開來。我們面臨的是一個新的設計領域的案例，經典的橋樑建造者只關注重力載荷結構，卻進入了航空領域。結果是一個重大的錯誤。

接下來，讓我們看看由於人類使用電腦系統而產生的複雜性。在使用允許共享或交換信息的線上系統時——而這裡網路工作站顯然屬於這一類——人們面臨一個兩難：如果完全信任所有其他用戶，就容易受到任何惡意用戶的反社會行為的影響——考慮病毒的情況。但如果試圖完全孤立，不僅會感到無聊，而且信息世界將停止成長並因與他人的互動而得到增強。結果是我們大多數人在一個複雜的權衡區域運作，採用各種信任和安全機制安排。即使像密碼這樣簡單的概念也常常是個問題。它們記起來很麻煩，容易不小心洩露，而且如果共享了，就無法選擇性地撤銷。隱私和安全問題特別難處理，因為責任通常分散在用戶、管理員和供應商之間。更糟的是，沒有辦法簡單地「看」一個系統就能確定其隱私和安全影響是什麼。難怪這個領域總是會出錯。

使用電腦系統的後果之一是信息越來越多地保存在中央存儲設備中。電腦存儲設備變得異常可靠——除了它們壞掉的時候——這就是問題所在。即使是最有經驗的電腦用戶，也可能被當今設備幾乎完美的運行所迷惑，產生一種虛假的安全感。這個問題因供應商的態度而加劇，這與汽車行業最初對待安全的態度並無二致，他們將不可避免的磁碟故障視為抑制銷售的負面問題。

所需的是對一長串「如果會怎樣」的持續警惕：硬體故障、人為失誤、蓄意破壞、盜竊、火災、地震、長期媒體故障，甚至制度記憶的喪失（關於恢復程序）。而且只要有些人必須「從痛苦中學習」，錯誤就會繼續發生。

討論風險或可靠性的一個進一步複雜因素是，沒有一個好的語言可以進行對話。統計數據經常被誤用，也經常被誤解。我們還會聽到荒謬的絕對說法，例如「戰略防禦倡議將生產一個完美的、不可飽和的核攻擊防護盾」[14] 或「反應堆不可能過熱」。問題在於，我們的生活中一直都有風險，我們從來就不擅長討論它們，而有了電腦，我們現在又有了很多新的來源。

另一個複雜性來源是快速變革，這種變革通常由技術進步推動。結果是程序或使用方式發生變化，新的漏洞可能隨之產生。例如，在電話網絡領域，光纖電纜與銅線相比的經濟效益和效率正迅速導致全國電話基礎設施的重大升級和更換。由於一根光纖電纜能以合理的成本傳輸數千根銅線等量的流量，光纖正在迅速取代銅線。因此，可能會發生一種轉變，在特定區域內，網絡鏈路變得更加稀疏，而多路互連的節點連接性降低。

困難在於冗餘度降低，並且更容易受到孤立事故的影響。不久前，在 Chicago 地區，一個光纖交換中心發生火災，導致大量客戶數週無法使用服務。最近，在 New York City，金融交易所在 New Jersey 因一台挖掘機事故而關閉數小時。顯然，在這兩個例子中，效率都領先於穩健性。

我將特別指出的最後一個複雜性來源源於人類用戶在現代生活中被迫處理多種技術時的脆弱性。在短短一個多世紀裡，從電話和電力，到汽車、電影和無線電——我甚至不想列舉所有技術，因為我們都非常熟悉。總體結果是我們的生活方式發生了巨大變化，而且我們看到這些變化甚至今天仍在發生。考慮電視剪輯風格在幾十年裡發生的變化、投影片投影儀對大學教室的影響，以及我們現在使用自動提款機進行銀行業務的方式。而生活方式變革的進程似乎以更快的速度繼續著，文字處理器、答錄機、傳真機和電子郵件的出現。

許多生活方式變化的一個後果是，有些人感到壓力重重，被過多的輸入過度刺激。自然的防禦是越來越依賴他人作為信息過濾器。但是，壓力重重的生活方式與與原始數據隔絕的結合，將不可避免地導致更多的混亂和錯誤。

結論

本次演講的大部分旨在試圖說服你們，在複雜的、雄心勃勃的系統中，失敗是不可避免的。然而，如果我不提出解決問題的方法，那將是我的疏忽。不幸的是，我能提供的方法清單相當短，但值得簡要回顧。

首先，強調簡單和優雅的價值非常重要，因為複雜性會加劇困難，正如我們所見，也會製造錯誤。我對優雅的定義是：以最少的機制和最大的清晰度實現給定的功能。

其次，隱喻的價值不應被低估。隱喻的優點在於其預期行為是所有人都能理解的。不必要的溝通和誤解得以減少。學習和教育速度更快。實際上，隱喻是一種內化和抽象概念的方式，讓人們能夠在更高的層面思考，從而避免低層次的錯誤。

第三，在設計或合成中使用約束性語言是一種強大的方法。通過不允許程式設計師或設計師表達無關緊要的想法，可能的錯誤範圍變得更加有限。

第四，必須嘗試預測人類使用錯誤和硬體故障，並適當開發必要的應急路徑。這個「如果會怎樣」的思考過程不像聽起來那麼容易，因為其中隱含著需要為事件賦予發生的可能性以及解決故障獨立性問題。

第五，在系統設計中，應該假設它需要被修復或修改。總體效果將是一個更加健壯的系統，其中功能模組化和結構化程度很高，並且可以輕鬆進行修復。

第六，也是最後一點，在大型專案中，最好的投資之一是對團隊進行交叉培訓，以便幾乎每個人都知道比他們需要知道的更多。顯然，通過教育冗餘，團隊對意外的悲劇或人員離職更有韌性。此外，團隊成員意識的提高有助於及早發現全局性或系統性的錯誤。這確實是一個「三個臭皮匠勝過一個諸葛亮」的情況。

最後，我在這次演講中觸及了許多不同的主題，但我將重點指出其中三個：首先，技術的演進支持了雄心勃勃願景和夢想的豐富未來，這將不可避免地涉及複雜的系統。其次，必須始終嘗試從過去的錯誤中學習，但同時要警惕新的情況可能需要新的解決方案。第三，必須記住，雄心勃勃的系統需要一種防禦性設計和實現理念。換句話說，「不要問是否會發生意外，而是問當意外發生時會怎麼辦。」

參考資料 (References)

Brooks, F.P., Jr. No silver bullet. IEEE Comput. (Apr. 1987), 10-19.
Corbató, F.J. Sensitive issues in the design of multi-use systems. Unpublished lecture transcription of Feb. 1968, Project MAC Memo M-383.
Corbató, F.J., and Clingen, C.T. A managerial view of the Muhics system development. In Research Directions in Software Technology, P. Wegner, Ed., M.I.T. Press, 1979. (Also published in Tutorial: Software Management, D.J. Reifer, Ed., IEEE Computer Society Press, 1979; Second Ed,, 1981; Third Ed., 1986.)
Corbató, F.J., Clingen, C.T., and Saltzer, J.H. Multics: The first seven years. In Proceedings of the SJCC (May 1972), pp. 571-583.
Corbató, F.J., Daggett, M.M., and Daley, R.C. An experimental time-sharing system. In Proceedings of the Spring Joint Computer Conference (May 1962).
Corbató, F.J., Daggett, M.M., Daley, R.C., Creasy, R.J., Hellwig, J.D., Orenstein, R.H., and Horn, L.K. The Compatible Time-Sharing System: A Programmer's Guide. M.I.T. Press, June 1963.
Corbató, F.J., and Vyssotsky, V.A. Introduction and overview of the Multics system. In Proceedings FJCC (I965).
Daley, R.C. and Neumann, P.G. A general-purpose file system for secondary storage. In Proceedings FJCC (1965).
David, E.E., Jr. and Fano, R.M. Some thoughts about the social implications of accessible computing. In Proceedings FJCC (1965).
Glaser, E.L., Couleur, J.F. and Oliver, G.A. System design of a computer for time-sharing applications. In Proceedings FJCC (1965).
Neumann, P,G., a Multics veteran, has become a major contributor to the literature of computer-related risks. He is the editor of the widely-read network magazine "Risks-Forum," writes the "Inside Risks" column for the CACM, and periodically creates digests in the ACM Software Engineering Notes.
Organick, E.I. The Multics System: An Examination of its Structure. MIT Press, 1972.
Ossanna, J.F., Mikus, L. and Dunten, S.D. Communications and input-output switching in a Multiplex computing system. In Proceedings FJCC (1965).
Parnas, D.L. Software aspects of strategic defense systems. Am. Sci. (Nov. 1985). An excellent critique on the difficulties of producing software for large-scale systems.
Ritchie, D.M. and Thompson, K. The UNIX time-sharing system. Commun, ACM 17, 7 (July 1974), 365-375.
Vyssotsky, V.A., and Corbató, F.J. Structure of the Multics Supervisor. In Proceedings FJCC, 1965.

CR Categories and Subject Descriptors: C.2 [Computer Systems Organization]: Computer-Communication Networks; C.4 [Computer Systems Organization]: Performance of Systems; D.4 [Software]: Operating Systems; H.5 [Information Systems]: Information Interfaces and Presentation; K.2 [Computing Milieux]: History of Computing

General Terms: Design

關於作者 (About the Author)

FERNANDO J. CORBATO 是 Massachusetts Institute of Technology 電腦科學與工程系的副主任。作者目前地址：Computer Science and Engineering Department, Room NE43-514, 545 Technology Square, Cambridge, MA 02139.