Переїзд хостингу з даунтаймом: скільки хвилин простою коштує вам грошей і як звести його до нуля

О третій ночі ваш сайт лежить. Клієнти бачать білий екран. Google вже зафіксував недоступність і тихо опускає вас у видачі. А ви сидите перед монітором з чашкою холодної кави і думаєте: «Ми ж просто хотіли переїхати на новий хостинг, чому все зламалось?» Знайома картина? Якщо ні - вам пощастило. Якщо так - ви знаєте, що даунтайм під час міграції хостингу це не технічна дрібниця, а пряма фінансова втрата. І сьогодні ми розберемо, як перенести сайт так, щоб жодна жива душа навіть не помітила переїзду.

Чому простій під час міграції - це не «п'ять хвилинок»

Більшість власників сайтів уявляють переїзд хостингу як переїзд квартири: зібрав коробки, завантажив у машину, розклав на новому місці. Але уявіть, що ваша квартира - це магазин, і поки ви везете товар, двері зачинені. Кожна хвилина без відвідувачів - це гроші, яких ви не побачите.

Давайте порахуємо конкретно. За даними Gartner, середня вартість хвилини даунтайму для бізнесу складає приблизно $5,600. Так, для великих компаній. Але навіть невеликий інтернет-магазин з оборотом 100,000 грн на місяць втрачає близько 140 грн за кожну годину простою. А тепер додайте сюди репутаційні втрати, відмову пошукових систем індексувати сторінки і розчарованих користувачів, які просто підуть до конкурентів.

Головна небезпека міграції - не технічна складність, а ілюзія простоти. Люди думають: «Ну що там, скопіювати файли і базу». А потім з'ясовується, що DNS ще не оновився, база імпортувалась з помилкою, а права на папки злетіли. І ось ви вже сидите з тим холодним кавом о третій ночі.

Шість кроків до міграції з нульовим простоєм

Я провів десятки переїздів хостингу - для себе, для клієнтів, для друзів, яким «ну дуже терміново треба». І виробив алгоритм, який реально працює. Не теоретично, а в полі, коли на кону живий трафік і живі гроші.

1. Повний бекап на старому хостингу. Не «я ж робив місяць тому». Свіжий. Сьогоднішній. І зберігайте його локально, а не лише на сервері, з якого їдете.
2. Розгортання копії сайту на новому хостингу. Завантажуєте файли, імпортуєте базу, перевіряєте через тимчасовий URL або файл hosts. Сайт має працювати на новому сервері ДО будь-яких змін DNS.
3. Тестування на новому сервері. Перевірте все: форми, оплати, авторизацію, швидкість, SSL. Не «ну, головна сторінка відкривається - норм». Перевірте ВСЕ.
4. Зниження TTL записів DNS за 24-48 годин до переїзду. Поставте TTL на 300 секунд (5 хвилин). Це критично - коли прийде час міняти DNS, зміни розлетяться за хвилини, а не за добу.
5. Зміна DNS-записів. Вказуєте A-запис і NS на новий хостинг. Якщо TTL знижений заздалегідь - більшість користувачів побачать новий сервер протягом 5-15 хвилин.
6. Утримання старого хостингу ще 48-72 години. Не вимикайте його одразу! Частина DNS-серверів у світі може ще направляти трафік на стару адресу. Нехай обидва сервери працюють паралельно.

Ось і все. Шість кроків. Жодного простою. Жодної паніки. Якщо виконати їх у правильній послідовності - ваші відвідувачі навіть не зрозуміють, що щось змінилось.

Таблиця порівняння: міграція «на колінці» проти підготовленого переїзду

Щоб ви побачили різницю не на словах, а в цифрах, я склав порівняльну таблицю двох підходів. Один - «ну, якось само вийде». Другий - з підготовкою за алгоритмом вище.

Бачите різницю? Два-три дні підготовки рятують вас від годин (іноді - днів) простою. Інвестиція часу, яка окупається миттєво.

Бази даних: місце, де ховається 80% катастроф

Файли сайту - це зазвичай проста справа. Скопіював через SFTP або архівом - готово. А ось бази даних MySQL або PostgreSQL - це зовсім інша історія. Саме тут ламається більшість міграцій.

Чому? Тому що база - живий організм. Поки ви робите дамп на старому сервері, користувачі продовжують писати коментарі, оформляти замовлення, реєструватись. І між моментом експорту та моментом перемикання DNS виникає вікно, коли дані на двох серверах розходяться.

