Делай как вGoogle
 Скачать 5.77 Mb.
|
|
501 Раньше нам приходилось тщательно приурочивать пресс-релизы к двоичным выпус- кам. Мы должны были сначала провести успешное развертывание и только потом публиковать пресс-релиз о новых возможностях или функциях. То есть новые функ- ции становились доступны до того, как о них было объявлено, и имелся реальный риск, что их обнаружат раньше времени. И в этой ситуации проявляется вся ценность защитных флагов. Если доступ к новому коду защищен флагом, его можно изменить, чтобы включить функцию непосред- ственно перед выпуском пресс-релиза, что минимизирует риск утечки информации о ней. Обратите внимание, что защита кода флагом не является идеальным решением для действительно важных функций. Код все еще можно обнаружить и проанализи- ровать, если он плохо защищен, и не все функции можно скрыть за флагами, не уве- личив при этом сложность. Более того, даже изменения флагов должны выполняться с осторожностью. Включение флага сразу для 100 % пользователей — не лучшая идея, поэтому хорошим вложением может стать организация службы, управляющей безопасным развертыванием конфигураций. Тем не менее возможность отделить конкретную функцию от общего выпуска продукта является мощным рычагом для продвижения долгосрочной устойчивости приложения. Стремление к гибкости: создание серии выпусков Двоичный файл Google Search является первым и самым старым. С его помощью можно воссоздать летопись происхождения Google — поиск в нашей кодовой базе все еще позволяет находить код, написанный по меньшей мере в 2003 году, а часто и раньше. Когда смартфоны начали набирать популярность, в код, написанный в пер- вую очередь для развертывания на серверах, стали добавляться функции поддержки мобильных устройств. По мере того как приложение Search становилось все более интерактивным, развертывание сборок вызывало все больше сложностей. В какой-то момент мы выпускали двоичный файл Search только раз в неделю, и даже этот срок удавалось соблюсти не всегда. Когда Шери Шипе (Sheri Shipe), один из авторов этой главы, взялся за работу по увеличению частоты выпусков Search, на подготовку каждого выпуска у группы инженеров уходило несколько дней. Они собирали двоичный файл, интегрировали данные, а затем начинали тестирование. Каждую обнаружившуюся ошибку при- ходилось исследовать вручную, чтобы убедиться, что она не повлияет на качество поиска, пользовательский опыт и/или доход. Это был изнурительный процесс, требовавший много времени и не соответствовавший ни объему, ни частоте изме- нений. В результате разработчик не имел возможности узнать, когда его функция будет выпущена в производство. Это затрудняло выбор времени для пресс-релизов и публичных заявлений. Новые выпуски формируются не на пустом месте, и наличие надежного процесса подготовки выпусков упрощает синхронизацию зависимых факторов. В течение нескольких лет специальная группа инженеров внедряла непрерывный процесс 502 Глава 24. Непрерывная поставка выпуска, который упростил все, что касалось передачи двоичного файла Search во внешний мир. Мы автоматизировали все, что могли, установили сроки внедрения новых функций и упростили интеграцию плагинов и данных в двоичный файл. Теперь мы можем выпускать новые двоичные файлы Search через день. На какие компромиссы нам пришлось пойти, чтобы добиться предсказуемости цикла выпуска? Они сводятся к двум основным идеям, положенным в основу системы. Идеальных двоичных файлов не бывает Первая идея — идеальных двоичных файлов не бывает. Это особенно верно для сборок, включающих результаты труда десятков или даже сотен разработчиков, независимо разрабатывающих десятки важнейших функций. Исправить каждую ошибку невоз- можно, поэтому нам постоянно приходилось взвешивать такие вопросы, как: «Если переместить линию на два пиксела влево, повлияет ли это на отображение рекламы и потенциальный доход?», «Если немного изменить оттенок этого прямоугольника, пользователи с ослабленным зрением увидят в нем текст?» Остальная часть этой книги небезосновательно посвящена минимизации непредвиденных последствий для выпуска, но, в конце концов, мы должны признать, что ПО — в принципе сложная штука. Не существует идеального двоичного кода — каждый раз, когда в производство внедряется новое изменение, приходится принимать решения и идти на компромиссы. Ключевые показатели эффективности метрик с четкими пороговыми значениями позволяют запускать в эксплуатацию функции, даже если они не идеальны 1 , и до- бавляют ясности при решении спорных вопросов. В связи с этим вспоминается одна ошибка, связанная с редким диалектом, на котором говорят только на одном острове на Филиппинах. Когда пользователь формулиро- вал поисковый вопрос на этом диалекте, он в ответ получал пустую веб-страницу. Нам нужно было определить, стоит ли потратить силы и время на исправление этой ошибки и отложить выпуск новой важной функции. Мы бегали из офиса в офис, пытаясь выяснить, сколько людей говорит на этом языке, возникает ли ошибка каждый раз, когда пользователь вводил запрос на этом языке, и использовали ли эти люди Google на регулярной основе. Каждый инженер по ка- честву, с которым мы говорили, отсылал нас к вышестоящему специалисту. Наконец, собрав данные, мы задали вопрос старшему вице-президенту Search. Должны ли мы отложить выпуск важной функции, чтобы исправить ошибку, которая затронула лишь маленький остров на Филиппинах? Оказалось, каким бы маленьким ни был ваш остров, вы должны получать надежные и точные результаты поиска, поэтому мы отложили выпуск и исправили ошибку. 1 Как говорят наши специалисты по надежности относительно «бюджета ошибок»: совершен- ство редко бывает лучшей целью — вы должны выяснить, каков допустимый бюджет ошибок и какая часть этого бюджета была потрачена в последнее время, а потом использовать эти цифры, чтобы отрегулировать компромисс между скоростью и стабильностью. Качество и ориентация на пользователя: поставляйте только то, что используется 503 Соблюдение сроков выпусков версий Вторая идея: если вы опоздали на поезд, он уйдет без вас. Хочется вспомнить по- словицу: «Сроки определены, а жизнь — нет». В какой-то момент, чтобы соблюсти график выпуска, вам придется принять жесткое решение и отказать разработчикам во включении в выпуск их новых функций. Честно говоря, никакие просьбы или мольбы не заставят нас включить функцию в последний выпуск после истечения крайнего срока. Впрочем, есть одно редкое исключение. Представьте: поздний вечер пятницы и шесть инженеров-программистов в панике врываются в кабинет менеджера по выпуску. У них есть контракт с NBA, и они закончили работу над его реализацией минуту назад. Но изменения должны быть выпущены до завтрашней игры. Выпуск необхо- димо приостановить и добавить эту функцию в двоичный файл, иначе мы нарушим контракт! Инженер по выпуску с затуманенными глазами качает головой и говорит, что на сборку и тестирование нового двоичного файла уйдет четыре часа, а у его сына сегодня день рождения и ему еще нужно забрать воздушные шары. В мире регулярных выпусков, если разработчик опоздал на поезд, он сможет сесть на следующий, отправляющийся через несколько часов, а не дней. Это ограничива- ет панику разработчиков и значительно улучшает баланс между работой и личной жизнью инженеров по выпуску. Качество и ориентация на пользователя: поставляйте только то, что используется Раздувание — неприятный побочный эффект жизненного цикла разработки любого ПО, и чем большим успехом пользуется продукт, тем больше раздувается его база кода. Один из недостатков быстрой и эффективной серии выпусков — раздувание часто ускоряется и может приводить к проблемам для команды, развивающей про- дукт, и даже для пользователей. В частности, если ПО поставляется непосредственно клиенту, как в случае с мобильными приложениями, это может означать, что на устройстве пользователя будет расходоваться больше пространства и ему придется платить за загрузку продукта, данные и даже функции, которые он никогда не исполь- зовал и не будет использовать, а разработчикам придется мириться с уменьшением скорости сборки, сложностью развертывания и редкими ошибками. В этом разделе мы поговорим о том, как динамическое развертывание позволяет поставлять только то, что используется, и о компромиссах между полезностью и стоимостью функций. В Google часто создаются специальные команды, занимающиеся увеличением эф- фективности продукта на постоянной основе. Веб-приложения выполняются в облаке, а клиентские приложения используют ресурсы устройства пользователя — телефона или планшета. Выбор из двух типов приложений сам по себе демонстрирует компромисс: клиентские приложения часто обладают большей производительностью и устойчивостью к нестабильным соеди- 504 Глава 24. Непрерывная поставка нениям, но они более трудные для обновления и более восприимчивы к проблемам на уровне платформы. Распространенный аргумент против частого развертывания клиентских приложений: пользователи не любят частые обновления и вынуждены платить за данные и нарушения работоспособности. Могут существовать и другие факторы, ограничивающие этот выбор, такие как доступность сети или лимит на количество перезагрузок устройства, необходимых для получения обновления. Иногда приходится идти на компромисс и искусственно уменьшать частоту обнов- ления продукта, но этот выбор должен быть осознанным. В хорошо отлаженном процессе непрерывной поставки частота создания жизнеспособных версий может не совпадать с частотой их получения пользователем. Вы можете развертывать новые версии еженедельно, ежедневно или ежечасно, но вам следует осознанно настроить процесс выпуска с учетом конкретных потребностей ваших пользователей и целей вашей организации, а также определить оптимальную модель поддержки устойчи- вости продукта в долгосрочной перспективе. Выше в этой главе мы говорили о необходимости модульной организации кода. Она позволяет организовать динамическое и настраиваемое развертывание и эф- фективнее использовать ограниченные ресурсы, например пространство памяти на устройстве пользователя. Без нее каждый пользователь будет вынужден получать код, который он никогда не станет использовать, например для поддержки не нуж- ных ему переводов или архитектур других типов устройств. Динамическое развер- тывание позволяет поддерживать небольшие размеры приложений и доставлять на устройство только код, который будет полезен пользователям, а A/B-тестирование помогает найти компромисс между затратами на создание функции и ее ценностью для пользователей и вашего бизнеса. Настройка этих процессов требует затрат, а выявление и устранение трений, удерживающих частоту выпусков ниже желаемой, — кропотливый труд. Но долгосрочные выгоды с точки зрения управления рисками, скорости разработки и обеспечения быстрого внедрения инноваций настолько высоки, что эти затраты быстро окупятся. Сдвиг влево: раннее принятие решений на основе данных Если вы ориентируетесь на самый широкий круг пользователей, у вас могут быть клиенты с интеллектуальными экранами, акустическими системами или телефонами и планшетами на Android и iOS, а ваше ПО может быть достаточно гибким, чтобы пользователи могли настраивать его под свои нужды. Даже если вы разрабатываете только для устройств на Android, огромное разнообразие более чем двух миллиар- дов устройств может сделать перспективу специализации выпусков невыполнимой задачей. А с учетом скорости развития науки и техники, когда вы будете читать эту главу, могут появиться совершенно новые категории устройств. Сдвиг влево: раннее принятие решений на основе данных 505 Один из наших менеджеров по выпуску версий поделился мудростью, изменив- шей ситуацию. Он сказал, что разнообразие клиентского рынка — это не проблема, а факт. Приняв эту мудрость, мы можем изменить модель специализации версий следующим образом: y Если всеобъемлющее тестирование невозможно, нужно использовать репрезен- тативное тестирование. y Поэтапное развертывание с постепенным увеличением доли охватываемых поль- зователей позволяет быстро вносить исправления. y Автоматические A/B-версии позволяют получать статистически значимые результаты, подтверждающие качество версии, без утомительной нагрузки на пользователей, которые должны смотреть на информационные панели и при- нимать решения. В разработке ПО для Android Google использует специализированные пути те- стирования и поэтапное развертывание с постепенно увеличивающейся долей пользователей, и на каждом этапе тщательно анализируются все возникающие проблемы. Поскольку Play Store предлагает неограниченное количество путей для тестирования, мы также можем создавать команды контроля качества в любой стране, где планируем выпуск, что позволяет в мгновение ока провести глобальное тестирование ключевых функций. Одна из проблем, которые мы заметили при развертывании версий на Android, за- ключалась в том, что простая отправка обновления могла вызвать статистически значимые изменения в оценке продукта пользователями. То есть, даже если мы не вносим никаких изменений в продукт, выпуск обновления может оказать непред- сказуемое влияние на поведение устройств и пользователей. В результате, несмотря на то что ограничение распространения обновления узким кругом пользователей может дать ценную информацию о сбоях или проблемах со стабильностью, оно не позволяло нам понять, действительно ли новая версия приложения лучше старой. Дэн Сирокер и Пит Кумен уже обсудили в своей книге ценность A/B-тестирования 1 В Google некоторые из наших крупных приложений тоже проводят A/B-тестирование своих развертываний. Они отправляют две версии продукта, одна из которых ими- тирует желаемое обновление (то есть это старая версия приложения). Поскольку обе версии развертываются одновременно для достаточно широкого круга похожих пользователей, появляется возможность сравнить одну версию с другой и увидеть, действительно ли последняя версия ПО лучше предыдущей. При достаточно большой базе пользователей можно получить статистически значимые результаты в течение нескольких дней или даже часов. Автоматизированный конвейерный обработчик метрик может обеспечить максимальную скорость выпуска версии, распространив 1 Siroker D., Koomen P. A/B Testing: The Most Powerful Way to Turn Clicks Into Customers. Hoboken: Wiley, 2013. 506 Глава 24. Непрерывная поставка новую версию среди более широкого круга пользователей, как только будет накоп- лено достаточно данных, подтверждающих, что предельные метрики не затронуты. Очевидно, что этот метод применим не ко всем приложениям и может привести к значительным накладным расходам при недостаточно большой базе пользова- телей. В этих случаях рекомендуется стремиться выпускать версии, нейтральные к изменениям. Все новые функции в таких версиях защищены флагами, поэтому единственное, что проверяется во время развертывания, — это стабильность самого развертывания. Изменение культуры команды: дисциплина развертывания Принцип «постоянной готовности к развертыванию» помогает решить некоторые проблемы, влияющие на скорость разработки, но кроме него существуют также опре- деленные методы, решающие проблемы масштабирования. Команда, выпустившая продукт, может насчитывать менее десяти человек, каждый из которых по очереди выполняет развертывание и осуществляет мониторинг. Со временем команда может вырасти до сотен человек с подгруппами, отвечающими за определенные функции. По мере расширения организации количество изменений в каждом развертывании и количество рисков при каждой попытке выпуска новой версии увеличиваются в геометрической прогрессии. Каждый выпуск версии — это месяцы пота и слез. Успешный выпуск требует все больше усилий. Часто разработчик оказывается перед выбором, что хуже: отказаться от выпуска версии, которая на четверть состоит из новых функций и исправлений ошибок, или выпустить новую версию без уверен- ности в ее качестве. Повышенная сложность обычно проявляется в увеличении задержки между выпуска- ми. Даже если вы выпускаете новую версию каждый день, для подготовки полностью безопасного выпуска к развертыванию может потребоваться неделя или больше, и вам останется неделя для отладки любых проблем. Вот где принцип «постоянной готовности к развертыванию» может вернуть проект в эффективную форму. Частые выпуски позволяют минимизировать отклонения от заведомо хорошей версии, а но- визна изменений помогает решать проблемы. Но как команда сможет гарантировать поступательное движение вперед при всей сложности, присущей большой и быстро расширяющейся кодовой базе? В Google Maps мы считаем, что функции важны, но лишь немногие функции важны настолько, чтобы из-за них стоило отложить выпуск. Если выпуски происходят ча- сто, задержка внедрения одной функций оказывает намного менее отрицательное влияние, чем задержка внедрения всех новых функций, особенно если пользователи могут столкнуться со спешно разработанной и не совсем готовой функцией. Одна из обязанностей менеджера по выпуску версий — защитить продукт от раз- работчиков. Итоги 507 Чрезмерный энтузиазм, который разработчик испытывает при выпуске новой функ- ции, никогда не должен мешать ему ориентироваться на пользовательский опыт. Это означает, что новые функции должны изолироваться от других компонентов версии с помощью интерфейсов со строгими контрактами, разделения задач, тща- тельного тестирования, своевременного обмена информацией, а также соглашения о внедрении новых функций. Заключение За долгие годы работы мы обнаружили, что, как ни странно, «чем быстрее, тем без- опаснее». Состояние продукта и скорость разработки на самом деле не противоречат друг другу, и продукты, которые выпускаются чаще и с небольшим количеством из- менений, имеют более высокое качество. Они быстрее приспосабливаются к ошибкам, встречающимся в продакшене, и к неожиданным изменениям рынка. Кроме того, «чем быстрее, тем дешевле», потому что наличие предсказуемой и частой последо- вательности версий снижает стоимость каждого выпуска и делает стоимость отмены любого выпуска очень низкой. Простое наличие структур, обеспечивающих непрерывное развертывание, прино- сит большую выгоду, даже если развертываемые выпуски не распространяются среди пользователей. Что мы имеем в виду? На самом деле мы не выпускаем каж- дый день совершенно разные версии Search, Maps или YouTube. Но, чтобы быть готовыми к этому, нам нужны надежный и хорошо документированный процесс непрерывного развертывания, точные и актуальные показатели удовлетворен- ности пользователей и состояния продукта, а также скоординированная команда с четкой политикой в отношении процессов в продукте. Как показывает практика, для этого часто требуется настраивать двоичные файлы в продакшене, управлять конфигурациями (в VCS) и использовать набор инструментов, позволяющий предпринимать меры безопасности, такие как пробный прогон, механизмы отката и добавления исправлений. |