Windows 版 (精华区)

发信人: fiag (Fiag), 信区: Windows
标  题: Windows Server 2003开发历程揭密 zz
发信站: 哈工大紫丁香 (Thu Jul 24 07:35:02 2003)


Windows Server 2003开发历程揭密

------------------------------------------------------------------------------
-
 
作者/Paul Thurrott译者/蒋世滨

　　本文节选自《Windows & .NET Magazine国际中文版》

　　[导读]文章难度：中级★★★

 
　　Mark Lucovsky、David Thompson，微软Windows Server开发梦之队的资深成员，见证
了十五年微软Windows Server艰辛而辉煌的历程：NT团队组建，抛弃IBM的OS/2，与Intel
的紧密结合，NT三度更名称雄天下，充满传奇色彩的Windows Server 2003开发。本文将向
您全方位展示这些鲜为人知的Windows Server故事。

　　最近，我与Janet Robbins和Mike Otey一起游览了微软公司，我们有幸面见了在Wind
ows历史中最著名的两个人物：Mark Lucovsky和David Thompson。在Windows NT的早期，
Lucovsky和Thompson在这个重要软件项目的开发中扮演着关键角色。Mark Lucovsky是著名
的工程师，也是Windows Server的设计师，他与DEC公司的前雇员、NT设计师Dave Cutler
一起加入微软公司。他非凡的能力首先体现在如何使NT中数百成千的组件协同工作在一起
。对技术的敏锐嗅觉，以及为将NT从基于OS/2的系统转变成运行32位Windows程序的系统所
做的早期努力，使Lucovsky声名远扬。David Thompson是Windows服务器事业部副总裁，他
于1990年加入微软，他当时领导一个LAN Manager项目的高级开发组，后来又加入了NT团队
，Thompson指导NT网络子系统的开发，确保该产品可以与其他非微软产品协同工作。

　　微软组建NT梦之队

　　“起初，我们将NT的运行目标定位于Intel i860 (代码号为N-Ten)，一个令人生厌的
RISC处理器。由于我们没有一台i860机器，我们不得不使用i860模拟器。这就是我们称之
为NT的原因，因为它工作在‘N-Ten’上”

　　——Mark Lucovsky

　　微软著名工程师、Windows Server设计师

　　“我们在1988年11月作为一个小组一起到来。”Lucovsky告诉我们，并强调NT团队的
第一个任务是获取一台开发机器，后来是25MHz的386 PC机，具有110 MB硬盘和13 MB内存
。“它们价高质次。”他笑着说。在头两周里，除了用Word编写原始设计文档外，没有什
么重大的开发活动。

　　最后，到了开始写代码的时候了。“大约在1988年12月中旬，我们核查了最初的代码
，”Lucovsky说道，“到1989年1月份时，它只具有一个在Intel i860模拟器上引导的非常
基本的系统。”实际上，这是NT名称的真正来由，据Lucovsky透露，“New Technology”
这个说法是在该产品取得市场成功后加上去的。“起初，我们将NT的运行目标定位于Inte
l i860 (代码号为N-Ten)，一个令人生厌的RISC处理器。由于我们没有一台i860机器，我
们不得不使用i860模拟器。这就是我们称之为NT的原因，因为它工作在‘N-Ten’上。”


　　1989年4月，新指定的NT团队有了在模拟器上运行的基本系统内核。“我们5个来自DE
C的家伙和来自微软的Steve Wood一起开始工作，”Lucovsky说，“我们这个小组保持了很
长时间，经过一个夏季，我们开始考虑：创建一个操作系统究竟有多难？我们制定了一个
用18个月完成NT的计划。但是我们忘记了一些重要的因素，比如用户模式、网络等等。”


　　1989年之后，NT小组开始扩充。他们增加了正式的网络团队，和一个扩充的独立安全
性团队，他们先前负责文件系统和本地化开发。“在第一年中我们增加到50个人，”Luco
vsky说，“在这一年中，我们最终得到了第一台i860原型机，因此我们可以替换模拟器。
我们开始查看上下文切换次数，试图找到一个方法让它工作得更好。我们几乎立即就发现
i860将永远无法工作。因此，我们开始着眼于MIPS体系，另一种RISC设计。”

　　1989年12月，NT团队决定放弃i860并用MIPS R3000芯片替换。“我们在真实硬件上无
休止地引导NT，这样持续了两三个月，”Lucovsky告诉我们，“当我们移植到MIPS上之后
，我们得到了回报，我们将NT设计为可方便移植的，它几乎立即就开始工作了。这种改变
没有带来太多的痛苦。”

