Windows Server 2003: немного истории

Во время поездки в Редмонд с Джанет Роббинс и Майклом Оти я воспользовался случаем побеседовать с двумя знаменитыми личностями в мире Windows - Марком Луковски и Давидом Томпсоном. Для тех, кто не знает истории Windows NT, которую потом стали называть просто NT, поясню: Луковски и Томпсон играли ключевую роль в разработке этого важного проекта в области программного обеспечения. Марк Луковски, ведущий инженер и архитектор Windows Server в Microsoft, пришел в компанию с первой волной бывших сотрудников DEC (Digital Equipment Corporation), вместе с Дейвом Катлером, архитектором системы NT. Первоначально получивший известность благодаря своей удивительной способности разобраться в том, каким образом в системе NT работают вместе тысячи компонентов, Луковски широко известен своей технической проницательностью и предыдущими попытками преобразовать систему, уходящую корнями в OS/2, в систему, которая будет запускать 32-разрядные приложения Windows. Давид Томпсон, вице-президент группы Windows Server Product Group, появился в Microsoft в 1990 году, тогда он руководил группой новых технологий в проекте LAN Manager до присоединения к группе NT в конце 1990 года. Томпсон занимался разработкой сетевых подсистем NT, обеспечивая совместимость этого продукта не только с продуктами Microsoft, но и с решениями независимых разработчиков.

Вот как это все начиналось.

Первые годы. Группа NT прибывает в компанию Microsoft

"Мы пришли все вместе, как одна группа, в ноябре 1988 года", - сказал Луковски, припомнив, что первое задание для команды NT состояло в том, чтобы получить компьютеры для разработки, они были вершиной семейства - процессор 386, 25 МГц с накопителями на жестких дисках 110 Мбайт и 13 Мбайт оперативной памяти. "Они были ужасно дорогие", - вспоминал он, смеясь. Первые две недели работы были небогаты событиями, поскольку команда NT применяла Microsoft Word для создания первоначальной документации для проектирования.

Наконец, настало время писать программу. "Мы проверили первые куски программы приблизительно в середине декабря 1988 года, - рассказывает Луковски, - причем у нас было что-то типа загрузки почти основной системы на эмуляторе Intel i860 (с кодовым названием "N-Ten") уже в январе". Фактически вот откуда взялось имя системы NT. Луковски отметил, что имя "new technology" (новая технология) было добавлено после неожиданного успеха маркетинговой программы продукта NT. "Первоначально при разработке системы NT мы нацеливались на Intel i860, но появление RISC-процессора сильно выбивалось из графика. Поэтому не было ни одной системы i860 для проведения тестирования, и мы использовали эмулятор i860. Вот почему мы и назвали систему NT, ведь мы сами тогда работали на эмуляторе 'N-Ten'".

Переименованная группа, разрабатывающая систему NT, создала основную систему с режимом исполнения ядра basic kernel mode (basic kernel mode - привилегированный режим работы процессора для исполнения системного кода с неограниченным доступом к системным ресурсам - Прим. перев.) и подготовила запуск на эмуляторе к апрелю 1989 года. "Мы начали с пяти специалистов из DEC и одного 'со стороны' (т.е. из Microsoft), которого звали Стив Вуд, - пояснил Луковски, - И мы оставались крошечной группой довольно долго - все лето. Мы подумали, а насколько трудно создать ОС? И составили график на 18 месяцев для создания системы NT. Но мы забыли о некоторых важных компонентах: пользовательском, сетевом режиме и т.д."

К концу 1989 года численность группы NT начала расти. Добавилась одна сетевая группа и расширилась группа по безопасности, в дополнение к одному индивидуалу, который прежде отвечал за разработку файловой системы и локализации. "Численность нашей группы за тот первый год выросла до 50 человек или около того, - заметил Луковски. - И в течение года мы, в конце концов, получили первые функционирующие прототипы i860, так что могли использовать их вместо эмуляторов. Начав с рассмотрения контекстных переключателей программы, мы получили идею, как ее лучше реализовать. Почти сразу же стало очевидно, что i860 никогда не выполнит эту задачу. Тогда мы начали рассматривать архитектуру MIPS и как другой проект RISC".

В декабре 1989 года группа NT приняла решение прекратить работу с i860 и перейти на процессор MIPS R3000chip. "В течение двух-трех месяцев мы выполняли начальную загрузку системы NT на реальной аппаратуре в режиме Big Endian, - рассказал Луковски, - и наша архитектура действительно заработала. Мы разрабатывали проект NT, который можно было бы переносить с системы на систему, и мы доказали это при переходе на MIPS - система заработала практически сразу. Мы вносили необходимые изменения без особых затруднений".

Уже в то время численность группы NT стала быстро расти, теперь большинство ее членов приходило из Microsoft. Очень выросла численность группы графики, сразу был создан новый режим обработки графики. Разработчики начали портировать NT на Intel i386, который в то время был серийно выпускаемым процессором для персональных компьютеров. Луковски объяснил, почему для группы важно, что они первоначально не нацеливались на i386. "Мы какое-то время держались подальше от 386-х, чтобы не увязнуть в трясине архитектуры, - сказал он. - Мы не хотели использовать непереносимые решения. Если бы мы применили процессор Intel с самого начала, то получили бы более высокопроизводительную систему, но это могло бы причинить вред NT в дальнейшей работе и затруднить процесс создания новой архитектуры, как случилось с последними версиями Windows Server 2003 для 64-разрядного Itanium".

