Некоторый контент на этом сайте был создан с помощью AI

Pillar page

Интеграция систем для компаний

Объединяем ERP, CRM, бухгалтерские системы, кадрово-расчетные, KRS, MS Graph, Salesforce, SAP. Интеграции через API, очереди, ETL, вебхуки — с полным контролем качества, аудит-трейлом и производительным мониторингом.

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

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

Почему интеграции так сложны?

Каждая система имеет свою собственную модель данных, своё название для тех же полей, свою последовательность операций, свои собственные ограничения API (лимиты, задержки, временные ошибки). Две системы могут казаться «совместимыми» в теории, но на практике требуют недель работы над сопоставлениями, трансформациями, обработкой edge-case'ов и решением конфликтов.

Второй слой трудностей — это производственная надёжность. Интеграция, работающая правильно в dev-окружении, — это ~30% пути. Остальные 70% — это обработка ситуаций исключений: внешняя система недоступна, изменила контракт API, возвращает неожиданные данные, введён новый клиент в CRM с польскими символами, которых старый ERP не поддерживает. Каждый такой случай требует размышления, тестирования и оповещения, когда это происходит.

Типы интеграции

Шесть основных шаблонов. В большинстве проектов мы объединяем несколько, выбирая метод в зависимости от конкретного случая.

REST API / GraphQL

Синхронная коммуникация между приложениями. JSON в качестве формата обмена, OAuth2/JWT для авторизации, OpenAPI/Swagger для документации. Наиболее частый выбор для современных облачных систем.

Очереди сообщений

RabbitMQ, Redis Streams, Kafka — асинхронный обмен, когда отправитель не ждёт получателя. Идеально подходит для уведомлений, бизнес-событий, долгосрочных операций. Гарантия доставки + повторная попытка.

ETL / ELT

Пакетная загрузка данных в хранилище (Snowflake, BigQuery, Redshift, локальный PostgreSQL). Airflow или dbt в качестве оркестратора, валидация качества данных (Great Expectations), мониторинг lineage.

Веб-хуки

Пуш-уведомления из исходной системы (Stripe, GitHub, Slack, Salesforce) в наше приложение. HMAC-проверка подписи, идемпотентность, очередь мертвых писем для неудачных доставок.

SOAP / XML

Старые корпоративные системы (SAP, Oracle, банковское дело, страхование) — полная поддержка WSDL, XSD-валидация, WS-Security. Адаптер для современных протоколов для остальной части системы.

Базы данных — репликация, CDC

Поймание изменений данных (Debezium, AWS DMS) для потоковой репликации изменений из исходной базы в целевую. Логическая репликация PostgreSQL для высокодоступности и отчетов.

Шесть ключевых производственных проблем

Вещи, на которые мы обращаем внимание в каждом интеграционном проекте. Отсутствие одного из этих элементов = часовая бомба.

Идемпотентность

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

Повтор и откат

Временные сетевые ошибки — это норма. Экспоненциальный откат (1с, 2с, 4с, 8с...), джиттер для избежания thundering herd, цепной разрывщик после N неудачных попыток.

Отображение и преобразования

Система A называет поле "client_id", система B "customerId", система C "id_klienta". Центральный каталог сопоставлений, трансформации в одном месте, тесты каждой трансформации.

Окончательная согласованность

Данные в двух системах никогда не являются согласованными на 100% в реальном времени. Мы принимаем задержки (типично секунды), отслеживаем дрейф, оповещаем при более длительных расхождениях.

Аудит и соответствие требованиям

Каждая интеграционная операция записывает: кто/что/когда/откуда/куда, payload (анонимизированный, если содержит PII), результат. Журнал аудита соответствует требованиям GDPR и ISO 27001.

Масштабирование и затраты

Интеграции растут вместе с бизнесом. Горизонтальное масштабирование (больше экземпляров), ограничение скорости (защита от чрезмерных запросов), мониторинг затрат на каждую интеграцию.

