Как я перевёз продакшн EduSystem на HyperHost без даунтайма

Скажу честно: переезд продакшна я не люблю. За 12+ лет работы с IT-инфраструктурой я провёл достаточно миграций, чтобы знать, что «просто перенести сервер» не бывает. Работающая платформа, которой каждый день пользуются реальные люди, похожа на самолёт в полёте: менять двигатель приходится, не приземляясь.

В ночь с 5 на 6 сентября 2026 года мы перевезли продакшн EduSystem с DigitalOcean на VDS от HyperHost. Пользователи ничего не заметили. Данные не потерялись. Никто не написал в поддержку «а что случилось». Для миграции это лучшая оценка.

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

Зачем вообще было переезжать

Мигрировать без причины никто не станет. Слишком дорого и слишком рискованно.

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

Что именно мы перевозили:

• backend на Laravel/PHP
• frontend на Vue 3
• MySQL и Redis
• видео-инфраструктуру, работающую через очереди

Это не лендинг и не блог. Здесь десятки связей между компонентами, и любая может сломаться при переезде так, что заметишь это только через сутки.

Почему HyperHost, и почему я благодарен Юрию

С HyperHost я работаю с 2014 года, сейчас я их партнёр. Поэтому когда встал вопрос о новом доме для EduSystem, первым делом написал им. Ожидал стандартного сценария: вот тарифы, выбирайте, вот инструкция. Получилось иначе, и именно поэтому этот раздел есть в статье.

Со мной работал Юрий. Вот что он сделал, и почему это важно.

Сначала слушал, потом предлагал. Юрий не начал с прайса. Он разобрался в ситуации, выслушал и задавал вопросы, причём правильные: какой у нас стек, как была устроена предыдущая инфраструктура, где узкие места, какие нагрузки. Я сам много лет провожу discovery-сессии с клиентами и сразу вижу разницу между «продать тариф» и «понять задачу». Здесь было второе.

Сам подобрал конфигурацию и объяснил почему. Получив картину, Юрий предложил конкретную конфигурацию сервера и аргументировал, почему именно она подходит нашему проекту. Отдельно он заложил задел на будущее: конфигурация рассчитана не только на текущую нагрузку, но и на рост. Для меня это ключевой момент. Инфраструктуру, которую через полгода придётся переделывать, проще вообще не строить.

Предложил условия, о которых я не просил. Я работаю с HyperHost с 2014 года, и казалось бы, удивить меня уже сложно. Но Юрий сам, без моей инициативы, предложил выгодные условия и ряд бонусов и для меня, и для проекта. Для меня это говорит об одном: команда работает не на объём продаж, а на долгие отношения с клиентом.

Держал руку на пульсе во время переезда. Юрий контролировал процесс настройки и перехода и сразу сказал: если понадобятся дополнительные ресурсы или помощь, они готовы подключиться. Когда ты проводишь ночной cutover продакшна, знание, что за спиной есть живой человек, а не очередь тикетов, стоит очень дорого. Даже если в итоге помощь не понадобится.

Юрий, спасибо. Это был тот уровень сервиса, который я сам стараюсь давать своим клиентам.

Подготовка: миграция выигрывается до cutover

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

Что мы сделали заранее:

• Аудит инфраструктуры. Прошлись по чек-листу из нескольких десятков пунктов: окружение, сервисы, фоновые задачи, зависимости между компонентами, расписания. Задача аудита — найти то, что «тихо работает годами, и никто не помнит, зачем оно». Именно такие вещи ломаются при переезде первыми.
• Staging на новой инфраструктуре. Развернули полную копию и прогнали через неё реальные сценарии, от загрузки видео до обработки очередей. Здесь же ловили различия в окружении, которые на бумаге не видны.
• Сверка версий кода. Проверили, что на staging и в продакшн уходит одно и то же. Звучит банально, но разъехавшиеся ветки — одна из самых частых причин сюрпризов при переезде.
• План отката. Не «если что, вернём как было», а пошаговый сценарий: что делаем, в каком порядке, кто за что отвечает.

К последнему пункту я ещё вернусь, потому что он оказался главным уроком всей истории.

Cutover: ночь, DNS и первые пользователи

Переключались ночью. Не потому что «так принято», а потому что это простая математика риска: если что-то пойдёт не так, пострадает минимум людей.

Дальше всё прошло так, как и должен проходить хорошо подготовленный переезд. Через несколько минут после переключения DNS мы уже видели живых пользователей, работающих на новой инфраструктуре. Без потери данных. Без даунтайма для клиентов.

Признаюсь, момент, когда видишь первых пользователей на новом сервере, всё равно волнительный, сколько бы миграций ты ни провёл.

Главный урок: откат — это не одна кнопка

Этот момент я бы советовал запомнить каждому, кто планирует переезд.

Многие думают об откате как о кнопке «вернуть как было»: поменял DNS обратно, и готово. На практике откат инфраструктуры — это всегда комплекс синхронных действий. DNS, режим SSL, серверные задачи должны меняться согласованно, как единое целое.

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

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

Что получили в итоге

• Стабильная работа. Платформа работает без инцидентов с момента cutover.
• Полноценная схема бэкапов. Отдельно файлы, отдельно база данных, плюс снапшоты сервера. Три уровня защиты, каждый закрывает свой сценарий потери.
• Полная независимость. Инфраструктура, доступы и процессы теперь под нашим прямым контролем и понятны до последнего пункта.
• Запас на рост. Конфигурация подбиралась с прицелом на будущее, поэтому масштабирование не потребует нового переезда.

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

Ради чего всё это затевалось

Пару слов о самом продукте, чтобы было понятно, почему для меня стабильность — не абстрактная метрика.

EduSystem — технологический партнёр для тех, кто хочет запустить свой образовательный проект. Мы не продаём «коробку» и не оставляем человека один на один с настройками: наша команда сама разворачивает платформу под бренд партнёра, настраивает её и остаётся рядом, когда проект начинает расти. Брендироваться может любой сервис. Для нас важнее, чтобы партнёр мог спокойно масштабироваться и не упирался в технические ограничения.

Именно поэтому надёжная инфраструктура для нас — часть обещания, которое мы даём каждому, кто строит с нами свой проект.

Если вы тоже думаете о переезде

Короткая выжимка из этого кейса:

1. Выбирайте не тариф, а людей. Спросите себя, будет ли у вас живой контакт в момент миграции. В моём случае это оказалось решающим.
2. Аудит и staging обязательны. Это не «если останется время», а основа плана.
3. План отката пишите заранее и по шагам. И помните, что откат — это набор синхронных действий, а не одна кнопка.
4. Переключайтесь в часы минимальной нагрузки. Даже когда уверены, что всё готово.
5. Бэкапы настраивайте в несколько уровней. Файлы, база, снапшоты. И проверяйте, что из них реально восстанавливается.

Если у вас был свой опыт похожих переездов, буду рад сравнить чек-листы в комментариях.