Сбой сайта почти всегда случается в неудобный момент: в разгар распродажи, перед запуском рекламы или в пятницу вечером. В такой ситуации главная опасность — не сама поломка, а хаотичные действия: кто-то перезагружает сервер, кто-то откатывает базу на недельную копию, кто-то правит файлы прямо на рабочем сайте. В итоге простой растягивается с часа до суток, а часть заказов теряется навсегда. В этой статье — план, по которому мы действуем при авариях на сайтах клиентов, и то, что стоит подготовить заранее.
Первые 15 минут: оценить масштаб, а не чинить
Первое желание при падении сайта — немедленно что-то сделать. Но первые минуты лучше потратить на понимание того, что именно сломалось. «Сайт не работает» может означать десяток разных ситуаций: не открывается вообще, открывается с ошибкой 500, работает главная, но не работает каталог, сайт открывается, но не принимает заказы, сайт работает у вас, но не у клиентов. Для каждой из них — своя причина и своё решение.
Проверьте сайт с разных устройств и сетей: с компьютера в офисе и со смартфона через мобильный интернет. Если сайт не открывается только у вас, проблема может быть в сети или в DNS-кеше. Зафиксируйте точный текст ошибки и время, когда сбой начался, — это сэкономит время специалисту. Посмотрите, что менялось в последние сутки: обновления CMS, установка модуля, правки в коде, изменения в настройках хостинга или домена. По нашей статистике, примерно в 60% случаев сбой связан с недавним изменением, а не с внешней причиной.
Главное правило первых минут: не вносите изменений на рабочем сервере, пока не понятна причина и не сделана копия текущего состояния. Даже «сломанный» сайт содержит свежие заказы и регистрации, которых нет в резервной копии. Откат без сохранения текущих данных — самый частый способ превратить сбой в потерю данных.
Типичные причины сбоев и их признаки
Опыт поддержки нескольких десятков сайтов показывает, что причины аварий повторяются. Если сопоставить симптом с типичной причиной, диагностика занимает минуты, а не часы.
| Симптом | Вероятная причина | Что проверить первым |
|---|---|---|
| Сайт не открывается, браузер пишет, что адрес не найден | Истёк срок регистрации домена или сломаны DNS-записи | Срок оплаты домена, настройки DNS у регистратора |
| Предупреждение о небезопасном соединении | Истёк SSL-сертификат | Срок действия сертификата и автопродление |
| Ошибка 500 на всех страницах | Ошибка в коде после обновления, несовместимый модуль, смена версии PHP | Журнал ошибок сервера, последние изменения |
| Ошибка 502/504, сайт открывается через раз | Перегрузка сервера, зависшие процессы, исчерпаны ресурсы тарифа | Нагрузку на сервер, свободное место, медленные запросы к базе |
| Ошибка соединения с базой данных | Упала СУБД, закончилось место на диске, изменился пароль | Свободное место, состояние СУБД, параметры подключения |
| Посторонний контент, редиректы на чужие сайты | Взлом | Изменённые файлы, новые пользователи в админке |
| Сайт работает, но заказы не приходят | Сломана отправка почты, интеграция с CRM или платёжный модуль | Журналы отправки писем и обмена, тестовый заказ |
Отдельно отметим «тихие» сбои — последний пункт таблицы. Сайт выглядит нормально, но заявки уходят в никуда: почтовый сервер попал в чёрный список, сменился ключ API службы доставки, обмен с 1С зависает. Такие сбои опасны тем, что их замечают через несколько дней по падению продаж. Защищает от них только мониторинг ключевых сценариев, а не просто проверка доступности главной страницы.
Пошаговый план восстановления
Когда причина понятна хотя бы в первом приближении, действуйте по плану. Он одинаково работает для сайта-визитки и для интернет-магазина с интеграциями — отличается лишь объём проверок на последнем шаге.
Зафиксировать текущее состояние
Сделайте копию файлов и базы данных в текущем виде, даже если сайт не работает. В ней могут быть заказы, поступившие после последней резервной копии, и следы, нужные для расследования взлома.
Включить страницу обслуживания
Если сайт отдаёт ошибки или показывает чужой контент, лучше временно показывать аккуратную страницу «Ведутся технические работы» с контактами. Сервер при этом должен отдавать код 503, чтобы поисковые системы не исключили страницы из индекса.
Устранить причину
Откатить последнее обновление, отключить конфликтный модуль, продлить домен или сертификат, освободить место на диске, увеличить ресурсы. Если причина — взлом, сначала закрыть уязвимость и сменить все доступы.
При необходимости — восстановить из копии
Выберите последнюю заведомо исправную копию. Восстанавливайте сначала на тестовом окружении, а не поверх рабочего сайта, и проверьте, что копия действительно рабочая.
Перенести свежие данные
Сравните сохранённое на первом шаге состояние с восстановленной копией и перенесите заказы, регистрации и заявки, появившиеся после момента резервирования.
Проверить ключевые сценарии
Поиск, каталог, корзина, оформление заказа, оплата, отправка уведомлений, обмен с 1С и CRM, формы заявок. Проверку делайте реальными действиями, а не просмотром страниц.
Снять страницу обслуживания и наблюдать
Ещё несколько часов следите за журналами ошибок и нагрузкой: повторный сбой часто случается вскоре после восстановления.
Резервная копия: какой она должна быть, чтобы спасти
Восстановление возможно ровно настолько, насколько хороши резервные копии. И здесь большинство владельцев сайтов узнают неприятные новости именно в момент аварии: копии делались только для файлов без базы, хранились на том же сервере, что и сайт, или последняя успешная копия была три недели назад, а ошибки резервирования никто не читал. Подробно о стратегиях хранения мы писали в статье о резервном копировании, здесь — только то, что важно для восстановления.
Две ключевые метрики, которые стоит определить для своего сайта заранее, — допустимая потеря данных и допустимое время простоя. Для корпоративного сайта, который обновляется раз в неделю, потеря данных за сутки некритична, а простой в несколько часов неприятен, но не катастрофичен. Для интернет-магазина с сотней заказов в день потеря даже шести часов данных — это десятки заказов, которые придётся восстанавливать по звонкам и письмам. Отсюда разная частота копирования: для корпоративного сайта достаточно ежедневной копии, для активного магазина базу данных стоит копировать каждые час-два.
- Копируются и файлы, и база данных, причём согласованно по времени.
- Копии хранятся минимум в двух местах, одно из которых — вне сервера сайта.
- Есть копии разной глубины: последние сутки, неделя, месяц — взлом часто обнаруживают не сразу.
- Об ошибках резервирования приходят уведомления, и их кто-то читает.
- Восстановление из копии проверяется на тестовом сервере хотя бы раз в квартал.
Последний пункт — самый важный и самый редко выполняемый. Копия, из которой никто ни разу не пробовал восстановиться, — это надежда, а не гарантия. Пробное восстановление занимает пару часов и показывает реальное время, которое понадобится при аварии.
Восстановление после взлома: особый случай
Если сайт взломан, простой откат на вчерашнюю копию почти никогда не помогает. Злоумышленник мог получить доступ неделю или месяц назад, а вредоносный код проявился только сейчас. Восстановление на копию, в которой уже есть «закладка», вернёт проблему через несколько дней. Поэтому после взлома порядок действий другой.
Сначала нужно понять, как произошёл взлом: через уязвимый модуль, украденный пароль, незащищённую форму загрузки файлов. Затем — найти чистую копию, сравнив файлы с эталонной версией CMS и модулей. Часто проще не восстанавливать файлы из копии, а развернуть чистую версию CMS с актуальными модулями и перенести на неё шаблон, проверенный построчно, и базу данных, очищенную от вредоносных вставок. После этого обязательно сменить все пароли: от админки, хостинга, базы данных, FTP и SSH, почты. Если в базе хранились персональные данные клиентов, нужно оценить, могли ли они утечь, — это влечёт отдельные обязанности по уведомлению регулятора.
Сайт перестал открываться в субботу утром, у нас как раз шла акция. Команда на поддержке за полтора часа нашла причину — переполненный диск из-за журналов модуля, — освободила место, проверила заказы и перенастроила ротацию журналов. В понедельник мы получили отчёт, а не сюрприз.
Ольга К., руководитель интернет-магазина, «Домашний текстиль»
Что подготовить заранее: план на одну страницу
Лучшее время для подготовки к сбою — когда всё работает. Достаточно одного документа на одну-две страницы, который хранится не только на сервере сайта, но и у владельца, и у подрядчика. В нём должны быть ответы на вопросы, которые в момент аварии отнимают больше всего времени.
Где находятся доступы: регистратор домена, хостинг, DNS, админка, база данных, почта, платёжный сервис. Кто и в каком порядке реагирует: внутренний ответственный, подрядчик на поддержке, хостинг-провайдер. Где лежат резервные копии и как из них восстановиться. Какие сценарии проверять после восстановления. Кого и как уведомлять: менеджеров, клиентов, партнёров. Правила хранения доступов подробно описаны в статье про пароли и доступы для команды — без них план не сработает.
Полезно также заранее подготовить страницу технических работ в стиле сайта, с контактами и альтернативными способами заказа — по почте или через мессенджер. Если такая страница есть, во время аварии вы теряете меньше клиентов: человек видит, что сайт временно недоступен, а не сломан навсегда.
Как сократить время простоя в будущем
После каждого сбоя стоит провести короткий разбор: что произошло, почему не заметили раньше, что сделать, чтобы не повторилось. Это не поиск виноватых, а список конкретных доработок. Типичные выводы после разборов на наших проектах: настроить автопродление домена и сертификата, включить мониторинг свободного места на диске, перенести обновления CMS на тестовый сервер, добавить проверку отправки заказов каждые 15 минут, увеличить частоту копирования базы.
Многие из этих мер входят в стандартную техническую поддержку: мониторинг доступности и ключевых сценариев, контроль резервных копий, обновления через тестовое окружение, регламент реакции на аварии. Для магазина с заметным оборотом стоимость поддержки от 15 000 ₽ в месяц обычно меньше, чем выручка одного дня простоя в сезон.
Выводы
Восстановление после сбоя — это не героизм, а дисциплина. В первые минуты нужно оценить масштаб и сохранить текущее состояние, а не бросаться чинить. Затем — найти причину по симптомам, устранить её, при необходимости восстановиться из копии на тестовом окружении, перенести свежие данные и проверить ключевые сценарии реальными действиями. После взлома откат не помогает — нужна чистая установка, смена всех доступов и оценка утечки данных.
Всё остальное решается подготовкой: рабочие и проверенные резервные копии, мониторинг не только доступности, но и заказов, план на одну страницу с доступами и контактами, страница технических работ. Если такого плана у вас пока нет, начните с него — он окупится при первом же сбое.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
