Вступ
Компанія розміщує рекламу на сайті. Згідно зі статистикою, кліки є, але частина користувачів не доходить до форми заявки. Зовні проблема виглядає нестабільною: сайт то відкривається, то довго завантажується, то видає помилку, то браузер показує попередження щодо SSL.
Для бізнесу це неприємна ситуація: рекламний бюджет уже витрачено, а частина трафіку фактично потрапляє у технічний глухий кут. Найпоширеніша помилка — обмежитися ручним перезапуском і вважати завдання виконаним. Це може відновити роботу сайту на кілька годин, але не пояснює, чому виникла проблема.
Що перевіряється в першу чергу
- домен та DNS: куди вказує запис, чи немає старих IP-адрес та записів, що конфліктують;
- SSL: правильність сертифіката, ланцюжок, термін дії, перенаправлення HTTP/HTTPS;
- веб-сервер: відповіді nginx/apache, коди 500/502/504, помилки проксі-сервера;
- PHP та CMS: фатальні помилки, плагіни, тема, обмеження пам’яті, оновлення;
- хостинг та ресурси: місце на диску, пам’ять, процесор, ліміти процесів;
- резервні копії: чи є точка відновлення та чи можна швидко повернутись до попереднього стану;
- моніторинг: хто і як дізнається, що сайт знову не працює.
Хід робіт
Спочатку проводиться зовнішня перевірка без доступу: відкривається сайт за різними URL-адресами, перевіряються заголовки, перенаправлення, SSL та базова доступність. Це дозволяє з’ясувати, чи проблема лежить на рівні домену, сертифіката, веб-сервера чи додатка.
Після цього вже запитуються мінімальні права доступу: до панелі хостингу, логів веб-сервера, WordPress або сервера. Права доступу потрібні не «про всяк випадок», а для конкретної перевірки.
У логах зазвичай шукають повторювані ознаки: конкретну фатальну помилку PHP, нестачу пам’яті, неправильний цикл перенаправлення, помилку підключення до бази даних, конфлікт плагіна, збій PHP‑FPM, неправильне налаштування SSL або проблему з проксі.
Що вважається нормальним результатом
Хороший результат — це не просто «сайт зараз завантажився». Нормальний результат виглядає так:
- виявлено ймовірну причину збою;
- внесено конкретні зміни;
- перевірено основні URL-адреси, форму заявки та SSL;
- є розуміння, що робити у разі повторення;
- за необхідності додано моніторинг доступності;
- власник розуміє, які ризики залишилися.
Висновок
Сайт, який періодично виходить з ладу, не можна вирішувати лише перезапуском. Якщо на сайті розміщується реклама, технічна нестабільність безпосередньо призводить до втрачених заявок. Тому завдання має вирішуватися не «відновленням роботи сторінки», а діагностикою причини, фіксацією змін та мінімальним контролем повторення.