«Windows стала заложником собственного успеха»: бывший вице-президент Microsoft о разработке Windows Vista

Перевод материала Бена Фатхи о том, что происходило внутри компании и почему систему Vista не приняли пользователи.

Перевод подготовлен школой английского языка Skyeng.

Мне понравился текст Терри Краули «Что на самом деле случилось с Vista», в котором он подробно разбирает причины провала Windows Vista и её предшественника — проекта Longhorn, который так и не был завершён. Но Терри работал в команде Office, поэтому видел случившееся только со стороны.

Терри точно подметил многие моменты, которые в итоге привели к провалу проекта, и я не хочу их здесь повторять. Я расскажу, как произошедшее выглядело изнутри команды. Вряд ли у меня получится изложить свои мысли так же ёмко, как у Терри, но я попытаюсь осветить основные проблемы проекта. С выпуска Vista прошло уже десять лет, но сейчас её уроки актуальны как никогда.

Команда Windows — огромный механизм: тысячи разработчиков, тестировщиков, менеджеров проекта, специалистов по безопасности, дизайнеров, архитекторов и много кого ещё. И это не считая отдела кадров, рекрутеров, отдела маркетинга, продажников, юристов и, конечно, руководителей, директоров и вице-президентов каждого из направлений.

И вся эта огромная команда взаимодействует с тысячами других команд — от разработчиков железа до создателей драйверов и приложений.

На момент разработки Vista команда Windows состояла из трёх групп, работавших в трёх направлениях: ядро, сервер и клиент. Группа, работавшая над ядром, создавала основные компоненты операционной системы: ядро, хранилище, систему безопасности, систему взаимодействий, драйверы для устройств, модель установки и обновления, Win32 и так далее. Эти компоненты были одинаковыми во всех версиях Windows.

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

Конечно, структура команды неоднократно менялась, но эти три основные группы оставались неизменными даже по мере роста компании. Также стоит отметить, что команда ядра всегда гораздо теснее сотрудничала с командой сервера, чем с командой клиента. По крайней мере так было до выхода Vista.

Я пришёл в Microsoft в начале 1998 года. К тому времени разработку Windows 95 остановили, и команда Windows занималась исключительно Windows NT для всех платформ, от ноутбуков до серверов. Два года спустя код Windows 95/98 подняли из мёртвых и выпустили последний раз в виде Windows ME — этот релиз не понравился никому. Но им занималась небольшая команда, а основные силы были брошены на разработку Windows NT.

Мне повезло находиться в самом центре событий на протяжении более десяти лет. Я пришёл в Microsoft на самом активном этапе разработки Windows 2000 и ушёл только после выпуска Windows 7.

Первые семь лет я управлял командами, которые отвечали за хранение данных, файловые системы, высокий уровень доступности и кластеризацию, сетевые протоколы на уровне файлов, распределённые файловые системы и связанные с ними решения. Эти этапы совпали с выпуском Windows 2000, XP, Server 2003 и Longhorn.

После этого пару лет (приблизительно с момента перезапуска Longhorn до выпуска Vista) я руководил направлением безопасности. Я занимался всем, от обеспечения безопасности в Windows и антивируса до маркетингового продвижения наших решений и устранения уязвимостей.

Когда разработка Vista подходила к концу, Windows оказалась очень неустойчивой к вирусам и ошибкам, что серьёзно подорвало нашу репутацию. Нам приходилось заново доказывать, что наше ПО безопасно.

После выхода Vista и в течение всей работы над Windows 7 я занимался ядром, то есть я был в курсе внутренней структуры всех технологических решений, которые также использовали группы клиента и серверы.

После выпуска Vista команду реорганизовали: теперь каждая группа занималась определённым направлением, и у каждого направления было три руководителя (ведущий разработчик, тестировщик и менеджер проекта). Так у меня появилось два сообщника. Я руководил работой всех команд разработки, а они руководили тестировщиками и менеджерами проекта.

В истории Windows было немало случаев, когда команда бралась за большой и амбициозный проект, который через несколько лет приходилось закрывать или переориентировать. Можно вспомнить хотя бы незавершённый Cairo (проект операционной системы, который Microsoft разрабатывала с 1991 по 1996 год, — vc.ru). Его разобрали на части и частично выпустили в составе Windows 2000.