NT становится Windows NT

"К весне 1990 года мы имели версию для MIPS, медленно продвигающуюся вперед, и сосредоточились на версии для 386-х, - рассказывает Луковски. - Это было другое направление роста. В мае Microsoft выпустила Windows 3.0, и оказалось, что система Windows имеет потрясающий успех. Стало очевидно, что будущее - за персональными компьютерами с операционными системами, основанными на графических решениях. Мы стали присматриваться к Windows 3.0, и задумались, а что если бы вместо OS/2 мы сделали 32-разрядную версию Windows?" Это был вопрос, вокруг которого вращалось все в последующее десятилетие развития вычислительной техники. "Стив Вуд, Скотт Людвиг, специалист из группы графической системы для построения изображений и, собственно, я - смотрели на 16-разрядный программный интерфейс приложений Windows API и прикидывали, как бы ухватиться за него и дотянуть до 32-разрядного интерфейса приложений. Мы провели полтора месяца, создавая набор API, и потом представили его группе предварительного обсуждения проекта из 100 специалистов, чтобы выяснить их мнение об этом проекте", - вспоминает Луковски.

Главная характеристика нового программного API, который впоследствии получил название Win32, заключается в том, что это был новый API, он выглядел и функционировал точно так же, как 16-разрядный Windows API, что позволяло разработчикам без труда перейти на новую систему и перенести на нее свои приложения. "Мы обеспечили возможность переноса 16-разрядных приложений на NT, - отметил Луковски, - и эти приложения могли использовать преимущества уникальных возможностей NT, например, больший диапазон адресов. Кроме того, мы добавили новые API, которых не было в 16-разрядной версии. Мы добавили много новых функций в API, сделав полный набор API для операционной системы, однако мы старались сделать так, чтобы он оставался знакомым подавляющему большинству программистов Windows".

Реакция Microsoft была незамедлительной. "Им очень понравилось, - сказал Луковски, - когда они увидели, как это могло быть просто. Это была как бы Windows на стероидах, а не OS/2, которая использовала совершенно другую модель программирования". Однако создание системы NT как 32-разрядной Windows вместо OS/2 порождало новые проблемы, и не все они были техническими. Microsoft должна была получить одобрение независимых поставщиков программного обеспечения, ISV, и производителей комплектного оборудования, OEM, и, конечно, сообщить IBM об этом изменении. "Мы сделали предварительный показ для ISV с IBM, у нас была пачка приблизительно из 20 слайдов. Сначала они думали, что Win32 - это кодовое имя для OS/2. Посмотрели бы вы на их лица: 'Подождите, но это же не OS/2!", - вспоминает Луковски.

Решение перейти с OS/2 на Windows навсегда испортило отношения между двумя компаниями. "Но у нас было одобрение руководства, и мы начали перенос, - сказал Луковски. - Таким образом, вместо работ по подсистеме OS/2 для NT мы собрали Win32. В этот момент продукт и стал Windows NT".

Модульная архитектура NT во время этой переделки опять оправдала себя. "Благодаря нашей архитектуре микроядра, а ядро Win32 не связано со средой приложений (предметной областью), подобно интерфейсу переносимой операционной системы POSIX, нам не пришлось менять ядро или начинать новые работы по программированию, - отметил Луковски. - Не надо было менять глубокие внутренние компоненты планировщика. У нас были приложения из командных строк на С, и мы осуществили запуск приложений за две недели. Это был сентябрь 1990 года".

Томпсон подчеркнул значимость принципов построения системы NT: "Надежность нашей архитектуры ядра так высока, что мы могли бы перенести NT с машин 386-25 1990 года выпуска на современные системы, 64-разрядные мультипроцессорные машины и серверы-лезвия за 1000 долларов. Мы могли бы запустить целый массив служб на ней".

Сентябрь 1990 года в полном смысле этого слова стал поворотной точкой для Windows NT. Не случайно также, что Дейв Томпсон, ранее возглавлявший группу новых технологий Microsoft по LANMAN для OS/2 3.1, перешел в группу NT. "Мы переключились с этой темы, - пояснил Томпсон, - и численность группы возросла с 28 приблизительно до 300 человек. У нас был первый замысел реального продукта".

RTM и остальное

Первая версия Windows NT, Windows NT 3.1, была выпущена в июле 1993 года и названа для согласованности по номеру версии самого современного на тот момент 16-разрядного продукта Windows. Та версия NT напоминала настольную версию и имела серверные редакции и распределенную модель безопасности на базе доменов. С этого времени группа NT продолжила разработку ряда версий, которые все были созданы на одинаковой базе кода.

