В связи с предстоящим в первом квартале 2008 г. запуском Windows Server 2008 я взял интервью у Алекса Хинрикса, руководителя проекта Windows Server 2008, чтобы узнать, какие изменения в продукте будут полезны пользователям. А в том, что они будут полезны, нет причин сомневаться: версия Server 2008 — уникальная в серии Windows Server. Она претерпела существенные изменения, поэтому поначалу, несомненно, будут возникать проблемы с совместимостью, хотя потом, в прекрасном будущем, преимущества станут очевидны и неоспоримы.

Алекс Хинрикс руководит командой, выпускающей продукт Windows Server, и возглавляет разработку всего семейства продуктов, сложность которых постоянно растет, а результаты работы влияют почти на всех клиентов Microsoft. Он устанавливает графики и сроки, определяет процессы и передает выше по иерархии решения, требующие рассмотрения на более высоком уровне. Хинрикс уже ветеран Microsoft, он работает в корпорации 12 лет. Сначала он был программным менеджером Windows NT, затем руководителем отдела, ответственного за все выпуски Small Business Server (SBS), начиная с SBS 4.0 по SBS 2003. По завершении продукта SBS 2003 Хинрикс перешел на разработку продукта Windows Server.

Определение серверных ролей

Фундаментальное изменение в эволюции Windows Server связано с переходом на ролевую архитектуру управления. В Microsoft работа над новыми возможностями началась с Windows 2000, но именно в версии Windows Server 2008 эта операционная система стала полностью компонентной, что позволило учитывать роли управления продуктом при разработке базовой архитектуры.

По словам Хинрикса, разработчики с самого начала имели четкую концепцию Windows Server 2008. Изучая запросы клиентов, они выяснили, что потребители думают не о версии продукта, а рассматривают серверы как отдельные устройства. В помещениях вычислительных и серверных центров клиенты показывали на разные системы и говорили: «Это контроллер домена, это файловый сервер, Web-сервер, это DHCP». Такое использование диктует реализацию серверного продукта в стиле армейского швейцарского ножа на все случаи жизни. Так родилась идея архитектуры Windows Server на основе задания ролей.

Данное представление с самого начала разработки способствовало лучшему проектированию. Роли определяют цели, а глубокое компонентное представление означает, что можно устанавливать по умолчанию минимально возможную функциональность и предоставлять администраторам только то, что им нужно. Даже инженерные группы в Microsoft, за некоторым исключением, организованы по ролям. Есть генеральные менеджеры и менеджеры по тому или иному продукту, их работа буквально состоит в том, чтобы управлять направлениями, например бизнес Terminal Services, бизнес Active Directory, IIS и т. д. Опять же такое компонентное представление помогает видеть весь продукт в целом и принимать правильные решения.

Управление изменениями сложного продукта

Если посмотреть на процесс в ретроспективе, то Server 2008 разрабатывался дольше по сравнению с прежней версией Windows Server. Управлять таким сложным продуктом в течение многих лет и не утонуть в деталях (что, надо признать, было характерно для группы Windows Vista) — уже достижение. Разработка Server 2008 шла непрерывно, уверенно, без разногласий и конфликтов — полная противоположность тем условиям, в которых разрабатывалась Vista.

Ясный список функций был сформулирован уже на старте проекта. Разработчики выделили из моря возможностей ту функциональность, которую хотели включить в 2005 г., и произвели окончательную сортировку в декабре 2006 г. Конечно, со временем одна-две возможности добавились, но список функций был зафиксирован и описан уже к концу 2006 г.

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

Построение продукта на базе ролей позволило Microsoft сохранять курс при разработке, что в противном случае было бы невозможно. «Можно указать нескольким тысячам разработчиков, что мы делаем вот именно это, и тогда они смогут сосредоточиться на задаче. Наша клиентская база довольно большая, от малого бизнеса до крупных предприятий. Но все же она не сравнится с базой пользователей клиентских систем (например, Vista), когда учитываются требования всех потенциальных пользователей вплоть до сотрудников предприятий», — сказал Хинрикс.

Переосмысление Windows 2003

На разработку Server 2008 также повлияли уроки, которые Microsoft извлекла из разработки прежних версий продукта. Хинрикс отметил: «Мы пытались переосмыслить положительные наработки Windows Server 2003 и использовать их в Windows Server 2008. Это позволило избежать ошибок, потому что клиенты говорят нам, что хорошо, а что плохо».

