Сайт ліг і не встає: що робити в перші 10 хвилин, коли хостинг підвів

Ви відкриваєте свій сайт - а там білий екран. Або 502. Або взагалі нічого. Браузер крутить значок завантаження, наче медитує. Серце починає битися швидше, долоні пітніють, а в голові вже крутиться думка: «Все зламалося, бізнес закінчився, клієнти пішли до конкурентів». Знайомо? Я бачив такі обличчя десятки разів. І ось що скажу - перші 10 хвилин після падіння сайту визначають, чи втратите ви години або лише хвилини. Ця стаття - ваш план дій, коли хостинг раптом вирішив взяти вихідний без попередження.

Перше правило кризи: не чіпайте нічого, поки не зрозуміли що зламалось

Коли пожежник приїжджає на виклик, він не починає лити воду на сусідній будинок. Він оцінює ситуацію. З хостингом - так само. Найгірше, що ви можете зробити в перші хвилини - це хаотично перезавантажувати сервер, видаляти файли, міняти DNS-записи чи писати гнівний тікет провайдеру з текстом «ВСЕ НЕ ПРАЦЮЄ!!!».

Перші 60 секунд - це діагностика, а не паніка. Відкрийте блокнот (справжній або цифровий) і почніть фіксувати симптоми. Що саме не працює? Весь сайт чи окремі сторінки? Яку помилку показує браузер? Чи відкривається панель хостингу? Чи працюють інші сайти на тому ж сервері?

Ось мінімальний чеклист для перших 60 секунд:

1. Перевірте сайт з мобільного інтернету (не з вашого Wi-Fi) - можливо, проблема у вашого провайдера
2. Відкрийте isitdownrightnow.com або downforeveryoneorjustme.com - це покаже, чи лежить сайт для всього світу
3. Зайдіть в панель хостингу (cPanel, Plesk, DirectAdmin) - якщо вона відкривається, сервер живий
4. Перевірте пошту - хостер міг надіслати повідомлення про технічні роботи
5. Гляньте статус-сторінку хостинг-провайдера - у більшості є status page

Розшифровка помилок: що сайт намагається вам сказати

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

Бачите 403? Перше, що перевіряйте - файл .htaccess. Перейменуйте його на .htaccess_backup через файловий менеджер і оновіть сторінку. Якщо сайт ожив - вітаю, ви знайшли винуватця за 30 секунд. 500-ка? Увімкніть відображення помилок PHP (якщо це dev-середовище) або загляньте в error_log. Цей файл - ваш найкращий друг під час кризи.

Логи сервера: ваш чорний ящик після «катастрофи»

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

У cPanel логи помилок знаходяться в розділі Errors або через файловий менеджер у файлі error_log в кореневій папці сайту. У Plesk - Logs у розділі вашого домену. А якщо у вас VPS з SSH-доступом, то шукайте в /var/log/apache2/error.log або /var/log/nginx/error.log.

«80% інцидентів на хостингу вирішуються за 15 хвилин, якщо адміністратор вміє читати логи. Решта 20% - коли він їх навіть не відкриває.» - Олександр Горбенко, DevOps-інженер з 12-річним досвідом

Що шукати в логах? Конкретні рядки з мітками [error] або [crit]. Часто ви побачите щось на кшталт «PHP Fatal error: Allowed memory size of 134217728 bytes exhausted» - і це прямо вказує на причину. Пам'ять закінчилась. Збільшуєте ліміт в php.ini або wp-config.php - і сайт дихає знову.

Ось топ причин, які я знаходив у логах за 15 років:

• Вичерпана пам'ять PHP - плагін або скрипт з'їв все, що було
• Зламаний .htaccess - один зайвий символ після оновлення плагіну
• Переповнена база даних - мільйон записів у таблиці wp_options від кривих плагінів
• Досягнутий ліміт процесів - на shared-хостингу ви ділите ресурси з сусідами
• Зловмисний код - хтось вже господарює у ваших файлах

Коли винен хостер, а коли - ви самі

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

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

Ви винні, якщо: нещодавно оновлювали WordPress, плагіни чи тему, редагували файли вручну, встановили щось нове, або сайт став популярним і перевищив ліміти тарифу. Перевірте - чи не збігається час падіння з часом вашої останньої дії? У 70% випадків сайт лягає саме після «я тут трохи підправив».

Золоте правило: завжди робіть бекап перед будь-якими змінами. Навіть «маленькими». Особливо «маленькими». Тому що саме «я тільки один рядок поміняв» перетворюється на ніч без сну.

Покрокова реанімація: від білого екрану до працюючого сайту

Добре, ви зібрали симптоми, подивились логи, зрозуміли приблизну зону проблеми. Тепер - конкретні дії. Я розставив їх від простого до складного, тому що у більшості випадків перші три кроки вирішують проблему.

1. Перезавантажте PHP та очистіть кеш - у панелі хостингу знайдіть «Select PHP Version» або «PHP Manager» і натисніть «Restart». Якщо є кешуючий плагін - спробуйте видалити вміст папки /wp-content/cache/
2. Перейменуйте .htaccess - через файловий менеджер або FTP змініть назву на .htaccess_old. Оновіть сайт. Якщо ожив - зайдіть в Налаштування > Постійні посилання в WordPress і просто збережіть. Новий .htaccess згенерується автоматично
3. Вимкніть плагіни масово - перейменуйте папку /wp-content/plugins/ на /wp-content/plugins_off/. Всі плагіни деактивуються миттєво. Сайт ожив? Повертайте назву і вмикайте плагіни по одному, щоб знайти винного
4. Збільшіть ліміт пам'яті - додайте в wp-config.php рядок: define('WP_MEMORY_LIMIT', '256M');
5. Перевірте базу даних - у phpMyAdmin запустіть «Repair table» для основних таблиць WordPress
6. Відновіть з бекапу - якщо нічого не допомогло, це ваша остання лінія оборони. Тому бекапи й мають існувати

Як спілкуватися з техпідтримкою, щоб вам реально допомогли

Тут окрема наука. Я бачив тисячі тікетів і можу сказати точно: якість вашого запиту визначає швидкість відповіді. Повідомлення «Сайт не працює, виправте!!!» потрапляє в чергу з низьким пріоритетом. А от структурований тікет - обробляється вдвічі швидше.

Ідеальний тікет містить:

• Назву домену та точний час, коли почалась проблема
• Код помилки (403, 500, 502 - конкретика)
• Що ви вже перевірили та спробували
• Скріншот помилки та уривок з error_log

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

І ще одна порада, яку мало хто використовує. Зателефонуйте. Серйозно. Якщо у хостера є телефон підтримки - дзвоніть. Тікети чекають у черзі. Дзвінок - ні. За моїм досвідом, телефонний дзвінок скорочує час вирішення проблеми в 3-5 разів.

Ваш сайт колись ляже. Не «якщо», а «коли». Це не песимізм - це статистика. Навіть Amazon падав у 2023 році на 2 години. Різниця між професіоналом і новачком не в тому, що у першого нічого не ламається. А в тому, що він знає, де шукати і що робити, коли це станеться. Тепер знаєте і ви. Питання одне - чи збережете ви цю статтю в закладки до того, як вона вам знадобиться, чи будете шукати її в паніці о третій ночі?