Следующая версия, Windows NT 3.5, имела кодовое название Daytona; она была выпущена в сентябре 1994 г. "Проект Daytona был очень важен, - считает Томпсон. - Мы сосредоточились на проблемах полноты функций и производительности, а также на "полировке" большинства впервые введенных в версию 3.1 функций. Проект Daytona, кроме того, имел существенные функциональные усовершенствования и расширения".

Первоначальными задачами проекта Daytona были полнота, производительность, компрессия и совместимость с сетевым программным обеспечением Netware. Две из этих задач были символическими для того времени: двойная компрессия (типа DoubleSpace) была актуальной темой в начале 90-х годов, потому что дисковое пространство тогда было большим дефицитом, и операционная система Netware была в то время превалирующей сетевой ОС. "Мы в конце концов закончили функцию сжатия, - заметил Томпсон, - но порт с Netware был стратегическим. Серверы Novell располагались вокруг настольных систем NT- их разработчики не знали, хотят ли они создавать клиента. Мы предложили свою помощь, но они не проявили энтузиазма - и ладно. Мы сделали свою систему. Они просто упустили шанс. Наша система была лучшей для Netware, и клиенты пользовались ею не один год, даже после того, как разработчики, наконец, создали свою. Тот клиент включал настольную систему NT, потому что операционная система Netware была лидирующим сервером на рынке. Мы не могли бы иначе продавать настольные версии NT".

Временная диаграмма NT:

Проект Daytona также использовал преимущества технологии нового компилятора, который позволял Microsoft сжимать коды и запускать практичные настольные системы NT на более дешевых компьютерах, чем оригинальная версия. "Результаты были ощутимыми", - подчеркнул Томпсон.

Windows NT 3.51 должна была сопровождать выход Power PC, поскольку она проектировалась для него, а Power PC первоначально планировалось поставлять с версией 3.5. Но IBM постоянно задерживала Power PC, и в результате NT пришлось выпустить отдельно. "NT 3.51 была незначительно измененной версией, - отметил Томпсон, сравнивая ее с проектом Daytona. - После завершения проекта Daytona мы в основном в течение девяти месяцев занимались поиском неисправностей, ожидая, когда же IBM закончит аппаратуру Power PC. Однако благодаря этому NT 3.51 стала надежной и наши клиенты хорошо восприняли ее". NT 3.51 была окончательно завершена и выпущена в 1995 г.

Соответственно, следующий выпуск NT, Windows NT 4.0, стал известен как Shell Update Release (SUR), версия с новой оболочкой. Он решил другую перспективную задачу и еще раз доказал преимущество модульной архитектуры NT. "Мы хотели построить настольную систему, которая имела бы оболочку от версии 95, но использовала новую технологию NT, - сказал Луковски. - Мы в конечном итоге перенесли компоненты графического интерфейса пользователя Win32 и приняли их в качестве внутрипроцессного драйвера. Производительность была еще одним эффектом. У нас были неполадки, когда мы брали тот API и запускали его в другом процессе. Поэтому перенос кода в одинаковый со средой исполнения контекст решил много вопросов. Нам не пришлось иметь дело с зависаниями по GDI и USER. Это была большая работа, но она решила много проблем". Версия NT 4.0 увидела свет в июле 1996 г.

Везде Windows

Со следующей версией Windows NT потеряла частицу NT и стала называться просто Windows. Томсон говорит, что это решение было инициировано группой маркетологов: "Специалист по маркетингу Windows [9x] закончил маркетинг NT и сказал, что везде следует использовать Windows. Сначала нам не хотелось менять имя, потому что NT имела солидную репутацию. Однако в силу надежности, привнесенной Windows 2000, все начали говорить, что Windows 2000 намного лучше, чем 'старушка NT', хотя архитектура была одинаковой. Таким образом, то, как это произошло на самом деле, - чистая случайность". Кстати, по словам Томпсона, проект Windows 2000 не имел кодового имени, потому что Джим Аллчин не любил этих имен.

После завершения Windows 2000 самое важное решение, принятое группой Windows, заключалось в разделении выпусков клиентских и серверных продуктов Whistler, которые стали называться Windows XP и Windows Server 2003. "Это позволило нам сосредоточиться на клиентах серверных версий, которые предпочитают надежные системы, - заметил Томпсон. - Программное обеспечение настольных систем должно поставляться синхронно с циклами продаж производителей персональных компьютеров. С серверами меньше суеты".

Развитие Windows

Один элемент в семействе операционных систем NT, прошедших в процессе эволюции путь от системы Windows NT до системы Windows 2000, XP и теперь Windows Server 2003, на протяжении многих лет оставался неизмененным, хотя компоненты менялись очень сильно. Это процесс создания. Где-то в глубинах Microsoft фактически ежедневно как минимум один продукт Windows компилируется или собирается, превращаясь в исполняемый код, который будет тестироваться внутри компании в группах разработки. Для Windows Server 2003 этот процесс доводят до кондиции в здании 26 кампуса в Редмонде, где тысячи компьютеров и систем по штамповке компакт-дисков работают под присмотром нескольких инженеров.

