Доработка интеграций: когда чинить, а когда писать заново

Сайт, CRM, склад, мессенджер, канал продаж: пока систем две, их связывают один раз и забывают. Через год выясняется, что заказы приходят дважды, часть заявок теряется ночью, а суммы в отчётах не сходятся. Первое желание - починить то место, где вылезла ошибка. Иногда этого достаточно. Но часто корень в самой связке: она собрана под старый объём, без описания и без присмотра. Разбираем, как оценить состояние интеграции и выбрать, что с ней делать. Примеры подобных связок у нас собраны в разделе проектов.

Почему интеграция, которая работала, начинает сбоить?

Коротко: связка ломается от изменений вокруг - обновляется чужой API, растёт объём заказов, появляется новый канал, уходит разработчик. Слабые места проявляются со временем и под нагрузкой.

Типичные причины, по которым работающий обмен перестаёт справляться.

• Чужая система обновила API. Метод сменил имя, поле стало обязательным, старый способ отключили по расписанию. Обмен перестаёт передавать часть данных, и это замечают не сразу.
• Вырос объём. То, что держало 50 заказов в день, рассыпается на 500: время ожидания растёт, запросы обрываются прежде, чем придёт ответ, повторы создают дубли. Так было, когда данные магазина понадобилось сводить в одно место в реальном времени.
• Добавили новый источник. Подключили вторую площадку или мессенджер, а правила не совпали: разные статусы, разные поля, разные форматы дат.
• О сбое узнают от клиента. За обменом никто не смотрит: логов нет, оповещения не настроены, об ошибке сообщает покупатель.
• Ушёл тот, кто писал. Нет описания и доступа, поэтому любая правка начинается с разбора чужого кода.

Как понять, в каком состоянии ваша связка?

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

Опись - это шесть пунктов.

1. Что связано. Перечислите системы и направление обмена: сайт в CRM, склад в магазин, мессенджер в CRM.
2. Какие поля переносятся. Номер заказа, сумма, статус, покупатель, адрес, даты. Отдельно отметьте поля, которые кто-то заполняет руками после обмена.
3. С какой частотой идёт обмен. Каждую минуту, раз в час, по событию. Запишите и то, как быстро данные должны появляться на другом конце.
4. Где видно, что происходит. Логи, отчёт, экран со статусом обмена. Если смотреть негде, это и есть первая дыра.
5. Кто отвечает при сбое. Человек или подрядчик, к кому идут вопросы, когда обмен встал.
6. Что должно быть при ошибке. Остановить обмен целиком или продолжить с отметкой проблемной записи, кому уходит оповещение.

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

Три пути: починить точку, переделать обмен или взять готовый коннектор

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

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

Когда достаточно точечной доработки?

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

Проверьте по этим условиям.

1. Правила обмена не менялись, меняется только поведение в одном месте.
2. Большая часть данных доходит вовремя, теряется или задваивается небольшой кусок.
3. Обе системы работают, доступ к ним есть, ограничений на правки нет.
4. Понятно, где именно ломается: по логу или по воспроизводимому примеру.
5. Исправление не требует менять формат данных, которым пользуются другие системы.

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

Когда интеграцию выгоднее переписать?

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

Признаки, что пора переделывать.

• Правила обмена живут только в коде, описания нет, и никто не помнит, почему сделано именно так.
• Объём вырос в разы, и связка постоянно упирается в таймауты и лимиты.
• Каждая правка тянет за собой остальные: чинишь одно, ломается другое.
• Нужно менять формат или набор данных, а текущая схема этого не выдержит.
• Связка держится на человеке, который её сделал, и без него нечитаема.

Переделывать стоит по частям. Сначала работает старая связка, рядом собирается новая, и обмен переключается на неё участок за участком. Риск, что в один день встанет весь обмен, так ниже.

От чего зависит цена доработки?

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

Что двигает цену.

• Есть ли описание связки. Готовая опись из шести пунктов сокращает разбор.
• Есть ли у систем API. Если обмен идёт через интерфейс, доработка проще, чем когда данные тянут из базы напрямую.
• Сколько правил. Чем больше условий, статусов и полей, тем длиннее список проверок.
• Что с доступами. Доступы к обеим системам и тестовый контур для проверки экономят дни работы.
• Нужен ли перенос данных. Если старые записи надо перекинуть в новый формат, это отдельная работа.

Если доработка на этом этапе кажется большой, опишите задачу: мы разберём её и пришлём состав работ и смету за 24 часа.

Как поставить задачу подрядчику?

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

1. Опись связки. Шесть пунктов выше: что связано, поля, частота, логи, ответственный, поведение при ошибке.
2. Что должно измениться. По шагам: приходит заказ - что с ним происходит, где он появляется на другом конце.
3. Пример на реальных данных. Один-два случая, где сейчас ломается, с номерами записей и датами.
4. Что считается ошибкой. Дубль, потеря записи, задержка дольше нужного, обмен встал молча.
5. Поведение при сбое. Остановиться или продолжить, кому уходит оповещение, что видно в журнале.
6. Доступы и тестовый контур. Куда подрядчик подключается и где проверяет, не трогая рабочие данные.
7. Кому переходит результат. Описание связки, доступы и код после сдачи остаются у вас.

Как принять доработку?

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

1. Прогон на копии. Повторите случаи из задания и убедитесь, что они обрабатываются как договорились.
2. День под нагрузкой. Дайте связке поработать под настоящим объёмом: горстки тестовых записей для проверки мало.
3. Проверка дублей. Попросите показать, что при повторной отправке после сбоя запись не появляется дважды.
4. Проверка оповещений. Смоделируйте сбой и убедитесь, что оповещение пришло и в журнале видно причину.
5. Проверка отката. Заранее решите, как вернуть прежнее поведение, если новая связка не устроит.
6. Описание в руках. После сдачи у вас есть схема связки и понятная реакция на типовые сбои.

Когда интеграция вообще не нужна?

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

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

Часто выясняется, что задача решается без достройки связки и заметно дешевле, и это тоже результат. Как мы смотрим, нужен ли вообще ИИ или автоматизация, разбирается в отдельной статье.

Частые ошибки

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

1. Чинить один и тот же обмен годами, не понимая, как он устроен.
2. Заказывать доработку без описи связки и доступа к обеим системам.
3. Принимать работу по фразе «теперь работает» без повторяемого сценария.
4. Строить связку там, где достаточно ручного шага или выгрузки по расписанию.
5. Оставлять описание, доступы и код во владении подрядчика.
6. Начинать переделку разом, без периода, когда рядом работает старая связка.

Источники

• Martin Fowler, «Strangler Fig Application» - постепенная замена работающей системы частями: Strangler Fig
• Azure Architecture Center, «Retry pattern» - повтор при временных сбоях и правило задержки между попытками: Retry pattern
• Microsoft Learn, «Circuit Breaker pattern» - как перестать долбить неработающий сервис и вернуть его в строй: Circuit Breaker
• Шаблон «Idempotent Consumer» - как не плодить дубли при повторной доставке: Idempotent Consumer
• Enterprise Integration Patterns (Hohpe, Woolf) - каталог шаблонов обмена между системами: Enterprise Integration Patterns
• Stripe Docs, «Idempotent requests» - ключ идемпотентности против задвоения операций: Idempotent requests
• OWASP, «API Security Top 10» - риски при обмене данными через API: API Security Top 10
• Google API Design Guide, «Versioning» - почему смена версии чужого API ломает обмен: Versioning

Если связка между системами уже даёт сбои, не начинайте с правок: соберите опись и покажите нам задачу - вернёмся с составом работ и сметой за 24 часа.