Технический чек-лист запуска сайта: что проверить перед релизом

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

• Паритет staging и production, домен, DNS, SSL — проверяются до объявления даты релиза
• Заголовки безопасности, секреты в коде и уязвимости зависимостей — одним прогоном перед каждым деплоем
• Бюджет производительности и Core Web Vitals — числами, а не ощущением «вроде грузится быстро»
• sitemap.xml, robots.txt, canonical и 404-страница — до того, как краулер увидит сайт первым
• Готовый план отката и настроенный мониторинг — на случай, если что-то из списка выше всё же пропустили

Зачем нужен отдельный технический чек-лист, если есть бизнес-бриф и дизайн-ревью

Бизнес-бриф отвечает на вопрос, зачем сайту существовать и что он должен продавать клиенту; дизайн-ревью проверяет, что интерфейс выглядит так, как задумано, и корректно работает на разных экранах. Ни один из этих этапов не проверяет, выдержит ли окружение реальную нагрузку, не утёк ли ключ API в публичный репозиторий и настроен ли план отката на случай неудачного деплоя: это другая плоскость работы, и закрывает её не дизайнер и не менеджер проекта, а разработчик с отдельным чек-листом.

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

Окружение и инфраструктура: staging ≠ production

Самый частый источник пострелизных сюрпризов — различия между staging, на котором всё тестировали, и production, куда выкатили релиз. Разницы в версии языка, лимите памяти, часовом поясе сервера или значении переменной окружения достаточно, чтобы код, который неделю стабильно работал на staging, упал в первую же минуту на проде.

Паритет конфигурации окружений

Перед релизом стоит явно сверить: версии языка и расширений, переменные окружения, лимиты памяти и времени выполнения, часовой пояс, конфигурацию очередей и кеша — все они должны совпадать между staging и production, а не «примерно совпадать». Отдельно проверяется положение feature-флагов именно для прод-окружения: значение по умолчанию, унаследованное из staging, включает в проде то, что показывать пользователям ещё рано.

Домен, DNS и SSL-сертификат

DNS-записи часто меняют в последний момент перед релизом, а у них может быть выставлен TTL на часы, поэтому правки вносятся заранее, а не в день Х. SSL-сертификат проверяется не только на факт «сайт открывается по https», а на срок действия, корректную цепочку сертификатов и то, что сертификат выпущен на все нужные поддомены, включая www и маркетинговые поддомены, которые будут использоваться в ссылках на запуск.

Безопасность перед релизом: что проверить за один прогон

Безопасность перед релизом проверяется не точечно, по ощущению «вроде ничего критичного», а конкретными действиями, которые можно выполнить за один прогон и повторять при каждом деплое. Подробный разбор инъекций, XSS и CSRF — тема отдельного чек-листа безопасности веб-приложения, здесь — только то, что относится именно к моменту релиза.

Заголовки безопасности и секреты в коде

Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security и X-Frame-Options должны быть выставлены на боевом домене, а не только существовать в конфиге, который давно лежит в репозитории, но не применяется продовым веб-сервером. Параллельно стоит прогнать сканер секретов по истории коммитов: ключ API или пароль от базы, однажды попавший в git, остаётся в истории даже после удаления из последнего коммита, и единственный надёжный способ закрыть риск — считать такой секрет скомпрометированным и ротировать его.

Проверка зависимостей на уязвимости

composer audit
npm audit --production

Оба инструмента сравнивают установленные версии пакетов с базой известных уязвимостей и быстрее любого ручного аудита находят устаревшую библиотеку с опубликованным CVE. Если уязвимость нашлась в пакете, который давно не обновляется, решение не в том, чтобы игнорировать отчёт, а в том, чтобы оценить, доступен ли уязвимый код снаружи, и либо заменить библиотеку, либо временно закрыть место дополнительной проверкой на своей стороне.

Производительность: бюджет страницы, а не ощущения

