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

Типичная авария: как тестовый прогон создаёт боевые аккаунты

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

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

Разделение конфигураций стенда и прода по ключам и адресам

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

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

Отдельный пул номеров и почтовых ящиков для прогонов

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

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

Признаки, что стенд смотрит не туда

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

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

Правило «тестовый ключ не должен существовать в проде» и чек-лист перед первым прогоном

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

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

Частые вопросы

Как быстро проверить, что стенд не смотрит в прод?

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

Можно ли использовать боевые номера для короткого прогона?

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

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

Выгрузить их по опознавательному признаку — префиксу имени или дате создания вне обычного трафика, — удалить или деактивировать вручную, затем закрыть причину: общий ключ или общий адрес API.

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