В процессе эволюции NT - простите, Windows - изменилась поразительно, начиная с того момента, когда проект стартовал в конце 80-х годов. "Когда мы начинали работу, нас было шестеро, - вспоминает Луковски, - Сегодня в команде Windows 5000 сотрудников да еще 5000 дополнительных партнеров, генерирующих больше 50 миллионов строк кода для системы Windows Server 2003. Взаимодействие со всеми этими людьми, движущимися в одном и том же направлении, и сложный характер программы представляют собой колоссальную задачу. Сборка результатов их работы, компиляция и связывание в исполняемые файлы и другие компоненты, которые составляют один компакт-диск Windows, - это 12-13-часовой процесс, который выполняется ежедневно. Это самый большой проект по проектированию программного обеспечения, который когда-либо затевался. А компания Microsoft компилирует все 50 с лишним миллионов кода почти каждый день. Мы все время развиваем среду разработки".

Далее Луковски отметил, что когда разработчики вносят изменение, они компилируют всю систему. И продолжил: "Мы также должны уметь воспроизводить систему с любого места. Таким образом, разработчики проверяют код, мы давим на кнопку, а на выходе получается одна система. Мы должны уметь воспроизвести эту сборку через три года, используя различные инструменты, компиляторы и сценарии, которыми пользуемся сейчас".

Давид Томпсон уточнил этот процесс. "Ключом здесь является то, что мы строили эту систему несколько лет, совершенствуя ее в трех измерениях, - сказал он. - Первое - это сам продукт. Второе - метод проектирования продукта. И третье - это метод взаимодействия с широким кругом партнеров. Система контроля исходного кода программы (на входе транслятора), которую мы сейчас применяем, является новой, потому что мы фактически достигли "потолка" предыдущей версии еще с Windows 2000. Марк Луковски лично руководил разработкой этой новой системы. Мы начали с некоторой приобретенной технологии. Теперь мы действительно имеем ступенчатую сборку. Но каждый день промежуточные сборки трансформируются в полную сборку. Таким образом, мы можем расширяться, но сохранять устойчивость - мы каждый день знаем, на каком этапе находимся".

Попробуй то, что приготовил сам

Луковски немного рассказал о самом начале пути, когда первые образцы NT строились в его офисе, и за этим процессом наблюдал только один человек. Этот человек мог просто разослать электронную почту группе NT, когда новая сборка была готова, а потом 50 человек или около того могли "попробовать то, что приготовили", проверяя сборку на собственных системах и запуская тесты. "Я обычно просто ходил по зданию и записывал обнаруженные проблемы, - сказал Луковски. - Это было до NT 3.51. Теперь у нас семь сборочных лабораторий. Томпсон имеет собственную сборочную лабораторию на 1200 человек, которыми он руководит. Главная сборочная лаборатория создает официальную сборку, которая ежедневно рассылается тысячам людей. Автоматическое уведомление рассылается на многочисленные системы через базовые серверы по всей территории кампуса".

Затем о сборке продолжил рассказывать Томпсон: "После этого мы поворачивали стрелку и компоновали новую систему. Со временем численность группы выросла до 85 человек, и был организован серийный процесс для большего управления. Архитектор NT Дейв Катлер возглавлял лабораторию сборки около недели, и он требовал, чтобы разработчики записывали свои результаты проверки на доске в лаборатории. Я тоже там дежурил. Однажды я принял 85 запросов на проверку, самое большое число на тот момент. Теперь мы можем отслеживать каждый день больше тысячи. Это совершенно другой масштаб. Даже доска теперь электронная - естественно, на web".

"Нет других проектов программного обеспечения, подобных этому, - отметил Луковски, - но одна вещь, которая остается постоянной на протяжении этих лет, - это сколько времени занимает сборка Windows. Независимо от того, о каком поколении продукта идет речь, процесс компиляции и сборки системы занимает 12 часов". С увеличением производительности обработки информации, которая выросла в течение этих нескольких лет, система Windows тоже сильно выросла, и процесс проектирования стал более сложным, поэтому Microsoft приходится выполнять больше работы по анализу кодов, что является частью ежедневной работы по компиляции и сборке. "Центральные процессоры в лаборатории сборки постоянно дают эту цифру - 12 часов, - сказал он. - Со времен Windows 2000 мы изменили процесс. Теперь мы проводим декомпозицию исходного кодового дерева на независимые исходные деревья и используем новую среду сборки. Это многомашинная среда, которая позволяет обходить препоны быстрее. Однако из-за всех новых процедур анализа кодов процесс все равно занимает те же 12 часов".

"Опробовать код на себе всегда было главным требованием группы NT, - рассказывает Томпсон, - Это одна из тех вещей, которые мы делали всегда, начиная с первых дней. Мы только сегодня шутили по этому поводу, как ни удивительно, говоря о нашей программе электронной почты. Возвращаясь к тому времени, когда мы впервые запустили NT на настольной системе, наша программа электронной почты не могла запускаться, потому что была DOS-приложением, а у нас еще не было режима совместимости с DOS. Поэтому я перенес наше внутреннее почтовое приложение, WizMail, на Win32, и таким образом, мы смогли применять NT-системы".