Самый важный урок — развертывать продукт заранее и у большего количества клиентов. Разработчики Microsoft знали — необходимо было добиться того, чтобы наиболее актуальные роли — Web-сервер, Active Directory (AD), Network Access Protection (NAP), Terminal Services Gateway — были надежными до окончательной поставки клиентам. Вот почему эти роли проходили внутреннее тестирование в Microsoft и внешнее тестирование у клиентов в рамках программы Technology Adoption Program (TAP), как минимум, в течение 18 месяцев. Как заметил Хинрикс, период тестирования был необычным. В некоторых случаях понадобилось более двух лет. Была развернута версия Beta 2 (в 2005 г.) внутри Microsoft и для внешнего испытания — у 50 клиентов, с которыми было налажено тесное сотрудничество. Они получали еженедельные запросы и дополнительное финансирование, к ним регулярно выезжали специалисты. Они запускали Active Directory (из Server 2008) два года назад, так же как и в Microsoft.

Обратная связь в рамках программы TAP привела к значительному повышению качества — Microsoft приняла к сведению замечания, связанные с надежностью и простотой использования. «В некоторых случаях администраторы сообщали, что часть графического интерфейса бессмысленна. В конце концов, роль Active Directory стала настолько устойчивой, что каждый понедельник мы обновляли наш домен разработчиков новой сборкой. Дела шли так хорошо, что оценить готовность мы смогли через 18 месяцев работы», — рассказывает Хинрикс.

В конце концов в Microsoft пришли к выводу, что процесс самого точного бета-тестирования не сможет выявить все ошибки, потому что они не будут обнаружены, пока продукт не увидит свет. «Нельзя предусмотреть все. Единственный способ обрести уверенность — выполнить широкое развертывание. Мы следовали этому принципу при разработке Windows 2000/2003 и будем ему верны и в версии 2008», — убежден Хинрикс.

Другой хороший пример дает Microsoft IIS. В Microsoft провели развертывание IIS внутри и у внешних заказчиков. Теперь сайт Microsoft.com работает на версии IIS Server 2008 уже несколько лет, кроме того, компания продвигает программу IIS Go Live для клиентов начиная с версии Beta 3. Цель простая — развертывать, развертывать и снова развертывать.

Непрерывный процесс сборок

Что касается внутренней стороны процесса, то в Microsoft реконструировали процесс создания сборок для Server 2008 таким образом, что сам процесс, как и собственно продукт, стал все больше складываться из частей. Главная сборка операционной системы создается ежедневно, как и для прежних версий продукта, но процесс реализации сделанных изменений внутри главной сборки стал намного более детальным, чем прежде.

В группе серверных ролей, например, видны подгруппы типа AD, Terminal Services, IIS и еще порядка 20 других подгрупп. Главный разработчик в подгруппе AD фиксирует код на уровне серверных ролей при получении кода сверху. После того как код переработан для широкого распространения, он передается на более высокий уровень и снова сливается с главным деревом проекта. Процесс продолжается, причем на каждом уровне нужны специалисты, которые следят за качеством и необходимостью добавлений в код.

«Код непрерывно изменяется вверху и внизу дерева, причем поддерживается высокое качество на обоих уровнях реализации постоянных проверок, — говорит Хинрикс. — Эти проверки выглядят как верификационные тесты сборки — BVT (Build Verification Tests), набор тестов для подсборок с целью проверки специальных моментов, дабы убедиться, что специалисты AD не нарушили целостность других программ, или уберечь другие группы от проверок. Все должно работать».

В Microsoft также используют инструменты проверки качества кода с целью обнаружения ошибок в системе безопасности, проверок на переполнение буферов и обнаружения других возможных проблем. Предусмотрены и проверки взаимозависимости кода — что-то около 40 вариантов зависимостей между компонентами. Для поддержки компонентного представления операционной системы следует убедиться, что приводящих к сбоям случайных зависимостей не возникает. «Все эти тесты предназначены для выявления уязвимых мест на как можно более глубоком уровне, так что они оказывают воздействие на самые небольшие группы разработчиков, — комментирует Хинрикс. — Эти инструменты запускаются с вечера, а утром мы получаем отчеты о состоянии. Мы можем наблюдать, как обстоят дела у различных групп».

Разработка Windows Server 2008 как многокомпонентного продукта привела к изменению и принципов процесса выпуска сборок по сравнению с Windows 2003. Теперь вместо одной главной точки выдачи кода есть семь отдельных, и в каждой из них выдается код для сотрудников, участвующих в разработке отдельного компонента. Во всех точках проводятся ежедневные собрания, как в главной группе по выпуску. Повестка дня у главной группы простая: кто из семи групп выпусков готов передать код на верхний уровень (в соответствии с деревом подготовки главной сборки)?

Главная группа выпуска по-прежнему используется для отлавливания ошибок, но многие ошибки ловятся ниже по дереву разработки, т. е. акценты несколько смещены.

Как работает группа

«Все предельно просто, — рассказывает Хинрикс. — Приходим сюда каждое утро и проверяем состояние основной сборки. Процесс построения идет всю ночь. Проверяем наличие аварийных прерываний каких-либо BVT (тестов верификации версии) или резидентных тестов из числа проводимых. Проверяем степень исправности очередного суточного варианта сборки». По словам Хинрикса, аварийные прерывания сборки происходят редко. В таких случаях сбойный код нижних уровней древовидной схемы может нарушить отношения зависимости или функции основной сборки, вызывая временную остановку сборки до обнаружения подозрительного кода. Во время разработки Windows Server 2003 это случалось много раз, а с Server 2008 — всего один или два раза.

«В фокусе суточной работы группы до осени 2006 г. была система Windows Vista, — отметил Хинрикс. — Работа над Server велась скорее 'за компанию'. Но когда система Vista была готова, практически сразу произошла 'смена караула', и я возглавил группу». Теперь в фокусе находятся Server 2008 и Vista SP1, разрабатываемые параллельно. «После Vista RTM, вышедшей в начале ноября 2006 г., мы переключились очень быстро, — добавил Хинрикс. — Это было похоже на два авианосца, обгоняющих друг друга. Код Vista RTM дал нам очень стабильную основу, поэтому с самого начала мы взяли хороший темп. С тех пор каждый день мы создаем стабильную основную сборку, поскольку большинство проблем нейтрализуются еще до возникновения».

Изоляция кода

Стараясь извлекать уроки из прошлого, группа Windows Server сделала еще один верный ход, основываясь на опыте работы с Windows 2003, а именно: код продукта был изолирован еще на раннем этапе разработки. «Мы зафиксировали список функций в конце 2006 г., — отметил Хинрикс, добавив, что тогда же была учреждена формальная процедура управления изменениями, которой должен был следовать каждый желающий сделать запрос на изменение. «У нас есть комиссия, членом которой являюсь и я, и все желающие внести функциональные изменения в продукт встречаются с нами. Мы взвешиваем последствия предлагаемых изменений», — сказал он.

Большая часть изменений отклоняется, поскольку группа Server с предубеждением относится к «богатству возможностей», которое, по мнению группы, создало проблемы для ранних версий Windows Server. Теперь разработчики не могут по своей прихоти регистрировать новый код. Microsoft использует «ворота качества» на верхних и нижних уровнях дерева кода для контроля всего, что приходит извне. «Мы много работали над сохранением списка функций, которому придали окончательную форму, и принимаем только те изменения, которые связаны с блокированием процесса развертывания либо подкреплены экономической аргументацией, настолько убедительной, что мы просто вынуждены это сделать», — подчеркнул Хинрикс.

Возникает очевидный вопрос: какие функции были добавлены после зафиксированного в конце 2006 г. состава продукта? По понятным причинам Хинрикс был не расположен обсуждать отвергнутые функции, но одно принятое изменение достойно упоминания: на довольно поздней стадии разработки Server 2008 группа решила, что просто обязана добавить Windows PowerShell в продукт, хотя многих пользователей привело бы в замешательство наличие двух сред разработки сценариев и командной строки, у одной из которых (PowerShell) не все возможности поддерживаются встроенными средствами управления.

«Это как раз отвергаемый нами тип изменений, — признал Хинрикс. — Не хочется беспорядочно добавлять новые инструменты администрирования в продукт на таком позднем этапе и нет возможности создания необходимых сценариев для PowerShell после выхода Beta 3. У нас уже были инструменты, работающие из командной строки, и мы заметно улучшили традиционную среду командной строки в Windows Server 2008, так что решение было компромиссным. Нам нравится PowerShell, и мы хотели его иметь «в коробке», но при этом нам казалось нецелесообразным отодвигать дату выпуска, просто чтобы добавить сценарии администрирования для PowerShell».