　　从这时起，NT团队迅速扩大，来自微软不同阵营的人现在都加入进来。当一种使用图
形的新风格被创立后，图形团队迅速增长。他们也开始将NT转向当时的主流PC处理器Inte
l i386，Lucovsky解释了他们最初没有定位到i386的原因。“我们暂时避开386是为了避免
局限于该体系，我们不想采用一个不可移植的构想。”他说如果在一开始就定位于Intel系
列芯片，则他们在早期就可以有一个较高性能的系统，但是那样就会长久地伤害NT，并且
将很难跟上新体系结构的发展，比如最近基于64位Itanium芯片的Windows Server 2003。


　　NT变成Windows NT

　　“我们的核心体系非常坚固，所以我们才能使NT从适应1990年的386-25，一直发展到
今天适应嵌入式设备、64路64位多处理器的机器和以1000美元为单位的刀片式服务器。”


　　——David Thompson

　　微软副总裁、Windows Server产品组

　　“在1990年的春天，我们的MIPS版本继续曲折前进，同时我们开始狂热地开发386的版
本，”Lucovs说道，“这是另一个巨大突破。”那一年5月，微软发布了Windows 3.0，立
即受到了全世界的关注。Windows由于其基于PC的图形功能而取得了非凡的成功。“我们开
始研究Windows 3.0并且自问‘如果用32位的Windows版本替换OS/2将会怎样呢？’”Luco
vsky又甩出一个更深层次的问题：“Steve Wood、Scott Ludwig、一个图形工程师组的人
以及我本人，我们4个家伙研究了16位的Windows API，并研究如何将其延伸到32位。我们
花了一个月完成了一半的API集合，然后把它交给100位设计评估者，看看他们的想法。”


　　新的API最终命名为Win32，关键的一点是，尽管它是一个新的API，但是它看上去和运
行起来都与16位Windows API相似，这使得开发人员可以很容易地将程序移植到新系统上。
“我们使得16位程序可以非常容易地移植到NT上，”Lucovsky说，“并且这些程序将得益
于NT的独特功能，比如更大的寻址空间。我们也增加了许多16位版本中所没有的API。我们
增加了主流的新功能，使它成为一个完整的操作系统API，但我们使用了Windows程序员所
熟悉的风格。”

　　这在微软内部立即引起了反响。“当他们看到它是如此易用时，立刻就喜欢上了它，
”Lucovsky说，“它基于Windows而不是OS/2，它使用了一种完全不同的编程模式。”然而
，替换OS/2产品，将NT变成一个32位的Windows版本，带来了新的课题，其中并不完全是技
术问题。微软不得不获取ISV和OEM审批，当然也要将这个改变通知IBM。“我们对IBM做了
一个ISV预览，足足有20多页，然后我们说：‘看，这就是我们要做的。’开始他们以为W
in32不过是OS/2的一个迷人绰号，可是接下来你可以看看他们的脸色：‘等一等，这不是
OS/2！’”

　　对OS/2的抛弃永远地伤害了两家公司的感情。“但是我们执行了审批，并且开始了进
程，”Lucovsky说道，“因此我们选择了Win32运行NT，替代了OS/2子系统。”他说，那一
刻，这个产品变成了Windows NT。

　　NT的模块式结构为这个改变提供了便利。“应该感谢我们的微内核体系，它减弱了内
核与应用程序环境的关联程度，比如POSIX和Win32。我们不必改变内核，也不必从头开始
编程，”Lucovsky告诉我们，“日程计划的内容不必更改，我们在两周的时间里运行命令
行应用程序。这时是1990年9月。”

　　Thompson详细阐述了NT基础的重要性：“我们的核心体系非常坚固，所以我们才能使
NT从适应1990年的386-25，一直发展到今天适应嵌入式设备、64路64位多处理器的机器和
以1000美元为单位的刀片式服务器。我们可以为其提供全系列的服务。”

　　1990年9月是Windows NT真正的转折点，同时也是Dave Thompson加入NT团队的时间，
他先前领导微软的Lanman for OS/2 3.1高级开发团队。“我们经受了转变，”Thompson告
诉我们，“我们的队伍从28人增加到300人。我们有了第一个真正的产品计划。”

　　NT大事记

　　1988年10月31日：David Cutler抵达微软

　　1988年11月：NT项目开始运作

