Главная › Блог › Что проверить после релиза сайта: контрольный список веб-студии

Что проверить после релиза сайта: контрольный список веб-студии

4 августа 2026 · 19 мин чтения

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

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

Ниже — готовый чек-лист для веб-студии. Он подходит для обычных сайтов и интернет-магазинов; отдельный раздел посвящён обновлениям 1С-Битрикс.

Коротко

После публикации проверьте:

домен, TLS, редиректы и HTTP-ответы;
отсутствие аварийных ошибок и неожиданных изменений конфигурации;
критические бизнес-пути;
формы, почту, CRM, оплату, доставку и 1С;
вход, сессии и права;
robots.txt, noindex, canonical и sitemap;
аналитику и согласия;
cron, очереди, агенты и фоновые задания;
кеш, производительность и ресурсы;
мониторинг после снятия технического окна.

До релиза должны быть готовы владелец, план отката, актуальная резервная копия или другой проверенный способ восстановления и список стоп-условий.

Почему «страница открылась» недостаточно

Релиз может закончиться без ошибки, а сайт — остаться частично сломанным:

главная отдаётся из кеша, но приложение не создаёт заказ;
форма показывает успешную отправку, но письмо не приходит;
старые пользователи вошли по существующей сессии, а новый вход не работает;
PHP-код опубликован, но миграция базы не выполнилась;
новое поле заказа не принимается 1С;
файлы загрузились, но CDN продолжает отдавать старый JavaScript;
production унаследовал noindex со staging;
аналитика считает двойные события;
cron запускает задачу старой версией кода;
новый релиз работает без нагрузки, а через час исчерпывает память.

Поэтому post-release проверка должна идти по карте бизнес-путей и охватывать отложенные эффекты. Как составить карту критических путей сайта — отдельный практикум курса.

Что подготовить до релиза

Чек-лист после публикации начинается до публикации.

Зафиксировать состав изменения

В карточке должны быть:

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

Фраза «залили последние правки» не позволяет понять, что проверять и что возвращать назад.

Выбрать окно

Учитывайте не только низкий трафик, но и доступность нужных людей:

разработчика;
администратора;
представителя клиента;
специалиста 1С;
владельца платёжной интеграции;
человека с правом на откат и DNS.

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

Подготовить восстановление

В зависимости от проекта это может быть:

предыдущий воспроизводимый артефакт;
blue/green или canary-схема;
снимок виртуальной машины;
резервная копия файлов и базы;
обратная миграция;
feature flag;
сохранённая конфигурация;
инструкция ручного переключения.

Для 1С-Битрикс учитывайте совместимость файлов ядра и структуры базы. Официальная документация предупреждает: несоответствие версий может сделать сайт неработоспособным. Нельзя считать планом фразу «если что, вернём папку по FTP».

Проверить копию, а не только её наличие

Минимум:

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

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

Снять исходный снимок состояния

За 15–30 минут до изменения сохраните:

результаты критических синтетических проверок;
текущую долю ошибок;
время ответа;
ресурсы сервера;
размер очередей;
последнюю успешную фоновую задачу;
свежесть обмена с 1С;
пример реального заказа или заявки без лишних персональных данных;
текущие robots, canonical и основные заголовки.

После релиза будет с чем сравнивать. Иначе любое отклонение придётся оценивать на глаз.

Определить стоп-условия

До публикации запишите, что заставит остановить раскатку или откатить изменение:

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

Во время сбоя команда не должна спорить, достаточно ли серьёзна неработающая оплата.

Карточка релиза

# Релиз [ID]: [краткое название]

Дата и окно: [начало — окончание, часовой пояс]
Владелец: [имя]
Решение об откате: [роль и контакт]
Связанный клиент: [проект]

## Цель

[Какой пользовательский или технический результат меняется]

## Состав

- Код: [версия / commit / artifact]
- База: [миграции]
- Конфигурация: [изменения]
- CMS и модули: [версии]
- Внешние зависимости: [список]

## Критические пути

1. [путь и доказательство успеха]
2. [путь и доказательство успеха]
3. [путь и доказательство успеха]

## Восстановление

- Предыдущая версия: [идентификатор]
- Бэкап или снимок: [место и время без секрета]
- Обратимость миграции: [да/нет/условия]
- Команда или инструкция отката: [ссылка]
- Допустимое время решения: [значение]

## Стоп-условия

- [условие]

## Коммуникация

- Клиент предупреждён: [да/нет/не требуется]
- Техническое окно: [ссылка]
- Канал команды: [ссылка]

Контрольный порядок по времени

T−30: исходное состояние