"Когда вам приходится использовать собственную систему, вы видите ошибки и результаты выполнения, - добавил Томпсон. - И вы обращаетесь к тому, кто за это отвечает, и просите исправить ошибку". Одна из основных обязанностей Томпсона, когда он вошел в группу NT, заключалась в том, чтобы перенести файловый сервер на систему NT, чтобы его можно было использовать в качестве сервера для исходного кода. Это была своего рода проверка на прочность, поскольку потом система NT начала применять опытный образец файловой системы NTFS. "Сетевая группа взялась за нее очень серьезно, - сказал Томпсон, - и убедилась, что файловый сервер готов для внутреннего развертывания. Раз приняв ее, мы больше никогда от нее не отказывались. Очевидно, если файловый сервер идет ко дну, это беда. Мы ощущали большое напряжение, преодолевая тот критический момент".

После сворачивания работ над Windows NT 4.0 группа Томпсона начала работу с первой службой каталогов - Microsoft Active Directory, AD. Первая служба каталогов Microsoft публично дебютировала на PDC (Professional Developers Conference) - конференции профессиональных разработчиков в 1996 г. "До службы каталогов AD у нас были домены NT для нашей инфраструктуры, - уточнил Томпсон, - и переход на службу каталогов AD был чрезвычайно сложным. Мы ввели AD в действие очень рано, сначала в своей группе, потом в более широкой группе Windows. Затем мы реализовали AD в Рэдмонде в апреле 1999 г."

"Компания Microsoft предоставляла службу каталогов AD всем остальным в компании постепенно, - продолжает Томпсон, - применяя тщательное планирование. Весь Редмонд погрузился в чащобу лесов топологии AD вместе с Windows Server 2003. Для всех серверов инфраструктуры мы всегда делаем полное развертывание внутри, затем передаем это на уровень партнеров по совместным разработкам JDP (Joint Development Partners - партнеры по совместным разработкам). Они тестируют и вводят результат в производство, при этом используется больше 250 сценариев использования. Мы получаем отчеты по неполадкам, обратную связь по функциям и тестирование по сложным сценариям, которые фактически осуществляют реальную проверку продукта".

Система Windows Server 2003 достигла надежности 99,995 процентов на стадии RC1 (Release Candidate 1 - первый кандидат на выпуск) прошлым летом, и Web-сайт Microsoft.com был полностью реализован на системе Windows Server 2003, когда появился второй кандидат в ноябре 2002 г. - RC2. "Интенсивное использование внутри компании и с помощью партнеров является определяющим, - отметил Томпсон, - и у нас сложился более ясный взгляд на то, что представляет собой этот продукт теперь. Сегодня мы не просто доставляем информацию в почтовый ящик, но еще и предоставляем широкий спектр дополнительных инструментов, продуктов, служб и документации". Томпсон объяснил, что группы, продолжающие работать над системами Outlook 11, Exchange Server 2003 (Titanium) и Windows Server 2003, теперь работают вместе еще более тесно для проверки всеобъемлющих сценариев, удовлетворяющих требованиям пользователей. В прошлом эти продукты разрабатывались более независимо.

Взгляд на сопровождение

"За многие годы сопровождение достигло нужной кондиции, - добавил Луковски. - Мы многое делаем для создания правильной пропорции пакетов обновлений service packs, оперативных исправлений, ветвей эволюции продукта, бета-тестирования и партнеров JDP".

"Мы реально увеличили время сопровождения продуктов, - сказал Томпсон. - Когда Microsoft поставляет серверный продукт, клиенты могут использовать его в течение десяти лет. Так называемая основная поддержка длится семь лет, но компания на протяжении длительного времени постоянно развивала метод доставки обновлений и исправлений ошибок. Прежде всего, Microsoft необходима уверенность, что исправления ошибок применимы ко всем соответствующим версиям системы".

"Наша работа по быстрому выявлению изъянов в системе безопасности подразумевает, что мы теперь активно выпускаем быстрые исправления (hot-fixes), когда можем это сделать, - заметил Томпсон. Кроме того, бывало, что пакеты обновлений были составными. Однако клиенты ясно давали понять, что им в пакетах обновлений нужны только исправления ошибок. Хотя это приводит к одному интересному вопросу: "Что на самом деле представляет собой ошибка? Это пропущенная функция?" Сами клиенты часто имеют разные мнения на этот счет. Но система Windows NT 4 SP3 была окончанием добавления новых свойств в пакетах обновлений.

Односторонний эффект основного сопровождения заключается в том, что компания Microsoft должна сохранять условия испытаний для каждой пермутации (измененной формы) своих операционных систем. Это означает, что последний, "золотой" выпуск Windows 2000 представляет собой одну ветвь, Windows 2000 SP1 - другую, Windows 2000 SP2 - третью и так далее. А так называемая "проверка на себе" - оказывается важна также и для производства пакетов обновлений. "В своей ИТ-системе мы аккуратно храним отдельную инфраструктуру Windows 2000, мы можем выполнять развертывание системы Windows 2000 и проводить испытания в производственных условиях, - подчеркнул Томпсон. - Это очень дорого, но овчинка стоит выделки".

