Интеграции до разработки: что проверить

Вернуться к блогу

Автор: Антон Горохов, Руководитель Backend направления
Опубликовано: 29.10.2026
Время чтения: 9 минут

Как подготовить интеграции к оценке до начала разработки

Hola, Amigos! На связи Антон Горохов, Head of Backend в Amiga.

Формулировки «связать сайт с CRM» недостаточно для обоснованной оценки. За ней может скрываться чтение одного справочника, двусторонний обмен заказами или критичный для бизнеса сценарий – тот, сбой которого блокирует основную работу продукта, например оплату.

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

Что нужно знать до оценки, а что можно уточнить позже

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

Этап	Что выясняют	Результат
Предварительная оценка	Бизнес-сценарий, системы и владельцы, основные данные, объемы, допустимая задержка, документация и известные ограничения.	Диапазон работ с допущениями и списком неизвестных.
Обследование	Критичные методы API, форматы, лимиты, права, ошибки и возможности тестовой среды.	Проверенные предположения и уточненная оценка.
Проектирование	Детали режима обмена, преобразование данных, повторы, очереди, хранение секретов, аудит и критерии приемки.	Спецификация для реализации и проверки.

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

Этапы подготовки интеграции к предварительной оценке

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

Если границы сценария и роли систем еще не определены, сначала полезно провести бизнес- и системный анализ перед разработкой.

Минимум для предварительной оценки

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

Какой пользовательский или бизнес-сценарий должна поддерживать интеграция?
Какие системы участвуют в сценарии и кто отвечает за каждую из них?
Какие данные передаются, в каком направлении, в каком примерном объеме и с какой допустимой задержкой?
Есть ли документация, тестовый доступ и примеры запросов или файлов?
Какие ограничения уже известны: лимиты, тарифы, сроки внешней команды или отсутствие нужных методов?

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

Карта систем показывает данные и ответственность

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

Для каждого узла достаточно зафиксировать:

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

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

Карта систем и потоков данных для планирования интеграции

Схема показывает системы-участники интеграции, направления обмена данными и зоны ответственности команд.

Для значимых данных определяют основную систему-источник

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

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

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

API проверяют на критичном сценарии

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

До фиксации оценки проверяют возможности и ограничения API, которые могут изменить способ интеграции или существенно повлиять на объем работ. Это могут быть права на чтение и изменение данных, лимиты, пагинация, форматы ответов и коды ошибок. Если доступ получить нельзя, это фиксируют как допущение и отдельно оценивают обследование.

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

Режим обмена зависит от сценария и возможностей системы

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

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

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

Сценарии сбоев влияют на состав работ

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

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

Какие ошибки допускают автоматический повтор?
Как исключить повторное создание заказа или платежа?
Кто получает уведомление и какие данные нужны для разбора?
Что видит пользователь при недоступности внешнего сервиса?
Можно ли продолжить сценарий вручную?

Ограничения безопасности выясняют до оценки

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

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

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

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

План интеграционных и регрессионных проверок стоит согласовать с QA-командой до реализации.

Зрелость внешней системы меняет уверенность оценки

Один бизнес-сценарий может потребовать разного объема работ:

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

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

Карточка интеграции собирает данные для оценки

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

Поле	Что указать
Название и цель	Какие системы связываем и какой сценарий поддерживает обмен.
Владельцы	Кто отвечает за требования, документацию и доступ с каждой стороны.
Данные	Сущности, значимые поля, основная система-источник, направление и ожидаемый объем.
Интерфейс	API, события или файлы; ссылка на документацию и версия.
Задержка	Когда данные должны быть доступны и что произойдет при опоздании.
Ошибки	Критичные сбои, что видит и может сделать пользователь при сбое, необходимость ручной обработки.
Безопасность	Способ авторизации, роли, чувствительные данные и известные ограничения.
Проверка	Тестовый контур, учетные записи, примеры данных и доступ к журналам.
Ограничения	Лимиты, тарифы, окна доступности, сроки внешней команды и известные риски.
Неизвестные	Что не подтверждено, как влияет на оценку, кто отвечает за проверку и как ее выполнить.

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

Следующий шаг

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

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