Разработка ядра в некоторых проектах длилась больше шести месяцев, поэтому приходилось работать над ними параллельно и мёрджить, когда была готова основная часть кода. Огромные куски кода постоянно заменялись и видоизменялись, из-за чего проект всегда был в полуразобранном состоянии.

В ходе работы над Windows 7 мы попытались поддерживать проект в более работоспособном состоянии и ужесточили дисциплину, но ранние проекты постоянно разваливались на части.

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

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

Но был и второй вариант, ещё хуже: если у разработчиков или руководства не хватало духа закрыть проект, разработку продолжали, хотя она никому уже была не нужна. В конечном итоге проект всё равно приходилось закрывать, потому что он не имел смысла. Я сам руководил парой таких проектов. Но легко судить, когда уже знаешь итог.

Каждая команда старалась протолкнуть в релиз собственную фичу и зачастую не особо заботилась об интеграции с другими компонентами и пользовательским интерфейсом. Также никому не хотелось заниматься сквозным тестированием и прочими скучными вещами вроде обновлений — работу над ними постоянно откладывали.

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

Мы всегда работали над несколькими крупными проектами параллельно, не считая множества второстепенных задач. У каких-то команд код оказывался более исправным, чем у других, и в итоге «богатые богатели, а бедные беднели»: те команды, которые в какой-то момент отстали от общего темпа, уже не могли сократить разрыв.

На конечных этапах разработки менеджеры проекта начинали внедрять требования уже к следующему релизу, и «богатые» команды (с исправно работающим кодом) начинали их выполнять. Но остальные (а их было большинство) продолжали работу над текущим релизом. В основном это относилось тестировщикам, которые продолжали работать над релизом вплоть до его выпуска.

Это приводило к тому, что новый код тестировался не сразу, а «бедным» командам (с наименее исправным кодом) приходилось постоянно вносить правки, вместо того чтобы продолжать работу. В таких командах чаще всего отсутствовал командный дух и разработчики постоянно сменялись, а новичкам приходилось работать с плохим кодом, логику которого они не понимали.

В ходе разработки Vista и Longhorn я руководил командами, которые разрабатывали файловые системы и решения для хранения данных. Поэтому я оказался вовлечён в разработку WinFS, хотя этим в основном занималась команда, разрабатывающая базу данных SQL.

Сам Билл Гейтс активно участвовал в процессе — его даже в шутку называли «менеджером проекта WinFS». Тогда сотни и тысячи человеко-часов оказались потрачены на разработку технологии, время которой уже прошло: мы хотели объединить возможности базы данных и файловой системы и использовать их для создания уникальных многофункциональных приложений.

Сейчас понятно, что удачное решение этой задачи предложила Google, разработав решение для быстрой и беспрепятственной индексации неструктурированных данных. И их технология работает во всём интернете, а не только на локальном диске. И она даже не требует вносить изменения в программы. Если бы WinFS выпустили, разработчики приложений всё равно смогли бы переписать свой код и использовать все её возможности только через несколько лет.

Изначально предполагалось, что WinFS станет одним из основных нововведений в Windows Vista (в те времена, когда она ещё называлась Longhorn). Но когда проект Longhorn закрыли и на его базе спешно стали собирать Vista, от идеи выпускать WinFS в рамках новой ОС отказались.

Проект передали команде SQL, и несколько лет над ним продолжали работать. За это время Windows обзавелась встроенным поисковым движком, который не требовал внесения каких-либо изменений в ПО. Но разработка WinFS продолжалась, хотя цель становилась всё менее ясной.

Windows Vista унаследовала от Longhorn все нововведения в плане безопасности. В то время стремительного развития интернета мы постоянно узнавали что-то новое о безопасности и хотели использовать эти знания, чтобы сделать ОС максимально безопасной для всех пользователей.

У нас не было выбора. После Windows XP мы стали заложниками собственного успеха. Мы создали систему, которую обожали пользователи, но которая оказалась беззащитна перед угрозами интернета. Чтобы закрыть уязвимости в Windows XP, запустили проект Windows XP Service Pack 2. Несмотря на непримечательное название, проект требовал колоссальных затрат и отнимал ресурсы у разработки Longhorn.

