Тестовый контур — это вторая, отдельная копия связки: копия базы приёмника, песочница на стороне поставщика и тот же обмен, настроенный между ними. На нём проверяют, что произойдёт, когда что-нибудь пойдёт не так, — и это единственное место, где такую проверку можно провести, не трогая работу компании.
В смете он занимает 44 000 ₽ из 398 000 ₽ — 11 % проекта надёжной интеграции. Это и делает его первым кандидатом на вычёркивание: сумма заметная, а польза не видна на демонстрации. Вычеркнув, компания получает не экономию, а перенос проверок на боевые документы: следующие две недели связку тестируют на живых заказах реальных клиентов, а следы этих проверок потом убирает бухгалтер.
Ниже — что именно входит в контур, почему обезличивание не формальность, восемь сценариев приёмки с разбором на обычные и аварийные, честный расчёт отсутствия контура на одном проекте, три обходных пути при отсутствии песочницы у поставщика и два случая, когда контур действительно не нужен.
Что входит в тестовый контур для обмена
Состав отличается от «тестовой среды вообще»: для интеграции важны не только копия системы, но и вторая сторона обмена, а её обычно контролирует не подрядчик и не вы.
- 1Копия базы приёмника
Развёртывается из свежей резервной копии, обычно на отдельном сервере или в отдельной области того же. Важна не столько актуальность, сколько полнота структуры: обмен ломается на редких сочетаниях данных, а не на типовых. Развёртывание и подготовка занимают около 4 часов, дальше копия обновляется по мере надобности, а не ежедневно.
- 2Обезличивание данных
Реальные телефоны, имена, адреса и реквизиты заменяются на сгенерированные с сохранением формата. Отдельно вычищаются рабочие адреса отправки: тестовый контур не должен уметь отправить письмо или сообщение настоящему клиенту. Скрипт обезличивания пишется один раз за 4 часа и потом применяется при каждом обновлении копии.
- 3Песочница на стороне поставщика
Отдельная тестовая учётная запись у второй системы — площадки, маркетплейса, службы доставки, банка. У части поставщиков она есть и выдаётся по заявке, у части нет вовсе. Именно эта строка чаще всего оказывается препятствием, и на неё нужен ответ до начала работ, а не после.
- 4Набор приёмочных сценариев
Восемь проверок, описанных так, чтобы их мог провести заказчик без программиста. Их составление и первый прогон — около 6 часов. Этот набор живёт дольше проекта: его повторяют после каждого обновления любой из двух систем.
Итого 14 часов работы — 42 000 ₽ по ставке 3 000 ₽/час — плюс 2 000 ₽ за сервер на первый месяц. Это и есть строка «тестовый контур на копии базы» на 44 000 ₽ в модельной смете, которую мы разбирали построчно в материале про стоимость надёжной интеграции.
Схема потоков данных в две горизонтальные зоны, разделённые сплошной линией. Верхняя зона «Боевой контур»: узлы «Система-источник» → «Обмен» → «База приёмника»; над связкой подпись «работает как обычно». Нижняя зона «Тестовый контур»: узлы «Песочница поставщика» → «Тот же обмен, отдельная копия» → «Копия базы»; рядом блок «Набор из 8 сценариев приёмки» со стрелкой ко всей нижней связке. Между зонами одна вертикальная стрелка сверху вниз, проходящая через блок-фильтр «Обезличивание: телефоны, имена, адреса, реквизиты», подпись на стрелке «резервная копия, раз в месяц». Обратной стрелки снизу вверх нет — вместо неё перечёркнутый значок с подписью «из теста в бой данные не возвращаются». Сбоку от копии базы врезка «отключены все адреса отправки: писем и сообщений реальным клиентам не уходит». Чертёжный стиль, подписи по-русски.
Обезличивание: копия базы — это ещё одна система персональных данных
Копия боевой базы с настоящими телефонами и адресами клиентов — не «тестовые данные», а полноценная база персональных данных. К ней обычно имеет доступ подрядчик, лежит она на отдельном сервере, о котором никто не помнит, и живёт дольше проекта. По требованиям 152-ФЗ это означает всё то же самое, что и для боевой базы: локализация в России, ограниченный доступ, срок хранения и поручение обработки подрядчику.
Обезличивание снимает большую часть этих обязанностей и стоит четыре часа. Главное требование к нему звучит неочевидно: обезличенные данные обязаны сохранять форму настоящих. Иначе проверки перестают что-либо проверять — обмен, отлаженный на телефонах вида «1234567», в бою упрётся в первый же номер с плюсом и скобками.
| Поле | Что нельзя делать | Что делать вместо |
|---|---|---|
| Телефон | Заменять на короткие числа или на одно и то же значение | Генерировать номер той же длины и с реальным кодом, но из диапазона, который не выделен операторам |
| Имя и наименование | Ставить «Тест1», «Тест2» — обмен не встретит длинных названий и кавычек | Подставлять сгенерированные наименования, включая длинные, с кавычками и с латиницей внутри |
| ИНН и КПП | Писать произвольные цифры: они не пройдут контрольную сумму и упадут не там, где надо | Генерировать корректные значения с верной контрольной суммой, но не принадлежащие реальным организациям |
| Адрес электронной почты | Оставлять настоящие: тестовый прогон отправит письмо живому клиенту | Заменять на домен, который заведомо никуда не доставляет, и дополнительно отключать отправку в контуре |
| Суммы и количества | Обнулять или округлять: пропадут именно те случаи, на которых обмен ломается | Сохранять как есть — коммерческой тайной они становятся только вместе с контрагентом, а контрагент уже заменён |
Самая частая авария тестовой среды — не утечка, а отправка. Копия базы разворачивается вместе со всеми настройками, включая рабочие адреса почты, телефонию и подключения к площадкам, — и первый же прогон рассылает настоящим клиентам письма о заказах, которых не было. Отключение исходящих каналов делается в тот же час, когда развёрнута копия, до первого запуска обмена, и проверяется отдельным пунктом приёмки.
Восемь сценариев приёмки, из которых четыре аварийные
Набор составлен так, чтобы его мог провести заказчик своими силами: каждый сценарий описывается как действие и ожидаемый результат, без обращения к коду. Первые четыре проверяют, что обмен работает. Вторые четыре — что он не ломается, когда что-то идёт не так, и именно они определяют, переживёт ли связка первый месяц.
- 1Обычный проход. Одна заявка доезжает от источника до приёмника со всеми полями. Проверяется не факт создания документа, а совпадение каждого поля: состав, суммы, контрагент, склад.
- 2Граничные данные. Длинное наименование, нулевое количество, дробное число, кавычки в названии, латиница и кириллица в одном поле. Половина ошибок обмена живёт именно здесь, а не в логике.
- 3Неполная запись. В заявке нет обязательного поля. Правильное поведение — не создавать документ и отправить запись в отдельную корзину для разбора, а не подставить пустое значение и продолжить.
- 4Массовая порция. 500 записей за один прогон. Проверяется, что обмен не упирается в ограничение по времени и не оставляет половину работы сделанной.
- 5Повтор. Одна и та же заявка отправлена дважды. Второго документа появиться не должно — приёмник обязан ответить «уже создано» по ключу операции. Механику мы разбирали в материале про задвоенные заказы при обмене.
- 6Отказ приёмника. Вторая система выключается на 20 минут, за это время оформляются три заявки. После включения все три должны доехать сами, без ручного вмешательства и без дублей.
- 7Медленный ответ. Приёмник отвечает через 40 секунд. Обмен не должен посчитать это ошибкой и отправить повтор — иначе один медленный ответ превращается в два документа.
- 8Откат. Неудачный выкат новой версии обмена откатывается за 15 минут, и данные, прошедшие до отката, не теряются и не задваиваются.
Сценарии с пятого по восьмой — аварийные, и ни один из них нельзя проверить на боевой базе. Чтобы проверить поведение при отказе приёмника, надо выключить учётную систему на двадцать минут в рабочий день. Чтобы проверить защиту от повторов, надо намеренно создать дубль в живом учёте. Поэтому в проектах без тестового контура эти четыре сценария просто не проверяются — и всплывают потом, в бою, в момент, когда никто к ним не готов.
Сравнение в две колонки. Левая колонка «Можно проверить и на боевой базе, с оговорками» — четыре строки: «Обычный проход», «Граничные данные», «Неполная запись», «Массовая порция 500 записей»; под колонкой пометка «останутся следы: тестовые документы и контрагенты». Правая колонка «Только на тестовом контуре» — четыре строки: «Повтор одной заявки дважды», «Отказ приёмника на 20 минут», «Медленный ответ 40 секунд», «Откат выката за 15 минут»; под колонкой пометка «на боевой базе означает остановку учёта в рабочий день». Между колонками вертикальная разделительная линия с подписью «44 000 ₽ — цена правой колонки». Чертёжный стиль, подписи по-русски.
Доля в смете: 11 % и от чего она зависит
В модельной смете надёжной интеграции «сайт — CRM — 1С» на 398 000 ₽ тестовый контур стоит 44 000 ₽ — это 11 %. Обычная вилка по рынку шире, 10–20 % от проекта, и место внутри вилки задают четыре вещи.
| Что влияет | Двигает долю вниз, к 10 % | Двигает вверх, к 20 % |
|---|---|---|
| Копия базы | База небольшая, копия разворачивается на имеющемся сервере | База в сотни гигабайт, нужны отдельный сервер и отдельные лицензии |
| Персональные данные | В обмене нет ни имён, ни телефонов — обезличивать нечего | Клиентская база, записи разговоров, медицинские или платёжные сведения |
| Песочница поставщика | Есть, выдаётся по заявке и бесплатно | Нет вовсе или платная — приходится строить обходной путь |
| Число направлений обмена | Одно направление, только чтение | Шесть направлений, запись в обе стороны, аварийные сценарии по каждому |
Отдельная статья, которую забывают заложить: сервер под контур на время проекта и на первый месяц эксплуатации — 3 500–9 000 ₽ в месяц. Дальше контур либо остаётся навсегда, если систему регулярно обновляют, либо гасится до следующего обновления, и тогда его разворачивают заново за пару часов. Второй вариант дешевле, но требует, чтобы скрипт обезличивания и набор сценариев лежали в вашем репозитории, а не в голове подрядчика.
Что стоит проверка на боевой базе
Считаем на том же проекте: обмен «сайт — CRM — 1С», компания на 50 человек, две недели проверок. Ставки: инженер 3 000 ₽/час, внутренний разбор обмена 1 100 ₽/час, бухгалтер 844 ₽/час, час простоя обмена приёма заявок 1 800 ₽.
Обратите внимание на честность этой арифметики: на одном-единственном проекте разрыв невелик. Контур становится очевидно выгодным на втором событии — при первом обновлении учётной системы, при смене версии API поставщика, при добавлении нового направления обмена. Каждое такое событие требует повторного прогона тех же восьми сценариев, и во второй раз контур уже стоит не 44 000 ₽, а два часа на обновление копии — 6 000 ₽. Что происходит с доработками при обновлениях учётной системы, мы разбирали отдельно — обновление 1С после доработок.
И вторая честная оговорка: строка «незамеченный простой» на 28 620 ₽ появляется в расчёте не автоматически. Она появляется тогда, когда непроверенный аварийный сценарий срабатывает в бою и никто этого не замечает — а не замечают именно потому, что мониторинг тоже обычно вычёркивают. Методику расчёта этой суммы мы разбирали в материале про мониторинг интеграций.
Диаграмма из двух столбцов в рублях. Левый столбец «Тестовый контур» — 51 000 ₽, два сегмента: «строка сметы 44 000 ₽» и «сервер на проект и первый месяц 7 000 ₽». Правый столбец «Проверки на боевой базе» — 57 266 ₽, пять сегментов снизу вверх с подписями: «уборка следов 5 064 ₽», «разбор документов в отчётности 2 532 ₽», «разбор дублей 2 750 ₽», «неудачный выкат 18 300 ₽», «незамеченный простой 28 620 ₽». Верхний сегмент правого столбца выделен штриховкой с пометкой «возникает, только если аварийный сценарий сработал в бою». Справа от столбцов отдельная низкая колонка «Повторный прогон при следующем обновлении» высотой 6 000 ₽ с подписью «2 часа на обновление копии». Ось — рубли. Чертёжный стиль, подписи по-русски.
Если поставщик не даёт песочницу: три обходных пути
Отсутствие тестовой учётной записи у второй системы — самая частая причина, по которой контур получается неполным. Путей три, и все они хуже настоящей песочницы; выбирают по тому, какой риск для вас приемлемее.
| Обходной путь | Как устроен | Чем рискуете |
|---|---|---|
| Заглушка вместо второй системы | Пишется простой приёмник, который отвечает так же, как настоящий: те же коды, те же задержки, те же ошибки | Проверяется ваша сторона, а не совместимость. Реальные особенности поставщика вылезут при запуске |
| Отдельная учётная запись на боевом сервисе | Заводится настоящая, но техническая учётная запись: свой магазин, свой склад, свой контрагент с префиксом | Действия настоящие: тестовый заказ может уйти в отчётность, в маркировку или клиенту. Требует отдельного соглашения с поставщиком |
| Запись и воспроизведение ответов | Реальные ответы поставщика записываются один раз в журнал и потом воспроизводятся для тестов | Ловит форматы и не ловит поведение: отказ, задержку и лимит так не проверить |
Практическая комбинация, которая закрывает почти всё: заглушка для аварийных сценариев плюс техническая учётная запись на боевом сервисе для проверки совместимости. Первое даёт возможность безнаказанно ронять приёмник, второе — убедиться, что настоящая система принимает ваши данные. Обязательное условие для второго — письменная договорённость с поставщиком о том, что эта учётная запись техническая, и её данные не попадают в расчёты и отчётность.
И отдельный вопрос, который стоит задать до подписания договора: есть ли у поставщика песочница и что в ней доступно. Если ответ отрицательный, это не повод отказываться от интеграции, но это повод заложить в смету обходной путь, а в договор — формулировку про то, чем именно подтверждается работоспособность обмена. Полный набор таких формулировок мы собрали в материале про требования к интеграции.
Два случая, когда контур не нужен
Мы зарабатываем на интеграциях и всё равно советуем вычеркнуть эту строку в двух ситуациях. Обе распознаются на первой встрече.
- Разовая миграция. Обмен выполняется один раз — перенести справочник, залить остатки, поднять историю — и после этого выбрасывается. Здесь роль контура играет сама миграция: она делается в два прохода, сначала на копии базы для подсчёта расхождений, потом на боевой. Отдельный постоянный контур строить не под что, потому что повторных прогонов не будет.
- Обмен, который ничего не меняет в приёмнике. Сценарий только читает: выгружает остатки в таблицу, забирает статусы для отчёта, собирает данные для дашборда. Ошибка в таком обмене даёт неверную цифру в отчёте, а не испорченный документ, и обнаруживается она сверкой. Контур здесь избыточен; достаточно проверки на копии данных, а не на копии системы.
Есть и третий, пограничный случай, который мы называем честно: пилот, который заведомо выбрасывается. Если связка собирается на месяц, чтобы проверить гипотезу, и все стороны понимают, что она умрёт, полноценный контур можно не строить — но тогда в проекте не должно быть ни одного шага, который пишет в учёт. Как только пилот начинает создавать документы, он перестаёт быть пилотом, и все аварийные сценарии возвращаются в список обязательных.
Проверка на боевой базе — это не экономия на тестировании. Это перенос тестирования на клиентов.
