微软精心打造的 Vista 系统，为什么死得这么快？

（点击上方公众号，可快速关注）

转自：36氪（编译组出品。编辑：郝鹏程、王雅琪）

http://36kr.com/p/5119417.html

编者按：从后来的很多反馈看来，Vista 都是一个超前于时代的操作系统。但这个操作系统在当年却遭遇了前所未有的失利——究竟为什么 Vista 会失败、死亡？当时的项目团队主管之一 Ben Fathi 在 Medium 发表了文章 What Really Happened with Vista: An Insider’s Retrospective，给我们提供了内部的视角。

Windows 有这么一个传统：团队成员在新的 Windows 系统版本发布后，会在海报上签上自己的名字（本图是一张 DVD）。而当发布会结束的时候，海报上就会有成百上千个签名。

经验是你在需要的时候才会得到的东西。—— Steven Wright

我喜欢读 Terry Crowley 的博客（《Vista 到底怎么了？》）。Terry“运筹帷幄之中”，虽然作为局外人，但却把涉及到 Windows Vista 项目以及与之相关但已被放弃的 Longhorn 项目的复杂阴谋报道得精彩迭出。

他正确地指出了困扰这个项目的许多问题，不过在此我并不想重复这些问题。我认为对这种事情，只有从一个内部人士的角度提出看法才不失公允。我也不奢望能够像 Terry 的文章那样说服力强，只求大家能对可能的错误有所了解。从 Windows Vista 的发布日期算起，到现在，已经 10 年了，但这些教训在现在比以往任何时候都更有意义。

Windows 团队是个庞然大物，有成千上万的开发人员、测试人员、项目经理、安全专家、界面设计人员、架构师等等，还有人力资源人员、招聘人员、销售人员、律师，当然还有很多经理、董事和副总裁等等。然后还有成千上万的合作团队（在微软内部以及外部）支持这一整个系列的团队的运作，范围从底层硬件到设备驱动程序，再到平台上的应用程序。

微软足球场上，Windows 团队的照片。（航拍）

从组织上来说，Windows 实际上包含了三个团队：核心、服务器和客户端团队。核心团队负责操作 Windows 系统所有版本所共享的一切核心组件（内核本身、存储、安全、网络、设备驱动程序、安装和升级模型、Win32 等）。而服务器团队则专注于服务器市场所需的技术（终端服务、集群和高可用性、企业管理工具等），而客户端团队负责与桌面和消费者相关（web 浏览器、媒体播放器、图片等）的技术。

当然还有其他的组织机构，虽然 Windows 越来越受欢迎，团队的规模也在扩大，但基本结构仍然保持不变。可以说，从文化和组织角度讲，核心团队更接近服务器团队而不是客户端团队——至少在 Vista 发布之前是这样。

我的微软经历

我是 1998 年入职微软的。然后我很幸运，在这头庞然大物里呆了十几年——在 Windows 2000 的全盛时期加入了它，并一直坚持到 Windows 7 的发布。

在任期的前 7 年里，我管理负责存储、文件系统、高可用性/集群、文件级网络协议、分布式文件系统和相关技术的团队。这与 Windows 2000、XP、Server 2003 和 Longhorn 大致相同。

后来，我就调到了负责管理安全项目的部门，可能待了有一两年的时间吧——大概是从 Longhorn 项目重启到 Vista 发布。我的职责范围从 Windows 的安全技术到杀毒产品，再到安全营销的附加解决方案，以及安全补丁等紧急响应。病毒和蠕虫给 Windows 带来了巨大的打击，让微软在市场上建立的安全软件的声誉毁于一旦。

在 Vista 发布之后，以及 Windows 7 开发之前的这段时间里，我管理着 Windows 的所有核心开发事务。这意味着所有技术开发全都在后台运行，客户端和服务器团队都可以使用。在 Vista 发布后，Windows 各级团队由开发、测试和项目管理三方负责组织，所以我最后跟两人一起负责，我管理开发团队，他们分别管理测试和项目管理团队。

Windows 团队曾经尝试过许多大规模和有野心的项目，不过这些项目在几年后往往被放弃或重新规划。更早的例子是雄心勃勃的 Cairo 项目，它最终失败了，最后有些残存的理念传承至 Windows 2000 中。

问题1：更新迭代的时长过久

在我看来，Windows 最大的问题在于每个版本的时长。平均而言，一个版本从开始到完成大约需要 3 年时间，但“新”代码的开发时间只有大约 6 到 9 个月。其余时间都用于集成、测试之类的——每个阶段持续几个月。

一些项目的核心开发时间要超过 6 个月，所以它们就齐头并进，最后在准备就绪时与主代码库合并。这意味着主干几乎总是支离破碎的，因为大量的功能被集成或替换掉了。在 Windows 7 发布期间，为了确保有一个持续健康和功能正常的代码库，我们对其进行了更严格的控制，但之前发布的版本都有好几个月的不稳定期。

开发过程总体来说还是比较混乱的，开发人员会说服自己和他人他们的代码优于别的项目，他们最后能及时优化仅剩的一些小部分，这样一来即使是半成品，这也是一个可以发布的版本。

3 年的发布周期意味着我们很少知道当我们发布新版本时，外部的竞争环境会是什么样子的。错过一场发布意味着项目取消，但一个团队或高管就是不能让自己放弃。我个人也负责过一些这样的项目。

问题2：团队庞大，进度不一致且最终测试难

考虑到每个团队都想把自己的东西夹在新版本中，所以他们通常会在与其他组件的集成、用户界面、端间测试以及升级等繁琐而乏味的问题上浪费时间，却忽略了棘手的问题。反过来，这意味着一些团队很快变成了别人的瓶颈，因为每个人都在为最后一刻完成用户界面设计或升级测试而努力。

在任何给定的时间点，都有多个主要的版本处于开发状态。随着时间的推移，不同的团队负责不同情况下的代码库开发导致了马太效应——由于某种原因落后的团队往往会更落后。

当一个项目接近完成时，项目经理将开始关注下一个版本的需求，而“健康”（富有）团队的开发人员将开始执行新的代码，但是组织的大部分（穷人）仍然要应用当前版本。特别是测试团队很少从旧版本中解放出来，直到它发布，所以新代码在项目开始时并没有经过彻底的测试，因为“不健康”的团队总是落后，对当前版本进行最后的修改，然后进一步落后。这些团队通常是士气最低、耗时最高的团队，这意味着工程师们接手的是他们没有编写过、因而也不理解的代码。

问题3：与软件供应商关于安全问题的矛盾

在 Vista/Longhorn 项目的大部分时间里，我负责的板块是存储和文件系统技术，也就是说我参与了 WinFS 的工作，尽管它主要是由 SQL 数据库团队（Windows 团队的一个姐妹组织）发起的。比尔·盖茨甚至亲自参与，甚至被戏称为“WinFS”项目经理。

不过事后看来，显然谷歌轻松地解决了为非结构化数据提供无缝且快速搜索的问题。不过他们这样做是为了整个互联网，而不仅仅是为了你的磁盘容量。

当 Longhorn 项目被取消，Vista 残存的一鳞半爪匆匆组装在一起时，WinFS 项目就已经被否决了。SQL 团队将它作为一个独立的项目进行了几年。而那时 Windows 已经有了一个内置的索引引擎，而且完全是在不需要更改变更应用的情况下实现的。因此，WinFS 的相关性变得更加模糊，可项目却仍在继续。

Longhorn 项目中大量与安全相关的架构在该项目废止之后，被保存为 Windows Vista 项目的一部分。我们在迅速膨胀的互联网世界中学习了很多安全知识，并希望将所学到的经验用于操作系统之中，以提高所有客户的整体安全性。

我们别无选择。因为 Windows XP 表明了我们是自己成功产品的受害者。当面对互联网时代的现实时，一个设计初衷仅为实用的系统在满足安全性方面是远远不够的。解决这些安全问题意味着创建一个并行的项目，即 Windows XP Service Pack 2，这是一项巨大的工程，而且从 Longhorn 项目中汲取了数千个资源。

在 Vista 中执行严格的管理边界意味着打破 Windows 系统中的每一个应用程序。部分的解决方案是用户帐户控制，但这可以说是 Vista 最令人讨厌的特性。当用户在运行命令时，系统总会询问用户是否真的打算提高权限级别。由于安装遗留应用几乎总是需要提升特权，因此用户在系统上的初体验就是大量的账户控制窗口弹出，毫无疑问这不会给用户留下什么好影响。而如果管理权限从登录用户中被删除了，可以毫不夸张地说 99% 的 Windows 应用程序都无法正常安装。

从各方面来看，Vista 比微软之前发布的任何操作系统都要安全得多，但在这个过程中，我们也以前所未有的方式打破了应用程序和设备驱动程序的兼容性，因为我们不再支持臭名昭著的应用了，或者使用像用户账户控制这样的机制来绕过它们。客户们讨厌它，因为他们的应用程序崩溃了；系统合作伙伴讨厌它，因为他们觉得他们没有足够的时间更新和认证应用程序，所以 Vista 就这样被扫地出门。

在许多情况下，这些安全性质的更改意味着需要对第三方解决方案进行深入的系统结构改变。而且大多数系统的供应商都没有对他们遗留的应用程序进行大量的改进投资。其中一些解决方案采用了非正统的方法来修改数据结构，甚至在内核中使用指令来实现它们的功能，这就经常性地造成严重破坏。而大约 70% 的 Windows“蓝屏”是由这些第三方驱动程序造成的，他们不愿意使用支持的接口程序来实现他们的功能。杀毒软件供应商因为使用这种方法所以一向口碑不佳。

