Хабрахабр

[Перевод] Что действительно случилось с Vista: инсайдерская ретроспектива


Традиционно группа разработчиков Windows подписывает постер (в данном случае изображение DVD) с выпуском новой версии Windows. Ко времени окончания вечеринки по поводу релиза на нём будут сотни или тысячи подписей

«Опыт — это то, что ты получаешь только после того, как он тебе понадобится» — Стивен Райт

Мне понравился содержательный блог Терри Кроули («Что действительно случилось с Vista»). Терри работал в группе Office и проделал фантастическую работу, описывая сложные козни вокруг Windows Vista и связаного, но заброшенного проекта Longhorn — с точки зрения внешнего наблюдателя.

Он верно подметил многие из проблем, которые преследовали проект, и я не хочу повторять о них снова. Я только подумал, что будет честно изложить инсайдерский взгляд на те же события. Не рассчитываю на такое же красноречивое или исчерпывающее изложение, как у Терри, но надеюсь пролить некоторый свет на то, что пошло не так. Прошло десять лет с момента выхода первой версии Windows Vista, но эти уроки сейчас кажутся актуальными как никогда.
Windows — это монстр. Тысячи разработчиков, тестеров, менеджеров программ, специалистов по безопасности, дизайнеров UI, архитекторов и т.д. И это не считая обслуживающего персонала из отдела кадров, рекрутеров, ребят из маркетинга, продажников, юристов и, конечно, множества менеджеров, директоров и вице-президентов по каждому из перечисленных направлений. Вся эта группа окружена многими тысячами сотрудников у наших партнёров (как внутри, так и за пределами Microsoft), которые поставляли всё: от оборудования и драйверов устройств до приложений, работающих на платформе.

Аэросъёмка группы разработки Windows на футбольном поле в Microsoft

В то время организационно Windows на самом деле делилась на три группы: Core, Server и Client. Группа Core поставляла «каркас»: все ключевые компоненты операционной системы, общие для всех версий Windows (само ядро, система хранения, безопасность, сетевая подсистема, драйверы устройств, модель установки и обновлений, Win32 и проч.). В свою очередь, серверная группа сосредоточивалась на технологиях для серверного рынка (службы терминалов, кластеризация и бесперебойная работа, инструменты корпоративного управления и др.), а клиентская группа отвечала за технологии, связанные с десктопной и пользовательской версией (веб-браузер, медиаплеер, графика, оболочка и др.).

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

Ко времени моего прихода в Microsoft в начале 1998 года Windows означало Windows NT — архитектурно, организационно и в отношении самого продукта. От кодовой базы Windows 95 по большей степени отказались, а Windows NT внедрили для каждой разновидности Windows — от ноутбуков до серверов в кластере. Спустя два года кодовую базу Windows 95/98 должны были воскресить для одного последнего релиза — той самой Windows ME, о которой так много злословили — но этот проект вела маленькая группа, в то время как абсолютное большинство работало на кодовой базе NT. Мне повезло провести более десяти лет в чреве монстра. Я начал в разгар разработки Windows 2000 и оставался до завершения Windows 7.

Первые семь лет я провёл в группах, ответственных за систему хранения, файловые системы, бесперебойную работу/кластеризацию, сетевые протоколы файлового уровня, распределённые файловые системы и связанные технологии. Позже я провёл год или два в группе управления безопасностью Microsoft. Она включала в себя всё от технологий безопасности в Windows до антивирусных продуктов, маркетинг безопасности и экстренное реагирование, такое как выпуск обновлений безопасности. Это было ближе к концу жизненного цикла Vista, когда вирусы и черви поставили Windows на колени и когда репутация Microsoft как разработчика защищённого и безопасного программного обеспечения подверглась массовому избиению на публике.

Последние три или четыре года, во время подготовки выпуска Windows 7, я управлял всей разработкой группы Core в Windows. Это означает владение практически всеми технологиями, которые работают «под капотом» и используются и серверной, и клиентской группой. После выпуска Vista всю команду Windows организовали по направлениям и по триадам (Dev, Test, PM) на всех уровнях организации, так что у меня было двое соучастников по преступлению. Я руководил группами разработки, в то время как они руководили, соответственно, группами тестирования и группами менеджмента.

Команда Windows в прошлом нередко пыталась осилить амбициозные и массивные проекты, которые спустя несколько лет забрасывали или перепрофилировали. Предыдущий пример — амбициозный проект Cairo, который в итоге распотрошили: спаслись лишь некоторые его части, включённые в состав Windows 2000.

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

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

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

Трёхлетний цикл релиза означал, что мы редко представляли себе, как будет выглядеть конкурентный ландшафт и внешняя экосистема на момент релиза. Если разработка функции не успевала к релизу, то от неё совсем отказывались (поскольку она вряд ли имела смысл через 6 лет после начала разработки) или, что хуже, её «отсылали в Сибирь», то есть продолжали разработку компонента, который по большей части игнорировала вся остальная организация и который был обречён на неудачу или бесполезность — но группа или руководство просто не могли принять решение об отказе от разработки. Я лично нёс ответственность за несколько таких проектов. Зрение при взгляде в прошлое становится стопроцентным.

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

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

