Во второй части разобрались с видами интеграций и как выбрать нужную.
Теперь главное не угробить её и довести до прода живой.
Как аналитик проектирует интеграцию: 5 шагов 🧠
Шаг 1. Понять зачем
Как и в любой другой задаче — сначала выясни, какую проблему решает интеграция.
Звучит очевидно, но порой от неё можно вовсе отказаться в пользу уже существующего решения. Или окажется, что интеграция уже была и просто никто её не описал 🙂
Шаг 2. Определить стороны
Кто поставщик, кто потребитель, кто владелец данных.
Договорились — зафиксировали письменно. В идеале прикладываем куда-то себе в аналитику, чтобы не потерять.
Шаг 3. Выбрать модель
Один из самых важных шагов.
Если есть архитектор — выбор модели можно дополнительно согласовать с ним.
Нет архитектора? Соберитесь с командой и обсудите варианты вместе.
Или в системе, с которой будете интегрироваться есть только Kafka, то и выбирать не придется.
Если у внешней системы есть только Kafka, то выбирать способ и вовсе не придется
Шаг 4. Описать данные
Какие поля едут, в каком формате, что обязательно, что делать если поле пустое.
Это и есть маппинг — про него у меня есть отдельный пост.
Шаг 5. Договориться об ошибках
Что делает система, если запрос упал? Таймаут? Ретрай? Алерт?
Этот вопрос часто забывают и потом на разборе инцидента кому-то приходится краснеть.
Типичные ошибки, через которые думаю многие проходили 🤦
❌ «Договорились устно»
Вы попросили команду соседнего сервиса сделать доработку, получили ответ «да, без проблем». Никто это не зафиксировал. Через месяц они выкатили релиз без вашей правки и сломали вам прод. Классика.
❌ Не проработали обработку ошибок
Happy path описан на 5 страниц, ручки готовы, диаграммки построены.
А что делать, если внешний сервис вернул 500? Все забили и потом «ой, какая-то ошибка на проде»
❌ Забыли про нефункциональные требования
Сколько запросов в секунду? Какой допустимый таймаут? Без этого интеграция может работать на стенде и падать на проде под высокой нагрузкой.
❌ Не согласовали интеграцию с обеими сторонами
Одну сторону спросили, вторую нет. В итоге маппинг написан под старую версию API.
У меня такое довольно часто бывало и теперь всегда спрашиваю ссылку на свежую доку.
Что зафиксировать в документации 📄
Базовый минимум любой интеграционной доки:
➡️ Цель интеграции и бизнес-контекст
➡️ Участники: кто поставщик, кто потребитель
➡️ Тип интеграции: синхрон/асинхрон, REST/Kafka и.т.д
➡️ Описание запроса и ответа (маппинг полей)
➡️ Обработка ошибок
➡️ Нефункциональные требования: таймауты, нагрузка, доступность
➡️ Ссылки на API-документацию внешней системы
Ну и чеклист готовности интеграции к проду
Сохраняй, пригодится:
✅ Бизнес-цель понята и зафиксирована
✅ Стороны определены, владелец данных назначен
✅ Тип интеграции выбран и обоснован
✅ Маппинг полей согласован с обеими командами
✅ Обработка ошибок описана
✅ НФТ прописаны
✅ Документация актуальна и доступна команде
✅ Тестовый стенд проверен
Раньше интеграции казались мне душной однотипной х*йней, с которой лень разбираться.
Но приняв их, вдумчиво разобравшись и проработав огромное количество становиться проще.
Надеюсь, если вы их и не полюбите, то хотя бы начнёте щёлкать как орешки.
Когда разбираешь интеграцию по частям она перестаёт пугать. Потому что за техническими терминами всегда одно и то же: две системы, которым нужно договориться. А помочь им в этом твоя работа 😉
А какой пункт из чеклиста вы чаще всего пропускаете? Признавайтесь в комментариях 👇
IT АНАЛитика | Подписаться