Что нужно для интеграции
Интеграция
В рамках данного обзора речь пойдет о том, что такое интеграция, зачем она может быть нужна, а так же о том, всегда ли стоит воспринимать этот термин только в положительном аспекте.
Но, обо всем по порядку.
Примечание: Данный материал является субъективным мнением, носит чисто информативный характер, не является претензией или иным порочащим действием и ни к чему не призывает.
Интеграция это
Кроме того, стоит знать, что термин применяется во многих сферах, таких как экономика, ИТ, экология, социология и так далее. И в каждой из них под термином могут подразумеваться свои особенности.
Зачем нужна интеграция?
Теперь рассмотрим зачем вообще может быть нужна интеграция. Причины кроются как минимум в следующих аспектах:
1. Формирование ранее недоступных возможностей. В некотором смысле это как с синергией. Абстрактный пример. Допустим, в деревне Муково пекут хлеб, а в селе Сборкино собирают ягоды. Как только у них создается общий рынок, то не только в обоих деревнях становятся доступны хлеб и ягоды, но так же возникает возможность для создания иных товаров, таких как пироги, булочки с джемом и т.п.
2. Снижение издержек. Тут как минимум два момента. Во-первых, возможность более эффективно использовать постоянные издержки. Например, вместо двух полупустых складов, один, но заполненный. Во-вторых, снижение стоимости ресурсов, услуг и прочего. Например, если фрилансер Вася, который пишет сайты, объединится с фрилансером Колей, который занимается дизайном, то стоимость сайта с дизайном может быть меньше, чем если бы они занимались делом по отдельности. Причины тому различны. В частности, в такой ситуации поиск и взаимодействие с заказчиком упрощается, что снижает расходы времени и сил (соответственно, и цену).
3. Создание единой системы. У конкуренции существуют не только плюсы, но и минусы. Одним из последних являются риски, связанные со стабильностью. Абстрактный пример. Допустим, для производства товара требуется несколько видов сырья. Однако так случилось, что один из поставщиков по каким-либо причинам отказался поставлять некое сырье (по сути, это остановка производства товара, при отсутствии резерва). Конечно, если у поставщика существуют конкуренты, то найти аналог можно, но возникает масса вопросов, таких как «а достаточное ли количество?», «а в какие сроки?», «а какая цена?» и так далее. В случае же единой системы таких вопросов не возникает или их становится меньше.
4. Конкурентное преимущество. Низкие цены, возможность создавать ранее недоступный товар и прочее. Это может позволять существенно выделяться среди конкурентов, хотя и не всегда.
5. Увеличение сфер влияния или расширение. Абстрактный пример. Обычно целевая аудитория, которая заинтересована в комплексных услугах, не занимается самостоятельным решением каждой отдельной проблемы. Поэтому если, скажем, Вася пишет сайты, а Коля рисует дизайн, то эти клиенты не будут у них ничего заказывать, в случае если их услуги предоставляются по отдельности. Но, вообще пункт подразумевает больше моментов. Например, те же электронные платежные системы и расширенная доставка. Их интеграция в сайт позволяет продавать товар в меньшей зависимости от месторасположения.
6. Диверсификация. Суть в следующем. Чем больше направлений, тем меньше вероятность, что неудача в одном из них сильно отразится на общем результате. Абстрактный пример. Допустим, если выпускаются 5 разных товаров и 1-2 из них не вызвали интерес у потребителей, то всегда можно сконцентрироваться на оставшихся. А вот если товар один, то спрос на него крайне важен.
Примечание: Примеры в основном экономические, но их можно экстраполировать в другие сферы. Например, конкурентное преимущество в социальной сфере может проявляться как «для человека не составляет проблемы быстро узнать специализированную информацию». Хотя, как уже говорил, в каждой из областей может быть своя специфика.
Всегда ли интеграция это хорошо?
Так или иначе, интеграция порождает зависимости. Что, в свою очередь, приводит к возможности наличия обратной связи. А это может быть как плюсом, так и минусом.
Отвлеченный абстрактный пример. Допустим, на поверхности лежит два шарика. Если вы толкнете один, то второй сдвинется только в том случае, если его заденет первый. Но если шарики были соединены, скажем, ниткой, то вариантов становится больше. Например, если один из шариков слишком сильно толкнули, то нитка начнет тянуть второй шарик.
Если приводить более жизненный пример, то таким фактором может быть, скажем, репутация. Допустим, Вася производит коробки для сока, а Коля производит концентрат для сока. Вася и Коля объединились и дополнительно начали выпускать сок. В такой ситуации неудачный пиар кого-либо из них автоматически отразится на другом и скажется не только на продажах (что это?) сока, но и каждого из исходных товаров.
Плюс еще нюанс в том, что немаловажно с какой стороны оценивать интеграцию.
Например, чисто гипотетически, интеграция может приводить к образованию монополий и олигополий. Утрируя, было 10 поставщиков, они объединились в одного, так и появилась монополия. Для производителей товаров это меньшие риски и больше стабильности. А вот для потребителей тот еще вопрос (см. обзоры). Не говоря уже о низкой вероятности появления конкуренции.
Конечно, в реальности не все так просто, как звучит, и существуют различные механизмы, но все же.
Если приводить пример из социологии и специфику групп, то 10 девушек, которые незнакомы друг с другом, это в среднем больше шансов для мужчин, чем если эти 10 девушек тесно общаются. Банально потому, что информация становится общедоступной, плюс еше может модифицироваться и обрастать разными подробностями. В частности, если пара расстается, то нередкая ситуация, что в глазах своих знакомых противоположный партнер обрастает негативными отзывами и характеристиками. Не сложно догадаться, как подобное может сказываться в этих двух ситуациях.
Или, скажем, тот же пример с Васей, создающим сайты, и Колей, рисующим дизайн. Если клиент захочет попросить Васю написать сайт, но дизайн будет заказывать у Пети, то это может вызвать некоторые вопросы. Так, если у Васи с Колей жесткая договоренность, то заказчику придется заказывать сайт у кого-то другого или не использовать дизайны Пети.
Поэтому к интеграции стоит относится со здоровым скепсисом и рационализмом.
В одних случаях эффект от интеграции полезен каждому, в другом случае нет. Например, тот же пример с Мукино и Сборкино. Мало того, что стали доступны оба вида товаров, так еще и появились иные. А вот в примере с Васей, Колей, Петей и клиентом, тот еще вопрос, который сильно зависит от контекста ситуации.
Так же вам может быть интересен обзор типичные ошибки в бизнесе.
И, как обычно, всегда помните про здравую логику и то, что у вас своя голова.
Понравился обзор? Тогда время подписываться в социальных сетях и делать репосты!
ТЗ на интеграцию информационных систем: 5 главных вопросов аналитика
Системные и бизнес-аналитики довольно часто участвуют в проектах интеграции информационных систем. Сегодня рассмотрим, с чего начать предпроектное исследование, чтобы успешно разработать требования к интеграции и оформить их в виде технического задания (ТЗ) по шаблонам российских ГОСТ’ов (34.602-89 и 19.201-78) или международных стандартов спецификации. Также разберем, чем пакетный парсинг отличается от потоковой передачи событий и каковы сложности интеграции нескольких информационных систем с разными моделями данных.
Что такое интеграция информационных систем: краткий ликбез для бизнес-аналитика
Когда речь идет об интеграции информационных систем (ИС), под этим подразумевается односторонняя передача или взаимный обмен данными, которые в них хранятся. Выполнять такую передачу или обмен данными будет программное обеспечение (ПО), внешнее по отношению к связываемым информационным системам, или внутренние компоненты их самих. Как именно это будет происходить, решает ИТ-архитектор или ведущий разработчик, который отвечает за техническое решение. Чтобы корректно разработать требования к реализации такого ПО, аналитик должен понимать ключевые аспекты интеграции, которые мы и рассмотрим далее. С учетом современной тенденции российского (и не только) рынке к слиянию ролей системного и бизнес-аналитика, такой краткий ликбез по интеграции информационных систем пригодится начинающим специалистам обеих профессий. Итак, разработать требования к интеграции помогут точные ответы на следующие 5 вопросов.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
Ближайшая дата курса
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Зачем?
Поскольку любое исследование в бизнес-анализе начинается с определения потребности, неудивительно, что «Зачем?» — это первый вопрос при интеграции ИС. Зная ответ, аналитик сможет определить полезность и нужность, т.е. ценность интеграции для бизнеса: решает ли она реальную проблему и действительно ли эту проблему стоит решать. Например, сотрудники компании тратят 2 часа рабочего времени на внесение данных из одной информационной системы в другую. Зная количество этих сотрудников и их почасовую ставку, нетрудно рассчитать экономию от автоматической передачи данных между разными системами. Это и будет ценность интеграции в денежном выражении. Сопоставив потенциальную выгоду интеграции с затратами на ее реализацию, можно сделать выводы о периоде окупаемости интеграционного решения и его целесообразности. Подробнее о бизнес-проблемах, их причинах и следствиях мы говорили в прошлой статье.
Кроме того, понятные ответ на вопрос «Зачем нужна интеграция ИС» поможет определить сценарии обмена данными между ними, причем как в плане бизнес-процессов, так и с технической точки зрения. Иначе говоря, «Зачем?» является главным и первым вопросом аналитика в любом проекте, позволяя определить дальнейший путь выявления требований к решению и ключевые аспекты его реализации. В техническом задании на разработку ПО для интеграции информационных систем или спецификации требований ответ на вопрос «Зачем?» располагается во введении или разделах, которые описывают назначение и цели создания программного продукта.
Сколько?
Хотя главным вопросом для бизнеса являются деньги и то, что с ними связано, здесь речь идет не о стоимости интеграционного решения, а о том, какое количество ИС необходимо связать между собой. Если нужен обмен данными между всего 2-мя «коробочными решениями», а бизнес не планирует строить полноценную инфраструктуру данных, добавляя десятки специфических ИС для поддержки различных процессов и направлений деятельности, то границы проектируемого интеграционного ПО могут располагаться внутри 2-х связываемых систем. Когда речь идет о создании корпоративной дата-магистрали, к которой подключено много ИС, при разработке ТЗ аналитику нужно тщательно проработать требования к внешним интерфейсам, которые будут обеспечивать многосторонний обмен данными.
На основании этих требований и особенностей самих связываемых систем ИТ-архитектор принимает решение о модели интеграции. Например, это может быть общая шина предприятия (ESB, Enterprise Service Bus) с очередью сообщений, набором коннекторов к источникам и приемникам данных, а также объединяющей программной платформы. Или реализация CDC-подхода, когда с помощью триггеров отслеживаются и обрабатываются изменения в базах данных прикладных систем (Change Data Capture), сливаясь в единое корпоративное хранилище (DWH, Data WareHouse). Или же обмен данными по запросу через удаленный вызов процедур из одной системы и обращение к конечной точке другой методами RESTful-API. Подробнее о способах интеграции ИС с технической точки зрения мы поговорим в следующий раз. А пока отметим, что при разработке ТЗ или спецификации требований информация о количестве связываемых ИС и их архитектурных особенностях будет отражена в разделе «Ограничения дизайна и реализации».
Какие данные?
Этот вопрос касается структуры данных, которыми будут обмениваться связываемые системы. Каждая ИС имеет свою модель данных – чаще всего она является реляционной, где информация структурирована в связанные таблицы. В реляционной модели каждая таблица имеет заранее определенное количество столбцов для хранения данных конкретного типа: целочисленных, символьных и пр. Некоторые СУБД поддерживают не только реляционную парадигму – они называются NoSQL и хранимые в них данные могут иметь различную структуру, например, как JSON-файл со множеством ключей. Поскольку каждая ИС имеет свою уникальную модель данных, интеграция – это не просто передача записей (или значений отдельных полей) из одной таблицы в другую. Поэтому в функциональных требованиях к интеграционному решению аналитик указывает, какие данные будут передаваться, в каком виде они изначально хранятся в источнике и как будут ложиться в приемник. При этом в функциональные требования также включается преобразование значений, например, приведение к единообразной форме отображения адресов, личных данных клиентов или названий предприятий.
Например, в одной системе адрес хранится в одном поле таблицы строкового типа, а в другой – разбит на несколько отдельных полей с разными типами данных: индекс, область, город, улица, номер дома, корпус, квартира. В этом случае интеграционное решение будет выполнять синтаксический анализ (парсинг) исходных данных, чтобы выделить разные значения из единой строки и записать их в различные поля модели данных системы-приемника. Аналогичный парсинг будет выполняться и для сложных типов данных в случае интеграции нескольких систем, например, при разборе сообщений, хранящихся в очереди корпоративной ESB-шины. Описать данные, которыми будут обмениваться интегрируемые системы, а также сопоставить компоненты одной модели данных и другой поможет техника под названием «Словарь данных», которую мы недавно разбирали здесь. В дополнение к этому будет полезно показать источники и приемники данных с процессами их преобразования. Сделать это можно с помощью диаграмм потоков данных (DFD, Data Flow Diagram), которые мы разбирали в этой статье.
Проектирование интеграции с веб-сервисом
Все больше и больше аналитиков, проджектов и продактов приходят в айти из маркетинга, консалтинга, продаж и других нетехнических индустрий, да и вообще без опыта работы. И я тут не стал исключением. Существует проблема, что в первые годы на тебя падает немерено технических терминов и концепций, ты пытаешься в них разобраться, но не понимаешь до какого уровня деталей тебе надо опускаться в каждой из них. Надо ли разбираться, что значит обнаруженный тобой термин WSDL и какие бывают виды асинхронного выполнения запроса, или достаточно знать, что у веб-сервиса просто есть запрос и ответ? Статья нужна, чтобы решить эту проблему для одной из самых частых фичей – научиться работать с веб-сервисом для обмена данными, выполнения целевых действий в других системах и прочих интеграций.
На русском и английском есть куча материала про то, зачем нужны веб-сервисы, какие они бывают, как их спроектировать, есть прикольные кейсы. Но про то, как взаимодействовать с ними на практике, особенно на сложных корпоративных системах, я не нашел ничего исчерпывающего. А как показывает опыт, черт кроется именно в деталях и подпунктах, большинство из описанных в этой статье – мои собственные «шишки».
Представь, что тебе надо сделать такую штуку: в зависимости от ответа веб-сервиса, который угадывает зарплату человека, отобразить пользователю кнопку разного цвета. Скажем если зарплата до 20 тыс. рублей, ты делаешь красную кнопку, если от 20 до 100 тыс., то желтую, и если она больше 100 тыс., то зеленую. Казалось бы, что может быть проще! Но чтобы описать эту задачу для разработки и разобраться во всем самому, тебе будет не лишним обратить внимание на 15 разных вопросов, а если фича безумно важная, то еще на 8 других.
Ну чего, погнали, программа минимум:
Найди или попроси страницы с описанием веб-сервиса и задачи, в которых кто-то описывал интеграцию с ним. Проверь наличие всех пунктов ниже, чтобы не раздражать человека, спрашивая лишний раз 🙂
Продовые и тестовые ссылки / адреса (англ. Endpoints PROD, QA / TEST). Веб-сервис доступен именно по этим адресам. Ссылка на тестовый контур будет полезна, чтобы проверить работу сервиса, не внося изменений и не нагружая прод. Ссылки очень похожи на адреса обычных сайтов по формату, часто в них будет содержаться слово “api”. Можно попробовать открыть их в браузере, и иногда что-то отобразится.
Тут веб-сервис поиска в Youtube выдал ошибку, поскольку ожидал, что в запросе мы передадим ключ API (выдается на их сайте, индивидуальный для каждого)
Аутентификация. Как мы будем авторизоваться в веб-сервисе, чтобы он нам отдал нужные данные? Тут много разных вариантов: по ключу API, токену, логину и паролю в теле запроса, бывают и другие.
Примеры запросов: что передавать в веб-сервис для разных случаев, чтобы получить нужные тебе данные? Все ли эти данные у тебя есть?
Запрос в Swagger
Ответ в Swagger
Что мы делаем во время ожидания ответа от сервиса? Особенно актуально, если имеем дело с сервисами, которые долго отвечают, и это заставляет ждать живого пользователя, как в примере с разноцветной кнопкой. Пользователь может не понять, почему ничего не происходит.
Таймаут (максимальное время ожидания ответа) и реакция на него. После таймаута мы перестаем ожидать ответ и происходит определенное поведение твоей системы, к примеру отправка запроса в другой сервис. Почему перестаем ожидать ответ: либо из-за того, что не можем больше ждать, надо уже как-то реагировать, либо если спешить некуда, но мы достаточно уверены, что сервис уже не ответит. Будет круто, если сможешь получить распределение времени ответа сервиса. Можно будет поставить таймаут, к примеру, как 99 перцентиль, но чаще это уже будет описано / можно спросить разработчиков сервиса.
Характеристики полей: тип поля, обязательность и длина строки.
Тип поля. Надо следить, чтобы мы передавали в запросе поля в том же формате, который ожидает получить сервис. Самые частые кейсы тут: передаем число как строку текста “2007”, вместо 2007 и разные форматы дат и времени, к примеру Date “2007-01-01” вместо DateTime “2007-01-01 11:00:00”. Когда получаем ответ от сервиса, тоже лучше следить, что данные из ответа запроса приходят в том же типе/формате, который мы ожидаем, иначе их надо будет конвертировать (переводить) в нужный тип.
SOAP UI Swagger
Длина строк – лучше проверить, что строки текста, которые мы передаем в запросе не сожмутся. Для SOAP есть возможность посмотреть в WSDL мин / макс длину строк в символах, ищи поля minLenght / maxLength. Для REST длина строк определяется на стороне сервиса и обычно само собой подразумевается, что строки не сожмутся. Однако если ты делаешь важную фичу или передаешь текстовую строку длиной в абзац в поле, которое по смыслу должно быть коротким (Имя, Телефон, Адрес), лучше уточнить это у разработчиков сервиса.
Поведение твоей системы в случае ошибок от сервиса (англ. exception flow). Надо продумать, как реагировать на ошибки от сервиса, к примеру можно делать перезапросы по такому правилу: сервис запрашивается раз в 20 минут, суммарно до 10 раз, после чего забиваем.
Поведение твоей системы, если важные поля в ответе придут пустыми / с некорректным значением (к примеру, писать сообщение об этом). На практике такое случается частенько, пример: сервис начинает возвращать не валидированные данные из новых источников.
Полностью проверь работу интеграции на PROD / QA контуре, если есть такая возможность. Обрати внимание, что на QA контуре часто бывают моки или заглушки – когда сервис возвращает в ответе одно и то же подстановочное значение вместо нормальной обработки запроса. Если веб-сервис должен что-то сделать в другой системе, проверь, что это целевое действие выполнено, покажи запросы владельцу сервиса. На практике довольно часто всплывают проблемы именно на этом этапе.
Нагрузка. Обсуди с владельцем сервиса частотность вызова его сервиса, изменение нагрузки в течение суток / недели, а также ее потенциальные изменения в будущем.
Делать ли логирование запроса и ответа. Есть много плюсов: можно отслеживать баги, фрод, смотреть сколько было запросов сервиса суммарно.
интерфейс для просмотра логов Kibana
Кэширование ответа сервиса. Если есть вероятность, что в течение короткого времени потребуется вызов сервиса с такими же параметрами запроса и предполагается, что ответ не будет меняться, то можно этот ответ сохранить, чтобы не вызывать сервис еще раз. Особенно актуально, если вызов сервиса является небесплатным и небыстрым.
Левел 2. Эти моменты лучше проверить, если фича важная:
Доступность сервиса в зависимости от времени. Если у сервиса есть “часы пик” во время которых он становится менее доступным, следует это учесть во время планирования работы с ним: предупредить пользователей, внимательно продумать реакцию на таймаут и ошибки в ответах.
Алерты. Если успешный ответ от сервиса является критичным, можно настроить алерты на ошибки, доступность или резкое изменение среднего значения в ответе / доли определенных значений.
Надо ли реализовать логику обработки ответа на стороне веб-сервиса. На нашем примере с разноцветной кнопкой в зависимости от полученной в ответе зарплаты: можно сделать эту логику в твоей системе (часто самый простой вариант), однако если границы 20 и 100 тыс. предполагается часто менять, а также классификацией красный / желтый / зеленый будут пользоваться другие люди и системы, может иметь смысл доработать сервис и передавать в ответе сразу цвет кнопки. Иначе запросто может возникнуть рассинхронизация и одинаковые по зарплате люди будут с разными кнопками.
Меняется ли структура ответа в зависимости от параметров запроса? К примеру, в запросе есть параметр “strategy”, в зависимости от которого в ответе возвращается разное число параметров. Наша система должна учитывать это.
Логика обработки ответа. Если ты меняешь существующую интеграцию с веб-сервисом, не забудь о том, что на вашей системе может быть логика, которую надо обновить. К примеру, вы считываете только определенные поля из ответа и надо добавить новые.
Левел 3. Самый важный проект за год, баги недопустимы!
Примеры ошибок. Возможно, потребуются сценарии и алерты на разные ошибки. Так ошибки описаны у Яндекс.Толоки
Невыполнение целевого действия при успешных ответах. Бывают случаи, когда сервис в случае невыполнения целевого действия возвращает 200 OK (код об успешном выполнении). Пример: сервис сам передает запрос в другой сервис после нашего запроса, но не дожидается ответа от него и сразу шлет 200 OK, но на самом деле целевое действие еще могло не успеть произойти и должен быть ответ с кодом 201 Created.
Синхронное / Асинхронное выполнение запроса. При Синхронном выполнении запроса, он обрабатывается сразу при получении. При асинхронном взаимодействии запросы попадают в очередь на стороне сервиса и целевое действие сразу не выполняется. У владельцев или пользователей сервиса можно узнать, сколько в среднем событие лежит в очереди и сколько еще требуется времени на обработку запроса. Успешные коды 201 и 202 намекают на асинхронность. Если ты их получил, лучше проверить, что целевое действие выполнится.
Самые популярные HTTP статус коды
Спасибо за внимание! Делитесь в комментах своими кейсами.
Как сделать хорошую интеграцию? Часть 1
Вопрос в заголовке включает в себя неочевидную часть, ведь перед тем, как рассказывать про создание хорошей интеграции стоит определить, какую интеграцию мы считаем хорошей. А ответ на этот вопрос не однозначен.
Что такое хорошо, определяют наши ценности, а они у всех разные. Поэтому для кого-то хорошая интеграция — это та, которую написал сам, где все красиво, и нет костылей, обходящих ошибки навязанных средств. Для других — это та, которая работает на базе надежных, проверенных временем инструментах и концепциях. А для третьих — наоборот, использующая самые современные, передовые технологии и подходы. Но это все — неверный подход, потому что опирается он на мнение создателей интеграции, а смотреть надо с позиции тех, кому эта интеграция приносит ценность.
Кому же интеграция приносит ценность? В первую очередь — пользователям, которые в результате могут совместно использовать несколько систем. И им важно, чтобы интеграция работала быстро и без ошибок. А когда ошибки и случались бы, то быстро и технологично исправлялись бы, и не только в коде, но и в данных. Еще пользователям важно, чтобы интеграция была адаптивна к изменениям и развитию этих систем, чтобы ее расширение не требовало больших трудозатрат и не становилось ограничением развития, равно как и масштабирование по объемам передаваемых данных.
Обо всем этом я написал статью, опираясь на опыт 25+ лет разработки и внедрения корпоративных систем, включающий разработку собственной интеграции и использование различных вендорских платформ. Статья получилась очень большая, поэтому рассказ будет в нескольких частях с продолжением. Сегодня я начну с достаточно неожиданной темы.
Хорошая интеграция – это интеграция с хорошей админкой
Почему? Потому что именно админка определяет, насколько быстро и технологично служба поддержки может разобраться с возникшими инцидентами и устранить проблему. Так что с позиции использования и эксплуатации это логично. И, казалось бы, проектировать и реализовывать ее должны именно в этой логике.
Однако, на практике дело обстоит совсем не так — разработчики начинают с выбора технологической платформы и после этого упоенно пишут ядро. А админку делают по остаточному принципу, при этом ориентируясь на ситуацию, когда инциденты — редки и уникальны. Конечно, этому есть причины. С одной стороны, разработчики верят в свой код, который (конечно) будет работать правильно и без ошибок. А, с другой стороны, заказчик хочет сократить стоимость, поэтому тоже верит разработчикам. Ну, или делает вид, что верит, при этом имея План Б — жестко связать их SLA оперативного исправления инцидентов. Обычно такой план срабатывает плохо, — и теряет от этого, конечно, бизнес. Потому что в ситуации, когда админка только показывает ошибку, но не позволяет с ней работать, служба поддержки обращается к разработчикам для разбора инцидентов. Те разбирают инциденты вручную долго и дорого, напрямую работая с базой данных или через технические средства для прямых обращений по http или другим протоколам.
А инцидентов может быть много. Мир не стоит на месте, и интегрируемые системы регулярно развиваются и обновляются. Далеко не всегда доработки ведут опытные разработчики, знакомые с кодом, их вполне могут отдать новичкам без достаточного опыта, потому что авторы кода делают новые проекты, и, возможно, уже в другой компании. По разным причинам очередной релиз могут выпускать быстро, без полноценного тестирования.
Да и при тестировании очередное неудачное обновление с ошибкой запросто может породить вал из сотен или тысяч ошибок. Все таки тестовый контур не полноценно эмулирует реальный поток данных. Особенно, если этот поток новый и касается функционала, которого раньше не было. А ограничения целостности в сложном IT-ландшафте носят распределенный характер и изменения данных, допустимые в одной системе, могут оказаться неприемлемыми в другой, об этом мы отдельно поговорим в статье.
Также встречаются ошибки, которые проявляются только в каких-то редких ситуациях и потому сложно локализуемы. Но при этом регулярно повторяются по десятку в месяц или, что еще хуже — всплесками в сотню штук раз в полгода. Потом выясняется, например, что из-за внутренней ошибки Oracle некоторые транзакции завершаются не совсем корректно. Вполне может быть, что где-то в глубине инцидентов об этом уже несколько лет стоит баг, запланированный к устранению в будущем, а пока для этих ситуаций предлагается workaround. Другой пример, когда разработчики обнаруживают ошибку в собственном старом коде.
Поэтому хорошая интеграция — это такая, в которой админка позволяет быстро и технологично разбираться с инцидентами. Что же такая админка должна поддерживать?
При обработке сообщений
Прием сообщений не должен полностью останавливаться на первой же ошибке
Остановка потока при любой ошибке — очень плохо, так как при любой частной ошибке, вызванной, например, обработкой нового типа сообщений, мы получаем вал инцидентов и нарушение взаимодействия систем. После исправления остановленный поток будет невозможно обработать быстро, при этом среди необработанных сообщений могут быть важные и срочные изменения, совершенно не связанные с той самой частной ошибкой. В целом практика показывает, что большинство сообщений могут быть обработаны независимо друг от друга.
Необходимо контролировать последовательность обработки сообщений
Хотя в целом сообщения можно обрабатывать независимо, для для конкретной цепочки нарушение порядка часто чревато ошибками на системе-приемнике. При этом, сквозная нумерация всех сообщений и остановка всей интеграции из-за этого при первой же ошибке — недопустимо, как я уже говорил. А во многих случаях простая последовательная нумерация невозможна, потому что отправка и прием сообщений часто выполняется многопоточно.
Поэтому должны быть механизмы для связывания сообщений в цепочки с блокировкой последующих при ошибке внутри конкретной цепочки. Например, при разработке распределенного каталога товаров в такую цепочку выстраиваются все изменения и вызовы методов, связанные с одним объектом. А также все изменения цен и скидок на конкретный артикул, поскольку они часто взаимодействуют друг с другом.
Интерфейсы обработки инцидентов должны позволять обработать сообщения с нарушением последовательности или пропускать отдельные сообщения. Однако очень важно, чтобы обработка с нарушением последовательности была выведена на отдельные действия, чтобы избежать ошибок.
Надо уметь посмотреть сообщение, письмо или вызов, который будет выполняться
Я помню свой шок при работе с удаленными транзакциями Oracle в конце 90-х, когда выяснилось, что ошибочную транзакцию можно выполнить, но посмотреть ее содержание невозможно. Поэтому важно показать не только конверт сообщения, но и внутреннее его содержание в структурном виде, несмотря на обобщенный характер таких интерфейсов.
Длинный упакованный xml или json — не слишком хороший вариант. Особенно сложно, когда у нас есть несколько конвертов, а внутренние сообщения шифруются и, в том числе, потому, что их содержание не всегда должно быть доступно службе поддержки. Тут могут быть неразрешимые ситуации, когда инженер поддержки не может разобраться с ошибкой, потому что не видит содержания сообщений, а бизнес-специалист, имеющий доступ и способный провести диагностику, не использует служебный интерфейс службы поддержки.
Надо уметь запустить сообщение на обработку в системе-получателе
Это актуально, если при обработке была внутренняя ошибка в коде или данных, которую исправили. Это часто бывает при расширении протокола интеграции — новые поля обрабатываются неверно, ошибку исправляют, и после этого для исправления данных необходимо повторно обработать сообщения. Аналогично может быть нужно, если сообщения оказались чувствительны к порядку обработки, а это не предусмотрели.
Например, в систему обработки заказов вдруг приходит с сайта заказ на товар, которого нет в каталоге. При разборе оказалось, что новые заказы поступают сразу при создании на сайте, а каталог обновляется по ночам. Когда покупателям позволяли заказывать только тот товар, который есть в наличии, а для появления товара на сайте в третьей системе должны были принять его поставку, то остатки появлялись на сайте только на следующий день и товар успевал распространиться по всем системам. А когда покупателям позволили делать заказы на отсутствующий товар, в том числе новый, никто не подумал, что информация о нем может еще не дойти до других систем.
Надо уметь найти сообщение в системе-источнике и повторно его отправить
Иногда сообщения теряются по дороге. Протокол http не гарантирует ни доставку сообщений, ни получение ответа. При этом повторная отправка при отсутствии ответа чревата дублированием сообщений — ведь потерять могли именно ответ, а не само сообщение. Кроме того, цепочка передачи часто включает несколько этапов и получение ответа о доставки по всей цепочки не всегда просто. Аналогична ситуация и с другим транспортом. Поэтому при надежном транспорте предпочитают контролировать успешную постановку в очередь. Однако, если было выяснено, что сообщение пропущено и ожидаемые изменения не пришли, надо уметь найти сообщение в системе-источнике и повторно отправить:
Интерфейсы работы с инцидентами должны быть ориентированы на массовую обработку
Массовые ошибки будут всегда. И нужно уметь отбирать сообщения для обработки по тексту сообщения об ошибке и другим атрибутам, чтобы избежать ситуации отбора вручную, отслеживая только глазами в большой таблице, что нужно обработать, а что — нет.
При изменении объектов
Если передаются не просто сообщения, то для хорошей интеграции с технологичным решением проблем нужны дополнительные пункты:
Поддержка распределенных ограничений целостности
Бизнес-логика очень часто накладывает ограничения на атрибуты объектов не только в пределах одного объекта, но и в совокупности. Например, НДС в заказе зависит от категории товара и от налогового режима контрагента — покупателя или продавца. И такие ограничения важно контролировать, особенно если ошибки ведут к налоговым или другим регуляторным последствиям. В случае, если изменения происходят в рамках одной системы, контроль относительно прост: при создании заказа проверяются атрибуты товара и контрагента, а при изменении атрибутов контрагентов или товаров — что это изменение не нарушает существующих данных.
А вот если каталог товаров ведет одна система, справочник контрагентов — другая, а заказы — третья, то задача усложняется. При обработке заказа проверить атрибуты товара проблем не будет. А вот при изменении атрибутов товара или контрагента проверить заказы будет непросто. Потому что систем ведения заказов может быть много, а какие атрибуты являются значимыми — неизвестно. Можно, конечно, эмулировать двухфазную транзакцию, когда сначала во все системы посылается сообщение о намерении изменить атрибуты, и только после подтверждения всеми системами готовности к такому изменению — сообщать о нем. Но это — чрезвычайно сложный протокол. К тому же в полной реализации между подтверждением готовности к изменению и приходом новых значений система-получатель должна работать в особом режиме, обеспечивающим как принятие изменений, так и отказ от него. По сути, в этот период атрибут теряет конкретное значение, у него оказывается два варианта. И хотя я видел реализацию таких двухфазных протоколов, на практике от них больше проблем, чем пользы.
Именно поэтому в админке, с технологичным сопровождением инциденты, связанные с невозможностью принять конкретные изменения в конкретной системе, быстро, технологично диагностируются и разбираются. И принимается решение по существу: изменения могут быть отменены в основной системе, или проведены обратные изменения, или, наоборот, будет решено что такие изменения не нарушают бизнес-логику и правила проверки следует изменить:
Сверка данных
И, наконец, интеграция должна включать систему независимой сверки данных между системами в автоматическом режиме или по запросу. И хорошо, если это поддерживает админка, а не разработчик, вручную выгружающий данные из систем и сравнивающий их. Очень много ошибок, как показывает практика, связано с эффектами косвенного изменения объектов, которые не попадают в сообщения по интеграции. Например, когда изменения повешены на триггеры базы данных, и сервер приложений о них поэтому не в курсе. Поэтому важно при сверке передавать интегральные показатели, причем отражающие не только то, что попало в поток интеграции, а характеризующие множества синхронизируемых объектов в целом.
Конечно, при больших объемах независимая передача всех объектов для контроля невозможна. Однако для разбора ошибок однократная выгрузка всех объектов из обеих систем с их сверкой может оказаться вполне приемлемым решением. В случае, если их все-таки слишком много — можно проводить сверку интегральных показателей по группам объектов. Например, эффективным способом сверки часто является сравнение текстовых файлов — если их выгружать отсортированными по ключу или так, чтобы первые позиции обеспечивали текстовую сортировку. Можно пользоваться стандартным diff или его аналогами. А с некоторыми командами мы использовали такой подход не только для сортировки, но и для интеграции с legacy-системой, которая не умела выгружать изменения, в то время как по бизнес-процессам были правки документов в прошлое. Приходилось выгружать полную витрину за полтора года, а потом сортировать, сравнивать и получать ежедневную порцию изменений. И все это тянул слабенький комп под unix с помощью стандартных утилит — это было еще до эпохи облаков.
Если же по интеграции передаются вызовы процедур, изменяющие множество объектов, то результат может зависеть от состояния данных, включая обработку других сообщений, поступивших по интеграции (при том, что порядок может быть не гарантирован). Например, в одной из наших систем была передача назначения скидок, действующая на группы магазинов и товаров — интерфейс пользователя работал именно в этих категориях. И оказалось, что в системе-получателе на результат действия влияет в том числе текущее состояние классификации товаров и магазинов по группам (которое также поступало из основной системы). Поэтому последовательность обработки сообщений была очень существенной, а при ошибке вообще приходилось останавливать всю серию связанных сообщений. Переходить на низкий уровень передаче не хотелось из-за объемов информации, но работа без контроля иногда приводила к сложным ошибкам, которые было невозможно поймать. Решением стала передача в сообщении количества объектов, на которые должна подействовать скидка — сигнал об ошибке начал своевременно приходить, а так как сама ситуация была крайне редкой, ее ручной разбор не вызывал проблем.
Уведомления
Для оперативной реакции на ошибки интеграции, естественно, необходимы оперативные уведомления службе поддержки. К сожалению, ошибки интеграции часто имеют кумулятивный эффект и носят массовый характер, что часто проявляется при установке обновлений. При этом, не всегда сразу — обновления часто проносят вечером или ночью, в период минимальной нагрузки, а работа с данными, которая породит ошибки, будет на следующий день, или через день, если поток данных идет не в оперативном режиме, а по ночам. Или вообще имеет свой недельный или месячный ритм, и тогда эффект может проявиться еще более отдаленно. Поэтому чем раньше будут замечены ошибки репликаций, тем меньше придется потом исправлять в данных.
Для этого в интеграции должны быть средства для мониторинга и настройки уведомлений. Раньше для этого разрабатывали собственную систему уведомлений, а сейчас целесообразнее пользоваться стандартными средствами мониторинга, например, на основе Prometheus и Grafana. Однако, разработка системы запросов для мониторинга все равно относится к конкретной системе интеграции, потому что здесь очень важно выделить группы проблем по их критичности, чтобы обеспечить оперативную эскалацию и решение проблем. И важно учитывать, что если ошибки возникают при приеме ночного потока, то они могут блокировать нормальную работу пользователей, которые привыкли начинать рабочий день рано. В отличие от разработчиков, которые любят приходить достаточно поздно — а ведь им еще нужно время для локализации и исправления ошибок.
Продолжение следует
На этом я заканчиваю сегодняшнюю статью.
В следующий раз мы будем говорить уже про сами транзакции и их консистентность, а также про идемпотентные операции, обеспечивающие устойчивость, про обеспечение возможностей развития и некоторые другие аспекты хорошей интеграции.
На весенний и осенний сезоны 2021 года открыт прием докладов на конференции. Для 2021 года мы подготовили 14 конференций, в том числе и перенесенных с этого года. Смотрите план наших конференций на весь 2021 год с датами закрытия Call for Papers.
Изучайте, подбирайте конференцию для себя!