　　1993年7月27日：Windows NT 3.1发售

　　1994年9月21日：Windows NT 3.5发售

　　1995年5月30日：Windows NT 3.51发售

　　1996年7月31日：Windows NT 4.0发售

　　2000年2月17日：Windows 2000发售

　　2001年10月25日：Windows XP发售

　　2003年4月24日：Windows Server 2003发售

　　1993年7月，Windows NT的第一个版本Windows NT 3.1发布了，版本号的命名与当时的
16位Windows产品一致。那个版本的NT有桌面和服务器两个版本，并使用域形式的分布式安
全机制。从那时起，NT团队开始连续地发布产品，所有的开发都基于相同的底层代码。


　　第二个发布版本Windows NT 3.5(代码名为Daytona)在1994年9月投放市场。“Dayton
a是一个非常有价值的项目，”Thompson说，“我们把焦点放在尺寸和性能上，放在对3.1
的功能进行完善上。Daytona有了显著的改进和增强。”Daytona最初的主题是尺寸、性能
、压缩以及Netware兼容性。其中的两个想法具有当时的时代特征：1990年以前，双倍压缩
是一个热门话题，因为当时硬盘很昂贵；Netware也是当时占优势的网络操作系统。“我们
最终停止了压缩项目，”Thompson说，“但是Netware兼容性部分是具有战略意义的。Nov
ell对NT桌面系统是矛盾的，他们不知道自己是否希望创建一个客户端。我们提供了帮助，
但是他们保持混乱，并且……我们做出了自己的。它是一个更好的Netware客户端，被用户
使用了几年，尽管最后他们也做了一个。这个客户端使NT桌面系统可以成为Netware的客户
端，因为Netware当时是市场上的主流服务器系统。否则我们的NT桌面将卖不出去。”

　　Daytona也得益于新的编译器技术，它使微软可以压缩代码尺寸，也使NT桌面成为真正
的低端系统。“结果是可统计的，”Thompson说。

　　Windows NT 3.51是配合Power PC发布的，因为它是围绕Power PC设计的，在3.5版本
中没有提供对Power PC的支持。由于IBM经常延迟Power PC芯片组的发布，导致了一个孤立
的NT发布。“NT 3.51的发布非常不值，”Thompson说，与对Daytona的评价正相反。“Da
ytona完成后，为了等待IBM完成Power PC，我们大概用了9个月进行错误修正。但是正因为
如此，NT 3.51是非常稳固的，我们的客户喜欢它。”NT 3.51最终于1995年5月开始销售。


　　接下来的Windows NT 4.0，开始采用Shell Update Release(SUR)，这是另一个得益于
NT模块化结构的挑战性任务。“我们希望创建一个使用95外壳的桌面，但是它使用NT技术
。”Lucovsky告诉我们，“我们最终迁移了Win32 GUI组件，并使其作为进程内驱动。性能
是受影响的一个方面，在一个不同的进程中运行这个API会带来问题。因此将代码迁移到作
为运行时的相同上下文，将解决大量问题。我们不必为GDI和USER做死锁检测。它是一个重
大工作，但它解决了大量令人头疼的问题。”NT 4.0于1996年7月投放市场，它是NT系列产
品的一个分水岭。

　　Windows挤掉NT

　　接下来的发布中，Windows NT放弃了NT这个名字，成为简单的Windows。Thompson说这
个决定来自市场队伍。“一个家伙从Windows市场部调到NT市场部，并且说我们将在所有地
方使用Windows这个名字。起初，改变名称令我们所有人都感觉不舒服，因为NT有很好的声
誉。但是由于伴随Windows 2000一起推出的可靠性，人们开始谈论究竟Windows 2000比旧
的NT要好多少，尽管它们基于相同的体系结构。所以这是一个偶然事件，Windows 2000没
有一个代码名是因为Jim Allchin不喜欢。”Thompson说。

　　自从完成Windows 2000之后，Windows队伍所作的最大决定是在Whistler产品中，分别
发布客户端和服务器，即现在的Windows XP和Windows Server 2003。“这使得我们将焦点
集中于服务器客户，他们现在更多地要求稳固性，”Thompson告诉我们，“桌面软件将按
照PC制造者的销售周期同步发售。这与服务器周期不同。”

　　David Thompson，微软公司Windows服务器事业部副总裁。1990年加入微软公司，在转
入Windows NT项目组之前，领导和负责公司的LAN Manager for OS/2项目。在开发Window
s NT期间，Thompson领导的开发团队在NT联网子系统方面作出优异贡献，不仅保证了该产
品可以与微软产品协调工作，而且保持了与其他公司产品的兼容性。

