Як я переніс продакшн 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. Бекапи налаштовуйте в кілька рівнів. Файли, база, снапшоти. І перевіряйте, що з них реально відновлюється.

Якщо у вас був власний досвід схожих переїздів, радий буду порівняти чек-листи в коментарях.