Сайт перестав відкриватися. Власник пише хостингу — там відповідають, що сервер працює нормально. Розробник каже, що проблема на сервері. У результаті сайт не працює, а відповідального знайти неможливо.
Такі ситуації виникають через просту причину: поняття «технічна підтримка сайту» часто використовують для абсолютно різних послуг.
Хостинг-провайдер підтримує серверну інфраструктуру. Розробник працює з кодом і CMS. Системний адміністратор відповідає за серверне середовище. А частина завдань взагалі залишається відповідальністю власника сайту.
Коротко: хто за що відповідає
| Проблема | До кого звертатися |
|---|---|
| Сервер недоступний | Хостинг |
| Закінчився дисковий простір | Хостинг / адміністратор |
| Не працює плагін WordPress | Розробник |
| Помилка після оновлення CMS | Розробник |
| Потрібно налаштувати PHP-FPM на VPS | Системний адміністратор |
| Сайт заражений | Спеціаліст із безпеки / розробник |
| Не працює DNS | Хостинг або реєстратор домену |
| Потрібно змінити текст чи товар | Контент-менеджер / власник |
На практиці межі можуть відрізнятися залежно від договору, але ця таблиця добре показує загальну логіку.
Що зазвичай робить технічна підтримка хостингу
Хостинг відповідає насамперед за інфраструктуру, на якій працює сайт.
До його зони відповідальності можуть належати:
- робота фізичних серверів;
- мережеве підключення;
- доступність хостинг-панелі;
- робота системного ПЗ на shared-хостингу;
- створення резервних копій, якщо вони входять у тариф;
- DNS-сервіси;
- базові налаштування SSL;
- контроль серверної інфраструктури.
Якщо одночасно перестали працювати десятки сайтів на одному сервері, проблема майже напевно знаходиться саме на цьому рівні.
Що хостинг зазвичай не зобов’язаний виправляти
Ось тут у власників сайтів часто виникають неправильні очікування.
Хостинг може підтвердити, що PHP працює, але не зобов’язаний шукати, чому конкретний WordPress-плагін викликає fatal error.
До завдань розробника, а не провайдера, зазвичай належать:
- конфлікти плагінів;
- помилки теми;
- зламаний checkout;
- несправний модуль OpenCart;
- помилки JavaScript;
- невдала кастомізація;
- помилки після оновлення CMS;
- повільні SQL-запити, створені кодом сайту.
Приклад: сайт показує 502 Bad Gateway
На перший погляд це серверна помилка. Але причин може бути декілька.
Наприклад:
- зупинився PHP-FPM — серверний рівень;
- закінчилася RAM — серверний рівень;
- плагін створює нескінченний процес — рівень сайту;
- важкий SQL-запит зависає — рівень застосунку або бази;
- неправильно налаштований nginx — адміністрування сервера.
Тому код помилки ще не визначає відповідального.
Докладніше причини ми розбирали у матеріалі про помилку 502 Bad Gateway.
Що входить у нормальну технічну підтримку сайту
Якщо бізнес замовляє окрему послугу підтримки сайту, вона має бути значно ширшою за підтримку хостингу.
Контроль працездатності
Потрібно регулярно перевіряти:
- чи відкривається сайт;
- чи працює адміністративна панель;
- чи працюють форми;
- чи оформлюються замовлення;
- чи надходить пошта;
- чи немає критичних PHP-помилок.
Оновлення CMS
WordPress, OpenCart та інші системи потрібно підтримувати в актуальному стані.
Але правильна підтримка — це не кнопка «оновити все».
Перед важливими оновленнями необхідно:
- створити резервну копію;
- перевірити сумісність;
- за можливості протестувати зміни на staging;
- виконати оновлення;
- перевірити ключові функції сайту.
Контроль плагінів і модулів
Непотрібні розширення потрібно видаляти, а не накопичувати роками.
Особливу увагу слід приділяти компонентам, які:
- більше не підтримуються;
- мають відомі вразливості;
- несумісні з новими версіями PHP;
- створюють високе навантаження.
Резервні копії — це частина підтримки, а не страховка «на всяк випадок»
Бекап потрібен не лише після злому.
Він може врятувати сайт після:
- невдалого оновлення;
- видалення даних;
- помилки розробника;
- пошкодження бази;
- зараження;
- невдалої міграції.
Для комерційного сайту бажано мати не одну, а декілька точок відновлення.
При цьому потрібно періодично перевіряти, що резервна копія дійсно відновлюється. Наявність архіву ще не означає, що він придатний для використання.
Моніторинг швидкості
Сайт може залишатися доступним, але поступово ставати повільнішим.
Причинами можуть бути:
- зростання бази даних;
- нові плагіни;
- накопичення логів;
- перевищення ресурсів;
- зростання кількості товарів;
- зміна характеру трафіку.
Тому технічна підтримка повинна хоча б періодично контролювати час відповіді сервера та поведінку ресурсоємних сторінок.
Якщо сайт починає відповідати повільніше, корисно провести діагностику TTFB, а не одразу купувати дорожчий тариф.
Безпека сайту
Хостинг захищає свою інфраструктуру, але він не може повністю контролювати код вашого сайту.
На стороні самого проєкту потрібно:
- оновлювати CMS;
- видаляти непотрібні компоненти;
- використовувати складні паролі;
- обмежувати адміністративні доступи;
- контролювати появу нових користувачів;
- перевіряти підозрілі файли;
- мати актуальні бекапи.
Після підозрілої активності потрібно виконати перевірку сайту на шкідливий код.
Хто повинен стежити за SSL
На shared-хостингу автоматичне продовження безкоштовного SSL часто забезпечує провайдер або панель.
Але власнику все одно потрібно контролювати результат.
Сертифікат може перестати оновлюватися через:
- зміну DNS;
- проблему з доменом;
- помилку перевірки;
- CDN;
- некоректну конфігурацію вебсервера.
Для бізнес-сайту краще дізнатися про проблему моніторингом, а не від клієнта, який побачив повідомлення браузера.
Хто відповідає за домен
Це ще одна зона, про яку часто забувають.
Домен може бути зареєстрований зовсім не там, де знаходиться сайт.
Потрібно контролювати:
- дату продовження;
- контактний email;
- доступ до кабінету реєстратора;
- DNS;
- двохфакторну авторизацію.
Втрата доступу до домену може бути значно серйознішою проблемою, ніж збій хостингу.
Особливості підтримки WordPress
Для WordPress основний технічний цикл виглядає приблизно так:
- оновлення ядра;
- оновлення плагінів;
- контроль теми;
- перевірка PHP;
- бекапи;
- оптимізація бази;
- контроль безпеки;
- перевірка форм;
- контроль кешування.
Проблема старих WordPress-сайтів полягає в тому, що одне оновлення часто тягне за собою інше. Наприклад, нова версія плагіна потребує новішого PHP, а стара тема з ним уже несумісна.
Саме тут регулярне обслуговування дешевше й безпечніше, ніж велике оновлення раз на п’ять років.
Особливості підтримки OpenCart
У магазині OpenCart перевіряти потрібно значно більше бізнес-процесів.
Після технічних змін обов’язково тестуються:
- категорії;
- фільтри;
- пошук;
- сторінка товару;
- кошик;
- checkout;
- оплата;
- доставка;
- листи;
- CRM або обмін із системою обліку.
Те, що головна сторінка відкривається, ще не означає, що магазин працює.
Чим підтримка VPS відрізняється від підтримки shared-хостингу
Це принципово важливий момент.
На shared-хостингу більшу частину серверної роботи бере на себе провайдер.
На unmanaged VPS власник може сам відповідати за:
- оновлення Linux;
- nginx або Apache;
- PHP-FPM;
- MySQL;
- фаєрвол;
- резервне копіювання;
- моніторинг;
- безпеку SSH.
Тому дешевий VPS без адміністратора може виявитися дорожчим і ризикованішим за хороший shared-тариф.
Managed VPS: коли це має сенс
Managed-рішення корисне, коли сайт уже потребує VPS, але власник не хоче самостійно адмініструвати Linux.
Перед покупкою потрібно з’ясувати, що конкретно означає слово managed у конкретного провайдера.
Наприклад, чи входить:
- налаштування вебсервера;
- оновлення системи;
- моніторинг;
- backup;
- аналіз аварій;
- допомога з базою даних.
Що не повинно входити у звичайну технічну підтримку
Потрібно відділяти підтримку від розвитку сайту.
Новий функціонал — це вже розробка.
Наприклад:
- нова система фільтрації;
- інтеграція CRM;
- редизайн;
- новий особистий кабінет;
- розробка калькулятора;
- підключення нового API.
Якщо зміни вимагають проєктування, програмування та тестування нового функціоналу, їх правильніше оцінювати окремим завданням.
Ситуація №1: сайт повністю недоступний
Порядок дій:
- перевірити, чи працює сервер;
- перевірити DNS;
- перевірити SSL;
- подивитися HTTP-код;
- переглянути error log;
- перевірити ресурси;
- лише потім переходити до CMS.
Ситуація №2: сайт працює, але повільно
Тут немає сенсу одразу писати хостингу «зробіть сайт швидшим».
Потрібно визначити:
- TTFB;
- CPU;
- RAM;
- повільні SQL-запити;
- плагіни;
- зовнішні API;
- розмір сторінки;
- кеш.
Лише після цього можна зрозуміти, чи потрібна оптимізація коду або сильніший сервер.
Ситуація №3: сайт зламали
Нормальна технічна підтримка не повинна просто видалити знайдений вірус і закрити заявку.
Потрібно:
- зберегти поточний стан;
- визначити заражені файли;
- знайти точку проникнення;
- очистити сайт;
- оновити вразливий компонент;
- змінити доступи;
- перевірити cron;
- повторно просканувати систему.
Якою повинна бути підтримка бізнес-сайту
Для комерційного проєкту хороший мінімум виглядає так:
| Завдання | Періодичність |
|---|---|
| Контроль доступності | Постійно |
| Резервні копії | Щодня або за потребою бізнесу |
| Перевірка оновлень | Регулярно |
| Перевірка основних функцій | Після кожної зміни |
| Безпековий аудит | Періодично та після інцидентів |
| Контроль ресурсів | Регулярно |
| Аналіз критичних помилок | При появі |
П’ять запитань до підрядника перед замовленням підтримки
- Що саме входить у щомісячну підтримку?
- Хто відповідає за резервні копії?
- Що відбувається, якщо сайт падає в неробочий час?
- Чи тестуються оновлення перед production?
- Де закінчується підтримка і починається оплачувана окремо розробка?
Чим чіткіші відповіді на ці питання, тим менше конфліктів виникне після першої серйозної проблеми.
Коли підтримка сайту ще не потрібна
Для простого статичного проєкту, який майже не змінюється і не виконує бізнес-критичних функцій, щомісячне комплексне обслуговування може бути надлишковим.
Але навіть у такому випадку потрібно:
- продовжувати домен;
- мати бекап;
- контролювати SSL;
- оновлювати CMS, якщо вона використовується.
Сигнали, що регулярна підтримка вже потрібна
- сайт приносить заявки або продажі;
- використовується WordPress або OpenCart із багатьма модулями;
- працюють платіжні системи;
- є CRM та зовнішні інтеграції;
- запущена реклама;
- простій сайту коштує бізнесу грошей;
- ніхто регулярно не перевіряє оновлення та бекапи.
Висновок
Технічна підтримка сайту — це не одна універсальна служба, яка відповідає за все.
Хостинг забезпечує інфраструктуру. Розробник відповідає за CMS і код. Системний адміністратор — за керований сервер. Власник — за доступи, домен та організацію процесу.
Найкраща схема виникає тоді, коли ці зони відповідальності визначені заздалегідь. Тоді при проблемі не потрібно годинами з’ясовувати, кому писати: кожен знає свою частину системи, а сайт швидше повертається до нормальної роботи.
