1.1 昂貴主機的極限浪費：批次處理時代「一次只能跑一個程式」的困境#
一台機器 = 一棟房子的價格#
1960 年代中期，一台 IBM System/360 大型主機的價格約在 百萬美元等級（若含周邊與租約，總擁有成本常達數百萬美元），換算成今日幣值超過千萬美元。許多大學與企業是用聯邦補助、企業貸款，甚至跟 IBM 簽下長期租約才請得動這尊神像。
然而，這台珍貴無比的機器，絕大多數時間都在——發呆。
批次處理（Batch Processing）的荒謬日常#
當時的主流作業模式是「批次處理」：
【批次處理的一天】
08:00 操作員收一大疊打孔卡，按提交順序排隊
08:05 載入第一個程式（Fortran 編譯器，磁帶機轟隆作響）
08:40 編譯完成，載入下一個程式
08:41 新程式一啟動就除以零 → 整機當機 → 重開機要 10 分鐘
09:00 換下一個使用者的卡疊……
17:00 機器維修保養
問題一目了然：
- CPU 等人：工程師要親自（或請操作員）把卡片放進讀卡機、換磁帶，CPU 常常閒置等待機械動作。
- 一次一個程式：記憶體裡永遠只有一個程式，程式結束到下一個程式載入之間是純粹浪費。
- 一個程式搞垮全部：程式可以直接讀寫任何實體記憶體與裝置，一個 bug 就能當掉整台百萬美元的主機。
- 排隊數天：大學生把卡片疊交進櫃檯，常要等一兩天才拿得到印出來的報表——而且往往只是一行
SYNTAX ERROR。
利用率：不到 20% 的殘酷現實#
業界事後統計，當時主機的 CPU 有效利用率普遍低於 20–40%，而「人」的成本（操作員、程式設計師等待的時間）卻不斷上升。IBM 內部一份著名的分析指出：讓機器閒著一秒，就等於燒掉數美元——在 1960 年代，這是一線工人的小時薪。
成本結構的倒錯：
硬體：極貴，每一秒都該榨乾
人： 相對便宜，但等待時間被硬體吞噬
→ 結論：一切優化都應以「讓 CPU 永不閒置」為最高目標
兩條救贖之路： Multiprogramming 與 Time-Sharing#
工程師們想到兩個解法：
| 方案 | 概念 | 問題 |
|---|---|---|
| 多道程式設計（Multiprogramming） | 記憶體同時放多個程式，一個等 I/O 時切換給另一個 | 程式之間如何隔離？一個程式覆寫別人的記憶體就全毀 |
| 分時系統（Time-Sharing） | CPU 時間切成小片，輪流服務多個互動式使用者 | 每個使用者都期望自己「獨佔」一台機器的假象 |
MIT 的 CTSS（1961）與後來的 Multics 專案證明分時在技術上可行，但 Multics 越做越大、越做越難。IBM 高層一度對分時冷嘲熱諷——直到他們發現客戶排隊等機器的憤怒信件雪片般飛來。
為什麼問題比想像中更難？#
多個使用者共用一台機器，真正的難題不是「切換」，而是每一個人都想要完全相容的假象：
- 舊程式寫死了「我擁有從位址 0 開始的全部記憶體」；
- 舊作業系統（如 OS/360 之前的一整套產品線）直接操作實體裝置；
- 你不可能要求數千個已存在的客戶程式全部改寫。
要讓未經修改的舊軟體在新環境下運行、還要彼此隔離——這個看似不可能的需求，正是「虛擬機」概念的起點。
歷史關聯：這是典型的「需求驅動發明」。經濟壓力（機器太貴、利用率太低）＋制度壓力（使用者排隊、舊軟體不能改）共同逼出了下一節 IBM 劍橋科學中心那個瘋狂的想法。