Когда проект приближался к завершению, программные менеджеры начинали составлять требования к следующему релизу, а группы в «здоровом» состоянии (богатые) начинали внедрять новый код, тогда как бóльшая часть организации (бедные) по-прежнему копалась с текущим релизом. В частности, группы тестирования редко освобождались до выпуска релиза, так что в начале проектов новый код не был тщательно протестирован. «Нездоровые» группы всегда отставали, делая последние штрихи для текущего релиза и отставая всё дальше и дальше. Именно в этих группах зачастую трудились разработчики с самым низким уровнем морального состояния и наиболее истощённые. Это значит, что новые сотрудники групп [взамен ушедших истощённых — прим.пер.] наследовали хрупкий код, который они не писали и поэтому не понимали.

На протяжении почти всего срока разработки Vista/Longhorn я нёс ответственность за систему хранения и файловые системы. Это значит, что я был вовлечён в проект WinFS, хотя его вели преимущественно сотрудники группы SQL СУБД, родственной структуры для команды Windows.

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

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

Когда Longhorn отменили, а из её тлеющих углей поспешно собрали Vista, систему WinFS уже выкинули из релиза ОС. Группа SQL ещё несколько лет продолжала работу над ней как над отдельным проектом. К этому времени в Windows появился встроенный движок индексации и интегрированный поиск — реализованный чисто на стороне без необходимости изменения в приложениях. Так что необходимость в WinFS стала ещё более неясной, но проект по-прежнему продолжался.

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

У нас не было выбора. Windows XP показала, что мы стали жертвами собственного успеха. Спроектированная для удобства система явно не соответствовала требованиям безопасности, столкнувшись с реальностью интернет-эпохи. Для решения этих проблем безопасности требовалось создание параллельного проекта. Windows XP Service Pack 2 (несмотря на своё название) стал огромной затеей, которая высосала тысячи ресурсов из Longhorn.

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

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

Я как руководитель отдела безопасности в Microsoft лично потратил несколько лет, объясняя производителям антивирусов, почему мы больше не разрешим им «патчить» инструкции ядра и структуры данных в памяти, почему это представляет риск для безопасности и почему им в дальнейшем следует использовать штатные API, что мы больше не будем поддерживать их легаси-программы с глубокими хуками в ядро Windows — теми самыми методами, которые применяют хакеры для атаки пользовательских систем. Наши «друзья», производители антивирусов, развернулись и подали на нас в суд, обвинив нас в том, что мы лишаем их средств к существованию и злоупотребляем своим монопольным положением! С такими друзьями кому нужны враги? Они просто хотели, чтобы их старые решения продолжали работать и дальше, даже если это означает снижение безопасности наших общих пользователей — а ведь именно эту безопасность они должны были улучшать.

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

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

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

Суровая реальность в том, что на тот момент жизненного цикла понадобилось примерно три года, чтобы выпустить основной релиз Windows и это было слишком долго для быстро меняющегося рынка. WinFS, безопасность и управляемый код — вот лишь некоторые из массивных проектов, которые стояли на повестке Longhorn. А были сотни более мелких ставок.

Когда у вас организация из многих тысяч сотрудников и буквально миллиарды пользователей, то нужно предусмотреть абсолютно всё. Тот же релиз ОС, который предполагалось запустить на планшетах и смартфонах, также должен был работать на вашем ноутбуке, на серверах в дата-центре и во встроенных устройствах типа сетевых хранилищ, коробочек “Powered by Windows” — не говоря уже о работе поверх гипервизора (HyperV) в облаке. Эти требования тянули команду в противоположные стороны, поскольку мы пытались добиться прогресса на всех сегментах рынка одновременно.

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

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

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

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

Теперь представьте поддержку одной и той же ОС на протяжении десяти лет или больше для миллиардов пользователей, миллионов компаний, тысяч партнёров, сотен вариантов использования и десятков форм-факторов — и вы начнёте вступать в кошмар поддержки и обновления.

Глядя в прошлое, Linux оказался более успешным в этом отношении. Несомненной частью решения стало сообщество open source и такой подход к разработке. Модульная и подключаемая архитектура Unix/Linux — тоже значительное архитектурное улучшение в этом отношении.

Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.

«Военная комната» Windows, позже переименованная в «корабельную» (ship room)

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

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

Кстати, ничего из этого не должно быть принято как извинения или оправдания. Речь не об этом.

Сделали ли мы ошибки? Да, в избытке.

Принимали ли мы специально неверные решения? Нет, я не могу вспомнить ни одного.

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

Могли мы справиться лучше? Да, ещё как.

Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.

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

Теги
Показать больше

Похожие статьи

Кнопка «Наверх»
Закрыть