Изолированное нагрузочное тестирование: найдите все скрытые интеграции до production

Одно действие пользователя — это дерево запросов

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

Grafana k6 явно задаёт проверки и пороги, но сценарий контролирует только собственные действия. Успешный ответ 200 не доказывает, что сервер не обратился к боевой платёжной системе или что асинхронный worker не отправил десять тысяч писем.^[1][2]

График показывает иллюстративное дерево запросов commerce-приложения. Его задача — заставить провести инвентаризацию, а не объявить универсальный fan-out.

Sandbox-учётные данные необходимы, но недостаточны

Тестовый режим Stripe создаёт объекты отдельно от боевых. Тестовые учётные данные Twilio не тарифицируются, не меняют боевое состояние и не соединяются с реальными телефонами. Это сильная защита, но её точность намеренно неполна.^[4][6]

Twilio прямо отмечает, что тестовые SMS и звонки не запускают status callbacks. Поэтому workflow может пройти в sandbox и сломаться, когда production-callback приходит поздно, дважды или не по порядку. Для capacity-тестов sandbox провайдера стоит оборачивать детерминированным локальным двойником, а совместимость контракта проверять отдельно.^[6]

У аналитики, error tracking, feature flags и API моделей часто нет универсального безвредного тестового режима. Если тестовый контур видит публичный интернет, одна забытая переменная окружения способна превратить синтетический трафик в настоящий счёт или действие над клиентом.

Запрет по умолчанию превращает пропуски в доказательства

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

DNS важен, потому что зависимость может сменить адрес без изменения кода. Асинхронные workers важны, потому что запрос способен завершиться раньше начала побочного эффекта. Экспортёры телеметрии важны, потому что во время нагрузки могут стать самой объёмной внешней зависимостью.

Одних зелёных проверок недостаточно. Terminal evidence должно показать, что все разрешённые назначения соответствуют объявленной топологии, каждая запрещённая попытка объяснена, а teardown не нашёл состояния вне контура.

Что должен возвращать проверяемый изолированный тест

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

Teardown — часть теста. Временные данные, buckets, очереди, port forwarders, fault rules и секреты нужно удалить, а результат zero residue записать до того, как доказательства станут конечными.

• Неизменяемая топология и точный ресурсный envelope до запуска.
• Явно запрещённая внешняя сеть с проверенным списком исключений.
• HTTP-проверки по операциям вместе с утверждениями о базе, очередях и интеграциях.
• Перехваченные DNS- и сетевые попытки приложения и фоновых workers.
• Детерминированные двойники провайдеров, умеющие вернуть успех, задержку, 429, 5xx и повреждённый ответ.
• Доказательство teardown с нулём ресурсов и постоянного тестового остатка.