В 9:12 в чат приходит сообщение: «сайт лег, реклама идет, лидов нет». В такие моменты бизнес теряет деньги не только из-за сбоя, но и из-за суеты вокруг него. Первые 15 минут нужны не для героизма, а чтобы локализовать проблему.
На одном проекте в e-commerce команда уже собиралась перезапускать сервер, маркетинг продолжал вести трафик, а ломалась только оплата после обновления модуля на WordPress. Главная открывалась, каталог работал, падал один критичный шаг. Это уже другой сценарий, и решается он иначе.
Сначала отделите полное падение от локального сбоя
Фраза «сайт лежит» почти бесполезна. Нужна короткая и точная формулировка: 500 на форме, 503 на главной, NXDOMAIN после смены DNS, 404 только у каталога. Когда картина понятна, техподдержка идет в нужное место сразу.
Обычно на это уходит 5-10 минут. Откройте сайт с другого устройства и через мобильный интернет. Проверьте главную, форму, корзину, админку и одну внутреннюю страницу. Если главная жива, а заказ не проходит, значит, у вас не «все упало».
| Симптом | Что это обычно значит | Первое действие |
|---|---|---|
| 500 | ошибка приложения | смотреть последние изменения и логи |
| 502/504 | прокси не достучался до приложения | проверить Nginx, PHP-FPM, Node.js |
| 503 | сервис не справляется или завис | проверить нагрузку и внешние сервисы |
| NXDOMAIN | проблема с DNS | сверить записи и срок домена |
У нас был магазин, где команда решила, что умер весь сайт, потому что заказов не было 40 минут. Проверили руками - проблема оказалась только в checkout после обновления платежного плагина. Поиск причины занял 25 минут вместо 2-3 часов хаотичных проверок.
Первые 15 минут - это сбор симптомов
Разработчику нужен не крик «срочно», а набор фактов: время сбоя, точный URL, текст ошибки, скриншот, что работает, что нет, были ли деплой, смена DNS, SSL, обновление плагинов. Один такой пакет обычно экономит 20-30 минут.
Есть вещи, о которых вспоминают слишком поздно: истекший SSL, непродленный домен, переполненный диск, сломанная CRM, платежка или служба доставки. В прошлом году мы разбирали B2B-сервис на Laravel 11 и PostgreSQL 16. Сайт открывался, API отвечал, а формы молчали, потому что CRM перестала принимать запросы по токену. Снаружи это выглядело как поломка сайта, внутри - одна интеграция.
Для стартовой проверки хватает такого минимума:
- открыть сайт из другой сети
- проверить 3-4 критичных сценария
- зафиксировать время и текст ошибки
- вспомнить последние изменения
- посмотреть статус хостинга, Cloudflare или CDN
curl -I https://example.com
nslookup example.com
dig example.com
В аварии ничего не улучшайте
Самая частая ошибка - начать чистить кэш, перезапускать сервисы, обновлять плагины и откатывать релиз одновременно. После этого уже непонятно, что было причиной, а что команда добавила своими руками.
Я обычно сначала фиксирую состояние: копию логов, snapshot сервера или базы, список последних действий. Если проект на Node.js 20 + NestJS за Nginx отдает 502, полезнее понять, где рвется цепочка между приложением и прокси, чем обновлять пакеты на проде.
Частая ошибка: почистить логи и временные файлы до разбора. Правильный порядок другой: сначала сохранить артефакты инцидента, потом делать одно контролируемое изменение.
Неудачный кейс у нас тоже был. На старом WordPress мы первым делом перезапустили сервисы и почистили логи. Сайт вернули быстро, но потом уже не смогли доказать, что корень был в конфликте плагина после автообновления. Через несколько недель проблема вернулась.
Пока технари чинят, бизнес должен принимать обращения
Если сайт приносит заявки, техническая работа должна идти параллельно с ручным спасением потока. Нужны телефон, мессенджер, простая резервная форма и человек, который предупредит продажи. Нужен и один координатор инцидента, чтобы в чате не было пяти разных команд.
У одного клиента лендинг шел с бюджетом 120-150 тыс. ₽ в день. Разработчик искал причину 503, а маркетинг еще 2 часа лил трафик в пустоту. После этого мы сделали простой регламент:
| Ситуация | Что делать |
|---|---|
| Главная недоступна > 10 минут | ставить рекламу на паузу |
| Сломана только форма | дать телефон, Telegram, резервную форму |
| Проблема в одной интеграции | оставить трафик на рабочие страницы |
| Причина не ясна > 30 минут | подключать внешнюю поддержку |
Такой лист выглядит скучно, но в реальной аварии он полезнее длинной переписки о том, кто виноват.
Повторяющиеся падения почти всегда говорят о проблеме в процессе
Если за квартал у вас было 2-3 сбоя - переполненный диск, кривое обновление, SSL, DNS, сломанная интеграция - дело уже не в невезении. Обычно это означает, что нет мониторинга, staging, журнала релизов и понятного порядка действий.
У компании, с которой мы работали в прошлом году, сайт падал 3 раза за квартал. После того как настроили мониторинг, staging и регламент релизов, критичных инцидентов не было 6 месяцев. Не потому, что код стал идеальным. Команда просто перестала действовать вслепую.
В ближайшие 6-12 месяцев чаще будут ломаться не страницы сами по себе, а связка вокруг сайта: DNS, CDN, формы, CRM, платежи и авторизация. Если у вас до сих пор нет человека, который в первые 30 минут принимает решения, авария у вас уже запланирована.