[ ] критические проверки зелёные;
[ ] активного несвязанного инцидента нет;
[ ] фоновая обработка не находится в опасной фазе;
[ ] резервная копия или механизм отката готов;
[ ] свободное место и ресурсы достаточны;
[ ] нужные участники доступны;
[ ] клиент и поддержка знают об окне;
[ ] мониторинг не отключён целиком.

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

T0: публикация

[ ] записано точное время начала;
[ ] зафиксирована версия;
[ ] команды и миграции завершились с ожидаемым статусом;
[ ] не было ручных отклонений от инструкции;
[ ] техническое окно ограничено только нужными сигналами;
[ ] создана отметка о релизе в системе наблюдения;
[ ] известен текущий исполнитель каждого шага.

Не подавляйте все алерты на час «чтобы не мешали». Отключите только ожидаемые сигналы на короткое время и оставьте критические бизнес-проверки видимыми.

T+5 минут: признаки немедленного отката

Проверяйте в таком порядке:

сайт и критические URL отвечают;
нет массовых 5xx, циклических редиректов и ошибок TLS;
новая версия действительно активна;
структура базы соответствует коду;
вход и права не нарушены;
нет признаков потери или некорректной записи данных;
основной денежный путь проходит хотя бы до безопасной контрольной точки.

Если сработало стоп-условие, начинайте утверждённое восстановление. Не тратьте всё разрешённое окно на исправление production, если откат быстрее и безопаснее.

T+15 минут: бизнес-пути

[ ] форма отправляется;
[ ] тестовая заявка дошла до согласованной конечной системы;
[ ] товар добавляется в корзину;
[ ] сумма, скидка и валюта корректны;
[ ] заказ создаётся;
[ ] доступные способы доставки и оплаты отображаются;
[ ] безопасный тест оплаты или его прокси-проверки проходят;
[ ] авторизация и выход работают;
[ ] критическая операция личного кабинета доступна;
[ ] заказ или заявка видны сотруднику клиента.

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

T+30 минут: интеграции и фоновые процессы

[ ] email и SMS не застряли;
[ ] webhook CRM принимает события;
[ ] платёжные callback обрабатываются;
[ ] очередь не растёт без обработки;
[ ] cron, агенты и планировщики запускаются;
[ ] обмен с 1С не заблокирован;
[ ] импорт и экспорт используют ожидаемую схему;
[ ] фоновые задачи не выполняются бесконечно;
[ ] сторонние API не получают аномальный поток;
[ ] нет повторной обработки одной операции.

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

T+60 минут: стабильность

[ ] доля ошибок вернулась к исходному диапазону;
[ ] время ответа не ухудшается;
[ ] память, CPU, диск и соединения стабильны;
[ ] нет роста очередей и временных файлов;
[ ] кеш постепенно наполнился без ошибок;
[ ] CDN отдаёт актуальные ресурсы;
[ ] новые пользовательские события выглядят корректно;
[ ] мониторинг не показывает региональной проблемы;
[ ] не поступают однотипные обращения поддержки.

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

Следующий рабочий день

[ ] ночные задания завершились;
[ ] обмены и отчёты свежие;
[ ] новые реальные заявки и заказы дошли;
[ ] аналитика получила события без дублей;
[ ] поисковые настройки не изменились;
[ ] журнал ошибок не содержит нового повторяющегося класса;
[ ] тестовые данные очищены;
[ ] карточка релиза закрыта с результатом;
[ ] обнаруженные дефекты превращены в задачи;
[ ] карта мониторинга обновлена.

Проверка инфраструктуры и HTTP

Для основных доменов и критических страниц проверьте:

разрешение DNS;
сертификат и цепочку TLS;
основной хост и www;
HTTP → HTTPS;
отсутствие бесконечных редиректов;
ожидаемый конечный URL;
коды ответа;
ключевое содержимое;
заголовки кеширования;
отсутствие служебной заглушки;
работу из основных регионов аудитории;
мобильный и desktop-путь, если они различаются.

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

Формы, письма и CRM

Для каждой критической формы:

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

Если форма использует CAPTCHA, не отключайте защиту на production ради ручного теста. Используйте разрешённый тестовый механизм или заранее согласованный маршрут.

Подробнее: почему форма может молчать при работающем сайте.

Интернет-магазин: заказ и оплата

Проверяйте ветки, где релиз мог изменить:

карточку товара;
тип цены;
остаток;
торговое предложение;
скидку и купон;
валюту;
корзину;
тип плательщика;
доставку;
налоги;
оплату;
создание заказа;
уведомление;
передачу в 1С.

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