在我担任微软的安全主管期间，我花了数年时间向杀毒软件厂商解释为什么我们将不再允许他们为内核内存中的指令和数据结构打补丁、为什么这是一个安全隐患，以及为什么他们需要使用我们批准的程序接口，我们将不再支持他们的遗留应用程序与 Windows 内核挂钩——因为黑客们会用同样的方法来攻击消费者。我们的“朋友”——杀毒软件——威胁要起诉我们，声称我们是在阻碍他们的生计，滥用我们的垄断力量！简直了，有这样的朋友，谁还需要敌人？即使冒着降低我们共同客户的安全的风险，他们也不愿意改进本就应该改进的方法。

问题4、5、6：新形势、大型公司创新难、垄断

计算机行业那些年里发生了翻天覆地的变化——手机的兴起，云计算的出现，创建新的广告业模式，社交媒体的病毒式增长，64 位计算机的成熟等等，而这些只是 Windows 面临的攻击的一小部分。

这很正常，因为这体现出了创新者的困境。我们添加的代码越多，项目的复杂度就越高，团队的规模就越大，系统规模也越大，也就越难跨越竞争。

好像竞争的压力还不够似的，工程师们和项目经理们还得花无数个小时和来自司法部以及公司律师的代表们一起研究看是不是违反了反垄断法律。

更为残酷的是，产品的生命周期决定了大约需要 3 年时间才能推出一个主要的 Windows 版本，但这对于日新月异的市场来说实在是太慢了。WinFS、安全性和托管代码只是 Longhorn 议程上的一些大型项目，除此之外还有数不清的的小赌注。

当你公司上下有成千上万的人、客户有数十亿的时候，每个人就都有发言权。那些被认为能够在未来应用到平板和手机的操作系统现在还被要求也能应用到笔记本电脑上、数据中心的服务器上等等不一而足——更不用说云端的虚拟机监控程序。当我们试图同时在市场的各个环节上取得进展时，这些要求与团队的努力完全是南辕北辙。

Longhorn 和 Vista 不可能被孤立地看待。它们只有在与之前及之后发布的版本（Windows 2000 和 XP, Windows Server 2008 和 Windows 7）结合在一起看时才有意义，这样也能对整个行业有个更全面的了解。

问题7：兼容性难题

Windows 是它自身成功的受害者。它已经成功地渗透到许多市场，而那些市场业务现在对操作系统的设计产生了一定的影响，使其设计理念常常是互相冲突的。尝试满足所有这些不同的需求意味着不能完全满足其中任何一个需求。

微软在九十年代取得过巨大成功，但在十年后陷入困境。因为周围的世界在不断变化，我们在努力跟上它。说实话，这些趋势我们都把握到了，也努力地回应它们。

简而言之，我们其实知道当一个特定的操作系统即将被发布时，它在三四年前就已经过时了。而我们所能做的最好的事情是为新的云服务提供增量和无摩擦的服务。但恰恰相反，我们不断向现有的系统里添加功能，这就需要在每次发布之前进行数月的测试，结果就在我们最需要加速的时候速度反而变慢了。当然，我们也没法删除旧的功能，这些功能确保了在 Windows 上已经运行的应用程序的兼容性。

现在想象一下，在十几年或更长的时间里，为数十亿的客户、数百万的公司、成千上万的合作伙伴、成百上千的场景和数十种形式提供一种全支持的操作系统，你就会逐渐对兼容性的噩梦有所了解了。

事后看来，Linux 在这方面更成功。开源社区和软件开发的方法无疑是解决方案的一部分。在这方面，Unix/Linux 的模块化和可插式架构实现了体系结构的有效改进。

微软的“作战室”，后来改成“研讨室”

内部组织的动态和个性也很重要。我们都有自己最喜欢的特性，我们合作伙伴推动我们采用新的标准，帮助它们在平台上认证。我们都有证明我们的技术和想法的野心……只要我们能在下一个 Windows 版本中体现出来并“俘获”数以百万计的客户。

然而开发团队和测试团队难以保持一致，因为前者努力键入代码，后者则致力于发现更复杂和深奥的测试用例。至少可以说，组织内部的动态很复杂。

当然，这一切都不应该被当作借口。

我们有没有做错什么？当然有，而且错的不少。

但我们是故意犯错的吗？当然不是。

我们能做的更好吗？当然可以。

换到今天我们能做的更好吗？当然不，此一时，彼一时。

现在回望过去的时候，应该沮丧还是悔恨呢？我更喜欢把它当成经验教训。我敢确定我们没有人在以后的项目中会犯同样的错误。前事不忘，后事之师。人非圣贤，孰能无过？

看完本文有收获？请转发分享给更多人

关注「程序员的那些事」，提升编程技能