Хочу пояснить, что ядро Windows NT всегда позволяло создавать несколько пользователей и назначать им права. Однако эту возможность зачастую игнорировали, чтобы обеспечить совместимость с Windows 95. Получалось, что любой пользователь по умолчанию получал права администратора.

Разработчики ПО часто этим пользовались, и в итоге программы постоянно перезаписывали общие файлы и изменяли настройки. Эту уязвимость эксплуатировало и вредоносное ПО: вирус мог без труда проникнуть в систему, потому что у пользователя были права администратора.

Чёткое разделение прав пользователя и администратора привело к нарушению работы практически каждой программы для Windows. Решить эту проблему должна была функция UAC (контроль учётных записей): при выполнении команды или скрипта система спрашивала пользователя, действительно ли он хочет дать процессу более высокий уровень привилегий.

При первом входе в систему повышать уровень привилегий приходись практически для каждой программы — неудивительно, что пользователи возненавидели функцию UAC.

Без преувеличения можно сказать, что 99% программ для Windows невозможно было даже установить, если у пользователя не было прав администратора. Мы столько лет поддерживали совместимость с Windows 95, что оказались в ловушке — теперь повышение безопасности системы неизбежно приводило к нарушению совместимости.

С точки зрения безопасности Vista превосходила любую другую ОС от Microsoft. Но она не поддерживала «заведомо небезопасные API» или обходила их при помощи контроля учётных записей, что приводило к практически нулевой совместимости с программами и драйверами.

Пользователи ненавидели Vista, потому что программы не работали нормально; разработчики программ и железа ненавидели Vista, потому что у них не было времени обновить своё ПО и драйверы — мы хотели выпустить Vista как можно скорее, чтобы обойти Apple.

Чтобы мы смогли закрыть уязвимости в безопасности, многим сторонним разработчикам пришлось серьёзно менять архитектуру своего ПО — а большинство из них не хотели тратить ресурсы на поддержание уже вышедших приложений.

Некоторые решили пойти по нестандартному пути: изменить структуру данных и даже команды ядра так, чтобы задействовать обходные API и параллельные процессы. Зачастую это приводило к хаосу в системе: в какой-то момент 70% всех отказов системы («синих экранов») были вызваны именно тем, что разработчики не хотели использовать официальные API.

Когда я возглавлял отдел безопасности Microsoft, мне приходилось лично объяснять производителям антивирусов, почему мы больше не можем позволить им изменять команды ядра и структуру данных в памяти, почему это делает систему уязвимой и почему им впредь нужно пользоваться официальными API. Я объяснял, что мы больше не будем поддерживать программы, которые вносят изменения в ядро Windows — потому что то же самое делают и вирусы.

В ответ же наши «друзья» — производители антивирусов — угрожали нас засудить за то, что мы монополизировали рынок и теперь злоупотребляем своей властью. С такими друзьями и врагов не надо. Они хотели, чтобы их старые приложения работали на новой ОС, даже если это представляло угрозу для пользователей — а ведь именно за безопасность пользователей они должны были бороться.

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

Все эти факторы не были на руку Windows. Мы делали то, что делают все разработчики успешных продуктов: зарыли голову в песок и продолжали улучшать существующую систему. Мы добавляли новый код, усложняли систему, наша команда и экосистема росли — и в результате нам становилось всё сложнее обойти конкурентов.

Но нам мешала не только конкуренция. В те времена разработчики и менеджеры проекта в соответствии с антимонопольным законодательством тратили часы, дни, недели и годы на документирование API, использованных в предыдущих релизах.

Разработка очередной версии Windows тогда занимала примерно три года. Правда в том, что для стремительно меняющегося рынка это слишком долгий срок. В ходе разработки Longhorn мы работали над WinFS, решением проблем безопасности и внедрением управляемого кода. И это только самые крупные проекты, а ещё были сотни мелких.