Быстрые исправления рассматриваются как ограниченные версии, которые решают только одну специфическую проблему и не оказывают влияния на другие части системы. Томпсон сказал, что клиенты должны применять быстрые исправления только в том случае, если на них влияет проблема, которую это исправление ликвидирует. Однако исправления для системы безопасности все вместе представляют собой другую версию. "Мы надеемся, что все наши клиенты устанавливают исправления для системы безопасности (security fixes), - сказал он, - поэтому мы очень аккуратны с ними и выполняем усиленный тип тестирования. Исправления для системы безопасности представляют собой выпуски GDR (GDR - Generally Deployable Releases - обычно развертываемые выпуски), в точности как пакеты обновлений".

Корни, стволы и ветви

Как отмечалось ранее, различные версии Windows требуют последовательности точек ветвления кода в эволюции продукта. В этих точках каждый отдельный продукт Windows "ветвится", отходит со временем от главного эволюционного "корня". Поэтому каждый выпуск Windows собирается в последних и, как минимум, двух различных версиях; Windows Server 2003 и Longhorn, на момент написания этой статьи, разрабатываются одновременно. Поскольку Windows Server 2003 был взят от XP, серверный продукт в основном построен на XP. Longhorn, клиентский выпуск, который последует за XP через несколько лет, фактически выделен из основы кода серверной ветви, а не XP, как можно было ожидать.

"Механика этого процесса довольно сложна, - комментирует Луковски. - Вы имеете главную ветвь кода для текущей версии Windows, а эта ветвь становится исходной основой для оперативных исправлений и следующего пакета обновлений, который становится ветвью, и теперь мы имеем две ветви, которые необходимо тестировать для оперативных исправлений и пакетов обновлений. Мы не можем приказать клиентам установить, скажем, SP1 и затем развернуть это быстрое исправление. И это продолжается для каждой версии Windows, поэтому некоторые версии имеют два-три пакета обновлений, много оперативных исправлений и исправлений для системы безопасности. Любой из них представляет собой управляемый набор из 50 миллионов строк кода. Это весьма сложно для учета".

Кроме того, для каждой главной ветви активной разработки компания Microsoft также имеет приблизительно 16 ветвей группового уровня, чтобы обеспечить возможность достижения независимости/параллельности на уровне групп при разработке общей главной ветви. Каждая группа сохраняет полную среду сборочной лаборатории, которая собирает полный выпуск, в том числе последние изменения группы и проверенные ими изменения интегрируются в главную ветвь, так чтобы другие могли посмотреть результат их работы.

Сортируем ошибки в "военной комнате"

Во время последнего рывка к выпуску RTM сердце проекта - это "военная комната", War Room, где группа разбора, War Team, проводит совещания по два-три раза в день, пять-шесть дней в неделю. "Группа разбора просматривает сообщения и метрики, чтобы определить ежедневное состояние проекта, - сказал Томпсон. - Теперь все автоматизировано, но когда-то мы входили в комнату и бродили вокруг бумажных отчетов о том, что мы делали. В комнате бывало человек по 15-20. Теперь это выглядит совсем по-другому".

Что касается Windows Server 2003, то командой War Room руководил Тодд Ванк, как потом оказалось, весьма славный парень. Однако на четырехчасовых сессиях в War Room у Ванка была железная хватка, он продвигал процесс вперед неуклонно, мало уделяя внимания извинениям сотрудников группы по продукту, которые не показывались на совещаниях.

Вот как это происходит. Каждое утро в 9.30 представители различных групп по функциям Windows Server 2003 встречаются для сортировки ошибок. Они входят в комнату для совещаний. В центре помещения располагается большой стол, а участники обычно должны стоять. Помещение всегда переполнено. Как-то мы присутствовали на совещании группы разбора - первый раз, когда посторонние проникли в "святая святых" Windows Server, и только второй раз за время проектирования NT и Windows. Группа обсудила 50 ошибок, большая часть которых представляла собой всего лишь трудности с наименованием, хотя я согласился не обсуждать специфику ошибки, рассматривавшейся в тот день. Поскольку мы посетили War Room на завершающей стадии проектирования этого продукта, и самый большой известный вопрос в последнюю минуту был связан со сменой имени, имя Windows .NET Server 2003 заменили на Windows Server 2003.

Каждая ошибка регистрировалась в безграничной системе трекинга ошибки, каждая ошибка сопровождалась подробной информацией о том, как она была обнаружена, какими клиентами, было ли что-нибудь, на что она повлияла, и полная история предпринятых действий с указанием даты решения проблемы. Ванк быстро продвигался по ошибкам, обращаясь к членам отдельных функциональных групп для объяснения, как устранялись ошибки. Если в IIS (Internet Information Server) была одна или несколько ошибок, то представителю группы IIS приходилось не только объяснить свойства ошибки, но надо еще и пояснить, повлияла ли она на клиентов, как исправление могло бы повлиять на другие части системы, и как скоро оно будет выпущено. Задержки процесса разработки из-за ошибки часто приводили к ее переносу в следующий выпуск - Longhorn - если они не были достаточно важны.

