18 января 2024 г.

Валерий Немцов

В статье поговорим о том, как можно организовать интеграционное обеспечение проекта в крупном ИТ-ландшафте. Чаще всего сложности возникают в том, что количество потоков достаточно большое (300+). Надо спроектировать обмены, чтобы не осталось «белых пятен», согласовать спецификации, выдержать единство принципов сопоставления данных, продумать порядок переключения систем и затем передать на поддержку. Поэтому поделимся нашим опытом, как делать подобные проекты прозрачно, надежно и комфортно всем участникам. Рассмотрим жизненный цикл подобных работ.

1. Проектирование

Роли: Функциональный и технический архитекторы

Самый первый этап закладывает основу дальнейших работ, и он должен быть выполнен максимально качественно, чтобы избежать концептуальных ошибок. Когда мы говорим о крупном ИТ-ландшафте — это чаще всего несколько десятков информационных систем, и при проработке текущего состояния обменов и целевого состояния количество информационных потоков может достигать нескольких сотен. Такой объем данных удержать в голове и не ошибиться — крайне сложная задача, даже если у вас очень круто развита память. Здесь на выручку функциональному архитектору приходит ПО класса System of Systems Integration (в нашем случае Integration management studio — IMS), которое позволяет оперировать всем ИТ-ландшафтом в одном окне с детализацией до метаданных всех окружающих систем. При проектировании мы сначала должны поделить потоки данных на некоторые группы, которыми оперировать будет уже под силу. Чтобы это сделать удобно, предлагаем следующую классификацию:

1. По видам потоков

  • НСИ;
  • Транзакционные данные;
  • Срезы данных (цен, остатков и т. п.).

2. По сегментам данных

Здесь деление происходит по доменам информации и их сегментам. Например:

  • НСИ
    • Контрагенты
      • Поставщики;
      • Покупатели;
      • Прочие.
    • o Договоры
      • Договоры закупок;
      • Договоры продаж;
      • Договоры аренды;
      • Договоры прочей хозяйственной деятельности.
    • o Номенклатура
      • Готовая продукция;
      • Производственные полуфабрикаты;
      • Сырье.

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

На выходе мы получаем спроектированный состав интеграционных потоков.

2. Формирование требований

Роли: Функциональные аналитики

Здесь в игру вступают функциональные аналитики. Их задачей становится проработка интеграционных потоков уже с детализацией до реквизитного состава, событий наступления выгрузки и отборов, которые могут уточнять детализацию сегментов данных. Также при этом виде работ необходимо понимать текущую модель работы ИС в ландшафте и целевую. Понять, что полнота потоков на каждом этапе изменения потоков будет обеспечена и не возникнет разрывов. Работа достаточно рутинная, но требует значительной степени внимания. Чтобы снизить риски человеческого фактора при проработке потоков + повысить скорость такого описания, нам явно потребуется ПО SoS, которое позволит оперировать метаданными всех рассматриваемых систем и помогать делать автосопоставление. Также из этой работы последует определение правил идентификации данных при обмене между системами.

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

3. Разработка

Роли: функциональные аналитики, разработчики, QA

На этом этапе стоит уделить внимание понятным техническим моментам — делать хорошо, плохо не делать. А также спроектировать сам механизм обменов, чтобы он был стабильным. Применительно к крупным ИТ-ландшафтам можно утверждать, что наиболее часто встречающийся подход — использование корпоративных шин данных, т. к. это значительно повышает скорость разработки и снижает затраты на разработку интеграционного шва. (В наших работах мы чаще всего используем Datareon, т. к. это решение качественно и надежно позволяет решить задачи обменов)

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

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

На выходе мы получаем разработанные согласно ТЗ механизмы обменов, которые готовы к запуску в продуктовом контуре.

4. Поддержка

Роли: специалисты службы поддержки

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

Также необходимо понять, к каким потокам будут предъявляться наибольшие требования к производительности и критичности по скорости трансляции рассматриваемых данных в другие системы. Для этих потоков необходимо реализовать инструменты сверки данных между системами, которые при анализе выборки данных за какой-то период позволят либо показать отличия, либо убедиться в корректности обменов. Еще один из интересных артефактов вывода в продуктив интеграционных потоков — формирование инструментов мониторинга, которые позволят проактивно мониторить обмен наиболее критичными данными и оповещать ответственных об ошибках.

Ах да, куда же без корректной, живой документации? Если работа организована согласно вышеописанной методике — то мы автоматически при взаимодействии разработчиков с аналитиками в рамках 2 и 3 этапов получаем уже готовую документацию, которую не стыдно отдать группе поддержки.

5. Обеспечение службы безопасности информацией о потоках данных

Роли: специалисты службы безопасности, функциональный архитектор.

Чаще всего служба безопасности довольно плотно взаимодействует с ИТ-подразделением, чтобы иметь максимально полную и прозрачную картину по ИТ-ландшафту. Наибольший интерес представляют 2 вопроса:

  • Использование портов применительно к серверам приложений, т. к. это потенциальное окно во внешний мир.
  • Организация разделения доступа к данным разного уровня доступа — например, что одна организация не видит НСИ другой организации. Также в рамках этого пункта активно рассматривается вопрос данных, которые относятся к 152ФЗ.

Чтобы удовлетворить запросы службы безопасности оперативно, полно и без лишних издержек, на помощь приходит IMS (Integration management studio), которое нас сопровождало с самого первого этапа (проектирования).

На выходе мы получаем готовое описание системы, которое будет давать понятные ответы на вопросы по интеграционным потокам, в том числе про 152ФЗ.

Заключение

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

Источник: Валерий Немцов, компания «Константа»