Критерий успеха — заказ с правильными данными виден в системе, где с ним работает сотрудник, а не только страница «Спасибо».

Авторизация, сессии и права

Проверьте:

новый вход, а не только существующую сессию;
восстановление пароля по безопасному сценарию;
выход;
срок и область cookies;
роль обычного пользователя;
роль менеджера;
запрет доступа к закрытым данным;
CSRF-защиту и редирект после входа;
SSO или внешний провайдер;
работу нескольких сайтов или поддоменов, если сессия общая.

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

SEO и индексирование

После релиза проверьте на основных шаблонах:

HTTP-статус;
<title> и основной заголовок;
meta robots;
заголовок X-Robots-Tag;
canonical;
hreflang, если используется;
robots.txt;
sitemap;
отсутствие ссылок на staging;
микроразметку, если она менялась;
рендеринг важных ссылок и контента без авторизации.

Особое внимание — noindex. По правилам Google он может быть задан как HTML-тегом, так и HTTP-заголовком. Одной проверки исходного шаблона недостаточно.

robots.txt не следует использовать как способ canonicalization, а закрытая от обхода страница может не позволить поисковому роботу увидеть noindex. Поэтому сравнивайте назначение каждого механизма, а не просто наличие файла.

Аналитика и реклама

Проверьте:

загрузку нужного контейнера;
отсутствие staging-идентификатора;
одно событие на одно действие;
UTM и источники;
ecommerce-события и сумму;
согласие пользователя и региональные условия;
отсутствие персональных данных в URL и аналитических параметрах;
конверсии формы, заказа и оплаты;
рекламные пиксели, если они входят в область релиза.

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

Кеш и производительность

После публикации возможны две противоположные ошибки:

пользователи получают старый код из кеша;
кеш полностью сброшен, и сервер временно перегружен.

Проверьте:

версионирование статических файлов;
CDN и браузерный кеш;
кеш шаблонов и данных;
согласованность между нодами;
корректное прогревание;
время первого и повторного ответа;
тяжёлые запросы;
CPU, память, диск и соединения;
ошибки JavaScript на ключевых страницах.

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

Что проверить после обновления 1С-Битрикс

Общий чек-лист дополняется специфическими проверками.

До обновления

[ ] лицензия и доступ к обновлениям в ожидаемом состоянии;
[ ] известны текущие версии ядра и модулей;
[ ] проверены системные требования;
[ ] полная копия включает файлы, ядро и базу либо есть другой согласованный механизм восстановления;
[ ] архив проверен на целостность;
[ ] кастомизация ядра и модулей известна;
[ ] staging максимально близок к production;
[ ] обмен с 1С, cron и агенты не выполняют опасную операцию;
[ ] план восстановления учитывает изменение базы.

Сразу после

[ ] административная часть открывается;
[ ] авторизация администратора и пользователя работает;
[ ] «Проверка системы» не показывает новое критическое отклонение;
[ ] журнал событий и PHP-логи не содержат повторяющейся новой ошибки;
[ ] публичные компоненты не показывают исключение;
[ ] кеш и композитный режим работают ожидаемо;
[ ] файловые права не изменились;
[ ] агенты и cron запускаются;
[ ] почтовые события обрабатываются;
[ ] Marketplace-модули совместимы;
[ ] правила проактивной защиты не блокируют легитимный путь.

Для магазина

[ ] каталог и торговые предложения доступны;
[ ] цены и остатки соответствуют контрольным значениям;
[ ] корзина сохраняется;
[ ] скидки рассчитываются;
[ ] заказ создаётся;
[ ] платежи и доставки доступны нужным типам плательщика;
[ ] письма по заказу отправляются;
[ ] экспорт заказа в 1С не нарушен;
[ ] импорт каталога проходит на тестовом изменении;
[ ] обмен не создаёт дублей и не деактивирует неожиданные товары.

Настройки импорта важны: 1С-Битрикс позволяет выбирать действия над товарами, отсутствующими в CommerceML-файле, включая удаление, деактивацию или сохранение. После изменения модуля обмена контроль массовых изменений обязателен.

Как принять решение об откате

Откат оправдан, когда:

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

Но откат не всегда прост:

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

Поэтому перед откатом:

остановите дальнейшее влияние;
зафиксируйте текущую версию и время;
оцените новые пользовательские данные;
выберите roll back, roll forward или отключение функции;
сохраните доказательства;
выполните утверждённый план;
повторите весь критический контроль.

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

Когда релиз можно закрыть

Релиз завершён, когда:

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