Кроме того, после выдачи варианта установки Server Core для Server 2008 клиенты Microsoft немедленно начали говорить о своем желании, чтобы были добавлены другие роли, среди которых в первую очередь упоминалась роль Web-сервера. Но, поскольку в этой версии Server Core не предусмотрена поддержка Microsoft .NET Framework, не было возможности создания для этой среды версии Web-сервера Microsoft IIS, которая поддерживала бы динамические возможности, например ASP.NET. Вместо этого группа Windows Server решила, что будет поддерживать роль Web-сервера в Server Core, но в первой редакции эта версия Server Core будет без поддержки .NET-ориентированных функций IIS. В результате на свет появился вариант «малозаметного» IIS, что обеспечивает сверхбезопасность. Клиенты были в восторге, поскольку получили именно то, что им было нужно в данном пространстве, а именно низкоуровневый вариант Web-сервера, способный составить эффективную конкуренцию решениям на базе Linux.

«Реакция на бета-версию была однозначной, — поделился Хинрикс. — Клиенты сказали: «Этот Server Core — сказочная штука, но вы пропустили самую важную роль». Вот мы и позаботились об этом».

Добавление IIS к Server Core было важным делом и стоило затраченных усилий, учитывая большое число развернутых систем пользователей, находящихся под влиянием IIS. Напротив, PowerShell — технология, поддержка которой сохраняет общую ориентацию в разработке Windows Server, с учетом того, что наличие полного комплекта сценариев администрирования не имеет решающего значения в первоначальной версии (сценарии могут быть добавлены впоследствии через Internet). Это желательно, но не обязательно. Заметим, что Microsoft непременно обеспечит для PowerShell поддержку полного набора сценариев администрирования через Web-библиотеку параллельно с выпуском Server 2008. Хинрикс отметил, что уже сложилось определенное сообщество пользователей PowerShell, и эта группа также, без сомнения, обеспечит пользователям полезные и функциональные сценарии для данной среды.

Работа с клиентами

Одной из наиболее примечательных особенностей, развившихся в ходе работы группы над Server 2008, является скрупулезный учет отзывов пользователей, интегрируемых в процесс разработки. «Старый метод обратной связи предполагал, что клиенты заносят в файл данные о дефектах, выявленных в бета-версии, после чего мы получаем нарекания и наносим визиты клиентам, — сообщил Хинрикс. — Конечно, такая практика продолжается. Но, помимо этого, мы теперь обрабатываем данные CEIP (программа совершенствования на основе опыта пользователей), которые представляют собой информацию, приходящую с серверов, установленных по всему миру. Эта информация, получаемая строго с разрешения пользователей, поступает в Microsoft, и мы можем ее анализировать».

Это большой объем данных. Microsoft получила данные CEIP с более чем 165 тыс. систем с установленной третьей бета-версией Windows Server 2008, вышедшей в конце апреля 2007 г. Компании известно не только число клиентов, установивших Beta 3, но даже какие именно роли были установлены. И я могу назвать эти данные: в процентном соотношении самые популярные роли Windows Server 2008 — Active Directory (AD), Web Server, File Server и Terminal Services.

Server 2008 также поддерживает взгляд на элементы, которые являются функциональными компонентами, не имеющими такого широкого описания, как роли. На данный момент самые популярные компоненты — PowerShell и, что удивительно, Desktop Experience — технология, обеспечивающая настольной системе Windows Server 2008 облик, более схожий с Vista. По словам Хинрикса, пользователи жаловались на этот компонент в Windows 2003, поэтому он был изъят из установки по умолчанию, и желающие могут установить его отдельно.

Члены группы Windows Server также знают, какие комбинации ролей устанавливаются на одном и том же сервере и какая используется архитектура (x86 или x64). «Мы знаем, что все пользователи покупают и будут покупать x64, — сказал Хинрикс. — Все развертываемые системы относятся к x64. На 32-разрядных системах (x86) проводится некоторое тестирование, но мы также знаем, что во многих случаях это осуществляется в средах виртуальных машин (имеющих тенденцию использовать только 32-разрядную архитектуру). Поэтому мы проводим тестирование и разработку на x64. Данные CEIP помогают нам сохранять правильную ориентацию процесса разработки и верные приоритеты».

Информация от клиентов помогла Microsoft определить набор функций для Windows Server 2008. «Фактически это положило начало Server Core, — заявил Хинрикс. — Клиенты говорили, что им не нужны все эти многочисленные службы и дополнительные компоненты. Им приходилось устанавливать QFE (оперативные исправления), не имеющие отношения к серверным ролям, которые они использовали. Это положило начало компонентной организации — разрыванию зависимостей и приходу к более компактному и сокращенному варианту операционной системы. Эта операционная система работает без излишеств и не нуждается в графическом интерфейсе, Internet Explorer или .NET Framework». Но при этом Microsoft рассматривает и возможность изменения комбинации поддерживаемых компонентов в Server Core в будущем по результатам обратной связи с клиентами.