　　Mark Lucovsky，微软公司著名软件工程师和服务器构架设计师。1988年与Dave Cutl
er一起加入微软公司。他们都是前Digital Equipment Corporation(DEC)公司的杰出软件
设计师。Lucovsky凭借在早期将NT从基于OS/2的系统迁移到32位Windows应用程序过程中的
杰出贡献和技术敏锐，受到众多工程师的敬佩。

　　作者/Paul Thurrott译者/蒋世滨

　　本文节选自《Windows & .NET Magazine国际中文版》

　　“Windows团队的5000个开发者为Windows Server 2003编写了超过5000万行代码，这
是一个艰巨的任务，是已尝试的最大的软件工程任务，没有任何软件项目可与之相比。”


　　——Mark Lucovsky

　　NT系列操作系统从Windows NT发展到Windows 2000、XP，到现在的Windows Server 2
003，尽管细节部分在戏剧性地改变，但有一个关键元素一直没有改变，这就是build操作
。在微软内部，事实上每一天至少有一个Windows产品被编译或生成为可执行代码，开发队
伍可以立即对它进行测试。对于Windows Server 2003，这个过程在微软公司的26号大楼中
达到了极致，在那里，成排的PC和CD复制机始终处于几个工程师连续监视下。

　　“回想早年的日子，我们开始只有6个人，”Mark Lucovsky告诉我们，“现在Window
s团队有5000个成员，加上额外的5000合作伙伴，生产了超过5000万行的Windows Server 
2003代码。让所有人员遵从统一的领导制造代码是一个巨大的任务。生成他们的工作结果
，编译并连接为可执行程序或其他组件，最后组成一个Windows的CD，这个过程持续12到1
3小时，每一天都在进行。这是曾经尝试过的最大的软件工程任务。没有其他软件项目可与
之相比。”几乎在每一天，微软编译所有的东西——全部的5000万行代码，“我们始终在
改进开发环境。”Lucovsky强调。

　　“当我们开动机器时，我们编译全部的内容，”他说，“我们必须能够在任何时间点
再生这个系统。开发者Check-In代码，我们按下按钮并产生系统。我们应该能够在未来3年
内，使用不同的工具、编译器以及脚本再生系统。”

　　David Thompson详细介绍了这个过程。“关键在于我们整年地生成系统，并从三个方
面推进它，”他说，“首先是产品本身，其次是我们设计产品的方法，第三是我们与广大
客户的交互途径。产品的进化是完美的，我们现在使用了全新的源码控制(Source code c
ontrol)系统。我们从已有的技术开始，Mark Lucovsky亲自领导了新系统的开发，我们每
天都会生成一个阶段性(Staged)Build，这些阶段性Build将形成最后完整的Build。我们在
持续发展的同时维持了稳定性——我们了解我们每天的进度。”

　　吃掉它：微软端出狗食

　　“有一天我收到了85个Check-In，那是我们当时可以有的最大数量，现在我们每天可
以接收1000个以上，这是一个完全不同的比例，尽管现在白板实际上是电子的——基于We
b的。”

　　——David Thompson

　　Lucovsky回忆了一些往事，第一个NT原型是在他的办公室里生成的，然后他发出一封
邮件告诉NT团队，NT Build准备就绪。于是NT团队的50多个人将“吃掉他们自己的狗食”
，在他们自己的系统上测试这个Build并进行压力测试。“我们过去只是围绕这个Build工
作并写下我们发现的问题，”Lucovsky说，“这就是为什么它是pre-NT 3.51，现在我们有
7个Build实验室。Dave Thompson有自己的Build实验室，覆盖1200个人。主要的Build实验
室进行官方Build，它每天进出上千人。贯穿大学的主干服务器自动地将通知传送到各个地
点。”

　　Thompson说：“起初，我们可以每天在固定时间Check-In代码然后停止开发，接着开
始生成新系统。最终，我们将团队增加到85人，并将过程系列化以进行更多的控制。我们
都为Dave Cutler工作，他掌管生成实验室大约有一周，然后要求每个人在实验室白板上写
下自己的Check-In请求，并使其成为强制模式。我也在那里待了一段时间，有一天我收到
了85个Check-In，那是我们当时可以有的最大数量，现在我们每天可以接收1000个以上。
这是一个完全不同的比例。尽管现在白板实际上是电子的——基于Web的。”