Команда может завершить окно, но оставить релиз в статусе наблюдения до ночного обмена. Это честнее, чем поставить «готово» до проверки асинхронной части.

Копируемый post-release чек-лист

# Проверка после релиза [ID]

Production URL: [адрес]
Версия: [идентификатор]
Начало: [время]
Проверяющий: [имя]

## Немедленный контроль

- [ ] DNS, TLS и редиректы корректны
- [ ] Основные URL отвечают ожидаемо
- [ ] Новая версия активна
- [ ] Миграции завершены
- [ ] Нет массовых 5xx и критических ошибок
- [ ] Вход и права работают
- [ ] Стоп-условия не сработали

## Бизнес-пути

- [ ] [Путь 1] — доказательство: [факт]
- [ ] [Путь 2] — доказательство: [факт]
- [ ] [Путь 3] — доказательство: [факт]

## Интеграции

- [ ] Почта / CRM
- [ ] Оплата / доставка
- [ ] 1С
- [ ] Webhook / API
- [ ] Cron / агенты / очереди

## Поиск и аналитика

- [ ] robots.txt
- [ ] noindex / X-Robots-Tag
- [ ] canonical / sitemap
- [ ] аналитические события без дублей
- [ ] нет staging-идентификаторов

## Стабильность

- [ ] Ошибки в исходном диапазоне
- [ ] Время ответа не ухудшается
- [ ] Ресурсы стабильны
- [ ] Очереди обрабатываются
- [ ] Мониторинг снят с технического окна

## Отложенный контроль

- [ ] [задача] — проверить в [время]

## Результат

Статус: [успешно / частично / откачено]
Окончание: [время]
Найденные дефекты: [ссылки]
Комментарий клиенту: [ссылка / не требуется]

Какие показатели собирать по релизам

Через несколько месяцев студия может увидеть качество процесса:

доля успешных релизов;
релизы с откатом;
инциденты в первые 24 часа;
время обнаружения дефекта;
время восстановления;
доля релизов с подготовленным откатом;
доля автоматизированных критических проверок;
дефекты, которые первым заметил клиент;
повторяющиеся классы ошибок.

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

Частые ошибки

Один универсальный чек-лист на все проекты

Общий каркас полезен, но критические пути, зависимости и стоп-условия должны быть проектными.

Проверку выполняет только автор изменения

Автор знает ожидаемое поведение и может не заметить отклонение. Для рискованного релиза полезна вторая пара глаз или автоматические независимые проверки.

Весь мониторинг отключается

Техническое окно скрывает реальное влияние. Подавляйте только ожидаемые события и сохраняйте запись фактов.

Откат не проверялся

Команда впервые открывает инструкцию уже во время падения. Проводите учебное восстановление заранее.

Проверяется только счастливая ветка

Ошибка часто живёт в другом типе плательщика, скидке, мобильной форме или новом пользователе. Выберите репрезентативные ветки по риску.

Релиз закрывается до фонового цикла

Импорт, очередь или отчёт могут сломаться позже. Оставьте контрольную точку.

Исправление делается прямо в production без фиксации

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

Как помогает Pingvera

Pingvera может сделать post-release проверку повторяемой:

проверить доступность и содержимое из нескольких точек;
зафиксировать изменение времени ответа;
проверить редиректы, SSL и домен;
отправить тестовую форму и подтвердить доставку письма;
контролировать страницы корзины и оформления безопасными сценариями;
принимать сигналы cron и других фоновых задач;
показать внутреннее состояние CMS и сервера при настроенной интеграции;
связать события с Telegram, email, MAX или webhook;
продолжить наблюдение после закрытия окна.

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

Сделайте проверку частью релиза: выберите пять стоп-условий и три критических пути, а затем настройте постоянный контроль в Pingvera.

Часто задаваемые вопросы

Кто должен проверять сайт после релиза?

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

Сколько времени наблюдать после публикации?

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

Нужен ли полный бэкап перед каждой правкой?

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

Что важнее: исправить на месте или откатить?

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

Как проверить оплату без реального списания?

Используйте официальный тестовый режим провайдера, если он отражает нужную интеграцию, либо согласованный ограниченный production-сценарий. Альтернатива — совокупность проверок страницы, конфигурации, callback и реальной доли успешных статусов с периодическим ручным end-to-end.

Что делать, если после релиза клиент заметил дефект первым?

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

Главное

Релиз заканчивается не тогда, когда файлы опубликованы, а когда подтверждено новое состояние production.

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

Источники и дополнительное чтение

Следующий материал курса: «Как контролировать обмен интернет-магазина с 1С и не узнавать об остановке по устаревшим остаткам».

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал