Не работает сайт: что проверить и что сообщить подрядчику

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

1. Уточните масштаб

Откройте сайт в приватном окне, на телефоне через мобильную сеть и, если возможно, попросите человека из другого города. Проверьте главную страницу и конкретный проблемный URL. Если не работает только один браузер, причиной может быть расширение, кеш или локальный DNS. Если недоступен только один раздел, вероятнее ошибка приложения, а не домена. Запишите точный адрес, время с часовым поясом, устройство, сеть и текст ошибки. Формулировка «сайт лежит» оставляет подрядчику повторять все проверки с нуля.

2. Посмотрите код ответа

• DNS_PROBE / NXDOMAIN. Причину стоит искать в области «DNS или домен». Не нужно сразу менять все записи наугад.
• Истёк сертификат. Причину стоит искать в области «SSL, домен, reverse proxy». Не нужно сразу отключать HTTPS.
• 404. Причину стоит искать в области «Маршрут, публикация, rewrite». Не нужно сразу восстанавливать всю базу.
• 403. Причину стоит искать в области «Права, firewall, защита». Не нужно сразу выдавать всем полный доступ.
• 500. Причину стоит искать в области «Код приложения». Не нужно сразу скрывать ошибку без логов.
• 502/504. Причину стоит искать в области «Приложение, upstream, нагрузка». Не нужно сразу перезапускать всё бесконечно.
• Белая страница. Причину стоит искать в области «JS или серверный рендер». Не нужно сразу очищать production-данные.

Код можно увидеть в DevTools → Network или командой curl, если вы ей пользуетесь. Один HTTP 200 ещё не гарантирует работу: страница может вернуть заглушку или ошибку внутри HTML.

3. Проверьте домен и DNS

Убедитесь, что домен оплачен и не истёк. Сверьте записи A/AAAA/CNAME с актуальной инфраструктурой. Изменения DNS распространяются не мгновенно, а разные провайдеры могут видеть разные ответы. Не удаляйте старые записи до понимания миграции.

Если недавно менялся сервер, проверьте, не указывает ли часть записей на старый IP. Отдельно учитывайте IPv6: ошибочная AAAA-запись может ломать сайт только у части пользователей.

4. Проверьте SSL

Браузер обычно сообщает об истёкшем сертификате, несовпадении имени или недоверенной цепочке. Проверьте срок, домены в сертификате и автоматическое продление. Причина может быть не в выпуске сертификата, а в недоступном challenge, неверном proxy или сертификате, который обновился на диске, но не загрузился процессом.

Не советуйте пользователям обходить предупреждение. Для форм, кабинетов и платежей это опасно. Сохраните текст ошибки и доменное имя, на котором она возникла.

5. Хостинг и ресурсы

Проверьте оплату хостинга или VPS, статус провайдера, свободное место, память и нагрузку. Заполненный диск часто мешает базе и логам; нехватка памяти завершает процессы; превышение лимитов виртуального хостинга даёт временные ошибки.

Не удаляйте логи и базу ради освобождения места без резервной копии. Сначала найдите крупные безопасные артефакты, проверьте ротацию и причину роста.

6. Веб-сервер и приложение

Для 502/504 проверьте, работает ли upstream: PHP-FPM, Node/PM2, контейнер или другой процесс. Сверьте порт и socket в Nginx, последние деплои и ошибки. Для 500 нужен журнал приложения с временем и request id. Рестарт может временно вернуть сайт, но без причины сбой повторится.

Если проблема появилась после релиза, сравните точный commit и конфигурацию. Безопасный откат предпочтительнее срочной серии несвязанных правок. Миграции данных откатывают только по проверенному плану.

7. База данных

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

Перед изменением создайте резервную копию и проверьте, что она читается. При восстановлении нужна отдельная точка, контроль схемы и smoke ключевых операций.

8. CDN, firewall и защита

CDN может закешировать ошибку, firewall — заблокировать диапазон, а защита — принять обычный трафик за атаку. Сравните прямой upstream и публичный домен, но не раскрывайте origin и не отключайте защиту глобально. Ищите конкретное правило и request id.

Если проблема только у одного пользователя, запросите его внешний IP безопасным способом и время. Не публикуйте IP, токены и персональные данные в открытой переписке.

Что сообщить технической поддержке

• точный URL и время с часовым поясом;
• текст/код ошибки и скриншот;
• работает ли с другой сети и устройства;
• какие изменения и деплои были перед сбоем;
• повторяется ли постоянно или периодически;
• контакты ответственного и бизнес-приоритет;
• безопасный способ передать доступы отдельно от чата.

Не отправляйте пароль, приватный ключ или токен в обычном сообщении. Создайте временную учётную запись с минимальными правами и отзовите её после работ.

Когда нужен срочный специалист

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

Za IT предлагает поддержку сайта: для нового клиента одна небольшая локальная проблема после подтверждения может быть исправлена за 0 ₽. Для системной проверки сайта, сервера и пути заявки подходит экспресс-аудит. Условия сопровождения разобраны в статье стоимость поддержки сайта, а особенности CMS — в поддержке 1С-Битрикс.

Как предотвратить повтор

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

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

Краткий порядок действий

1. Зафиксировать URL, время и ошибку.
2. Проверить другую сеть и масштаб.
3. Определить слой: DNS, SSL, HTTP, приложение или данные.
4. Сохранить логи и последние изменения.
5. Ограничить бизнес-ущерб.
6. Передать минимальные безопасные доступы.
7. Исправить одну подтверждённую причину.
8. Выполнить smoke и добавить профилактику.

Вывод

Когда сайт не работает, скорость зависит от качества первых данных и аккуратности изменений. Идите от внешнего симптома к конкретному слою, сохраняйте доказательства и не меняйте несколько систем одновременно. Так проще восстановить сервис и устранить причину, а не только временно скрыть ошибку.