Глючные обновления указывают на более глубокую проблему
Windows 10 на презентации в Токио, июль 2015 года
Очевидно, обновление Windows от 10 октября 2018 года было не самым удачным. Быстро появились сообщения о потере файлов на компьютерах, а Microsoft приостановила распространение обновления. С тех пор баг исправили, сейчас идёт тестирование нового апдейта перед его повторным выпуском.
Это не первое обновление Windows, в котором возникли проблемы — в предыдущих апдейтах мы видели такие вещи, как значительные аппаратные несовместимости — но оно явно стало худшим. Большинство из нас знает о резервном копировании, но в реальности многие данные, особенно на домашних компьютерах, не имеют бэкапа, и их исчезновение весьма неприятно.
Windows как сервис
В Windows 10 планировалось радикально изменить процесс разработки. Microsoft хотела лучше реагировать на потребности клиентов и рынка — и чаще выпускать новые функции. Windows 10 представлялась как «последняя» версия Windows. Мол, все новые разработки станут апдейтами Windows 10, поставляемыми через систему обновления несколько раз в год. Эта новая модель разработки получила название «Windows как сервис». И после некоторого первоначального беспорядка Microsoft остановилась на двух обновлениях функционала в год: в апреле и в октябре.
Эти усилия увенчались успехом. Microsoft выпускает полезные новые функции по новой модели, не заставляя пользователей ждать три года для обновления основной версии. Например, вышла удобная функция для незаметного запуска Edge в виртуальной машине, обеспечивающая большую защиту от вредоносных веб-сайтов. Подсистема Windows для Linux (WSL), которая позволяет нативно запускать Linux-программы в системе Windows, стала подспорьем для разработчиков и администраторов. Преимущества для обычных пользователей чуть сложнее заметить, но можно упомянуть функции VR, совместимые с SteamVR, улучшенную производительность игр и тёмную тему оформления. Хотя улучшения не такие значительные, но в целом нынешняя Windows 10 безусловно лучше, чем та, что вышла три года назад.
В те дни, когда Windows обновлялась только каждые три года, трудно было представить, что WSL когда-нибудь станет полезным инструментом
Всё это хорошо, а некоторые вещи вряд ли могли быть сделаны (по крайней мере, так же успешно) без введения модели «Windows как сервис». Разработка WSL, например, была основана на отзывах пользователей. Пользователи рассказывали о найденных несовместимостях и помогали расставлять приоритеты в разработке новых функций. Я не думаю, что WSL получила бы такой толчок к развитию без устойчивого прогресса обновлений каждые шесть месяцев — никто не захотел бы ждать три года, чтобы увидеть незначительное исправление. Например, чтобы важный для них пакет начал правильно работать. Регулярные обновления вознаграждают людей за сообщения об ошибках, потому что все действительно видят, что ошибки своевременно устраняются.
Проблема модели «Windows как сервис» — качество. Предыдущие проблемы с этой моделью и обновлениями безопасности уже подорвали доверие к политике обновлений Windows 10. Среди опытных пользователей распространилось мнение, что в Windows 10 снизилось качество ежемесячных обновлений безопасности, а установка полугодовых обновлений функций, как только они выходят, — безумие. Эти жалобы тоже имеют давнюю историю. Ненадёжные обновления стали причиной для беспокойства вскоре после выхода Windows 10.
Последняя проблема с удалением файлов заставила специалистов рассуждать, что двух обновлений функций в год может быть слишком много. Редмонд должен сократить их количество до одного, а Microsoft следует приостановить разработку новых функций и просто исправить ошибки. Некоторые беспокоятся, что компания находится в опасной близости к серьёзной потере доверия к обновлениям, а у некоторых пользователей Windows это доверие уже потеряно.
Это не первые призывы к Microsoft притормозить обновления функций — были опасения, что всё это трудно переварить и IT-отделам, и обычным пользователя, но с очевидными проблемами последнего апдейта эти призывы приобретают становятся особенно актуальны.
Дело не в частоте, а в том, КАК готовятся апдейты
Но те, кто настаивают на одном обновлении в год вместо двух, упускают главное. Проблема не в частоте выхода. Проблема в процессе разработки Microsoft.
Почему проблема не в сроках? Можем посмотреть на графики обновления других ОС.
С одной стороны, macOS, iOS и Android обновляются реже, так что может появиться впечатление, что Microsoft слишком усердствует. С другой стороны, есть прецеденты успешных обновлений с такой частотой: для Ubuntu выходит два релиза в год, а ChromeOS от Google, как и его браузер Chrome, получает обновления каждые шесть недель. Если выйти за рамки ОС, то в программе Microsoft Office Insider работает ежемесячный канал, где новые функции для пользователей Office выходят каждый месяц — и разработчики справляются с работой, не вызывая слишком много жалоб и при этом обеспечивая устойчивый поток новых функций и исправлений. Команда Visual Studio тоже часто выпускает обновления для своей среды разработки и интерактивных служб. Очевидно, что в Microsoft есть команды, которые хорошо адаптировались к реальности, где их приложения обновляются регулярно.
Выйдем за рамки локального софта и посмотрим на сетевые и облачные сервисы. Там и Microsoft, и другие компании всё чаще внедряют непрерывную доставку. Каждое обновление в системе автоматически развёртывается на рабочих серверах после прохождения достаточного количества автоматических тестов.
Конечно, ни один из этих проектов не сравнится по сложности с Windows. Может, в Ubuntu более разнообразный массив пакетов, но в любом случае многие из них разрабатываются независимо. Факт остаётся фактом: масштаб Windows необычайно велик — и компоненты беспрецедентно интегрированы в единую кодовую базу. Местами код Windows исключительно старый.
Безусловно, эти факторы усложняют разработку Windows, но неужели нельзя осилить два обновления в год? Дело вообще не в этом. Просто нужен правильный процесс разработки.
Windows 10 примерно в момент выпуска в 2015 году (Где все мои значки и меню «Пуск»?)
Процесс, уходящий корнями в историю
Microsoft не раскрывает конкретные детали процесса разработки Windows 10, но есть наблюдаемые характеристики этого процесса (как новые функции отправляются инсайдерам, типы ошибок в инсайдерских билдах) и есть некоторая информация изнутри компании. Все эти косвенные факты свидетельствуют об ущербности процесса разработки. Он сохранил некоторые общие черты с процессом разработки, который компания использовала ещё во времена трёхлетних релизов Windows. Сроки сократились, но основной подход не изменился.
В былые времена, когда между большими релизами проходило от двух до трёх лет, Microsoft пришла к процессу, разделённому на несколько этапов:
- проектирование и планирование;
- разработка компонентов;
- интеграция;
- стабилизация.
Примерно 4−6 месяцев планирования и проектирования, 6−8 недель интенсивного кодирования, а затем 4 месяца интеграции (каждая функция обычно разрабатывается в собственной ветке, поэтому их все нужно собрать и объединить вместе) и стабилизации (тестирование и исправление ошибок). В течение разработки продукта этот цикл повторяется два или три раза; для Windows будет три итерации, первая из которых является прототипом, а следующие две — реальными. Продолжительность фаз может меняться, но базовая структура широко используется в компании.
Из этого процесса очевидны некоторые вещи. Наверное, самое поразительное, что непосредственно на разработку нового кода тратится удивительно мало времени: для релиза Windows это два промежутка по 6−8 недель в течение всего трёхлетнего периода. Между этапом планирования/проектирования и фактически работающим продуктом проходит много времени. Это главный фактор, почему данный процесс нельзя описать как «гибкую разработку»: новые функции накрепко встраиваются в конечный продукт, так что их трудно изменить в ответ на обратную связь.
Отделение друг от друга разработки и исправления ошибок также является проблемой: на этапах разработки и интеграции надёжность и стабильность программного обеспечения сильно хромают. Интегрируемые функции принципиально не тестируются (потому что тестирование происходит позже) и никогда не используются друг с другом (потому что все они были разработаны отдельно в своих собственных ветвях до фазы интеграции). Беспорядок программного обеспечения затем доводят до приемлемого уровня через тестирование, сообщения об ошибках и исправление ошибок во время длительной фазы стабилизации. В этом процессе нужно многократно улучшать надёжность продукта.
Наделла представляет миру в Windows 10 в 2015 году
Новый мир не такой уж и новый
В новом мире мы видим, что для полного цикла компании требуется, возможно, семь или восемь месяцев. Хотя между выпусками только шесть месяцев, начало следующего цикла происходит до завершения предыдущего — для инсайдеров это очевидно по открытию группы "Skip Ahead".
Как правило, каждое обновление начинается с довольно тихого периода с несколькими видимыми изменениями, а затем наступает несколько месяцев с введением больших изменений — и огромного количества багов. Примерно за месяц до выхода обновления мы видим резкое замедление количества внесённых изменений и сильный акцент на исправлениях ошибок, а не на новых функциях.
Как описывают сами сотрудники Microsoft, последние несколько месяцев разработки включают фазу «уведомлять» (tell), затем один месяц фазы «спрашивать разрешения» (ask). На этапе «уведомлять» руководству Windows сообщают о вносимых изменениях с политикой принятия этих изменений по умолчанию. На этапе «спрашивать разрешения» допускаются только действительно существенные изменения, как правило, всего несколько изменений в день.
Например, первая сборка октябрьского обновления (кодовое имя RS5) была выпущена для инсайдеров 14 февраля, а стабильный билд апрельского обновления (RS4) произошёл через два месяца 16 апреля. RS5 не получил каких-либо существенных новых функций до 7 марта. Много функций добавили в течение мая, июня и июля, а затем в августе и сентябре были сделаны лишь небольшие изменения. Несколько небольших функций даже удалили в августе, так как их трудно было подготовить к выходу в октябре.
Безусловно, процесс немного изменился. Например, новые функции появляются в предварительных билдах в течение многих месяцев. Это указывает на то, что интеграция новых функций, кажется, происходит гораздо раньше — по мере разработки функций, а не в одном большом пакете слияния в конце.
Упадок качества
Но есть и ключевые сходства. Самое главное, что заведомо глючный код интегрируется в общую базу, а для решения любых проблем используется фаза тестирования и стабилизации. Этот момент даже признается явно: объявляя о новой предварительной сборке, Microsoft предупреждает: «Как обычно в начале цикла разработки, сборки могут содержать баги, которые бывают болезненными. Если это доставляет вам неудобства, вы можете рассмотреть возможность переключения на медленный цикл обновлений (Slow ring). Там сборки по-прежнему будут более высокого качества».
Мы видим это на практике в RS5. В октябре прошлого года с апдейтом внедрили новую функцию для OneDrive: значки (placeholders), которые отображают файлы в облачном хранилище, не загруженные локально. Всякий раз, когда приложение пытается открыть файл, OneDrive прозрачно извлекает файл из облачного хранилища и сохраняет его локально, а приложение даже не знает, что файл изначально не был доступен локально. В билде RS5 реализовали функцию очистки реплицированных облачных файлов из локального хранилища, если заканчивается место на диске.
Это действительно умная, полезная функция, которая улучшает интеграцию с облачным хранилищем. Это и новый код; есть драйвер ядра, который обеспечивает связь между кодом синхронизации облака (используемым для загрузки файлов и загрузки изменений) и значками в файловой системе. Есть ещё API (похоже, что третьи стороны тоже могут использовать эту функцию для своих служб синхронизации).
В предварительных билдах Windows используется зелёный «экран смерти» вместо синего, так что их легко отличить
Разумно предположить, что Microsoft сделает набор тестов для этого нового кода: создание файла, проверка синхронизации, удаление локальной копии с сохранением значка, открытие значка с загрузкой реального файла, полное удаление файла и так далее, и так далее. Существует несколько основных операций по манипулированию файлами и каталогами, и в любом гибком процессе разработки есть тесты для проверки, что все операции работают как ожидалось, и API делает то, что должен делать.
Кроме того, разумно было предположить, что любое изменение кода, которое ломает тесты, будет отклонено и не допущено к интеграции. Код должен быть исправлен, он должен пройти свои тесты, прежде чем когда-нибудь попадёт в основную ветку Windows, а тем более отправится бета-тестерам.
И всё-таки во многих предварительных сборках был баг: система вешалась при удалении каталога, синхронизированного с OneDrive. Этот баг не только интегрировали в код Windows, но и выпустили для конечных пользователей.
Тестируйте софт перед выпуском, а не после
Это говорит о некоторых фундаментальных принципах разработки Windows. Либо для этого кода вообще нет тестов (мне сказали, что да, разрешено интегрировать код без тестов, хотя я надеюсь, что это не является нормой), либо сбои тестов рассматриваются как приемлемые, неблокирующие проблемы, а разработчикам разрешено интегрировать код, который заведомо не работает должным образом. Снаружи мы не можем точно сказать, что именно происходит — возможно даже сочетание обоих подходов — но ни один из них нельзя назвать хорошим.
Для старых частей Windows это можно считать более простительным — всё-таки они разработаны до эпохи автоматизированного тестирования, и там действительно может не оказаться тестов. Но значки OneDrive не являются старой частью Windows, это совершенно новая функция. Нет никаких веских причин, почему для нового кода нет твёрдого набора тестов для проверки базовой функциональности. И известный дефектный код определённо нельзя включать в кодовую базу, пока он не исправлен, не говоря уже об отправке тестировщикам.
В результате, разработка Windows 10 по-прежнему идёт по старым принципам. Новые функции вливают в базу с деградацией стабильности и надёжности. Предполагается, что кодовую базу доведут до приемлемого уровня на этапе тестирования и стабилизации.
Неадекватное автоматизированное тестирование и/или игнорирование ошибок тестирования, в свою очередь, означает, что разработчики Windows не могут быть уверены, что изменения и исправления не вызовут волновых эффектов. Вот откуда появилась фаза разработки «спрашивать разрешения»: по мере завершения обновления количество изменений нужно свести к минимуму, потому что Microsoft не уверена, что область и влияние каждого изменения изолированы. Эта уверенность приходит только с массивной инфраструктурой дисциплинированного тестирования: вы знаете, что изменение безопасно, потому что все тесты успешно проходят. Независимо от того, какое тестирование компания проводит для Windows, его явно недостаточно, чтобы получить такую уверенность.
Но в других отношениях Microsoft действует так, словно у неё имеется эта уверенность. У компании много тестов; мне сказали, что полный цикл тестирования для Windows занимает много недель. Этот полный цикл действительно проводится, просто не на сборках, которые фактически идут в продакшн. Примером может служить обновление от октября 2018 года: код был собран 15 сентября, а 2 октября сборка стала публичной. Независимо от того, какая сборка RS5 прошла полный цикл тестирования, это не та, которую мы в реальности получили, потому что полный цикл тестирования занимает слишком много времени.
Это противоречивая позиция. Если последующие изменения кода сделаны с высокой степенью уверенности, что они ничего не сломали, можно запустить полный цикл тестирования на предыдущей сборке. Но если у Microsoft такая высокая уверенность, что эти изменения ничего не сломают, ей не пришлось бы так сильно их душить на этапе «спрашивать разрешения».
Windows 10 действительно может работать как надёжная машина
Как сделать всё правильно
Мы видим значительную разницу с реальными проектами Agile. Например, процесс разработки, который использует Google для своего сервера отгрузки рекламы. Это критическая часть инфраструктуры для компании, но новые разработчики в компании описывают, что они вносили изменения для закрытия маленькой ошибки — и изменения уходили в продакшн в течение дня. Когда исправление подаётся в репозиторий, тот автоматически пересобирается и подвергается батарее тестов. Мейнтейнер данного участка кода затем рассматривает изменение, принимает его и объединяет с основной кодовой базой, которая повторно тестируется и деплоится в продакшн.
Конечно, немного несправедливо сравнивать это с Windows: всё-таки для облачных сервисов гораздо легче откатить изменение при обнаружении ошибки. Изменение Windows с синим экраном при загрузке системы гораздо труднее отменить и восстановить. Но всё же рекламный сервер — это критический сервис Google, на нём компания зарабатывает деньги, в конце концов, и неудачный апдейт может легко нанести убыток в миллионы долларов. Но автоматические тесты и весь налаженный процесс позволяют даже стажёру в компании деплоить свои изменения в продакшн за несколько часов, и делать это с уверенностью.
Менталитет разработки принципиально иной. Новая функция может быть нестабильной во время разработки, но при добавлении в основную ветку она должна соответствовать высокому уровню качества. Подход Microsoft — «объединить сейчас все ошибки, мы исправим их позже», а в правильном процессе от багов избавляются до того, как влить новую функцию в основную ветку.
Если взять версию Chrome с канала для разработчиков, то обычно единственное свидетельство, что у вас не финальный релиз — это нестандартная иконка
В то время как облачные приложения позволяют проявить определённую гибкость, методы Agile подходят и для десктопного ПО. Например, в Google налажены похожие процессы для Chrome. В бета-версиях Chrome есть редкие баги, но в целом их код близок к релизному качеству. Действительно, принцип разработки Chrome в том, что даже самый свежий билд должен быть релизного качества. Вы можете использовать dev-версию Chrome как обычный браузер — и только по значку поймёте, что это альфа, а не стабильный канал. Такое возможно благодаря обширной автоматизации тестов и проверки: на протяжении всего процесса разработки код Chrome является высококачественным, без падения качества с последующими правками, которые мы видим в Windows.
Для этого Google вложилась в инфраструктуру. У неё работает распределённая система сборки, которая собирает Chrome параллельно на тысяче ядер, поэтому полную сборку можно выполнить всего за несколько минут. Налажены дисциплинированные ветвления, чтобы сделать слияния лёгкими и предсказуемыми. Google имеет широкий спектр функциональных тестов и тестов производительности, чтобы выявить ошибки и регрессии как можно раньше. Ничто из этого не даётся бесплатно, но для Google важно выдавать релизы Chrome на устойчивой, регулярной основе.
Процесс разработки Windows всегда был плох
В новом процессе разработки Microsoft пропорционально больше времени выделено на написание новых функций и меньше — на стабилизацию и исправление этих функций. Всё было бы хорошо, если бы качество функций было высоким с самого начала, с инфраструктурой тестирования и более высокими стандартами перед интеграцией нового кода. Но опыт работы с Windows 10 до сих пор заключается в том, что Microsoft не разработала процессы и системы, необходимые для поддержания этого нового подхода.
Проблема сокращения числа выпусков с двух до одного в год не исправит проблему. Мне часто кажется, что люди смотрят на прежнюю разработку Windows сквозь розовые очки. Но если вспомнить времена Windows 7 и ранее, то мы увидим очень похожие проблемы. И тогда обычным советом было не обновляться на новую версию Windows, пока не выйдет Service Pack 1. Почему? Потому что первый релиз всегда был недопустимо глючным и нестабильным — и лучше было подождать, пока Service Pack 1 решит большинство этих проблем.
Разница не в том, что новый подход к разработке Windows намного хуже, чем раньше, или что старый процесс давал лучшие результаты. Вовсе нет. Сейчас мы видим то же самое, что и тогда, только момент «подождать Service Pack 1» наступает дважды в год. После каждого нового обновления наступает момент, когда Microsoft считает, что код достаточно хорош для корпоративных пользователей — обычно через три-четыре месяца после первоначального релиза. Это и есть наш «новый» Service Pack 1.
Таким образом, мы получаем худшее из обоих миров: от старого подхода к разработке Windows остались плохие релизы, которые нужно исправлять. От нового подхода — релизы дважды в год, а не один раз в три года. Таким образом, нестабильность до выхода Service Pack сохраняется в течение большей части года.
Основной недостаток — в дестабилизации кодовой базы путём интеграции неадекватно протестированных функций в надежде всё исправить позже. Это плохой процесс. Это было плохо во времена, когда Windows выпускалась каждые три года, и это плохо, когда она выпускается каждые шесть месяцев.
Это не работа инсайдеров
Вторая проблема — характер проводимых испытаний. В штате Microsoft раньше было огромное количество тестеров, и на каждую функцию назначали определённое количество разработчиков и тестеров. Многих из них уволили или перевели на другие должности в 2014 году. Идея была в том, что больше обязанностей по тестированию возложат на разработчиков, создающих эти функции. Программа Windows Insider также обеспечивает большой объём неформального тестирования — со многими миллионами участников (инсайдеров). Это гораздо больше, чем в любой из предыдущих бета-программ Windows.
Не уверен, что старый подход обязательно обнаружил бы баг с потерей данных. Возможно, профессиональные тестеры не проверили бы конкретный сценарий, при котором удаляются данные. Но ясно, что Microsoft не справляется с обработкой потока сообщений об ошибках от инсайдеров. Потерю данных зафиксировали за три месяца до выхода обновления. Многие сообщения об ошибке кажутся низкого качества, им не хватает необходимых деталей или правильной терминологии, но если компания не заметила проблему в течение трёх месяцев, то совсем не очевидно, что более длительный период разработки имеет значение. Более длительный период разработки будет означать, что ошибку проигнорировали в течение шести месяцев, а не трёх.
Microsoft обещала изменить процесс обратной связи с инсайдерами, чтобы те указывали серьёзность проблемы и привлекали больше внимания к такого рода проблемам. Это может помочь, если инсайдеры будут корректно использовать индикаторы серьёзности, но кажется недостаточным для решения главной проблемы: слишком большого количества отчётов об ошибках слишком низкого качества.
Это относится к проблеме качества кода. Реальная сила программы Insider — разнообразие аппаратного и программного обеспечения. Инсайдеры могут выявить самые экзотические баги совместимости, проблемы с драйверами и так далее. Но инсайдеры не должны осуществлять базовое тестирование функций. Но часто возникает ощущение, что Microsoft использует их как штатных тестировщиков.
Более того, если качество кода падает во время разработки, то предварительные сборки обычно не подходят для повседневного использования на обычных ПК. Они недостаточно надёжны. В свою очередь, это подрывает ценность тестирования инсайдерами: они не устанавливают их на основной ПК и не подвергают сборки полному спектру аппаратного и программного обеспечения. Они используют второстепенные ПК и виртуальные машины.
Вы должны инвестировать в свои инструменты
Разработка инфраструктуры тестирования как у Chrome для такого гигантского проекта как Windows — очень серьёзная задача. Хотя некоторые части Windows допускают автономное тестирование, но другие можно эффективно проверить только в интегрированной целостной системе. Некоторые из них, такие как функция синхронизации файлов OneDrive, даже зависят от работы внешних сетевых служб. Это совсем не тривиальная задача.
Огромным изменением стало бы принятие принципа, что код Windows должен в каждым момент времени обеспечивать релизное качество — не «после нескольких месяцев исправления», а «прямо сейчас, в любой момент». Но это необходимое условие. Microsoft должна добиться ситуации, когда каждое новое обновление обладает релизным качеством с первого дня. Ситуации, где апдейт на самую последнюю версию не является проблемой — и такой выбор можно с уверенностью принять. Обновления функций должны стать незаметными событиями для пользователей. Сокращение количества релизов до одного в год или одного в три года не обеспечит такой ситуации, и никогда не обеспечивало. Должен измениться сам процесс, а не сроки.
Автор: m1rko