Как-то, когда я присутствовал на совещании, четыре ошибки одной функциональной группы были перенесены в проект Longhorn, потому что они не явились в "военную комнату". Когда кто-то сказал, что им следует дать шанс в другой день, Ванк отрезал: "Если бы это было важно, они были бы здесь. Это пойдет в Longhorn. Следующая ошибка".

Однажды после окончания совещания, которое длилось час, мы беседовали с Ванком. В приватной обстановке он был совсем другим человеком. Биография Ванка включает работу в NCR, America Honda и некой компании, связанной с обеспечением безопасности, в качестве контрактора правительства США, и еще почти восемь лет его связаны с компанией Microsoft. До того, как он вошел в группу Windows, Ванк был одним из самобытных архитекторов сайта Microsoft.com, еще три-четыре года он провел в качестве Internet guy в компании, которая раньше других в Microsoft поддержала культ Internet. На нашей встрече Ванк объяснил, как он попал на свою новую работу, что сейчас делает в компании Microsoft и как работает группа разбора - War Team.

"Моя работа заключается в том, чтобы управлять повседневными операциями, связанными с поставкой Windows, - сказал он, - Я отвечаю за 8000-10000 разработчиков, менеджеров программ и тестировщиков, а еще я должен контролировать их ежедневную работу".

Группа разбора - War Team - состоит из очень широкого круга лиц внутри группы Windows, и все они отвечают за разные области проекта. Среди них есть руководители тестирования, ответственные за протоколы TCP-IP и другие низкоуровневые технологии, разработчики - специалисты, которые ежедневно занимаются сборкой, и специалисты, которые выполняют верификационные тесты этих сборок. "Представлена каждая область проекта, - пояснил Ванк. - Ежедневные приказы для группы Windows Server отправляет группа разбора - War Team, и еще я делаю большую рассылку электронной почты. Эти послания электронной почты почти всегда имеют гриф Microsoft confidential, или даже еще выше; послания электронной почты - очень секретные и рассылаются только ограниченной группе лиц".

Как можно было заметить, работа War Room представляет собой отлаженный процесс, который происходит ежедневно в одно и то же время и длится ровно один час. Члены группы просматривают одну и ту же систему отслеживания ошибок каждый день и зачастую подробно рассматривают одни и те же проблемы, пока те не будут исправлены. "Если вас там нет, это нехорошо, - заметил Ванк. - Сотрудники Microsoft имеют повышенное чувство ответственности в отношении этого продукта и они должны точно знать, что все идет правильно. А если кого-то нет, я разбираюсь с ними. Я - погонщик мулов".

Помимо утреннего совещания в War Room, группа Windows Server проводит совещания после обеда с двух до трех часов дня и, если потребуется, - еще одно с пяти до шести часов после полудня. Ежедневная сборка обычно начинается в 4:30, но может задержаться до шести, так что это последнее совещание дает группе шанс подробно рассмотреть любые последние исправления ошибок, которые будут добавлены к сборке в тот же день. "Эта структура очень важна; нам надо знать, на какой стадии находится сборка в каждый момент времени. Мы подробно рассматриваем качество сборки, различные уровни важности и все эти вещи, которые происходят с вечера и требуют продолжения. Мы получаем подробные отчеты и рассматриваем все, что пойдет в проект", - пояснил Ванк.

Дополнительно к главной группе разбора - War Team - каждая из функциональных групп имеет собственные помещения для анализа. Таким образом, ежедневно могло проводиться по 50 совещаний, с подробным анализом отдельных компонентов системы. Такие заседания проводятся каждый день в восемь часов утра. Когда исправление ошибки проходит обсуждение в локальной группе разбора, оно представляется на совещании Ванка. "Они не могут войти в "военную комнату", пока у них не готово исправление ошибки, - заявил Ванк. - Исправление ошибки должно быть готово". Поскольку нет какого-то одного лица, принимающего решения, здесь существует система проверок и балансов, через которые проходит каждое исправление ошибок, прежде чем оно вводится в сборку.

Сложность сборки Windows поражает. "Чтобы упростить объяснение, примем, что Windows состоит из 100 000 файлов, - сказал Ванк. - Обычно существует семь хранилищ исходного кода, причем каждый содержит точную копию всех исходных кодов, хотя в этой точке мы подсоединены лишь к одной. Любая группа проектирования имеет собственное хранилище, так что, когда разработчик пишет одно исправление, он может компилировать его в хранилище для тестирования. Если сборка компилируется с его исправлением, они контролируют это исправление и затем проверяют его в главном хранилище главной сборочной лаборатории".

Конечно, не всякая сборка бывает успешной. Время от времени с Windows Server случается то, что в Microsoft называют "build on the floor", когда исправление разрушает некоторую часть системы. "Это обидно, - посетовал Ванк. - Был момент около года назад, когда мы не выдавали сборку в течение семи дней. Мы послали по электронной почте руководителям групп разработки продукта в компании объяснение этой проблемы, и компания запустила свою частную версию Defcon-5. Все красные флаги пошли вверх. Это очень прочно укоренилось в сознании разработчиков - не разрушать сборку. Они вносят свое изменение, а затем проверяют его. Но они не могут спокойно уйти домой. Мы разослали вызовы в три часа ночи, когда сборку сломали, нашли разработчика, который сломал ее, привлекли его к работе сразу и немедленно исправили положение. Разработчики ожидают вызовов 24 часа в день. Это как чрезвычайное положение. Слом сборки считается критической проблемой".

