Про що запитують у підтримку в перший тиждень після переїзду на сервер
Є закономірність, яку помічає будь-який спеціаліст підтримки: після переїзду проєкту на окремий сервер звернення приходять приблизно в одному й тому ж порядку. Житомирський розробник, який веде кілька клієнтських сайтів, описував свій перший тиждень майже так само, як це виглядає в статистиці будь-якого провайдера. Нижче — ці звернення по черзі, з поясненням причини.
День перший: «листи із сайту не доходять»
Найчастіше звернення взагалі. Причина зазвичай не в сервері, а в налаштуваннях домену: записи, які підтверджують право сервера надсилати пошту від імені вашого домену, залишилися прив’язаними до старого майданчика. Поки вони не оновлені, поштові сервіси складають листи в спам або відхиляють їх.
Перевіряти треба три записи, і робити це краще до перемикання адреси, а не після того, як клієнти перестали отримувати підтвердження замовлень.
День другий: «сайт не може записати файл»
Після копіювання права на теки часто з’їжджають. Сайт не зберігає кеш, не приймає завантажені зображення, не формує тимчасові файли. Лікується виставленням коректних прав — із запису лише там, де він справді потрібен.
Протилежна крайність зустрічається не рідше: права відкриті всім, і це вже питання безпеки, а не зручності.
День третій: «браузер показує попередження»
Сертифікат захищеного з’єднання залишився на старому майданчику або встановлений лише на одну з версій адреси. Відвідувач бачить червоний екран і йде. Перевіряйте обидві версії імені й переконайтеся, що переадресація на захищений протокол увімкнена.
День четвертий: «адмінка повільніша, ніж на старому хостингу»
Несподіваний, але частий випадок. Причина зазвичай у тому, що на новому сервері не увімкнено кеш байт-коду або ресурси виділені з запасом, але сам застосунок налаштований під старі обмеження. Другий варіант — на сервері за замовчуванням стоїть інша версія інтерпретатора.
Саме тому розумно брати віртуальний сервер для сайту з готовим оточенням і панеллю: базові параметри вже виставлені під типові задачі, і ви не витрачаєте перший тиждень на пошук того, що вимкнено за замовчуванням.
День п’ятий: «не працює те, що працювало»
Класика: перенесли файли й базу, але забули про заплановані задачі. Вони живуть окремо й не переїжджають разом із сайтом. У результаті не оновлюються залишки товарів, не йдуть нагадування, не формуються резервні копії. Випишіть перелік таких задач зі старого сервера до міграції.
День сьомий: питання, яке варто поставити першим
«А як мені відновитися, якщо щось зламається?» Правильний час для цього питання — до переїзду, а не після. З’ясуйте, хто робить копії, як часто, скільки їх зберігається і скільки коштує відновлення. Потім розгорніть одну копію на тестовому середовищі й переконайтеся, що вона справді розгортається.
Звернення, якого майже не буває
Показово, чого в цьому списку немає: питань про нестачу потужності. У перший тиждень ресурсів вистачає майже завжди, бо конфігурацію беруть із запасом. Проблеми виникають не через залізо, а через дрібні неузгодженості налаштувань, які непомітні до моменту, коли сайт починає обслуговувати живих відвідувачів.
Саме тому корисно виділити кілька днів на паралельну роботу: новий сервер уже піднятий і працює за тимчасовою адресою, старий ще обслуговує трафік. Усі перелічені звернення в такому режимі перетворюються на буденні правки без нервів і без втрачених замовлень.
Статистика звернень показує, що проєкти, які зробили цю перевірку в перший тиждень, рідше повертаються з аварійними зверненнями через пів року. Не тому, що в них менше збоїв, а тому, що збої перестають бути катастрофою.