OS/360

1964年4月7日，IBM在纽约和全球62个城市同步举行了一场盛大的发布会，宣布推出System/360系列计算机。这一天，蓝色巨人押上了整个公司的未来——此前五年，IBM投入了50亿美元（相当于今天的400亿美元）研发资金，试图用一套统一的硬件架构和一套统一的操作系统，来终结计算机世界的“巴别塔”困境。在这个宏大叙事中，OS/360操作系统并非配角，而是整个计划的心脏。它耗资5亿美元，由5000多名程序员耗时四年才勉强交付，最终成为软件工程史上最著名也最惨烈的失败与丰碑。

要理解OS/360的诞生，我们必须先回到1960年代初期的计算机世界。那时的计算机市场如同一片混乱的丛林。IBM自己就拥有多条互不兼容的产品线：用于科学计算的7090系列、用于商业事务处理的1401系列、用于实时控制的1620系列……每款机器都有自己的专属操作系统——如果那能被称为“操作系统”的话。大多数计算机只运行一个程序，程序员需要直接用机器码或汇编语言编写，作业之间靠人工切换磁带和卡片。一台机器上的软件完全无法移植到另一台，客户一旦购买了某款机型，就被锁定在特定的技术生态中，升级意味着从头开始。这种状况不仅让用户痛苦不堪，也让IBM的维护成本急剧膨胀——它需要为每款机型维护独立的软件栈和培训体系。更致命的是，竞争对手如Honeywell、Control Data和Sperry Rand正在蚕食IBM的领地，它们各自推出了性能更强、价格更低的专用机。

IBM的决策层意识到，必须做出一次豪赌。1961年，IBM成立了一个秘密项目组，代号“SPREAD”（系统编程、研究、工程与开发），由副总裁Vincent Learson领导。SPREAD小组的结论是：IBM需要推出一系列共享相同指令集架构的计算机，从低端到高端，覆盖所有应用场景。这个想法在当时近乎疯狂——过去计算机的设计哲学是“硬件决定软件”，每款机器都有自己的指令集和I/O系统。统一架构意味着IBM必须重新设计从晶体管到机箱的一切，还要编写一个能在所有机型上运行的操作系统。这个操作系统就是OS/360。

1964年1月，IBM任命Fred Brooks为OS/360的项目经理。Brooks当时32岁，是IBM最年轻的杰出工程师之一。他此前参与了IBM 7090的软件设计，以严谨和高效著称。但即使是他，也无法预见自己即将踏入的泥潭。Brooks后来在《人月神》中回忆，项目启动时，团队估算的规模大约是200人年，预计一年内交付。但很快，他们发现System/360的硬件设计在频繁变动，软件需求不断膨胀，而管理层又不断要求添加新功能。到1965年，OS/360的代码量已经超过100万行，参与人数超过1000人，预算飙升到5亿美元。Brooks最著名的观察——“向一个已经延迟的软件项目添加人力，只会让它更延迟”——正是来自这段痛苦的经历。

OS/360的技术挑战是前所未有的。它需要同时支持多道程序设计（多个程序共享CPU）、虚拟存储（将磁盘当作内存的扩展）、动态资源分配、以及多种编程语言（FORTRAN、COBOL、PL/I、汇编等）。更关键的是，它必须能在System/360家族的所有机型上运行，从只有8KB内存的低端Model 30，到拥有512KB内存的高端Model 75。这意味着操作系统必须极度模块化，能够根据硬件配置自动调整功能。Brooks的团队设计了分层架构：核心是控制程序（Control Program），负责中断处理、内存管理和任务调度；外层是系统服务程序（System Services），包括作业调度器、输入输出管理器和语言编译器。这种分层设计后来成为所现代操作系统的标准模板。

但OS/360的初期版本是一场灾难。1966年交付的第一个版本（OS/360 Release 1）充满了bug。用户报告说，系统会随机崩溃，作业莫名其妙地丢失，内存泄漏导致机器死机。IBM的客户支持部门被投诉淹没，一些大型客户甚至威胁要起诉IBM。更糟糕的是，OS/360的文档混乱不堪，安装手册厚达数千页，系统管理员需要像炼金术士一样通过反复试验来调优参数。Brooks在书中坦诚：“我们交付了一个有数百个已知错误的系统，这在今天是不可想象的。”

IBM不得不采取激进的补救措施。他们成立了专门的“老虎团队”（Tiger Team），由最优秀的程序员组成，集中攻关最严重的bug。同时，IBM开始向客户提供“系统支持计划”（System Support Program），派遣工程师驻场协助部署。到1967年，OS/360终于达到了勉强可用的状态，但代价是巨大的：IBM为OS/360投入的总成本超过5亿美元，而System/360硬件本身的研发费用是50亿美元。换句话说，操作系统占了整个项目成本的10%，这在当时是一个闻所未闻的比例。