«Сайт вроде грузится быстро» не проходит проверку перед релизом, потому что это не число, а субъективное ощущение на конкретном устройстве и канале разработчика. Бюджет производительности переводит это в конкретные значения: предельный вес страницы, число запросов, вес JavaScript — и CI можно настроить так, чтобы сборка падала при превышении бюджета, а не чтобы о проблеме узнавали из жалоб пользователей. Как задать бюджет и держать его в CI — отдельная тема, разобрана в материале про бюджет производительности сайта; здесь — что проверить именно перед релизом.

Core Web Vitals и реальные метрики

Перед релизом стоит смотреть не только на лабораторные замеры в Lighthouse, но и ориентироваться на пороги, которые Google публикует для Core Web Vitals: LCP, INP и CLS считаются хорошими показателями, когда укладываются в границы, рекомендованные для 75-го перцентиля реальных визитов, а не только для идеального лабораторного прогона на быстром канале.

Миграции базы данных и бэкап: как не потерять данные при релизе

Миграция схемы — самая необратимая часть релиза: откатить код легко, а откатить удалённую колонку с данными, которые уже перезаписаны, нельзя. Перед каждым релизом, который трогает схему БД, нужен свежий бэкап, снятый непосредственно перед миграцией, а не вчерашний плановый снимок. Разница между операциями, безопасными без даунтайма, и теми, что блокируют таблицу целиком, разобрана в материале про миграции базы данных без даунтайма; перед релизом стоит явно сверить план миграции с этим списком, а не полагаться на то, что «миграция маленькая, значит быстрая».

Отдельно стоит проверить саму возможность отката миграции: не каждая операция обратима технически — удаление колонки необратимо без бэкапа, и если обратной миграции нет, план отката для этого релиза должен опираться на восстановление из бэкапа, а не на команду отката миграции.

Техническое SEO перед запуском

Техническая проверка SEO перед релизом закрывает не ранжирование, а базовую корректность того, что увидит краулер в первые минуты после выкладки.

sitemap.xml, robots.txt, canonical

robots.txt на проде не должен содержать правила, скопированные со staging-окружения и запрещающие индексацию всего сайта, — одна из самых частых и самых дорогих ошибок релиза. sitemap.xml обновляется тем же деплоем, что и новые страницы, а canonical-адреса указывают на боевой домен без параметров staging-авторизации и внутренних query-строк.

404-страница и битые ссылки

404-страница должна реально отдавать код ответа 404, а не 200 с текстом «страница не найдена»: такая подмена ломает интерпретацию статуса страницы поисковиком и мешает вовремя заметить реальные ошибки в логах. Проверка внутренних ссылок на битые адреса, оставшиеся после переноса страниц, — отдельный быстрый прогон перед релизом, а не разовая работа при запуске сайта.

Что проверить, если релиз уже сегодня?

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

Мониторинг, логирование и план откат (rollback)

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

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

Сводный чек-лист

Весь список выше одним блоком — им удобно пользоваться прямо в день релиза:

1. Конфигурация staging и production совпадает: версии, переменные окружения, лимиты, часовой пояс, feature-флаги
2. DNS-записи обновлены заранее с учётом TTL, SSL-сертификат действителен и покрывает все нужные поддомены
3. Заголовки безопасности выставлены на боевом домене для всех типов ответов, а не только для главной страницы
4. Сканер секретов прогнан по истории коммитов, найденные секреты ротированы
5. composer audit и npm audit --production выполнены, критичные уязвимости закрыты или компенсированы
6. Бюджет производительности не превышен, Core Web Vitals проверены по 75-му перцентилю реальных визитов
7. Свежий бэкап снят непосредственно перед миграцией БД, возможность отката миграции проверена
8. robots.txt не блокирует индексацию, sitemap.xml обновлён, canonical указывают на боевой домен
9. 404-страница отдаёт код 404, битые внутренние ссылки проверены
10. Мониторинг и логирование с correlation id подключены, трекер ошибок активен
11. План отката проверен и работает за минуты, а не описан только на словах