　　“其他软件项目无法与之相比，”Lucovsky说，“但是有一件事是不变的，就是生成
Windows所需的时间。不管是该产品的哪一代，都需要12小时来编译并连接系统。”随着生
产过程能力的增长，Windows也随之增大，开发过程变得更为复杂，因此微软在每天的生成
中进行更多的代码检查。“Build实验室的CPU连续不停地工作12个小时，从Windows 2000
以后我们适应了这个过程。现在，我们将源代码彼此分隔开来并使用新的生成环境。这是
一个多机环境，使我们可以更快地生产。但是由于所有的代码都要进行分析，因此仍然需
要12小时。”

　　Thompson告诉我们，对于NT团队来说，完全“吞掉”他们自己的代码是必需的，并且
是与微软的自然条件并存的。“回想当年，这是我们一直在做的事之一，今天当我们谈起
email程序时都感到很可笑。当时第一次在PC上运行NT时，我们的Email程序无法工作，因
为它是一个DOS程序，而我们当时还没有DOS兼容模式。所以我们将内部的Email程序WizMa
il改造成Win32的，这样我们就可以只在NT系统上工作了。”

　　Thompson补充道：“当你被迫自己使用系统时，如果你看到了漏洞以及性能问题，你
必须找到那个负责人并要求他修正问题。”Thompson加入NT团队时，他的一个主要职责就
是将文件服务赋予NT，这样它就可以被用作源代码服务器。它需要的信任，特别是自NT使
用NTFS文件系统之后。“网络组非常认真地工作，”他说，“同时确保其做好内部布署的
准备。一旦它开始实施，就不可能回头。很显然，如果文件服务失败，那将是一场灾难。
所以那是我们的非常时期。”

　　后来，随着Windows NT 4.0开发的结束，Thompson的队伍采用了活动目录(AD)，这是
微软的第一个目录服务，它于1996年在Professional Developers Conference(PDC)公开发
表。“在AD之前，我们在基础构造中使用NT域，”他说，“转向AD更为复杂。我们很早就
部署了AD，先是我们的团队，然后是更广泛的Windows小组。在1999年4月，我们在雷德蒙
大学正式使用了AD。”

　　Thompson说，微软谨慎地在公司的其他级别实施AD，大学在上一年使用Windows Serv
er 2003实现了多森林AD拓扑。“对所有的基础服务器，我们总是在内部进行完全的部署，
然后推广到JDP(Joint Development Partners)，他们进行测试，并在250个使用场景中将
其产品化。我们收集错误报告、功能反馈以及复杂的测试环境，以考验产品。”

　　2002年夏天，Windows Server 2003(RC1)的可靠性达到了99.995%。2002年11月，Mic
rosoft.com网站完全采用Windows Server 2003(RC2)部署。“在内部大量使用并接近客户
是关键，”Thompson告诉我，“我们现在的产品更加成熟。我们不仅仅售出盒装产品，还
售出范围广泛的补充工具、产品、服务以及文档。”Thompson还谈到当前Outlook 11、Ex
change Server 2003(Titanium)和Windows Server 2003团队工作结合得更为紧密，以满足
最终客户的需求。过去这些产品经常是独立开发，互不相干的。

　　关注产品服务

　　Lucovsky补充道：“这些年服务也走向成熟，我们为每一个产品做了大量的工作，提
供正确的混合服务包、热修复、产品开发分支、beta以及JDP客户。”(在下一节里有更多
关于开发分支的信息)

　　“我们确实延长了对产品进行服务的时间。”Thompson说，因为微软售出一个服务器
产品时，客户可能使用长达10年之久。Volume或mainstream在过去的7年中提供服务，但是
公司一直在研究提供全程升级和修正的方法。首先，微软必须确保错误修正被应用到所有
开发分支。“我们在快速定位安全性缺陷上的工作，意味着我们现在可以更积极主动地发
布热修复，”Thompson强调，“同样，它使服务包更具弹性，一个可以像传递修正包一样
传递新功能的方法。但是客户使其更明确，他们只希望得到错误修正。尽管这导致了一个
有趣的问题：究竟什么才算是错误？一个缺失的功能是吗？客户经常有他们自己的观点。
不过NT 4 SP3是最后一个包含主要新功能的服务包。”

