Используйте этот чек-лист паритета стейджинга, чтобы выровнять auth, вебхуки, хранилище, cron и флаги — так ошибки в стейджинге будут повторять ошибки продакшена до релиза.
STRIPE_KEY_TEST, может скрыть отсутствие STRIPE_SECRET_KEY до дня релиза.\n\nДомены — ещё один тихий разрыв. Если продакшен на app.example.com, а стейджинг на случайном хосте, редиректы и cookie могут вести себя иначе, особенно с HTTPS и жёсткими настройками безопасности. Убедитесь, что редиректы, TLS и callback-URL настроены правильно для каждого окружения и следуют тем же правилам.\n\nНаконец, проверьте различия в рантайме, которые меняют результаты без правки кода: версии Node/Python, базовые образы ОС, версии БД и региональные настройки. Они влияют на обработку дат, пути файлов и задержки.\n\nКраткая проверка «базиса»:\n\n- Одинаковый git-коммит (или тег релиза) и та же команда сборки\n- Одинаковые ключи и типы env var (строка vs JSON), значения могут отличаться\n- Одинаковые шаблоны доменов, поведение HTTPS и правила редиректов\n- Одинаковые версии рантайма и базовый контейнерный образ\n- Одинаковые региональные настройки (часовой пояс, локаль), где это важно\n\n## Паритет аутентификации: провайдеры, редиректы, cookie и сессии\n\nАутха — то место, где «в стейджинге работает» чаще всего ломается. Рассматривайте вход как целую систему, а не как кнопку, открывающую попап.\n\nСопоставьте провайдеров идентификации, которых вы поддерживаете. Если в стейджинге включён только Google, а в продакшене ещё и GitHub или Auth0, вы не тестируете реальное приложение. Различия провайдеров меняют поля профиля, поведение подтверждения email и правила обновления токенов.\n\nЗатем сравните настройки OAuth по пунктам. Redirect URI и допустимые origin должны совпадать точно, включая протокол и поддомен. Частые ошибки:\n\n- В стейджинге разрешён http://localhost, а в продакшене требуется HTTPS\n- Несовпадение www vs без www блокирует callback\n- У провайдера до сих пор сохранены старые redirect URI от предыдущего домена стейджинга\n\nCookie и сессии тоже должны иметь одинаковые настройки безопасности. Небольшие флаги меняют всё: Secure, HttpOnly, SameSite, домен cookie и время жизни сессии. Если стейджинг на plain HTTP или другом домене верхнего уровня, поведение cookie может выглядеть «нормальным», тогда как в продакшене логин ломается.\n\nПеред релизом выполните проверку аутентификации, приближенную к реальному использованию: \n\n- Войдите через каждого провайдера, которого вы поддерживаете, затем обновите страницу и подтвердите, что сессия сохраняется\n- Пройдите восстановление пароля и подтверждение email полностью (включая ссылку в письме)\n- Проверьте в режиме инкогнито и на мобильном Safari (правила cookie отличаются)\n- Убедитесь, что logout очищает сессию и токены, а не только интерфейс\n- Прокиньте rate limits повторными попытками и подтвердите корректную обработку ошибок\n\nНе забывайте о защите, доступной только в продакшене: блокировки по IP, WAF, детекция ботов и лимиты провайдеров. Стейджинг не предупредит вас об этом, если вы это не протестируете.\n\n## Паритет вебхуков: эндпоинты, подписи и ретраи\n\nВебхуки — ещё одно место, где стейджинг может «врать». В стейджинге провайдер может указывать неправильный URL, использовать другой секрет или отправлять иной набор событий, чем в продакшене. В результате платежи, регистрации или уведомления ломаются у реальных пользователей.\n\nНачните с перечня всех отправителей вебхуков и точных событий, от которых зависит приложение (Stripe, GitHub, Slack, Zapier, внутренние сервисы). Возьмите их из дашбордов провайдеров и кода, а не из памяти.\n\nУбедитесь, что у каждого провайдера зарегистрирован и активен стейджинг-эндпоинт. Частая ошибка: «стейджинг-URL добавлен», но выбран старый эндпоинт, он отключён или настроен на другой набор событий.\n\nРассматривайте подписи как жёсткий контракт. Стейджинг должен проверять подписи так же, как продакшен: то же имя заголовка, тот же алгоритм хеширования, та же обработка raw body. Многие фреймворки ломают верификацию, если они парсят JSON до проверки подписи. Если в стейджинге пропускают проверку «чтобы быстрее», вы тестируете другое приложение.\n\nПрактическая проверка вебхуков: \n\n- Реплейте реальный продакшен-пейлоуд (с удалёнными чувствительными данными) в стейджинг и сравните HTTP-статус и время отклика\n- Подтвердите, что signing secret в стейджинге совпадает с тем, что использует провайдер для стейджинг-эндпоинта\n- Принудительно верните 500 и убедитесь, что провайдер ретраит как ожидалось\n- Проверьте идемпотентность: одно и то же событие, доставленное дважды, не должно дважды создавать заказ, списывать деньги или отправлять письмо\n- Логируйте стабильный request ID, чтобы отслеживать дубликаты при ретраях\n\nПример: Stripe ретраит payment_succeeded после таймаута. Приложение создаёт два заказа, потому что хэндлер не обеспечивает идемпотентность. Часто изменение в коде небольшое, но влияние в продакшене большое.\n\n## Паритет хранения: права, CORS и рабочие процессы с файлами\n\nЕсли приложение работает с файлами, хранилище — лёгкое место, где стейджинг может ввести в заблуждение. Сборка, которая работала с локальным диском и открытыми правами, может провалиться, как только доберётся до реального бакета со строгими правилами.\n\nСравните тип хранилища и модель доступа. Если в продакшене используется S3 или GCS с приватными объектами, в стейджинге должно быть то же самое. Различия в политике бакета, ролях IAM или настройках публичного доступа часто проявляются как «случайные» 403 ошибки, которые выглядят как баги приложения.\n\nCORS — следующая ловушка. Загрузка, работающая в одном окружении, может падать в другом, если разрешённые origin, заголовки или методы отличаются. Убедитесь, что оба окружения разрешают те же домены и тот же поток загрузки (прямая загрузка в бакет vs через ваш API).\n\nТестируйте рабочий процесс, а не только права. Используйте реальные размеры и типы файлов, а не крошечные демо-изображения. Многие ошибки связаны с обработкой MIME-типа, лимитами сервера или правилами хранения, которые отклоняют определённые расширения.\n\nКраткая проверка хранилища:\n\n- Загрузите большой файл и подтвердите, что UI показывает прогресс и корректно работает с таймаутами\n- Скачайте его тем же путём в UI, которым будут пользоваться пользователи (не через dev-шорткат)\n- Удалите файл и подтвердите, что запись и объект удалены\n- Сгенерируйте ссылку с истечением и убедитесь, что она протухает вовремя\n- Прогоните всё сопутствующее (миниатюры, OCR, антивирус) end-to-end\n\n## Cron и фоновые задачи: расписания, раннеры и оповещения\n\nПланировщик часто молча терпит сбои. Checkout может выглядеть нормально в браузере, но если ночная задача по инвойсам, чистке или отправке писем работает иначе, продакшен ломается позже, и это кажется случайным.\n\nЗапишите каждую запланированную джобу и что её триггерит: cron-расписание, воркеры очереди и таймеры внутри приложения. Если задача есть в продакшене, но отсутствует в стейджинге, стейджинг не предскажет падение.\n\nНастройки времени — классическая ловушка. Сравните часовой пояс, поведение с переходом на летнее время и что означает «полночь». Задача, которая запускается в 00:05 в продакшене, может запуститься в другое локальное время в стейджинге, обработав другой набор данных и породив пограничные кейсы.\n\nУбедитесь, что раннер задач действительно включён в стейджинге. Многие команды деплоят веб-приложение, но забывают включить планировщик, воркер-дина или контейнер. Результат — молчаливый успех: ошибок нет, потому что ничего не запускалось.\n\nПеред релизом: \n\n- Перечислите каждую задачу, её расписание и используемый часовой пояс\n- Подтвердите, что процесс scheduler/worker включён и имеет те же env var\n- Принудительно запустите ключевые задачи в стейджинге с данными, похожими на продакшен\n- Нарочно сломайте одну задачу, чтобы проверить ретраи, backoff и оповещения\n- Проверьте внешние зависимости: очереди, email/SMS, платежные API и лимиты\n\n## Feature flags: совпадение дефолтов, правил и fallback\n\nFeature flags полезны, пока стейджинг и продакшен не расходятся во мнениях о том, что «включено». Обращайтесь с флагами как с кодом: один источник, одинаковые правила и одинаковое поведение при ошибках.\n\nОпишите каждый флаг, к которому обращается приложение, и его предполагаемый дефолт. Команды часто переключают дефолты в стейджинге для демо и забывают вернуть. Так «безопасный» релиз превращается в неожиданное включение фичи.\n\nСравните, как оцениваются флаги: таргетинг по пользователю, по организации, процентные раскатки и «включено только для внутренних email». Небольшие наборы пользователей в стейджинге могут случайно пропустить важные ветки логики.\n\nПроверьте и «трубы» флагов. Стейджинг должен использовать тот же сервис флагов и ту же версию SDK, что и продакшен. Разные версии SDK могут менять кэширование, порядок оценки и обработку анонимных пользователей.\n\nХорошая проверка флагов:\n\n- Сравните состояния флагов и дефолты в обоих окружениях\n- Проверьте правила таргетинга (пользователи, организации, сегменты, процентные раскатки)\n- Подтвердите, что тот же провайдер и версия SDK задеплоены\n- Симулируйте outage (заблокируйте сервис флагов) и проверьте, что приложение ведёт себя безопасно\n- Найдите в коде хардкодовые «if staging then…» обходы\n\nОсознанно выберите fallback-поведение. Для платежей, аутха и админ-инструментов рискованно «fail open» (включать фичу при ошибке).\n\n## Как выполнить проверку паритета шаг за шагом\n\nПаритетные проверки работают лучше, когда стейджинг — репетиция, а не догадка.\n\nВыберите один критический пользовательский сценарий, который затрагивает максимальное число систем. Для многих приложений это: регистрация, подтверждение email, апгрейд, выход и повторный вход.\n\nПрогоните его в стейджинге с новыми аккаунтами и реальными браузерами. По ходу отмечайте каждый внешний вызов, который вы видите: auth, платежи, email, хранилище, вебхуки, аналитика, feature flags. Подтвердите, что у каждой зависимости есть эквивалент в стейджинге (или безопасная песочница) с совпадающими настройками, а не «похоже достаточно».\n\nПосле прогона зафиксируйте несколько деталей, пока они не забылись: какой провайдер аутх использовался, какие redirect URL сработали, запускалась ли проверка подписи вебхуков и какие фоновые задачи сработали позже.\n\nТипичная удача паритета: регистрация в стейджинге проходит, но «апгрейд» не открывает функции. Заметки показывают, что платежный вебхук указывает на старый стейджинг-эндпоинт, и событие не доходит до приложения.\n\n## Распространённые ошибки паритета, которые вызывают откаты ночью\n\nБольшинство откатов начинается с небольшой рассогласованности, которая казалась безобидной в стейджинге.\n\nПроблемы с аутхом часто «почти одинаковы»: другое OAuth-приложение, пропущенные redirect URL, домены cookie, которые не совпадают, или путь callback, отличающийся на один символ. Локально всё работает, в стейджинге — вроде нормально, а в продакшене — редирект-луп или сессия не держится.\n\nВебхуки приводят к другим проблемам. Иногда стейджинг по ошибке указывает на продакшен, отправляя тестовые события в реальные данные. Даже если эндпоинты верны, секреты подписи или настройки ретраев могут отличаться, и продакшен ведёт себя строже, чем стейджинг.\n\nСекреты — ещё одна классика ночи релиза. Удобный ключ прототипа попадает в клиентский код, в сборку или в логи. По мере роста трафика эти логи копируются и зона поражения увеличивается.\n\nПять ошибок, которые проходят ревью, но ломают релиз:\n\n- Redirect и настройки cookie отличаются на один домен или протокол\n- Стейджинг случайно обращается к продакшен-вебхукам, очередям или БД\n- Секреты печатаются в логах или встраиваются во фронтенд\n- Cron и фоновые задачи отключены в стейджинге, поэтому временные баги не проявляются\n- Дефолты или правила таргетинга feature flag различаются между окружениями\n\n## Быстрый чек-лист паритета, который можно вставить в релиз-ноту\n\nПроверки паритета перед релизом (стейджинг совпадает с продакшеном):\n\n- Сборка + рантайм совпадают: те же версии рантайма, тот же режим сборки, те же ключи env var присутствуют (значения могут отличаться) и тот же шаблон домена/субдомена.\n- Потоки логина проверены end-to-end: redirect/callback URL зарегистрированы, настройки cookie одинаковы (Secure, SameSite, домен), сессии выживают после обновления страницы, сброс пароля или magic-link письма завершаются.\n- Вебхуки как в продакшене: провайдер направлен на корректный стейджинг-эндпоинт, верификация подписи включена, ретраи не создают дубликатов, а неудачные доставки видимы.\n- Файловое хранилище работает по реальным правилам: лимиты загрузки совпадают, права совпадают (public vs private), CORS разрешает точный фронтенд-origin, ссылки для скачивания ведут себя одинаково.\n- Фоновые задачи предсказуемы: расписания совпадают, часовой пояс подтверждён, воркеры включены, ошибки оповещают ответственных, а флаги имеют одинаковые дефолты/правила и безопасный fallback.\n\n## Реалистичный пример: релиз, который сломался в первый день\n\nОдин основатель выкатил прототип SaaS с AI (собранный в Cursor и Replit), который в стейджинге выглядел идеально. Утром запуска потекли регистрации, и пришло первое сообщение в поддержку: «Я не могу войти».\n\nВ стейджинге вход работал, но у пользователей в продакшене после OAuth-callback происходил редирект на главную. Баг был прост: в продакшене использовался другой домен, а у провайдера аутентификации по-прежнему был сохранён старый redirect URI от стейджинга. Ещё хуже — продакшен-cookies ставились со строгим SameSite, поэтому сессии не сохранялись после редиректа.\n\nПока команда металась, возникла вторая проблема. Платежи проходили, но доступ не открывался. Провайдер платежей отправлял вебхуки, но приложение их не обрабатывало: эндпоинт в продакшене вообще не был зарегистрирован. В стейджинге тесты проходили, потому что команда использовала ручный переключатель «mark paid» вместо реальных вебхуков.\n\nИ ещё: загрузки файлов ломаются только у реальных клиентов. В стейджинге загрузки шли в либеральный бакет с широким CORS. В продакшене роль для записи была лишена прав, а allowed origins не включали живой домен, поэтому браузеры блокировали запрос.\n\nКороткая репетиция паритета поймала бы все три проблемы, заставив проверить конкретные интеграции: redirect URI и поведение cookie, регистрацию и верификацию вебхуков, а также права бакета и CORS.\n\n## Следующие шаги, чтобы держать стейджинг и продакшен в синхроне\n\nПаритет проще поддерживать, если его записать, автоматизировать небольшую проверку и назначить ответственного за исправление дрейфа.\n\nДержите единый источник правды для env var и интеграций. Простейшая таблица подойдёт: имя, назначение, где установлено и как выглядит «валидно» для стейджинга и продакшена.\n\nДобавьте повторяемый смоук-тест, который запускается на каждый релиз: войти, триггернуть один вебхук, загрузить файл и подтвердить выполнение одной фоновой задачи. Если что-то падает в стейджинге — остановите релиз и почините, прежде чем выучить тот же урок в продакшене.\n\nПрактический подход к решению, что должно быть реальным, а что — в песочнице в стейджинге: \n\n- Auth: реальный провайдер, отдельное приложение/клиент, стейджинг callback-домен\n- Платежи/email/SMS: песочница там, где можно, с чёткими тестовыми аккаунтами\n- Вебхуки: реальная подпись и поведение ретраев, направленные на стейджинг-эндпоинты\n- Хранилище: реальные правила бакета и CORS, но стейджинг-бакет\n- Cron/джобы: реальные расписания, но безопасные данные и получатели\n\nЕсли вы унаследовали AI-сгенерированный код и паритет постоянно ломается, проблема обычно глубже простых настроек: хардкоденные URL, раскрытые секреты, хрупкие обработчики вебхуков или фоновые воркеры, которые вообще не были подключены. FixMyMess (fixmymess.ai) помогает командам превращать сломанные AI-прототипы в готовый к продакшен код, диагностируя и исправляя проблемы с auth, надёжностью вебхуков и небезопасными настройками по умолчанию.