Содержание:
Когда коммерческий сайт перестаёт работать, главная задача владельца бизнеса — не угадать техническую причину, а быстро ограничить потери и передать подрядчику проверяемые данные. Беспорядочные перезапуски, обновления и откаты часто стирают следы сбоя, создают новые ошибки или уничтожают заказы, которые появились после последней резервной копии.
Ниже — план именно для владельца или руководителя проекта. Он не заменяет диагностику сервера, но помогает правильно провести первые минуты инцидента, не ухудшить ситуацию и быстрее получить результат от технической команды.
Первые 5 минут: подтвердите масштаб проблемы
Сначала исключите локальную неисправность. Откройте сайт с телефона через мобильную сеть, проверьте несколько страниц и административную часть, попросите коллегу повторить проверку из другого города или используйте внешний сервис доступности. Зафиксируйте точное время и часовой пояс.
Важно определить, что именно не работает: весь домен, отдельная страница, форма, корзина, личный кабинет, API или только административная панель. Фраза «сайт лежит» для разработчика слишком общая; скриншот, URL, код ответа и последовательность действий сокращают диагностику.
| Что наблюдаем | Что зафиксировать | Кому передать |
|---|---|---|
| Сайт не открывается нигде | URL, время, текст ошибки, результат с мобильной сети | Хостингу и технической команде |
| Главная работает, форма не отправляется | Страницу, поля без персональных данных, время попытки | Разработчику и ответственному за CRM |
| Корзина работает, оплата не проходит | Номер тестового заказа, этап, ответ платёжного сервиса | Разработчику и платёжному провайдеру |
| Проблема только у части посетителей | Город, провайдера, устройство, DNS или CDN | Администратору инфраструктуры |
| Админка недоступна, публичная часть работает | Текст ошибки и последнее действие | Разработчику CMS |
Что нельзя делать до диагностики
Не обновляйте CMS и плагины, не удаляйте файлы, не очищайте все таблицы, не переключайте DNS и не восстанавливайте вчерашний архив только потому, что он есть. Не запускайте многократно импорт, оплату или отправку заказа: повторная операция может создать дубли.
Не публикуйте в открытом чате пароли, дампы базы, ключи платёжной системы и персональные данные клиентов. Передавайте доступы через согласованный защищённый канал и после инцидента меняйте временные пароли.
Перезапуск сервера допустим как контролируемая мера, когда специалист уже собрал необходимые логи и понимает ожидаемый эффект. Если перезапуск «лечит» сайт на час, это симптом, а не устранение причины.
Первые 15 минут: заведите карточку инцидента
Даже для небольшого бизнеса полезна короткая карточка: когда заметили сбой, что видят пользователи, какие изменения были перед ним, кто отвечает за техническую часть и какие действия уже выполнены. В неё же записывают решения и время восстановления.
| Поле | Пример полезной записи |
|---|---|
| Начало | 09:42 МСК, сообщение менеджера отдела продаж |
| Влияние | Не открываются карточки и корзина, главная доступна |
| Последнее изменение | В 09:15 завершился импорт остатков из 1С |
| Проверка | Ошибка повторяется с двух сетей, HTTP 500 |
| Действия | Рекламные кампании приостановлены в 09:51, сервер не перезапускали |
| Контакты | Ответственный со стороны бизнеса и дежурный подрядчика |
Такая фиксация особенно важна при плавающей ошибке. Когда сайт сам восстановится, команда сможет сопоставить время сбоя с запросами, импортом, исчерпанием памяти или ответом внешнего API.
Как временно сократить потери бизнеса
Если сайт получает платный трафик, разумно временно остановить кампании, ведущие на неработающие страницы. Для корпоративного сайта можно направить обращения на телефон или резервную форму. Для магазина решение сложнее: нельзя принимать оплату, если заказ не фиксируется надёжно.
Иногда команда включает заранее подготовленную статическую страницу с контактами и сообщением о технических работах. Она должна находиться отдельно от неисправного приложения. Самодельное переключение домена во время аварии без понимания TTL и SSL может только увеличить простой.
| Тип проекта | Приоритет в аварии | Временная мера |
|---|---|---|
| Корпоративный сайт | Не потерять заявки | Резервный телефон, почта или независимая форма |
| Интернет-магазин | Сохранить заказы и оплаты | Остановить неисправный шаг, сверить операции с платёжной системой |
| B2B-портал | Не исказить обмен и документы | Ограничить опасные операции, сохранить очередь, уведомить пользователей |
| Сайт с активной рекламой | Не оплачивать бесполезные переходы | Приостановить кампании и зафиксировать время простоя |
Что подготовить технической команде
Для первичной диагностики обычно нужны адрес сайта, доступ к хостингу или облаку, журналы веб-сервера и PHP, сведения о базе, CMS, CDN, DNS и последних изменениях. Для интегрированного проекта добавляются контакты ответственных за 1С, CRM, платежи и другие внешние сервисы.
Не обязательно сразу передавать все права администратора. Сначала подрядчик описывает, какой доступ нужен и для какой проверки. Для нового исполнителя предпочтительнее создать отдельную временную учётную запись: так действия останутся различимыми в журналах.
Что проверяет подрядчик
Профессиональная диагностика идёт от внешнего контура к внутреннему: домен и DNS, SSL, CDN или балансировщик, веб-сервер, PHP или другой runtime, приложение, база данных, файловая система, фоновые задачи и интеграции. Одновременно проверяются ресурсы, недавние релизы и события безопасности.
| Симптом | Вероятная зона проверки | Подтверждающие данные |
|---|---|---|
| Домен не определяется | DNS, оплата домена, делегирование | DNS-записи и время их изменения |
| Соединение отклоняется | Сервер, firewall, веб-сервис | Статус служб и сетевые журналы |
| 500/502/504 | Приложение, PHP-FPM, proxy, лимиты | Логи ошибок и состояние процессов |
| Ошибка базы | Реквизиты, сеть, СУБД, диск, лимит соединений | Логи приложения и базы |
| Страница открывается, функция не работает | Код, JavaScript, API, очередь | Консоль, сетевые запросы и журнал задачи |
Для отдельных кодов ошибок на сайте уже есть специализированные материалы, например инструкция по ошибке 500. В аварии важнее не читать все варианты подряд, а сопоставить код с логом в то же время.
Исправление, откат или восстановление из копии
Если причина — недавний релиз, может быть быстрее откатить только изменение. Если повреждены данные, используют резервную копию или восстановление базы на выбранный момент. Если проблема инфраструктурная, переносят сервис или восстанавливают узел.
Решение принимают с учётом новых данных. Вчерашний архив магазина может вернуть сайт, но удалить сегодняшние заказы. Поэтому перед откатом сохраняют текущее состояние, оценивают разницу и определяют, какие операции нужно перенести в восстановленную версию.
Когда сайт снова открылся — инцидент ещё не завершён
Проверяют не только главную страницу. Нужно пройти форму, корзину, оплату в тестовом режиме, письмо, CRM, личный кабинет, поиск, cron и ключевые интеграции. Затем наблюдают за ошибками и ресурсами хотя бы один полный рабочий цикл.
После восстановления фиксируют первопричину, длительность, влияние на бизнес и действия, которые предотвратят повторение. Это может быть мониторинг, изменение резервного копирования, обновление кода, ограничение фоновой задачи или уточнение регламента. Более подробно организационная сторона разобрана в материале об аварийной поддержке коммерческого сайта.
Частые вопросы
Нужно ли сразу звонить хостингу?
Да, если недоступен сервер, домен или панель, но одновременно уведомите разработчика. Хостинг видит инфраструктуру, а команда проекта — код и бизнес-логику; причины нередко находятся на их границе.
Стоит ли перезапускать сервер самостоятельно?
Только по согласованному регламенту. Перезапуск может временно вернуть сайт, но стереть полезное состояние процессов и не устранить утечку памяти, тяжёлый запрос или атаку.
Когда нужно останавливать рекламу?
Когда целевая страница, форма, корзина или оплата действительно недоступны и нет рабочего резервного маршрута. Зафиксируйте время остановки и не забудьте проверить сайт перед повторным запуском.
Можно ли сразу восстановить вчерашнюю копию?
Для контентного сайта иногда можно, но для магазина или B2B-сервиса сначала нужно защитить новые заказы и документы. Откат без сравнения данных способен создать более дорогую проблему.
Какие доступы нужны срочно?
Обычно хостинг или облако, логи, CMS и сведения о DNS/CDN. Точный набор зависит от симптома. Лучше создавать отдельные временные учётные записи, а не пересылать основной пароль.
Как понять, что работа полностью восстановлена?
Пройти согласованный чек-лист бизнес-функций, проверить ошибки и очереди, сверить новые заявки или заказы и убедиться, что показатели остаются стабильными после возврата нагрузки.
Сайт уже не работает и нужен подрядчик?
Передайте German Web URL, время начала проблемы, скриншот и список последних изменений. Мы начнём с ограниченной диагностики, зафиксируем причину и согласуем безопасный способ восстановления. Работа разработчика рассчитывается по ставке 2 300 ₽ в час. Подробнее — в разделе технической поддержки сайтов.