　　影响主干服务的一个方面是微软必须为近期产品的每一次改变保留测试环境。这意味
着Windows 2000的最终版或“黄金”版是一个分支，Windows 2000 SP1是另一个，Window
s 2000 SP2又是一个，依此类推。“完全消化对于提供服务包也是很重要的。我们在自己
的IT组织保留了一个独立的Windows 2000基础生成品，这样我们可以随时生成Windows 20
00系统，并在产品环境中测试，”Thompson说，“这样做代价昂贵，但是值得。”

　　热修复被精简成只修正一个特定问题，并且不会影响系统的其他部分。Thompson说一
般情况下，客户只有在受到相关问题影响时，才应用一个热修复，但是安全性修正则是另
一回事。“我们希望所有的客户安装安全性修正，因此我们对它们非常谨慎，并且做了足
够的测试。它们一般是可分发的发布(Deployable Releases，GDRs)，就像服务包一样。”


　　主干、树和分支

　　正如前面提到的，不同的Windows版本需要一系列的产品代码分叉路口，在那里不同的
Windows产品从“主干”开发中“分支”出去。因此每一次Windows发行会产生至少两个不
同的版本，在本文撰写时，Windows Server 2003和Longhorn正在同时开发。因为Windows
 Server 2003是从XP分离的，因此这个服务器产品基本构建于XP之上。在未来几年要超越
XP的客户端发行版本Longhorn，实际上是从服务器代码分支基础生成的，而不是您所期望
的XP。

　　Lucovsky告诉我们：“这个机制是自觉的，我们对当前Windows版本有一个主要代码分
支，它成为热修复和下一个服务包的源码基础。一旦我们推出一个服务包，它就成为一个
新的分支，这样我们就有了两个分支，用来测试热修复和服务包。我们不能告诉客户说安
装SP1并进行热修复。这在每一次Windows发行中延续，因此会有两三个服务包，许多热修
复以及许多安全性修正。其中每一个都是被管理的，是一个5000万行代码的集合。这是一
个巨大课题。”

　　另外，对于每一个开发的主要分支，微软也有大约16个分支团队，并允许他们在公共
主线上独立地并行工作。每一个团队掌握一个完整的生成实验室环境，用来生成包含他们
所做更改的完整发行版本，各团队定期地将经测试的更改整合到主要分支中，这样他们可
以互相交流已测试的工作。

　　将错误消灭在作战室

　　“如果有人不在作战室，我会批评他们，我专踢笨蛋。”

　　——Todd Wanke

　　微软产品主管、Windows Server发行管理处

　　项目最令人激动的地方是在作战室，在那里战斗团队每周5到6天，每天会面2到3次。
现在Windows Server进入了开发的最后阶段。“战斗团队每天对项目进展进行度量并做出
报告。”Thompson告诉我们，说作战室令人震惊毫不夸张。“现在一切都是自动的，但是
想当初我们刚来时，都要将我们的工作写在纸上。那时作战室有大约15到20个人。现在大
不相同了。”

　　Todd Wanke掌管Windows Server 2003的作战室，我们惊讶地发现他非常迷人。但是在
作战室工作时，他是一个铁腕人物，他到处发号施令，产品组成员只能耐心地忍受残酷的
会议进程。

　　作战室的工作状况是这样的，每天早上9:30，来自不同Windows Server 2003功能团队
的代表进行会面并筛选错误。他们排队进入26号大楼的3243房间，它的门上标着手写的“
Argument Clinic”。在房子中央有一个大会议桌，但是许多参与者都站着，房子里总是塞
满了人。我们参加战斗团队会议的那一天，这是第一次允许外界人员进入Windows Server
的圣地，也是整个NT和Windows开发历史中的第二次，那一天团队讨论了大约50个错误，大
部分是简单的商标错误，尽管那天不允许我们参与一些特殊错误的讨论(因此我们很晚才进
入，最重大的论题是在最后一刻将Windows .NET Server 2003改名为Windows Server 200
3)。

　　每一个错误都被记入一个递增的错误跟踪系统，伴随着令人眼花的信息，包括错误是
如何发现的、是否有客户受到了影响，以及错误被根本解决的完整历史。Wanke快速地审阅
错误，并叫来相关功能团队的成员，让他们说明修正进展的情况。例如，如果IIS存在一个
或多个错误，则IIS团队的代表需要列席，他不仅要说明错误，还要说明客户是否会受影响
、修正对系统其他部分的影响，以及修正将在多长时间内完成。在开发过程的最后，如果
错误不是十分严重，它将被“传”给下一个Windows发行版本——Longhorn。

