---
title: "Интеграции: где на самом деле срываются проекты"
url: "https://kzsaleshub.com/marshrut-integracii-i-api/"
type: "knowledge_article"
category: "Библиотека"
language: "ru"
source: "KZSalesHub"
published: "2026-08-15"
last_updated: "2026-09-30"
---

# Интеграции: где на самом деле срываются проекты

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

## Зачем это бизнесу

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

## Маршрут

| Ступень | Что читаем | Что забираем | Срок |
| --- | --- | --- | --- |
| 1. Как устроен обмен | «Web API: сборник рецептов» | Запрос, ответ, коды состояния, форматы — словарь для разговора | 2 недели |
| 2. Проектирование интерфейса | «API как искусство» | Почему интерфейс — это обещание, которое дорого менять | 2 недели |
| 3. Развитие без поломок | «Непрерывное развитие API» | Версии, обратная совместимость, вывод старого из эксплуатации | 3 недели |
| 4. Асинхронность | «Apache Kafka: потоковая обработка и анализ данных» | Очереди, повторы, порядок сообщений — что делать, когда получатель недоступен | 3 недели |
| 5. Безопасность стыка | «Хакинг API» | Где утекают данные и почему авторизация на интерфейсе обмена сложнее, чем кажется | 2 недели |
| 6. Эксплуатация | Материалы по мониторингу и наблюдаемости | Как узнавать о поломке стыка раньше, чем о ней сообщит клиент | 2 недели |

## Семь выводов — своими словами

1. **Интерфейс обмена — это договор, а не код.** После первого подключения его нельзя менять в одностороннем порядке, и это ограничение живёт годами.
2. **Документация всегда отстаёт от поведения.** Планировать нужно исходя из того, что реальные ответы будут отличаться от описанных, и закладывать время на выяснение.
3. **Отсутствие тестового контура у второй стороны — главный риск сроков.** Проверять на боевой системе либо запрещено, либо опасно, и проект встаёт до появления контура.
4. **Синхронный вызов связывает доступность двух систем.** Если внешний сервис недоступен, ваш процесс останавливается; очередь разрывает эту связь ценой усложнения.
5. **Повторная отправка обязана быть безопасной.** Сеть теряет ответы, и без защиты от повторов появляются двойные платежи и дубли заказов — самая частая ошибка в интеграциях.
6. **Ограничения по частоте обращений всплывают на нагрузке.** Их нужно выяснять на этапе проектирования, а не на этапе запуска.
7. **У каждого стыка должен быть владелец с обеих сторон.** Интеграция без имён — это интеграция, которую никто не чинит в первый час.

## Что спросить до подписания

1. Есть ли тестовый контур и как быстро в нём заводят доступ?
2. Какие ограничения по частоте и объёму обращений?
3. Как оповещают об изменениях интерфейса и за какой срок?
4. Что происходит при недоступности: очередь, отказ или ручной ввод?
5. Кто со стороны второго участника отвечает за стык по имени?
6. Как согласуются справочники: кто источник истины по клиентам, товарам, статусам?

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

## Красные флаги

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

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

**Сколько закладывать на интеграции в смете**

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

**Можно ли обойтись выгрузками файлов**

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

**Кто должен вести список стыков**

Архитектор или руководитель проекта со стороны заказчика. Подрядчик видит только свою часть, а отвечает за целое всегда заказчик.

## Связанное

- [Model Context Protocol](https://kzsaleshub.com/framework/model-context-protocol/)
- [Наблюдаемость](https://kzsaleshub.com/framework/observability-three-pillars/)
- [Цепочка поставщиков услуг](https://kzsaleshub.com/framework/service-supply-chain/)
- [Модель C4](https://kzsaleshub.com/framework/c4-model/)

*Книги названы как источники. KZSalesHub не распространяет файлы изданий.*

Интеграция — это не разовая работа, а обязательство на годы: чужая система меняется, и ваша ломается вместе с ней. Версионирование и обработка сбоев закладываются сразу, а не после первого падения.

---
Источник: https://kzsaleshub.com/marshrut-integracii-i-api/