尽管如此，OS/360的商业影响是革命性的。它让System/360成为史上最成功的计算机系列之一。从1965年到1970年，IBM售出了超过3万台System/360，占据了大型机市场70%的份额。客户之所以愿意忍受OS/360的bug，是因为它解决了最根本的问题：兼容性。一家公司可以从低端Model 30起步，当业务增长时，无缝升级到Model 65或Model 75，而无需重写任何软件。这种“向上兼容”的能力彻底改变了计算机的商业模式，使软件投资成为企业的长期资产。OS/360还首次将操作系统作为独立产品进行定价和销售，而不是随硬件免费赠送。这一举措确立了软件作为商品的价值，为后来整个软件产业的兴起铺平了道路。

在技术演进方面，OS/360经历了一系列重要迭代。1967年，IBM推出了两个变体：MFT（多道固定任务）和MVT（多道可变任务）。MFT适用于内存较小的系统，它将内存划分为固定大小的分区，每个分区运行一个作业；MVT则更灵活，可以动态调整分区大小，适合高端机型。1972年，OS/360演变为OS/VS1和OS/VS2（即MVS），首次引入了虚拟存储技术。MVS后来成为IBM大型机操作系统的基石，至今仍在全球的金融、航空和政府系统中运行。事实上，如果你在2024年去一家大型银行的数据中心，很可能看到z/OS——MVS的直接后裔——在IBM zSeries大型机上处理着每秒数万笔交易。

OS/360的文化遗产同样深远。Fred Brooks在1975年出版的《人月神话》不仅记录了OS/360项目的教训，更成为软件工程领域的圣经。书中的观点——比如“没有银弹”（No Silver Bullet）——“添加人力只会让项目更延迟”——至今仍是项目经理的座右铭。Brooks还提出了“第二系统效应”（The Second System Effect）的概念，指出一个成功的系统之后往往会出现一个过度设计的失败系统，这被后来的许多项目（包括Windows Vista）所验证。OS/360的开发过程也催生了软件度量的概念：IBM的程序员开始统计代码行数、bug率、修复时间，这些数据后来成为CMM（能力成熟度模型）和ISO 9000标准的基础。

在轶事方面，OS/360的开发充满了黑色幽默。据说有一次，IBM的测试团队发现一个bug导致系统在特定条件下会删除所有文件。他们花了三天三夜才定位到问题：一个程序员在写代码时，误将“=”写成了“==”（在当时的汇编语言中，这会导致逻辑错误）。另一个广为流传的故事是，OS/360的文档团队曾试图编写一份“用户友好”的安装指南，结果被技术团队嘲讽为“童话故事”。更夸张的是，IBM内部流传着一句笑话：“OS/360是一个完美的操作系统——它永不崩溃，因为在你发现bug之前它就已经崩溃了。”这些轶事虽然苦涩，却真实反映了当时软件工程的原始状态。

OS/360对后续技术的影响是深远的。它的进程管理思想直接影响了Unix的分时系统——Ken Thompson和Dennis Ritchie在设计Unix时，参考了OS/360的任务调度机制。虚拟存储技术被移植到IBM的VM/370系统中，后者成为虚拟机技术的鼻祖，最终催生了VMware和KVM。OS/360的错误处理机制（如ABEND代码）成为大型机编程的标准术语，至今在z/OS中仍然使用。甚至“操作系统”这个术语本身，也在OS/360之后才被广泛接受——在此之前，人们通常称其为“监控程序”或“执行程序”。

在科技史中，OS/360的地位是双重的：它既是软件工程史上最著名的失败案例，也是现代操作系统的奠基之作。它教会了行业一个残酷的真理——大型软件项目的复杂度是不可线性扩展的。它也证明了，即使是最混乱的项目，只要投入足够多的资源和决心，也能最终成功。今天，当我们使用Windows、Linux或macOS时，我们受益于OS/360的遗产：多任务处理、虚拟内存、设备独立、以及操作系统作为独立产品的商业模式。而当我们读《人月神话》时，我们也在聆听那个时代的回声——一个关于野心、失败和坚持的故事，它告诉我们，软件从来不是简单的工程，它是人类智慧的极限挑战。

在IBM的档案室里，至今保存着OS/360的原始代码磁带。它们被密封在恒温恒湿的柜子中，像古代卷轴一样珍贵。偶尔，有历史学家会请求访问，但IBM的工程师会礼貌地拒绝：“那东西太老了，连我们自己的机器都读不了。”但OS/360的精神从未老去。它活在每一个操作系统的内核中，活在每一个软件项目经理的噩梦中，活在每一个程序员看到“ABEND”代码时的苦笑中。这就是OS/360——一个不完美的杰作，一个永恒的教训。