Если коммерческий сайт перестал работать, первые действия определяют не только скорость восстановления, но и размер потерь. Хаотичные обновления, удаление файлов и одновременная работа нескольких специалистов могут уничтожить следы причины и усложнить откат. Правильная последовательность: подтвердить сбой, ограничить ущерб, зафиксировать состояние, назначить ответственного и восстанавливать сервис по заранее выбранному сценарию.
Аварийная поддержка отличается от обычной доработки. Цель первого этапа — вернуть критичную функцию или безопасную временную версию сайта. Полное устранение причины, рефакторинг и профилактика выполняются после стабилизации.
Содержание:
Как понять, что инцидент действительно критический
| Ситуация | Приоритет | Первое действие |
|---|---|---|
| Сайт полностью недоступен | Критический | Проверить сервер, DNS, SSL и последние изменения |
| Не работает заказ или оплата | Критический | Остановить потерю/дублирование данных, проверить интеграции |
| Формы не отправляются | Высокий | Организовать временный канал заявок и проверить уведомления |
| Не работает часть каталога | Высокий или средний | Оценить долю пользователей и наличие обходного пути |
| Визуальная ошибка без влияния на функцию | Средний или низкий | Зафиксировать и включить в план |
Приоритет определяется влиянием на деньги, данные и пользователей. Ошибка цвета кнопки не становится аварией только потому, что её заметил руководитель. А тихий сбой передачи лидов в CRM может быть критическим, хотя сайт визуально работает.
Первые 15 минут
- проверьте сайт из другой сети и устройства;
- зафиксируйте время, симптомы и затронутые функции;
- не очищайте логи и не запускайте массовые обновления;
- остановите рекламный трафик, если заявки или оплата не работают;
- назначьте одного координатора и один канал коммуникации;
- предоставьте команде доступ к хостингу, CMS, логам и мониторингу;
- сообщите о последних релизах и действиях.
Если одновременно пять человек пишут разработчику и дают разные указания, восстановление замедляется. Координатор собирает информацию от бизнеса, а технический ответственный управляет действиями специалистов.
Что проверяет техническая команда
- доступность домена, DNS и SSL-сертификата;
- ответ веб-сервера и состояние PHP;
- нагрузку процессора, память и свободное место;
- базу данных и количество соединений;
- логи приложения, сервера и интеграций;
- последние изменения кода и конфигурации;
- cron, очереди и фоновые процессы;
- внешние сервисы: 1С, CRM, банк, доставка, CDN.
Задача диагностики — локализовать слой проблемы. Если сервер работает, но приложение возвращает ошибку, нет смысла менять DNS. Если сбой у платёжного провайдера, переустановка CMS не поможет.
Восстановление и окончательное исправление
Восстановить сервис можно откатом релиза, переключением на резерв, восстановлением копии или временным отключением проблемной функции. Это допустимо, если бизнес снова может принимать заявки и заказы, а данные не теряются.
После восстановления команда находит первопричину, готовит постоянное исправление и тестирует связанные сценарии. Затем составляется краткий отчёт: что произошло, почему мониторинг не предупредил раньше, какие данные затронуты и что предотвратит повторение.
Как считать потери от простоя
Потери = недополученная маржа + потраченный рекламный бюджет + стоимость остановки сотрудников + расходы на восстановление.
Для быстрой оценки возьмите среднее количество заявок или заказов за час, конверсию в продажу и валовую прибыль. Не следует приравнивать весь оборот к убытку: корректнее считать потерянную маржу и дополнительные расходы.
Пример 1. Небольшой корпоративный сайт
| Показатель | Пример |
|---|---|
| Заявки | 8 в рабочий день, то есть около 1 в час |
| Конверсия в договор | 25% |
| Средняя валовая прибыль | 40 000 ₽ |
| Ожидаемая потеря за 4 часа | 1 заявка × 4 × 25% × 40 000 = 40 000 ₽ |
| Восстановление | 4 часа × 2 300 ₽ = 9 200 ₽ |
В этом примере даже небольшой сайт оправдывает оперативное подключение: ожидаемая потеря выше стоимости четырёх часов разработки. Но круглосуточное дежурство ему может быть не нужно, если заявки поступают только в рабочее время.
Пример 2. Интернет-магазин
| Показатель | Пример |
|---|---|
| Оборот | 120 000 ₽ в час |
| Валовая маржа | 25% |
| Реклама | 8 000 ₽ в час |
| Простой | 3 часа |
| Потери | 120 000 × 25% × 3 + 8 000 × 3 = 114 000 ₽ |
При неработающей оплате рекламу следует остановить сразу. Если корзина сохраняет товары, можно временно переключить покупателя на заявку или оплату после звонка. Такой обходной сценарий уменьшает потери до полного ремонта.
Пример 3. Интегрированный B2B-проект
| Показатель | Пример |
|---|---|
| Заблокированные сотрудники | 30 человек |
| Стоимость часа сотрудника для компании | 1 500 ₽ |
| Простой | 4 часа |
| Внутренние потери | 30 × 1 500 × 4 = 180 000 ₽ |
| Дополнительно | риск задержки отгрузок и повреждения данных |
Для B2B-системы важнее не публичная страница, а доступ к кабинету, заказам и обмену. Временное восстановление только главной страницы не решает проблему. Нужны сценарии деградации: ручная выгрузка, очередь повторной отправки и запрет на дублирование операций.
Пример 4. Сайт с рекламными кампаниями
| Показатель | Пример |
|---|---|
| Расход рекламы | 60 000 ₽ в день, или около 2 500 ₽ в час |
| Сбой формы | 6 часов |
| Прямой расход без заявок | 15 000 ₽ |
| Дополнительный риск | алгоритм рекламы получает некорректные сигналы |
| Действие | остановить кампании или перевести на рабочую посадочную |
Маркетолог должен участвовать в аварийном регламенте. Разработчик восстанавливает сайт, а ответственный за рекламу ограничивает трафик и после ремонта проверяет цели и передачу конверсий.
Какие доступы подготовить заранее
- панель хостинга и SSH/SFTP;
- CMS и база данных;
- репозиторий кода;
- резервные копии;
- регистратор домена и DNS;
- аналитика и рекламные кабинеты;
- 1С, CRM и внешние API;
- контакты хостинга, банка и других провайдеров.
Во время аварии поиск владельца домена или единственного пароля может занять больше времени, чем само исправление. Доступы следует хранить в корпоративном менеджере паролей, а не в личном аккаунте бывшего сотрудника.
Что делать после восстановления
- проверить формы, заказы, оплату и интеграции;
- сопоставить данные за период сбоя;
- повторить неуспешные обмены без дублей;
- восстановить рекламу только после проверки конверсий;
- зафиксировать первопричину и хронологию;
- добавить мониторинг симптома, который был пропущен;
- обновить инструкцию и резервный сценарий.
Как подготовиться до аварии
Минимальный набор — мониторинг, актуальная копия, проверенные доступы, ответственные и список критичных функций. Для проекта с высоким ущербом от простоя нужен SLA и заранее согласованный порядок эскалации.
German Web принимает аварийные задачи при наличии ресурсов и доступов, но гарантированная скорость возможна только в заранее согласованном формате поддержки. Условия описаны на странице технической поддержки сайтов.
Частые вопросы
Нужно ли сразу восстанавливать сайт из резервной копии?
Нет. Сначала нужно понять причину и актуальность копии. Необдуманное восстановление может удалить новые заказы или вернуть уязвимость.
Стоит ли останавливать рекламу?
Да, если посадочная, форма, заказ или оплата не работают. Если есть рабочая резервная страница, трафик можно временно перевести на неё.
Что важнее: восстановление или поиск причины?
Сначала безопасно вернуть критичную функцию, если это возможно. Полный анализ первопричины продолжается после стабилизации.
Можно ли гарантировать устранение за 15 минут?
Нет. Можно гарантировать время реакции. Продолжительность восстановления зависит от причины, доступов, данных и сторонних сервисов.
Что делать, если разработчик недоступен?
Нужны корпоративные доступы, репозиторий, резервные копии и альтернативная команда. Критичный сайт не должен зависеть от одного личного аккаунта.
Нужен ли отчёт после аварии?
Да. Краткий разбор помогает устранить первопричину, обновить мониторинг и не повторить тот же сценарий.