Когда у вас тысячи сотрудников и миллиарды пользователей, приходится учитывать мнение каждого. Ваша ОС должна работать и на планшете, и на смартфоне, на сервере центра обработки данных и на встроенных устройствах, например серверах NAS, не говоря уже о гипервизорах (HyperV), работающих в облаке. Мы старались развиваться во всех направлениях, но зачастую их требования оказывались противоречивыми.

Понять причины провала Longhorn и Vista можно только в контексте предшествующих и последующих релизов: Windows 2000 и XP, Windows Server 2008 и Windows 7, а также состояния компьютерной индустрии в то время.

Windows стала заложником собственного успеха. Мы настолько глубоко проникли на многие рынки, что теперь неизбежно должны были учитывать их потребности при разработке новых версий. Часто эти требования оказывались противоречивыми. Если мы старались угодить всем пользователям, полностью угодить не удавалось никому.

В 1990-х годах наша архитектура имела такой успех, что мы слишком привязались к ней и перестали успевать за происходящими вокруг изменениями. Мы видели, что происходит, и старались не отставать, но довольно сложно развернуть проект на полном ходу, особенного когда прошло уже два года из трёхгодичного цикла разработки.

Суть нашей проблемы можно выразить так: на момент выхода ОС все наши идеи, с которыми мы начинали разработку три или четыре года назад, оказывались неактуальными или попросту ошибочными.

Нам нужно было просто обеспечить постепенное и беспрепятственное внедрение облачных технологий на мобильных устройствах, которые становились всё проще. Но вместо этого мы продолжали добавлять новые функции к существующей системе.

Для каждой их таких функций требовалось многомесячное тестирование — мы буксовали именно в тот момент, когда нужно было ускориться. И конечно, у нас не поднималась рука избавиться от старых функций, которые обеспечивали совместимость с более ранними версиями Windows.

А теперь представьте, что вы больше десяти лет разрабатываете ОС, которой пользуются миллиарды людей и миллионы компаний по всему миру в сотне разных сценариев и на десятках видов устройств. Уже чувствуете, насколько сложно поддерживать такую систему и обеспечивать её совместимость?

Сейчас понятно, что Linux гораздо лучше справился с этой задачей. Конечно, благодаря поддержке со стороны опенсорс-сообщества и открытому коду. Модульная система — отличное решение. Закон Конвея гласит: организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации. Windows в этом плане не была исключением. У открытого кода нет подобной проблемы.

Добавьте к этому внутреннюю конъюнктуру и личные интересы. У каждого из нас были любимые функции, партнёры убеждали нас ввести новые стандарты, помочь с сертификацией ПО, добавить несколько API специально для их программ. Мы все хотели доказать, что наши решения, наши идеи станут прорывом. Нужно только добавить в новый релиз, и у нас сразу появятся миллионы новых пользователей.

Мы верили в эти идеи и отстаивали их на планёрках и ежедневных совещаниях. И как и в любой компании, у нас были менеджеры, которые хотели получить повышение и расширить свою сферу влияния или хотя бы увеличить свою команду.

Команды разработки и тестирования зачастую борются между собой: одни стараются протолкнуть свой код, другие — найти в нём любые ошибки, пусть даже пользователь никогда с ними не столкнётся. Из-за этого обстановка в компании была, мягко говоря, напряжённая. И кроме того, раз в год в компании проводилась реорганизация, процессы приходилось выстраивать заново.

Я рассказываю об этом не для того, чтобы оправдаться.

Ошибались ли мы? Да, постоянно.

Совершали ли мы эти ошибки намеренно? Нет, я такого не припомню.

Работали ли мы над невероятно масштабным продуктом с огромной экосистемой (самой большой в мире на тот момент)? Да, всё так и было.

Сделали бы сейчас всё по-другому? Конечно. Легко судить, когда знаешь результат. Тогда у нас не было опыта, который есть сейчас.

Стоит ли корить себя за эти ошибки? Нет, я предпочитаю рассматривать их как уроки. Я уверен, что ни один из нас не допустил подобных ошибок в последующих проектах. Мы стали опытнее — а значит в следующий раз мы совершим совсем другие ошибки. Человеку свойственно ошибаться.

#microsoft #windows #vista