Сайт упал в пятницу вечером: что делать в первые 30 минут

Пятница, 19:40. В чат маркетинга прилетает скрин: белый экран, ошибка 500, «сайт недоступен». Реклама крутится, заявки обрываются, клиенты пишут в мессенджеры «у вас всё сломалось?». Техподдержка ещё не в сети, разработчик на даче, хостер отвечает шаблоном из базы знаний.

В такие минуты важны не глубокие знания веб-сервера, а порядок действий. Первые полчаса решают, потеряете ли вы вечер, выходные и часть рекламного бюджета — или локализуете ущерб, пока инженеры подключаются. Паника без ролей почти всегда удлиняет простой.

Руководителю и маркетологу не нужно чинить PHP. Им нужно: зафиксировать факт, отделить «у нас» от «у всех», снизить коммерческий ущерб и собрать входные данные для поддержки так, чтобы инженер не потерял час на поиск паролей.

Три типичных катастрофы

Белый экран или 500 после «мелкой правки». Кто-то выкатил плагин, поменял правила на сервере, обновил версию языка. Сайт «вчера работал». Здесь главное — не усугублять: не делать ещё десять правок подряд «на глаз» и не перезапускать службы без фиксации симптомов.

Хостинг, диск, DNS, сертификат. Иногда падает не сама система управления сайтом, а место на диске, лимит файлов, просроченный сертификат или запись имени. Маркетинг видит «сайт лёг», инженер видит другую картину. Без базовой диагностики все спорят о разном.

Взлом и редиректы. В выдаче чужая реклама, браузер ругается, с телефона — увод на спам. Паника толкает «быстро откатить всё из бэкапа трёхмесячной давности» — и потерять заказы за неделю. Нужны изоляция и аккуратный разбор, а не хаотичный откат.

Чего не делать в панике

Не перезапускать сервер десять раз подряд без записи того, что видели — сотрёте следы. Не менять все пароли до понимания вектора, если подозреваете взлом: сначала сохранить логи и снимок. Не обещать клиентам в соцсетях «через пять минут починим», если причина неизвестна. Не выключать всю рекламу на сутки вслепую, если можно поставить заглушку с телефоном и формой на запасном адресе.

Не пускать в бой десятерых «помощников» с полными правами. Один координатор инцидента лучше десяти одновременных правок.

Чеклист руководителя на 30 минут

Минуты 0–5: зафиксировать факт. Скрин ошибки, точное время, с какого устройства и сети проверяли, что говорят статус хостера и внешняя проверка доступности. Один человек ведёт хронологию в чате — иначе через час никто не вспомнит последовательность.

Минуты 5–10: отделить «у нас» от «у всех». Открыть сайт с мобильного интернета, через другую сеть, проверить статус площадки размещения. Если упало только в офисе — это локальная сеть. Если упало везде — эскалация инженеру.

Минуты 10–20: снизить коммерческий ущерб. Поставить заглушку с контактами, если есть доступ к панели. Приостановить платную рекламу на упавшие адреса или перенаправить на зеркало. Ответить ключевым клиентам коротко и честно: фиксируем сбой, заявки принимаем по телефону или почте.

Минуты 20–30: собрать вход для поддержки. Доступы к панели хостинга, файлам, админке, DNS, бэкапам — в одном месте. Что меняли за последние сутки-двое. Есть ли свежий бэкап и куда его можно развернуть. Список симптомов с разных устройств.

Почему роли важнее героизма

Когда все одновременно «лечат», обычно ломают ещё сильнее. Смешение ролей в первые минуты — главный ускоритель хаоса. Маркетинг не чинит сервер — он останавливает слив бюджета и держит коммуникацию. Директор не правит шаблоны — он назначает ответственного. Техника не пишет оправдания в комментариях — она диагностирует.

Если у вас заранее есть текст заглушки, список доступов и канал дежурного, пятничный инцидент сжимается. Если нет — первые полчаса уходят на поиск «у кого пароль».

После того как сайт снова открылся

Работа не закончена в момент «страница загрузилась». Нужен короткий разбор: причина, длительность простоя, оценка потерянных заявок, что предотвратит повтор. Если падение из‑за обновления без тестовой среды — введите правило: боевая среда только после проверки. Если из‑за диска — предупреждение на 85% заполнения. Если взлом — не только «почистили файлы», а закрыли вход, сменили секреты и проверили целостность.

Зафиксируйте в регламенте: кто объявляет инцидент, кто говорит с клиентами, кто имеет право менять боевую среду в ночи. Разовая удача не масштабируется.

Частые вопросы

Нужно ли сразу откатывать бэкап? Только если понятно, что правка или заражение свежие, а бэкап проверен и не уничтожит данные заказов. Иначе сначала диагностика.

Выключать ли рекламу? На упавшие страницы — да или перенос на рабочее зеркало. Глушить весь маркетинг без оценки — лишние потери.

Когда звонить хостеру, а когда разработчику? Если не открывается сама машина или панель — хостинг. Если открывается заглушка платформы или ошибка приложения — разработка и администрирование сайта.

На что смотреть через месяц

Любое улучшение проверяют не ощущением «стало спокойнее», а фактами: меньше инцидентов, короче простой, ниже доля ручной работы, предсказуемее счета и понятнее ответственность. Если через месяц картина не изменилась, вы либо выбрали не тот рычаг, либо не закрепили регламент и владельца.

Полезно зафиксировать исходную точку до изменений: сколько длился последний простой, откуда о нём узнали, сколько часов ушло на ручной сбор отчёта, какая строка счёта непонятна. Иначе через квартал снова будет спор «стало лучше или просто забыли».

Отдельно договоритесь, что считается успехом для бизнеса, а что — для инженерии. Для коммерции важны заявки, оплаты, скорость ответа клиенту. Для инженерии — повторяемость, наблюдаемость, откат. Когда метрики разные и не согласованы, проект «закрывают», а боль возвращается.

Итог

Чеклист на 30 минут не заменяет инженера, но резко сокращает хаос до его появления. Лучший сценарий — тот, которого не видно снаружи: мониторинг уже поднял тревогу, дежурный в работе, маркетинг получил готовый текст. Пока этого нет, хотя бы не теряйте первые полчаса на панику — используйте их на локализацию ущерба.