　　作战室的气氛是紧张压抑的，我大部分时间都保持缄默，心里祈求Wanke不要注意到我
和我的团队。作战室里进行激烈的争辩，对错误的处罚是受到其他团队成员的耻辱，并把
错误遗留给了Longhorn。当有人建议另找时间讨论时，Wanke简单地说：“去它的，如果它
足够重要，它就应该放在这里。它将留给Longhorn。下一个错误！”

　　当漫长的会议结束后，我们坐下来与Wanke闲聊，这时他已完全判若两人。我对他说：
“你主持了一个有意义的会议。”Wanke的背景包括NCR节约开支、美国本田以及作为美国
政府承包商的一个与安全性紧密相关的神秘角色。他已经伴随微软接近8年了。在加入Win
dows团队之前，Wanke是Microsoft.com网站的原始设计者之一，在微软所有人认识到Inte
rnet的重要性之前，他已经当了4年的“网民”。在我们的会谈中，Wanke讲述了他调换新
工作的过程，他现在做什么，以及战斗团队是如何工作的。

　　“我的工作是每天对Windows的销售操作进行管理，”他说，“我对800到1000个开发
员、程序管理员和测试员负责，我必须保证他们每天做正确的事情。”

　　Wanke说战斗团队由Windows团队的许多人组成，他们分别负责项目的不同领域。他们
的职责是测试TCP/IP和其他底层技术，一些开发员每天进行生成，另一些每天生成校验测
试。他告诉我们：“项目的每个领域都有代表，战斗团队每天向Windows Server队伍发出
指令，指令也来自我发出的公告板邮件。这些邮件几乎都是绝密的，特别机密的邮件只发
给少数小组成员。”

　　正如我们所见，作战室是一个严密的机构，每天每小时都在精确运转。团队的成员每
天研究相同的错误系统，并经常共同修正一个错误。“如果你不在那里，它就不会好，”
Wanke说，“微软的员工对产品有很强的主人翁意识，他们希望确保一切正确。但是如果有
人不在那里，我会批评他们，我专踢笨蛋。”

　　除了早上的作战室会议，Windows Server团队还在下午2到3点开会，如果需要，下午
5到6点还有一次。每天的Build工作一般在4点半开始，但是可以推迟到6点，因此最后一次
会议使团队有机会将最终修正增加到当天的Build中。Wanke说：“这个机构是很重要的，
我们需要在任何时间了解Build的进度。我们检查Build的质量，不同的压力级别以及通宵
运行发生的一切、任何我们需要跟踪的东西。我们获取详细的报告，并复检项目的所有内
容。”

　　除了主体战斗团队，每一个功能团队也有自己的作战室，因此每天最多可能有50次这
样的会议，每一次都针对一个特定的系统组件。这些额外的作战室会议每天早上8点召开。
当一个错误修正在本地战斗团队通过后，它会被推荐给Wanke的会议。“除非他们做好修正
准备，否则他们不能进入作战室，他们必须准备好修正。”Wanke说。

　　生成Windows的复杂程度令人惊叹。Wanke说：“为了简便，我们说Windows由100,000
个文件组成，通常有7个源码仓库，每一个都包含一个全部源码的正确复制，尽管我们只使
用其中一个。每个开发组都有自己的仓库，因此当一个开发员写好修正时，他可以用自己
的源码仓库进行编译并进行测试，然后提交给主要Build试验室。”

　　当然，不是所有的Build都是成功的。Windows Server经常遭受微软所称的“低级Bui
ld(build on the floor)”，当一个修正破坏了系统其他部分时，Build将报废。“那是残
酷的，”Wanke告诉我们，“在去年有一段时间，我们在7天的时间里都无法得到一个合格
的Build。我们不得不给公司产品组发邮件解释这个问题。”后来公司输入了他们的保留版
本Defcon-5。“所有的红色指标都攀升了，”他说，“这使开发员牢牢记住了不要破坏Bu
ild。他们做了修正，一个好的Build，然后进行了检查。但是他们不能回家。我们在凌晨
3点打电话，当一个Build损坏时，要找出破坏它的开发员，让他立即工作并修复。这个开
发员一天24小时随时待命。这将明显地增加工作量。一个损坏的Build被认为是一级严重错
误。”