Как мы реализуем проект интеграции

  1. Discovery (1-2 недели): сопоставление текущих потоков данных, идентификация источников правды для каждой сущности, сбор контрактов API, оценка рисков и зависимостей.
  2. Проектирование архитектуры (1 неделя): выбор шаблонов (синхронно vs асинхронно, push vs pull, hub-and-spoke vs point-to-point), схема журнала аудита, план мониторинга.
  3. Пилотный проект на одной сущности (2-3 недели): реализуем интеграцию для одного типа данных (например, клиентов) от начала до конца. Валидация контрактов, тесты нагрузки, dry-run на тестовой среде.
  4. Расширение на другие сущности (4-8 недель): последующие синхронизации (фактуры, заказы, продукты) с тем же шаблоном. Каждое внедрение предваряется Change Request и регрессионными тестами.
  5. Историческая миграция (1-3 недели): перенос существующих данных. Dry-run, аудит, план отката. Инкрементная миграция или в сервисном окне.
  6. Hypercare (4 недели после производства): интенсивный мониторинг, быстрое реагирование на инциденты, настройка оповещений. После hypercare переход к стандартному обслуживанию.

Примеры реализованных интеграций

KRS + CRBR — РеестрФирм

Микросервис, объединяющий данные из Krajowego Rejestru Sądowego (740к+ фирм) с Centralnym Rejestrem Beneficjentów Rzeczywistych. Smart кэширование (24ч), двойной источник с автоматическим fallback, 15+ REST эндпоинтов. Используется в процессах KYC, верификации контрагентов, генерации отчетов compliance.

SSO с несколькими приложениями

Центральная платформа Keycloak (realm eskom-ai) интегрирована с десятками клиентских приложений. OAuth2/OIDC + PKCE, социальный логин (Google, Microsoft, Apple, Facebook), провижининг пользователей, биллинг на основе использования токенов LLM. Single sign-on для всех продуктов ESKOM AI.

Microsoft Graph — календари, электронная почта, OneDrive

Интеграция с Microsoft 365 для автоматизации календаря (организация встреч через помощника AI), отправки транзакционных электронных писем, архивации документов. OAuth2 с делегированными разрешениями, токены обновления в Vault, мониторинг ограничений скорости Graph API.

LLM Proxy — маршрутизация с несколькими провайдерами

Центральная очередь, соединяющая несколько провайдеров LLM (Anthropic, OpenAI, локальный Ollama). Маршрутизация по заданию (простые — локальная модель, сложные — Claude Opus), кэш ответов, мониторинг затрат на проект, автоматический переход между провайдерами.

Самые частые вопросы