«Найбільша помилка при міграції - це думати, що база даних статична. Вона змінюється кожну секунду, і якщо ви не синхронізуєте останню милю, ви втрачаєте транзакції.» - Percona, Database Performance Blog

Що робити? Ось перевірений підхід для сайтів з активною базою:

• Зробіть перший імпорт бази заздалегідь - за день-два до перемикання DNS
• Безпосередньо перед зміною DNS зробіть інкрементальний дамп - тільки нові записи за останні години
• Для інтернет-магазинів: увімкніть «режим обслуговування» на 2-3 хвилини, зробіть фінальний дамп і перемкніть DNS
• Перевірте кодування (utf8mb4!) - класика жанру, коли після міграції замість тексту з'являються кракозябри
• Не забудьте оновити конфігураційний файл (wp-config.php, .env) з новими реквізитами підключення до бази

Ці п'ять пунктів запобігають 80% усіх проблем при переїзді. Не перебільшую - саме 80%.

Інструменти, які зроблять брудну роботу за вас

Ви не зобов'язані робити все вручну. Серйозно. Є інструменти, які автоматизують процес і мінімізують людський фактор - а саме він зазвичай і є причиною збоїв.

Для WordPress - плагіни All-in-One WP Migration або Duplicator. Перший працює за принципом «натиснув кнопку - отримав архів», другий дає більше контролю. Обидва справляються з базами до 1-2 ГБ без проблем. Для великих сайтів краще WP-CLI або ручний перенос.

Для сайтів на CMS (Joomla, Drupal, OpenCart) - Akeeba Backup (Joomla), Backup and Migrate (Drupal) або спеціалізовані модулі. Але чесно? Для не-WordPress часто простіше і надійніше робити перенос вручну через SSH.

Для будь-яких сайтів - rsync через SSH. Це як копіювання файлів, тільки розумне: передає лише змінені файли. При повторній синхронізації перед перемиканням DNS - процес займе секунди, а не години. Команда виглядає приблизно так: rsync -avz --progress user@old-server:/path/ /new-path/

Золоте правило: автоматизуйте все, що можна автоматизувати, але завжди перевіряйте результат вручну. Плагін може повідомити «успіх», а на сайті - білий екран. Довіряй, але перевіряй.

Що робити, якщо все пішло не за планом

План Б - це не розкіш, а необхідність. Навіть з ідеальною підготовкою щось може піти не так. Сервер нового хостера може лягти саме у момент вашої міграції (так, таке буває). Або PHP-версія відрізняється, і половина функціоналу не працює.

Ось ваш план евакуації:

1. Не видаляйте нічого на старому хостингу мінімум 72 години після переїзду. Це ваша страховка.
2. Тримайте під рукою старі DNS-записи. Якщо новий хостинг підвів - поверніть DNS назад за 5 хвилин. Якщо TTL низький, відкат буде майже миттєвим.
3. Моніторте сайт перші 24 години. UptimeRobot (безкоштовний) або Hetrixtools пришлють SMS, якщо сайт впаде.
4. Перевірте логи помилок на новому сервері. Більшість проблем видно у error.log ще до того, як їх помітять користувачі.

Пам'ятайте: відкат - це не поразка. Це розумне рішення. Краще відкотитись, розібратися з проблемою у спокійній обстановці і повторити міграцію через день, ніж героїчно «лагодити на живому» і зламати ще більше.

Міграція - це не подія, а процес

Найбільша ментальна пастка: сприймати переїзд хостингу як одну дію. «Ось зараз сяду і перенесу». Ні. Міграція - це процес з трьома чіткими фазами: підготовка (2-3 дні), виконання (1-2 години) і контроль (2-3 дні після). Загалом - тиждень. Тиждень, який рятує вам місяці нервів.

І ще одна думка наостанок. Я бачив десятки переїздів, де люди втрачали трафік, замовлення, іноді - цілі бази клієнтів. І жодного разу причиною не була складність технології. Причиною завжди була поспішність. Хтось вирішив «перенести за вечір», хтось «забув зробити бекап», хтось «не думав, що DNS так довго оновлюється».

Тож запитайте себе: ви готові витратити три дні на підготовку - чи три тижні на відновлення після невдалого переїзду? Відповідь, здається, очевидна. Але чомусь щоразу знаходяться ті, хто обирає другий варіант.