　　随着Windows Server 2003开发周期接近尾声，错误统计奇迹般地降低了，每天的过程
也简单多了。接着微软宣布了名称改变。“我们不得不接受这个可恶的决定，”Wanke告诉
我们，“他们应该在6个月前作决定。那时我们都会赞成这样做的。但是后来CEO Steve B
allmer不得不与所有的战斗团队探讨为什么做这个改变。”团队要修改所有商标图案、文
本和系统注册表，要求的速度是前所未有的。问题是要在几千个地方进行更改，而这通常
需要在错误跟踪系统中增加几千个入口。“我出去找了3个最精干的开发员，然后说‘去改
吧。’其中一个开发员修改了7,000处与Windows .NET Server相关的地方。我只是说有些
人我信任，有些人我不信任。我告诉这些小伙子，‘不要告诉我你们做什么，尽管去做吧
。’”

　　向终点冲刺

　　2003年1月21日，我们在作战室的那一天，据Wanke声称，Windows Server 2003的错误
达到了“绝对历史最低点”。“我们将在本周结束项目，”Wanke说，“它已完成了。我们
将把它卖出去。”那一天，Windows Server 2003只有少数的错误，并且大部分只是简单的
商标问题。“我们有大约150个重要问题需要定位，其中，我们即将修正100个。所有这些
错误的严重级别是一到三，加起来我们只剩下很少的一级严重错误需要修正，在销售之前
必须全部修正。”

　　Wanke说那时服务器团队已经修复了所有已知的安全性缺陷。他说：“我们对安全性很
满意，很高兴看到我们是安全的，我个人对这个工作过程有深刻印象。这是个修正和思考
的过程。我们都认为它非常安全。去年提出的‘可信赖计算’是我们的里程碑，因此所有
一切将会比较容易地开展。对开发员来说，他们现在有了统一的思想和最佳实践的相同培
训。在从前不同的小组使用不同的方法。安全性使它们得以统一。现在所有人都理解了最
终思想，并且相互交流容易多了。”

　　随着Windows Server 2003组件的开发完成，开发队伍进入了一个过渡期。首先，产品
将被封存，生成过程会被冻结。这个Build会被分发到大学以及微软公司体系。Wanke强调
：“这是最终的Build，我们将停下一段时间，其间对产品不会有根本的修改。被封存的B
uild也将由测试者和JDP成员持有。”

　　如果在封存期出现问题，战斗团队会逐个决定是否修正错误。如果是必要的内核修正
，就会产生一个新的Build，封存就被“重启”。“核心组件的更改会延迟RTM，”Wanke说
，“我们将首先请求客户运行，在停工之前也要运行数天，这是一个长时间的反复。”每
一个Windows Server 2003功能团队都必须连续地运行封存生成品21天，然后才可以投放生
产。

　　但是Wanke并不担心精确的日程表，因为一年的辛勤工作最终会有结果，他的团队已经
开始为RTM庆祝聚会做准备，聚会将在大学的一个足球场举行，如果不被允许，就移到一个
车库里，Wanke考虑的另一个与RTM相关的问题是必须确定启动地点。“我和启动队伍一起
登记地点，他们需要可信度在95%的确定日期。”他们也要使OEM们确信系统已准备好启用
，“我必须确保8000个期望者得到一个销售奖励。”Wanke补充道。

　　最后，所有努力的结果是诞生了一个微软历史上最可靠最安全的操作系统，Wanke对这
个项目的贡献是不可忽视的。“在一年半的时间里，我基本上没有离开战斗团队，没有因
为个人原因休息过一天，在后期我们每周工作6天，我们让员工在星期六带上自己的孩子。
那是一个家庭日。星期六没有法定要求。但你仍然要留在那里，仍然要进行生成工作。”


　　Wanke还会掌管未来版本Windows的战斗团队吗？

　　“没门，”他笑着说，“没门！” 

 

--
◢ ┏━━━━┓┏━━━┓ ┏━━━━┓ ┏━━━━┓ ◣
   ┃  ┏━━┛┗┓  ┏┛ ┃  ◢◣  ┃ ┃┏━┓¤┃   
   ┃  ┗━┓    ┃  ┃   ┃  ◥◤  ┃ ┃┃■┗┳┫   
   ┃  ┏━┛    ┃  ┃   ┃  ┏┓  ┃ ┃┗┓■┃┃   
   ┃  ┃      ┏┛  ┗┓ ┃  ┃┃  ┃ ┃  ┗━┛┃   
◥ ┗━┛      ┗━━━┛ ┗━┛┗━┛ ┗━━━━┛ ◤

※ 来源:．哈工大紫丁香 bbs.hit.edu.cn [FROM: 210.46.79.17]