Приведем несколько ситуаций, наглядно демонстрирующих необходимость полного обновления ресурса.
Например, возникла ошибка при применении промокода: клиент вводит код, оформление заказа проходит успешно, однако система некорректно учитывала скидку. Разработчики исправили ошибку, обновив систему — промо-код начал работать правильно. Все вроде бы хорошо…
Однако спустя час поступает тревожная информация от бухгалтерии: цены товаров в новых заказах расходятся с фактически уплаченными суммами. Одновременно выясняется, что та же проблема проявилась и в CRM-системе — скидки были рассчитаны неправильно.
Разбираемся дальше: оказывается, ранее внедрённый временный хак («костыль») повлиял на весь механизм расчёта скидок и промокодов. Удаление этого хака вернуло правильную работу промоков, но сломало другой важный компонент системы — теперь стоимость товаров снова считается неверно. Итог: приходится срочно устранять два новые критические проблемы, причем нельзя гарантировать, что следующая правка вновь не приведет к появлению ещё большего числа дефектов.
Заказчик обращается с простой просьбой: «Нужно добавить капчу в окно авторизации, поскольку большинство пользователей — это бот-трафик». Казалось бы, задача элементарная и должна занять пару часов. Однако команда потратила на её выполнение целый рабочий день.
Почему?
Дело в том, что на сайте предусмотрено сразу несколько способов авторизации, каждый из которых имеет собственный интерфейс окна регистрации и отдельный метод обработки входа. Полноценная переработка структуры оказалась бы чрезмерно затратной мерой, поэтому пришлось добавлять капчу отдельно в каждое окно и каждый способ авторизации. Это привело к значительному перерасходу ресурсов и дублированию усилий команды разработчиков.
Постоянные сложности с разработкой и поддержкой заставляют заказчика задуматься: возможно, дело вовсе не в проекте, а в самой команде исполнителей? Логично попробовать обратиться к другим специалистам и посмотреть, изменится ли ситуация.
Новый подрядчик проводит аудит исходного кода перед началом работы и приходит к выводу, что продолжать сотрудничество невозможно. Причины просты: структура кода крайне запутанная, изобилует многочисленными обходными решениями («костыли»), разобраться в которой практически нереально. Оценить объем предстоящих изменений становится невозможным, равно как и предсказать последствия любого вмешательства в существующий код. Принятие ответственности за такие условия — серьезный риск для любой профессиональной команды, поэтому отказ от участия выглядит вполне разумным решением.
Даже несмотря на приостановленную рекламу и низкий сезон, сайт работает медленно, а монитор производительности демонстрирует высокую загрузку процессора. Когда начинается рекламная кампания или увеличивается естественный приток посетителей, ресурс буквально зависает и выходит из строя.
Среди предложенных решений чаще всего звучат два варианта: увеличить вычислительную мощность сервера, хотя она уже существенно превышает норму, или создать дополнительный сервис для кэширования страниц. Но разработчики предупреждают, что оптимизация непосредственно самого сайта экономически невыгодна, поскольку затраты превысят выгоду. Очевидно, что скорость работы достигла тупика, решить проблему оперативно можно лишь добавлением внешних инструментов, которые маскируют симптомы, но не устраняют первопричину замедления.
Экономия на этапе запуска проекта
При запуске нового продукта или стартапа владельцы стараются минимизировать расходы, опасаясь значительных потерь, если проект окажется неудачным. Для сокращения издержек нередко выбирают наиболее бюджетных исполнителей. В результате разработку поручают начинающим программистам или недостаточно квалифицированным специалистам среднего уровня. Итогом становятся низкое качество программного кода, непродуманность архитектуры и общее снижение эффективности сайта. Такие ресурсы сложно масштабировать и поддерживать, поскольку улучшение имеющегося кода обходится значительно дороже, чем создание нового качественного решения.
Неразрешимый технический долг
Допустим, вам повезло подобрать сильную команду опытных специалистов, включая архитекторов и старших разработчиков. Тем не менее, даже в такой группе ради быстрого вывода продукта на рынок или в условиях высокой неопределённости неизбежно возникает накопление технического долга. Постепенно каждая новая версия добавляет всё больше временных решений и компромиссов, ухудшая состояние проекта.
Хорошо, если этот долг своевременно документируется в техническом плане или специальной отчётности, тогда есть возможность сохранить контроль над ситуацией. Гораздо хуже, если важные технические нюансы остаются исключительно в памяти ведущего специалиста или вообще нигде не записываются. Именно такая практика приводит к потере управления техническим долгом, который незаметно разрастается до огромных размеров.
Особенно опасно менять команду разработчиков без предварительного тщательного анализа текущего состояния кода. Нередко руководство отказывается проводить полную проверку кода, стремясь сэкономить средства. Результат очевиден: новый коллектив вынужден сталкиваться с неконтролируемым объёмом технических проблем, не имея чёткого представления о причинах возникших сложностей.
Итогом становится нестабильная платформа, любое изменение которой сопровождается появлением необъяснимых ошибок. Дальнейшая поддержка подобного проекта постепенно превращается в дорогостоящий и бессмысленный процесс, гораздо дешевле и эффективнее начать разработку с чистого листа.
Устаревшие технологии и инструменты
Первоначальная версия сайта зачастую создаётся на нестандартных или устаревающих технологиях, выбранных командой разработчиков исходя из личных предпочтений. Проблема заключается в том, что такие платформы быстро теряют поддержку производителя: прекращаются выпуски обновлений, совместимых с новыми языками программирования и средами исполнения.
Кроме того, бывает распространённая ситуация, когда разработчики вносят произвольные изменения прямо в ядро используемого фреймворка или CMS, вместо того чтобы создавать отдельные модули, расширяющие функциональность легальным способом. Подобная практика делает дальнейшие обновления невозможными.
Таким образом, теряется важная поддержка поставщика технологий, который регулярно выпускает обновления своего продукта. Обновления нужны для закрытия выявленных уязвимостей, добавления функциональности, устранения старых ошибок и адаптации к новым аппаратным средствам. Без официальной поддержки весь перечень улучшений приходится реализовывать вручную самим программистам, повторно проделывая ту же работу, которую уже выполнила компания-разработчик фреймворка. Рано или поздно эта дополнительная ручная работа станет столь громоздкой, что её дальнейшее ведение перестанет иметь смысл. Единственным выходом остаётся тотальное переписывание проекта с нуля.
Аудит и документирование
Прежде чем приступить к разработке новой версии сайта, важно составить детальную картину функционала старого сайта, который потребуется воспроизвести. Необходимо подготовить исчерпывающее техническое задание, включающее логическое описание каждого сценария взаимодействия пользователя с сайтом, а также интеграций с внешними сервисами.
Важно помнить, что старая версия существует лишь для изучения и подготовки полноценной документации. Старый код не должен переноситься в новую версию автоматически — иначе перенесутся и старые ошибки вместе с техническим долгом. Задача разработчиков состоит в проведении глубокого анализа существующей реализации, создании актуальной технической документации и последующем отказе от старого кода при работе над новым продуктом.
Разделение frontend и backend как стратегия модернизации сайта
Современная архитектура веб-приложений позволяет эффективно делить проект на две составляющие: frontend (клиентская сторона) и backend (серверная сторона). Эти компоненты представляют собой автономные проекты, обменивающиеся информацией посредством API-интерфейсов. Такая организация процесса даёт возможность организовать разработку двумя отдельными группами инженеров, которые могут независимо друг от друга планировать релизы и оперативные патчи.
Что это означает для полной переработки сайта? Проект можно разбить на два этапа: сначала обновить frontend, затем заняться backend'ом. Такой подход позволяет рационально распределить финансовые вложения и рабочую нагрузку во времени. Вы сможете поэтапно решать ключевые проблемы каждой составляющей, инвестируя деньги небольшими порциями, а не единовременно выделяя крупный бюджет.
1. Переход на современный дизайн
Использование устаревшего дизайна при обновлении интерфейса выглядит нелогичным. Создание нового frontend'a подразумевает одновременное внедрение свежего дизайна. Работа со старыми макетами не принесёт никакой выгоды, будь то верстка или программирование, поэтому лучше объединять обе задачи в одну: новое UI + новый frontend.
2. Избавление от исторических недостатков
Часто в старой версии сайта присутствуют фундаментальные архитектурные изъяны или неудобства в рабочих процессах. Перезапуск проекта предоставляет уникальную возможность избавиться от наследственных ошибок и качественно пересмотреть существующие механизмы, сделав продукт быстрее и удобнее.
3. Улучшение инфраструктуры
Если ваша инфраструктура страдает от частых сбоев, медленной работы серверов или низкого качества услуг провайдера, то миграция на новую платформу в рамках общего проекта оптимизации обойдется дешевле и проще, чем отдельное перемещение инфраструктуры позже. Оптимизацию хостинга и серверов целесообразно объединить с процессом внедрения нового сайта.
Интеграции
Для снижения рисков рекомендуется первоначально запустить новый проект с использованием проверенных и стабильных интеграций, уже используемых в старом варианте. Если планируется глобальное обновление интегрируемых сервисов, отложите замену старых решений на следующие этапы. Каждая новая интеграция потребует периода настройки и отладки, что увеличит вероятность задержек при запуске. Запускаться следует на текущих интеграциях, переход на новые осуществлять постепенно, чтобы избежать двойной нагрузки на разработчиков.
Пользовательский функционал
Чем больше новых функций запланировано на запуск относительно предыдущего сайта, тем выше вероятность задержки сроков. Каждый новый элемент предполагает цикл аналитики, проектирования, оценки рисков, разработки, тестирования и отладки. Ошибки на любом из этапов способны сдвинуть сроки выпуска проекта. Конечно, наличие новых функций желательно, но важно соблюдать баланс между возможностями вашей команды и ожиданиями бизнеса. Функционал, на реализацию которого пока не хватает ресурсов, целесообразнее перенести на следующий этап развития.
Постепенная замена старой версии сайта на новую
Процесс замены действующего сайта на новый требует постепенного подхода, так как перерыв в функционировании ресурса недопустим. Важно учитывать, что появление нового продукта на рынке влечет всплеск жалоб и запросов пользователей, связанных с возникающими дефектами и несовершенствами. Даже самое качественное тестирование не гарантирует отсутствие проблем. Мы предлагаем рассмотреть практичный подход к поэтапному переводу пользователей на новую версию сайта, позволяющий контролировать количество поступающих сообщений и интенсивность загрузки разработчиков.
Опыт нашей компании DDPlanet подтверждает эффективность пошагового введения новой версии сайта, позволяющего плавно перевести пользователей на обновлённую платформу, минимизировав негативные отзывы и риски для бизнеса.
Этап 1. Скрытая ссылка на новый сайт
Создаем незаметную ссылку на новый сайт, размещенную в заголовке или нижней части старого ресурса. Только самые внимательные пользователи заметят её и перейдут на новую версию добровольно. Поскольку посетители сами инициируют переход, они психологически подготовлены к возможным проблемам и воспринимают мелкие дефекты терпимо. Чтобы регулировать количество переходов, выводите ссылку выборочно, например, каждому второму или десятому посетителю главной страницы.
*Примечание: если пользователь однажды кликнул на ссылку, зафиксируйте это событие в cookie и оставляйте ссылку доступной для него впоследствии.
Этап 2. Модальное приглашение на новый сайт
Когда первая волна отзывов по ошибкам отработана, увеличьте приток новых пользователей с помощью более активного призыва — открывающегося модального окна. Контролируйте частоту появления окна: если число жалоб резко возрастет или появятся серьезные проблемы, снизьте интенсивность приглашений или временно откатитесь назад к первому этапу.
*Совет: помните, если пользователь закрыл окно приглашения, не надоедливо выводите его повторно в ближайшее время.
Этап 3. Принудительное перенаправление на новый сайт
Если уверены в готовности к большому объему трафика, начните принудительный редирект пользователей на новую версию. Регулируйте процент перенаправляемых пользователей динамически. Обратите внимание: при отсутствии добровольного согласия пользователи будут воспринимать новый сайт более придирчиво, любая мелочь способна повлиять на восприятие.
Этап 4. Официальный запуск на основном домене
Ваш сайт стабильно функционирует на новой платформе в течение длительного времени (например, минимум две недели), а возникающие ошибки несущественны и затрагивают небольшую долю аудитории. Теперь смело публикуйте новую версию на основном домене. Старую версию оставьте на резервном домене в роли аварийного хранилища. Поздравляю, теперь вы официально перешли в промышленную эксплуатацию!
Этап 5. Завершение эксплуатации старой версии
Спустя месяц-два стабильной работы нового сайта убедитесь, что потребность в возврате к предыдущей версии отпала окончательно. Тогда отключите сервер со старым ресурсом, удалите DNS-запись, снимите ссылку на старую версию с основного сайта. Через некоторое время завершите удаление старого сервера, сохранив архивы: снимок виртуальной машины, копию базы данных и исходники проекта — пусть хранятся в музее вашего ИТ-проекта.
Во время переходного периода нужно обеспечить параллельное функционирование обеих версий сайта. Наиболее удобным вариантом является использование дополнительного субдомена:
- Этап 1–3. Основной сайт доступен по адресу `www.vashdomen.ru`, а новая версия расположена на `new.vashdomen.ru`.
- Этап 4. Старая версия перемещается на `old.vashdomen.ru`, а новая полноценно занимает основное пространство на `www.vashdomen.ru`.
Сохранение последней просмотренной версии
Фиксируйте в cookies последнюю посещённую версию сайта каждым пользователем. Таким образом, при следующем визите его автоматически направляют на ту версию, которую он использовал ранее.
Синхронизация баз данных
Если данные пользователей, заказов или любых других сущностей хранятся раздельно на обоих сайтах (без использования сторонних сервисов), необходима постоянная синхронизация баз данных:
- Одинаковая структура БД: настройка двусторонней репликации обеспечит автоматическое обновление записей.
- Различающаяся структура БД: придётся предусмотреть специальные программные триггеры, отслеживающие события создания, редактирования или удаления данных на обеих версиях сайта.
Контент же проще обновлять вручную на обеих площадках параллельно, так как это не требует сложных технических решений.
*Примечание: значительно упрощает ситуацию хранение ключевых данных в специализированных интегрированных сервисах, а не локальных базах данных самих сайтов.
Если ваши интеграции включают сервисы, которые обращаются к сайту через API, существуют различные подходы к их организации.
Например:
1. Ретрансляция данных. Настройте передачу данных с одного сайта на другой (как описано в предыдущем разделе статьи).
2. Программная ретрансляция запросов. Реализуйте пересылку запросов на стороне исходной точки входа, направляя их на второй сайт.
3. Дополнительная точка входа. Создайте ретранслятор запросов, который будет отправлять внешние запросы на обе версии сайта одновременно.
*Заметка: для определенного типа данных может быть эффективным только одно из предложенных решений. Если данные будут проходить по нескольким маршрутам одновременно, это может привести к дублированию или бесконечному циклу.
Поисковые роботы не должны видеть обе версии сайта одновременно. До активации нового сайта на основном домене закройте его от индексации с помощью простых инструкций в файле robots.txt.
После публикации новой версии на основном домене также закройте старую версию от индексации поисковыми системами. Это простое действие, но его нельзя упустить — поисковые машины могут запомнить вашу ошибку надолго!
Кроме того, новая версия сайта должна пройти полную валидацию вашей SEO-командой до момента публикации на основном домене.
Оставьте свои контакты и мы свяжемся с вами в ближайшее время