C завершением цикла разработки Windows Server 2003 число ошибок резко уменьшилось, а процесс разбора становился с каждым днем проще. И тогда компания Microsoft анонсировала изменение имени. "Мы просто должны были смириться с этим решением, - признался Ванк. - Им следовало сделать это полгода назад. А на этой поздней стадии они пригласили Стива Балмера объяснить всем участникам группы разбора, почему было принято это изменение". Скорость, с которой группа могла обновить всю эту графику, тексты и записи реестра в системе, является оценкой динамичности процесса исправления ошибок. Проблема заключалась в том, что надо было внести несколько тысяч изменений, а это обычно означало несколько тысяч новых записей в системе отслеживания ошибок в продукте. "Я вызвал трех лучших разработчиков в группе и сказал: "Надо это сделать". Один разработчик изменил больше 7000 ссылок на Windows .NET Server", - сказал Ванк.

После трудов праведных

В тот день, 21 января 2003г., когда мы посетили совещание в комнате разбора - War Room, Windows Server 2003 достиг "абсолютного исторического минимума" по части ошибок, по словам Ванка. "На этой неделе мы останавливаем работы по проекту, - заявил он. - Все готово. Мы начинаем поставки". В тот день Windows Server 2003 имел немного активных ошибок, и как минимум четверть их была связана с простыми вопросами снабжения продукта торговой маркой. "Итак, там около 150 нерешенных вопросов для обсуждения, - сказал Ванк. - Причем мы исправили примерно сто. Все эти ошибки имеют степень сложности от 1 до 3. Нам осталось исправить несколько ошибок, степень сложности которых равна 1, и все они должны быть ликвидированы, чтобы мы могли начать поставки".

Ванк сказал, что серверная группа уже заделала все известные бреши в системе безопасности. "Мы очень довольны системой безопасности, - заявил он. - Меня лично впечатляет проделанная работа. Рывок от Trustworthy Computing за последний год был важным этапом для нас, и дальше все пойдет легче благодаря проделанной работе. Проще для разработчиков, потому что все они имеют теперь одинаковое отношение и одни и те же цели, а также одинаковую подготовку по лучшим методикам. В различных группах обычно были разные методы. Обеспечение безопасности дало толчок к их объединению. Теперь каждому легче взаимодействовать и видеть конечную цель".

По завершении проектирования Windows Server 2003 группа проектирования будет работать в переходном режиме. Во-первых, продукт войдет в состояние фиксации депонирования, и процесс сборки будет заморожен. Та сборка затем будет развернута по кампусу, включая корпоративную структуру Microsoft. "Это последняя сборка, - заметил Ванк. - Затем мы переждем какое-то время, в течение которого не будет сделано никаких основных обновлений продукта". Кроме того, зафиксированная сборка будет проверяться на тестерах и членами JDP.

В случае возникновения вопросов в течение фиксации сборки группа War Team принимает решения по вопросу обновления из-за ошибок. Если возникнет необходимость обновления ядра, то будет создана новая сборка, и фиксация возобновится. "Изменение компонента ядра может вызвать задержку выпуска последней версии, RTM, - пояснил Ванк. - Мы делаем паузу, прежде чем передать систему клиентам, и должны подождать несколько дней до решения о прекращении". Каждая функциональная группа, работающая в Windows Server 2003, должна работать с фиксированной сборкой 21 день без перезагрузки, прежде чем эта сборка может быть объявлена "золотой" и запущена в производство.

Но Ванка не напрягали с точным графиком, поскольку результат представляет собой итог весьма продолжительной работы. Его группа теперь готовит празднование RTM - на воздухе, на одном из многих футбольных полей кампуса, если погода позволит. У Ванка есть и другие вопросы по RTM, за которые он должен взяться, в том числе место проведения презентации. Он также ведет переговоры с OEM, ISV и маркетинговыми компаниями для изготовления значков, буклетов и так далее. "И я должен проследить за тем, чтобы 8000 тех, кто заслужил, получили свою награду", - добавил Ванк.

В конечном итоге, все это привело к обеспечению наиболее безопасной и надежной операционной системы, которую когда-либо создавала компания Microsoft, и трудно переоценить вклад Ванка в этот проект. "Я пропустил по существу одно-единственное совещание в "военной комнате" за полтора года, - заметил он, - мы встречались каждый день, а в конце разработки и шесть дней в неделю".

Я спросил Ванка, возглавил бы он группу разбора - War Team - для следующей версии Windows. "Ни за что, - ответил он мне, смеясь. - Ни за что!"

Поль Тюрро (thurrott@windowsitpro.com) - Редактор новостей в Windows IT Pro. Готовит еженедельные выпуски Windows IT Pro UPDATE (http://www.windowsitpro.com/email), а также ежедневные выпуски новостей WinInfo Daily UPDATE (http://www.wininformant.com/).