Что означает интеграция систем?
Интеграция систем — это процесс соединения двух или более приложений так, чтобы они могли обмениваться данными, вызывать события друг в друге и поддерживать согласованность информации. На практике: когда клиент добавляется в CRM, он автоматически появляется в ERP; когда счет выставляется в бухгалтерии, данные передаются в CRM и в аналитику. Без интеграции компания работает с данными вручную (экспортируя CSV, копируя между системами), что приводит к ошибкам, задержкам и затратам.
Какие технологии интеграции вы используете?
Выбор технологий зависит от контекста: REST API и веб-хуки для современных облачных систем, SOAP/XML для старых ERP/банковских систем, очереди сообщений (RabbitMQ, Redis Streams, Kafka) для асинхронного обмена, ETL/ELT для пополнения хранилищ данных, GraphQL когда клиент хочет гибкости. Часто мы смешиваем подходы — синхронно там, где пользователь ждет результат, асинхронно там, где важна пропускная способность.
Разваливаются ли интеграции при обновлениях исходных систем?
Это одна из самых больших проблем интеграции — и поэтому мы строим адаптеры с изоляцией (anti-corruption layer). Внешняя система меняет контракт → меняется только адаптер, остальная часть интеграции без изменений. Кроме того: контракты версионируются (v1, v2), интеграционные тесты запускаются ежедневно на sandbox API, оповещения Sentry/Wazuh при изменении формата ответа. Клиент узнает о проблеме до того, как она попадет к пользователям.
Как долго длится типичная интеграция?
Простые интеграции (одна система с другой, ~5 endpointов, один направление синхронизации) мы реализуем за 1-2 недели. Сложные (двунаправленная синхронизация, несколько сущностей, сопоставления, преобразования, дедупликация) занимают 4-8 недель. Интеграции с несколькими системами одновременно (hub-and-spoke) мы проектируем поэтапно, поставляя бизнес-ценность в итерациях по 2-3 недели.
Что с историческими данными при новой интеграции?
Каждый проект интеграции имеет отдельный этап исторической миграции. Сначала полный анализ: сколько записей, какие типы данных, где дубликаты, какие поля обязательны, а какие опциональны. Затем скрипт миграции с dry-run, аудит-трейлом (что было перенесено, что отклонено, почему) и планом rollback. Миграция выполняется в окне обслуживания или инкрементально, в зависимости от бизнес-риска.
Должна ли интеграция работать 24/7?
Зависит от бизнес-критичности. Онлайн-процессы (оплаты, авторизации) требуют высокой доступности — мы проектируем их с избыточностью (load balancer, multiple instances, health checks, auto-restart). Ночные процессы (отчеты, пакетные синхронизации) могут работать в окнах обслуживания. Каждую интеграцию мы классифицируем в SLA: время ответа p95, допустимый downtime ежемесячно, RTO/RPO.
Как вы мониторите производственные интеграции?
Каждая интеграция передает метрики в Prometheus (request rate, error rate, latency p50/p95/p99), логи в центральный SIEM (Wazuh), ошибки в Sentry. Тревоги при снижении пропускной способности, росте error rate или таймаутах. Dashboard показывает состояние всех интеграций в одном месте — оператор видит, что, например, интеграция с поставщиком X имеет 3% ошибок, в то время как остальные работают плавно.
Что с безопасностью при интеграциях с внешними системами?
Каждая интеграция использует минимальные необходимые привилегии (least privilege). Ключи и токены хранятся в HashiCorp Vault (не в файлах .env, не в коде). Коммуникация всегда через TLS 1.2+, сертификаты верифицируются (никогда verify=False). Входящие вебхуки имеют HMAC signature verification. После утечки токена — немедленная ротация, журнал аудита показывает, что и когда было сделано.
Чем интеграция через ESKOM AI отличается от классического ESB (Enterprise Service Bus)?
Классические ESB (Mule, BizTalk, WebMethods) — это монолитная платформа, дорогая в лицензиях, требующая выделенной команды. Наша модель: интеграционные микросервисы, каждая интеграция как отдельный компонент со своим deploy и мониторингом, инфраструктура основана на open source (FastAPI, RabbitMQ, Redis, PostgreSQL, Vault). Низкая стоимость лицензий, легче обслуживание, отсутствие vendor lock-in. Для части клиентов это финансовый аргумент, для части — стратегический.
Интегрируетесь ли вы с польскими государственными системами (KRS, CRBR, KSeF, ePUAP)?
Да. В производстве у нас есть микросервис, интегрирующийся с KRS и CRBR (rejestrfirm.eskom.ai — данные 740к+ компаний с beneficial owners). KSeF (электронное фактурование) — у нас есть готовые интеграционные компоненты в проекте Kontroling. ePUAP, электронные доставки — доступны через Microsoft Graph API и прямые интеграции. Полное соответствие польскому законодательству (GDPR, отчетные обязанности).

Есть ли у вас проект интеграции?

Мы начинаем с бесплатного аудита — картографируем существующие потоки данных, выявляем узкие места и предлагаем план в ясных этапах.