В мире технологий царит миф о «ночных работах». Мы привыкли думать, что масштабные обновления приложений происходят в тишине, пока город спит: серверы отключаются, данные переносятся, а утром пользователи видят новую версию. Но для платформ с аудиторией в десятки миллионов человек такой сценарий невозможен. У них нет ночи. Пока одни пользователи спят, другие активно пользуются сервисом. Остановка даже на час означает потерю доверия, отток аудитории и миллионные убытки.
Юсуп Изрипов — фронтенд-инженер с опытом работы на критически важных продуктах крупнейших российских технологических платформ — вёл техническую часть именно такого проекта. Полтора года его команда переписывала изнутри раздел социальной сети, которой ежедневно пользуются десятки миллионов человек. За всё это время не было ни одного объявления о технических работах, ни одного окна «сайт недоступен», ни одной новости про обновление. Пользователи заходили и пользовались ровно так же, как накануне.
Как это возможно? Почему попытка «уйти на полгода и сделать всё сразу» чаще всего обречена? Что общего между кодом и ремонтом в квартире, из которой нельзя выселить жильцов? И почему самая опасная ошибка может быть не в программе, а в том, как вы считаете цифры? Интервью о невидимой инженерной работе, от которой зависит, останутся ли с вами пользователи.
— Юсуп, начнём с главного. Вы говорите, что полтора года переписывали крупный раздел платформы, и никто из пользователей этого не заметил. Для человека, далёкого от разработки, это звучит как замена двигателя в движущемся автомобиле. Что вообще значит «переписать изнутри»?
— Это хорошее сравнение, но я обычно использую другое. Представьте ремонт в доме, из которого нельзя выселить жильцов. Воду отключать нельзя, лифт должен ходить, свет должен гореть, а стены при этом надо поменять. И поменять так, чтобы жильцы наутро не заметили разницы и не начали звонить в управляющую компанию.
Примерно в таком режиме живут большие сервисы. У них нет «ночи», когда можно всё закрыть: пока в одной стране люди спят, в другой — день. И нет возможности сказать аудитории: «Подождите полгода, мы делаем новую версию». За полгода люди просто уйдут туда, где ничего не ждут.
Раздел, о котором речь, писался годами. Часть кода делали люди, которые давно уже не работают в компании. Это нормальная история, а не признак чьего-то непрофессионализма: требования менялись, продукт рос, каждое поколение разработчиков добавляло своё поверх предыдущего. Через несколько лет получается конструкция, в которой всё связано со всем, и любая простая правка занимает вдвое больше времени, чем должна.
Я отвечал за техническую сторону этого переезда: в каком порядке менять части, как устроить границу между старым и новым, когда показывать результат людям и по каким признакам останавливаться. Вокруг работали серверная команда, аналитики, дизайнеры, мобильные разработчики — у каждого свои сроки. Название платформы тут лучше пропустить, важен порядок величин.
— Соблазн, наверное, был огромный: уйти на год, спокойно написать новую версию в тишине, а потом в один прекрасный день переключиться. Почему вы не пошли этим путём?
— Потому что так обычно заканчивается плохо. Продукт не встаёт на паузу. Пока одна команда пишет новое, вторая продолжает менять старое, потому что бизнесу нужны новые функции. К моменту, когда новая версия готова, она отстаёт от работающей на десятки изменений, и догонять их приходится тогда, когда сроки уже прошли.
Дальше выясняется, что никто не может сказать, всё ли перенесено. Спецификации у старого раздела нет, есть только его поведение, накопленное за годы. Сравнить старое и новое целиком за один день физически невозможно.
И самое неприятное: если после переключения что-то пошло не так, возвращаться некуда. Откатывать придётся не только видимую часть, но и всё, что успело поменяться под ней.
Поэтому правило, которое я поставил в начале и защищал потом весь проект, было простым: это не проект с датой сдачи — это способ работы. Всё новое делаем только на новой основе. Старое трогаем только ради исправлений. Кусок за куском старая часть вытесняется, и в любой день система остаётся рабочей.
— С чего начинать? С самого главного экрана? С сердца продукта?
— Нет, начинать логичнее не с самого важного и не с самого заметного, а с того, что чаще всего приходится править. Я посмотрел историю изменений за год и посчитал, в какие места кода команда возвращалась чаще всего. Картина оказалась показательной. Часть раздела не менялась годами, и переписывать её первой смысла не было. А несколько мест собирали десятки правок в год и съедали время на каждой задаче. Именно с них отдача видна сразу.
Первым в работу пошёл экран средней важности, но с высокой частотой изменений. Не самый посещаемый, чтобы отладить весь процесс на живых пользователях, не рискуя главным. Уже после него шли ключевые страницы.
— Вы упоминаете «единую дверь» между старым и новым. Что это такое?
— Самая ценная часть работы оказалась не в новом коде, а в стыке между двумя половинами. Старая и новая части должны были уметь разговаривать друг с другом, пока живут рядом. Если разрешить им общаться напрямую и как получится, старое прорастает в новое, и через полгода выясняется, что убрать его уже нельзя: от него зависят двести мест.
Поэтому я сделал одну общую дверь. Единственный переходник, через который новая часть видит старую, с понятными правилами по обе стороны. Новый код не знает, что там под ним. Когда старая половина уходила, менялся переходник, а не двести мест.
Отдельная сложность была с тем, что видно на каждой странице: верхнее меню, счётчики уведомлений, окно входа. Эти вещи должны были одинаково работать и на старых экранах, и на новых. Их вынесли отдельно, чтобы они поднимались один раз и не зависели от того, какая версия страницы открыта.
— А что с переходами? Когда человек уходит со старого экрана на новый, страница же загружается заново. Пользователь на секунду видит белый экран. На масштабе миллионов это же бьёт по опыту?
— Да, один раз это незаметно. Но если между двумя экранами ходят по десять раз за сессию, ухудшение видно в цифрах сразу. Решение оказалось не техническим, а планировочным. Мы смотрели по аналитике, между какими экранами люди реально ходят чаще всего, и переносили их группами. Тогда шов проходил по редким переходам, а не по частым.
— Вы говорите, что перед показом людям новая версия какое-то время работала впустую. Это как?
— У небольшой доли пользователей новая часть загружалась в фоне, запрашивала те же данные, записывала свои показатели, но на экран не попадала. Никто ничего не видел, а мы получали статистику того, как всё это ведёт себя на реальных телефонах и реальных сетях, а не на компьютерах разработчиков. Репетиция вхолостую.
— Вы выделяете три истории, на которые ушло больше всего времени. Начнём с первой: показатель упал, хотя ничего не сломалось.
— Первое включение на пяти процентах аудитории показало заметное падение целевого действия. Ошибок нет, скорость не хуже, жалоб нет. Разбирались неделю.
Причин оказалось две, и обе не в самом разделе. Первая: новая версия считала просмотры чуть иначе, чем старая. Момент, в который засчитывался показ, сместился, и знаменатель дроби поменялся. Продукт не стал хуже, изменилась линейка.
Вторая: у людей, попавших в новую версию, первое открытие было медленнее, потому что новые файлы ещё не сохранились у них в браузере. На медленном интернете часть просто не дожидалась. При сравнении групп целиком это выглядело как деградация, хотя относилось только к первому визиту.
После того как счёт привели к общему виду, а первый и повторный визит стали смотреть отдельно, картина развернулась в другую сторону. С тех пор я фиксирую способ подсчёта до начала работ, отдельным документом, и проверяю совпадение заранее.
— Вторая история — медленная поломка. Что это была за неисправность?
— Новая часть при закрытии экрана не до конца отпускала то, что брала у старой. На коротких сессиях это незаметно совсем. Но у людей, которые проводят в ленте полчаса и больше, на недорогих телефонах вкладка постепенно тяжелела, начинала подтормаживать, а потом браузер её выгружал.
В отчётах это выглядело не как ошибка, а как то, что один сегмент аудитории стал уходить раньше. Никакого сообщения о сбое, никакой аварии. Просто люди на дешёвых устройствах чуть быстрее закрывали приложение.
Нашли, потому что смотрели цифры в разрезе длительности сессии и типа устройства, а не среднее по всем. Починили в одном месте, в том самом переходнике, и это закрыло проблему сразу для всех экранов. Ради таких случаев он и делался.
— Третья история — про правила, которых нигде не записано. Почему вы называете это самой недооценённой частью?
— Приватность, блокировки, ограничения по возрасту, удалённые и скрытые записи, аккаунты в нестандартном состоянии. Всё это копилось годами и нигде не было описано: логика жила в самом коде, а люди, которые её закладывали, давно ушли.
Если переписывать новый экран просто по макету от дизайнера, эти правила теряются молча. Страница открывается, выглядит нормально, и в какой-то момент кому-то показывается то, что показывать было нельзя. Для социальной платформы это не мелкая ошибка — это доверие пользователей.
Я снял статистику за две недели по тому, какие сочетания состояний реально встречаются у людей, и отсортировал по частоте. Получилось около четырёх десятков вариантов поведения. В дизайне было описано меньше десяти. Этот список стал проверочным чек-листом на весь оставшийся проект.
Старый код — это не только код. Это ещё и требования, которые больше нигде не сохранились.
— Как вы включали новую версию? Был какой-то общий рубильник?
— Новую версию всегда можно было включить и выключить отдельно от того, что выложено на сервер. Сначала её видела только команда, потом сотрудники компании, потом один процент аудитории, потом пять, потом четверть, половина и все.
На каждом шаге смотрели не только на ошибки, но и на поведение: скорость открытия, отзывчивость на слабых телефонах, доля людей, уходящих в первые секунды, целевые действия раздела, поток обращений в поддержку.
Признаки, по которым мы останавливаемся, формулировались до включения, а не по ходу. Иначе любую просадку легко объяснить сезоном и поехать дальше.
Выключалась при этом не вся работа целиком, а конкретный экран. Если ломался один, отключался один, а не полтора года труда.
— Вы упоминаете «хвост» проекта. Что это?
— Последние проценты старого живут дольше всего. Редкие страницы, служебные сценарии, экраны, на которые люди попадают из поисковиков и почти никогда изнутри продукта. Пока хоть что-то из этого тянет за собой старую основу, поддерживать приходится обе версии сразу, и выигрыша по скорости почти нет.
Поэтому на остаток я завёл простой список: что осталось, кто отвечает, к какому сроку. Без него такие проекты живут в состоянии «почти доделали» годами. Реальный эффект пришёл не в тот день, когда новая версия открылась для всех, а в тот, когда со страниц ушла последняя зависимость от старой.
— Что вы вынесли из этого опыта? Что остаётся после такой работы?
— У хорошей миграции нет информационного повода. Нет анонса, нет ночных работ, нет извинений перед пользователями. Если аудитория что-то заметила, значит, где-то ошиблись.
Главное, что остаётся после такой работы, — это не новый код. Код перепишут ещё раз через несколько лет, это нормальный цикл. Остаётся устройство границы между старым и новым и список того, что система на самом деле должна делать. Именно эти две вещи определяют, дойдёт ли проект до конца.
Ограничение «продукт не останавливается» на самом деле помогает. Оно не даёт спрятаться в большую красивую переделку и заставляет резать работу на куски, каждый из которых можно включить, измерить и при необходимости выключить. Обычная разработка новых функций этому не учит.
— Последний вопрос. Как убедить бизнес, что такой проект нужен? Ведь снаружи это выглядит как огромные затраты времени без видимого результата.
— Такой проект бесполезно защищать словами про технический долг. Работает другой разговор: сколько времени сейчас уходит на типовую задачу в этом разделе, сколько будет уходить после и что происходит с ощущениями пользователя по дороге. Инженерное решение здесь приходится объяснять не только инженерам, и этому в профессии обычно нигде не учат.
— Спасибо, Юсуп. Получился разговор о том, что настоящее мастерство — не в громких запусках, а в тишине, в которой они происходят.
— Да. Идеальный ремонт — это когда жильцы не замечают, что стены меняли. С сервисами то же самое.
