Гетерогенный ландшафт что это
Построение гетерогенных ИТ-ландшафтов: комплексный подход на практике
Развитие технологий обеспечило принципиально новые возможности по созданию информационных систем для крупного бизнеса и органов государственного управления. На место устаревших разрозненных решений приходят системы систем, в состав которых входит электротехническое оборудование, вычислительная инфраструктура, программное, телекоммуникационное и организационное обеспечение с учетом всех их разнообразных взаимосвязей и взаимозависимостей.
Автоматизированные информационные системы (АИС) крупного бизнеса и органов государственного управления имеют ряд особенностей. Во-первых, это многозвенная иерархическая организационная структура, распределенная по всем субъектам Российской Федерации, в которой одновременно работают тысячи пользователей. Во-вторых, подобные системы как правило интегрированы с десятками других и обрабатывают сотни транзакций в секунду, оперируют сотнями терабайт хранимых данных. Уникальность таких решений, как правило, требует от их создателей больших усилий при разработке и сопровождении, а исходный программный код насчитывает миллионы строк.
За 15–20 лет эволюционного развития систем у предприятий накопились сотни слабо интегрированных программно-технических комплексов, которые имеют в основном монолитную и клиент-серверную архитектуру. Среди типичных проблем систем такого класса – необходимость работы в нескольких приложениях одновременно и ручного переноса данных из одной системы в другую, их разрозненность и задержка актуализации. При этом приложения физически распределены по разным серверам, загрузка которых как правило не превышает 5%, и обмениваются сообщениями по принципу «каждый с каждым». Разнообразие используемых программно-технических средств и наличие большого числа подрядчиков, осуществляющих их поддержку, в отсутствие единых технологических стандартов и регламентов приводит к тому, что любая доработка требует продолжительных сроков и высоких затрат.
Предельное упрощение технической архитектуры и унификация компонентов, предоставление ИТ-инфраструктуры как сервиса (IaaS) создают возможности для масштабирования и динамического изменения вычислительных ресурсов. Развитие средств мобильного доступа и расширение М2М-взаимодействия, а также существенный прогресс в области создания решений на базе открытого ПО выводят развитие больших информационных систем на принципиально новый уровень.
В результате необходим комплексный подход к созданию АИС для крупных предприятий и государственных ведомств, в рамках которого подобные решения должны рассматриваться как система систем.
АИС как система систем
для увеличения кликните по изображению
Источник: RedSys, 2015
Комплексный подход также подразумевает рассмотрение АИС как организации, состоящей из представителей заказчика и исполнителя, которая в течение достаточно продолжительного времени реализует программу из сотен взаимосвязанных ИТ-проектов.
АИС как организация
для увеличения кликните по изображению
Источник: RedSys, 2015
Наиболее эффективный процесс создания и развития АИС основывается на гибком, итеративном и инкрементальном подходе, при котором фазы анализа, проектирования, разработки и внедрения циклически повторяются, добавляя в системы, находящиеся в постоянной эксплуатации, на каждом цикле новые востребованные пользователями функции и качества. В зависимости от сложности решаемых задач продолжительность цикла варьируется от одного до нескольких месяцев.
АИС как процесс
Источник: RedSys, 2015
В техническом задании по ГОСТ 34.602-89 нефункциональные требования к АИС прорабатываются максимально подробно, поскольку именно они определяют архитектуру системы. Функциональные требования при этом описываются на достаточно высоком уровне. Дальше проектируется архитектура, которая описывается в техническом проекте по ГОСТ 34.201-89 и РД 50-34.698-90. Параллельно с подготовкой технического проекта запускается итеративная и инкрементальная разработка. На каждой итерации уточняются функциональные требования в виде сценариев использования в отдельных документах «Проектные решения» по ГОСТ 34.003-90, которые по мере готовности утверждаются заказчиком и прикладываются затем к техническому проекту. Таким образом реализуется гибкий, итеративный и инкрементальный подход.
Преимущества комплексного подхода
Комплексный подход к развитию и применению новейших информационных технологий позволяет создать единое информационное пространство, которое обеспечивает выполнение функций организации, гибко реагирует на изменения законодательства и условия бизнеса – и все это без значительных изменений в системе в течение 10–15 лет. Он способствует повышению уровня автоматизации выполнения бизнес-процессов и государственных функций, процессов взаимодействия с контрагентами и партнерами, упрощению административных и технологических процедур. Обеспечивает мониторинг, прогнозирование и предупреждение инцидентов, удаленное управление объектами и оборудованием.
Так, Пенсионный фонд РФ в ходе внедрения ведомственной автоматизированной информационной системы нового поколения (АИС ПФР-2) разработал и уже практически создал новую инфраструктуру. Она предполагает возможность выполнения всех функций на любом уровне – для каждого территориального органа решена задача отсутствия необходимости его привязки к конкретному территориальному признаку и унификации вычислительных средств (создание типовых комплексов и использование «плоской» IP-сети). «Наша информационная система состоит из 25 подсистем, – говорит зампредседателя правления Пенсионного фонда Николай Елистратов. – Некоторые из них по своим объемам и параметрам достойны называться полновесными ИС даже на федеральном уровне». При этом только благодаря созданию «плоской сети» удалось добиться снижения удельной стоимости корпоративной сети передачи данных (КСПД) в 4,2 раза при одновременном увеличении суммарной пропускной способности в 4,6 раза.
Модернизация ИКТ-инфраструктуры проведена и в Ростехнадзоре. На место разрозненных решений пришла комплексная система информатизации (КСИ), объединяющая около 17 абсолютно разных подсистем с разным количеством пользователей. «Часть из них направлена на автоматизацию основной, а часть – управленческой деятельности ведомства. При этом все системы интегрированы между собой. В целом в ней работает около 2 тыс. пользователей из 50 тыс. эксплуатирующих организаций, – отмечает советник отдела управления специальной безопасности Ростехнадзора Марина Макарчук. – После ее внедрения в ведомстве появилась единая база организаций и единые методологические принципы ведения реестров, автоматизации госуслуг, единая база доступа к спецификациям, протоколам, техническим заданиям».
Сергей Архипенков,
директор департамента комплексных архитектурных решений RedSys
Построение информационных ландшафтов с использованием сервисных шин
Основная проблематика интеграционных ландшафтов
В современном мире бизнес-приложения практически не могут существовать без интеграции с другими приложениями. Посредством интеграции мы можем как осуществлять простейший обмен данными, так и строить сложные композитные приложения.
Однако накопленный парк приложений в силу своих архитектурных, платформенных и «возрастных» отличий имеет массу проблем интеграционного уровня.
К основным проблемам подобного типа можно отнести:
• Различные интеграционные механизмы приложений
• Несовпадающие, либо частично пересекающиеся форматы данных, избыточность передачи данных
• Отсутствие единой точки управления
• Сложности с масштабированием интеграционной схемы
• Необходимость модификации приложений-подписчиков.
A. Различные интеграционные механизмы
Большинство приложений при проектировании получают тот или иной интеграционный интерфейс. Однако каждый вендор имеет свое понимание роли приложения в интеграционной схеме. И чаще всего он видит своё приложение в центре интеграционного ландшафта (особенно этим грешат поставщики финансовых систем). Исходя из этого видения и строится архитектура интеграционной части приложения. Но так как приложения разрабатываются в различные временные отрезки, то они получают обычно те интеграционные технологии, которые доминируют в данный период. А из-за «эгоцентричной» архитектуры чаще всего закладывается одна или две из наиболее популярных технологий. В результате мы имеем набор «приложений-эгоистов», ожидающих, что вся интеграция будет строиться по заложенной в них интеграционной модели.
B. Несовпадающие форматы данных
Проблема имеет те же корни, что и рассмотренная выше. Каждое приложение помещает себя в центр интеграционного ландшафта и планирует играть по своим правилам. Приложение описывает форматы и состав данных, опираясь на свою модель данных и алгоритмических базисов. Чаще всего передаваемые данные стараются привести к полной идентичности с внутренней моделью данных приложения, чтобы избежать накладных расходов на изменение форматов. В результате мы имеем ситуацию, когда данные либо частично, либо полностью не совпадают по форматам, вплоть до разных форматов носителей. Довольно часто, при простых схемах интеграции, это приводит к необходимости многократной отправки одних и тех же данных в различных форматах.
C. Отсутствие единой точки управления
Отсутствие единой точки управления – одна из краеугольных проблем при построении интеграционных ландшафтов. Когда каждое приложение пытается управлять интеграцией со своей точки зрения, ситуация довольно быстро становится слабоуправляемой. Требуется планирование комплекса мероприятий, иногда даже не связанных друг с другом, для мониторинга и обслуживания. Возникают очаговые центры компетенции, связанные с конкретным приложением. Однако, следует отметить, что частично проблема может быть решена засчет комплексного подхода к полной автоматизации предприятия – единая платформа, единые протоколы, единые форматы, сквозная документация. Но, несмотря на прозрачность и конечность методов, в реальности такое встречается очень редко.
D. Сложности с масштабированием интеграционной схемы
Проблемы, связанные с централизованным управлением, плавно перерастают в проблемы масштабирования интеграционной схемы. Для планирования масштабирования надо воедино связать информацию: кто, когда, в каком объеме и составе передает и ожидает данные, какие форматы использует и протоколы поддерживает. В таких условиях изменение формата даже одного из пакетов информации может приводить к повышенным трудозатратам и простоям.
E. Необходимость модификации приложений-подписчиков
Для обеспечения загрузки и выгрузки данных зачастую требуется модификация приложения-подписчика. Это приводит к необходимости постоянной модификации приложений при масштабировании интеграционного ландшафта, простоям приложения в период внесения изменений, повышению вычислительной нагрузки на приложение для обеспечения интеграции; требует наличия специалистов по каждой платформе, на которой реализованы приложения-подписчики. Также это затрудняет саму модификацию систем-подписчиков, так как при планировании модификаций проектной командой приложения ей требуется учитывать и планировать необходимые доработки по интеграционной модели. При этом проектной команде либо придется самой погрузиться в архитектуру интеграционных связей, либо дополнительно привлекать специалиста, обладающего этими знаниями.
Основные подходы к построению интеграционных ландшафтов
Не секрет, что современные продукты класса ESB (Enterprise Service Bus) нацелены именно на комплексное решение перечисленных проблем интеграционных ландшафтов.
Несмотря на различные подходы и компонентную базу, все они исповедуют следующие базовые принципы:
• Стандартизация форматов
• Обеспечение подключения систем-подписчиков в единую сеть посредством библиотеки коннекторов
• Гарантированность доставки сообщений
• Перенос правил обработки и маршрутизации на глобальный уровень
• Единые механизмы протоколирования и мониторинга
• Развитые средства масштабирования.
Следуя этим принципам, для построения интеграции обычно выполняют более или менее стандартный набор работ. На первом этапе выполняются аналитическая проработка и стандартизация структур передаваемых данных. Могут быть использованы следующие подходы: подход, при котором все данные от систем-источников приводятся к единым структурам, или подход, при котором данные приводятся к структурам систем-подписчиков перед доставкой. Довольно часто используется смешанный подход к структурам данных. Первый вариант позволяет сразу при получении привести передаваемые данные к стандарту и использовать эти данные в дальнейшем (например, для динамической маршрутизации данных на основании их содержимого). При необходимости формируются шаблоны информационных пакетов. Еще одним плюсом этого подхода является то, что в этом случае все участники интеграционного процесса одинаково понимают структуру данных периметра интеграции.
Второй подход позволяет сократить накладные расходы на преобразование данных и выполнять его при получении только для систем-подписчиков, которые в этом нуждаются. При смешанной схеме преобразование либо разделяется по типам данных, либо выполняется всегда на всех точках маршрута доставки данных. Делается это для упрощения последующего сопровождения интеграционного ландшафта. Так как мы знаем планируемую структуру данных и можем четко отслеживать её инструментами мониторинга и автоматической валидации.
После определения форматов и структур данных производят формирование процессов движения информации. Различают «маршрутную» и «потоковую» схемы доставки данных. Они довольно похожи между собой, но имеют и некоторые различия.
Эта схема предполагает, что система-отправитель не должна знать о потребителях данных. В свою очередь, системы-потребители не должны зависеть от поставщика данных. Они просто получают данные, на которые они подписаны, по факту их возникновения в сети. Это позволяет строить слабосвязанные схемы с возможностью буферизации и агрегации данных. Также эта схема отличается тем, что механизмы получения, обработки и загрузки данных выделены в отдельный процесс и не связаны напрямую с процедурой маршрутизации.
Для реализации этой схемы необходимо определить:
• Типы данных и методы их извлечения
• Список получателей и условия поставки данных этого типа до обозначенных получателей
• Список маршрутов
• Набор процедур трансформации.
Важно понимать, что для каждого объекта выполняются действия, связанные только с этим объектом. То есть, для системы-источника мы определяем, какие типы данных он будет отдавать, и каким образом мы их будем извлекать; определяется механизм трансформации полученных данных (если требуется). Для системы-подписчика, в свою очередь, также определяются типы данных, которые он будет принимать, механизмы загрузки и схемы предварительной трансформации (если требуется). В маршрутах описываются условия доставки различных типов данных до каждой системы-подписчика. Такой подход позволяет легко масштабировать интеграционную схему под любые возникающие изменения.
К недостаткам этой схемы можно отнести снижение сквозной прозрачности истории прохождения данных. Этот недостаток в системах чаще всего решается инструментальными средствами мониторинга.
При этом подходе специалист по интеграции описывает полные потоки прохождения данных. Системы-источники и системы-приемники жестко связаны между собой в рамках потока.
Для полного описания потока требуется определить следующие объекты и механизмы:
• Список доступных систем-источников
• Методы подключения к системам-источникам
• Методы извлечения данных для каждой системы-источника
• Методы трансформации данных
• Методы расщепления и сложения данных
• Список систем-подписчиков
• Методы подключения к системам-подписчикам
• Методы передачи данных для каждой системы-подписчика.
Чаще всего используется подход, когда один поток оперирует каким-то одним типом данных. Однако важно понимать, что классическая модель потоков не обязана оперировать одним типом данных. Проектирование таких систем ведется через определение списка потоков, структурирование информации внутри каждого потока. Далее определяются точки возникновения информации, список получателей и необходимые для них трансформации.
Важно понимать, что каждое описание потока требует заново формировать вышеописанный список объектов и механизмов.
Недостатками этой модели являются:
• Потенциальная возможность частичного пересечения по данным в различных потоках;
• Потоки, оперирующие несколькими типами данных, усложняют понимание полной схемы и требуют схем управления данных внутри потоков (потоки в потоках). Сложность растет с ростом уровня вложенности потоков;
• Для каждого потока требуется описание всех процедур извлечения, трансформации, подключения и т.д., даже если схожие процедуры используются в соседних потоках. Возрастает сложность изменения масштаба интеграционной модели.
При любом подходе важной составляющей интеграционной модели являются схемы трансформации данных. Различаются только места, в которых описываются эти схемы. В первом случае схемы трансформации описываются относительно систем – выход системы-источника, вход системы-подписчика – и представляют собой единую процедуру обработки данных для этого источника. Во втором случае схема трансформации описывается внутри потока данных и может быть разбита на несколько независимых участков. Хочется обратить внимание, что в отличие от интеграционных моделей типа «точка-точка», процедура трансформации позволяет довольно сильно снизить нагрузку на прикладное приложение. Практически, использование ESB со схемами трансформации избавляет клиентское приложение от всей нетипичной нагрузки по обеспечению обмена. Решается одна из типовых проблем – необходимость доработки системы-подписчика.
Схемы трансформации обычно обладают следующей функциональностью:
• Изменение форматов передаваемых данных
• Изменение структуры передаваемых данных
• Обогащение данными
• Обеднение данных в целях уменьшения объема
• Разделение информационных пакетов на несколько
• Слияние нескольких информационных пакетов в один
• Валидация данных прикладными бизнес-правилами.
Также разработка схем трансформации позволяет существенно снизить объемы передаваемых данных. Это достигается за счет того, что выгрузка данных осуществляется однократно, атомарно и только в необходимом объеме. При этом инициатором выгрузки является либо событие по изменению данных, либо запрос данных от схемы трансформации в объеме, необходимом для выполнения обогащения данных.
Все действия по извлечению данных, трансформации и загрузке протоколируются и записываются в журналы различных форматов. Наиболее частым подходом является выделение отдельного сервера под хранение таких журналов. Это позволяет подключать специализированные системы мониторинга для возможности оперативного получения данных в человекочитаемом виде.
Хранение журналов разделяется на оперативное и архивное. Для оперативного хранения зачастую используются циклически перезаписываемые лог-файлы, которые по мере заполнения сбрасываются в архивное хранилище.
Отдельно протоколируются состояние объектов ESB и счетчики производительности оборудования. Это позволяет строить полную оперативную картину прохождения данных и текущего состояния системы в целом. Наиболее продвинутые решения имеют в своем составе средства проактивной диагностики состояния сети. Эта диагностика позволяет заблаговременно информировать сотрудников, выполняющих обслуживание интеграционной сети, о возможности возникновения проблемы, чтобы устранять потенциальные угрозы.
В результате мы имеем четкую и прозрачную модель данных, управляемую из единой точки и обеспеченную различными средствами централизованного мониторинга.
***
Построение информационного ландшафта позволяет решить многие проблемы, которые присутствуют при точечных интеграциях, но требует вдумчивого подхода к проектированию и выбору решения. Следует оценить плюсы и минусы реализуемых подходов и выбрать продукт, максимально обеспечивающий покрытие будущего ландшафта коннекторами, блоками трансформации, имеющий развитые системы мониторинга и проактивной диагностики. Затем выбрать подходы к проектированию схем передачи данных, оценить какой из подходов наиболее предпочтителен в вашем случае. На выходе мы получим стабильную, масштабируемую интеграционную модель с полным и централизованным управлением процессом.
У любой компании, присутствующей в интернете, есть свой IT-ландшафт. Как сделать его более эффективным?
Product Manager B2B tools в «СберМаркете»
Понятие «IT-ландшафт» появилось среди производственных компаний. Но теперь все больше высокотехнологичных бизнесов делятся, как они выстраивают свои многослойные информационные системы.
Тимофей Попов, Product Manager B2B tools в «СберМаркете», на основе своего семилетнего опыта преобразований IT-ландшафта объясняет, что собой представляют такие системы и как с ними работать.
Что такое IT-ландшафт
IT-ландшафт или IT-архитектура — это совокупность информационных систем, сервисов, услуг и продуктов, которыми компания пользуется, чтобы поддержать или улучшить свою жизнедеятельность: на производстве, в коммуникации, аналитике, учете — или получить доход.
Сейчас у любой компании, которая использует интернет для ведения бизнеса, есть свой IT-ландшафт. У небольших фирм он может быть максимально простым: состоять из одного лендинга с десятью товарами и онлайн-кассой, собираться по частям из предложений на рынке. Так быстрее и дешевле.
Но также IT-ландшафт может представлять собой целый комплекс продвинутых инструментов для управления финансами, человеческими ресурсами, продажами, маркетинговыми активностями, техподдержкой, сбором данных. Такой сложный ландшафт можно найти, к примеру, у крупных маркетплейсов и онлайн-банков. Некоторые из гигантов даже продают свои технические наработки.
На число компонентов IT-ландшафта влияет то, какой принцип использует компания для его построения: монолита или микросервисов. В первом случае все компоненты ландшафта запускаются и работают одновременно. Во втором компоненты запускаются отдельно, по требованию пользователя, но связаны между собой. Тренд на микросервисную архитектуру стал устойчивым: в 2020 году в среднем компании использовали 137 уникальных микросервисов, и это на 30% больше, чем в 2018-м.
У IT-ландшафта есть несколько классификаций:
Каждая из этих классификаций используется в зависимости от характера задачи, которая стоит перед специалистами.
Что отличает правильно выстроенный IT-ландшафт
Важно помнить, что работа над улучшением ландшафта — работа постоянная. Весь ландшафт целиком не обновляется. Всегда будут приоритетные изменения. Ведь устанавливая обновление операционной системы на свой телефон, мы при этом не обновляем само устройство.
Его «железо» остается тем же. Но через какое-то время, к примеру, через два года может понадобиться и замена деталей. Однако, если телефон можно просто сменить, сделать то же самое с системой, на которой «живет» бизнес, без его приостановки нереально.
Как выстраивать IT-ландшафт
Работу по выстраиванию IT-ландшафта курирует CTO (Chief technical officer), в чем ему помогают, в том числе, системный аналитик или продуктовый менеджер. Выбор ответственного зависит от устройства компании. Однако не менее важно, чтобы команда, которой предстоит этим заниматься, понимала, зачем она меняет ту или иную часть системы.
Кратко алгоритм работы с IT-ландшафтом выглядит следующим образом:
Для составления продуктовых методологий можно взять CJM и Canvas, архитектуру предприятия Джона Захмана, Business Process Model and Notation (BPMN) и UML-диаграммы. В моделировании хранилищ данных, связей, источников помогут ER-диаграммы, data flow digram (DFD). Для наглядного представления всего IT-ландшафта стоит использовать ARIS, Visio, Miro, MindMap. В последнем можно сделать верхнеуровневые карты.
Приведу пример из своей практики. Когда я работал в McDonald’s, нам предстояло внедрить систему онлайн-платежей. Чтобы она появилась и исправно работала, нам было нужно настроить внутренние хранилища данных и сервисы (ЦО и рестораны) так, чтобы они получали и обрабатывали транзакции и информацию о заказах из мобильного приложения.
Также нам предстояло доработать системы финансового учета и отчетности, чтобы она учитывала онлайн-платежи. И все это — с нуля, потому что предыдущий IT-ландшафт был нацелен на поддержку бизнеса только в офлайне. Для его обновления понадобилось и дополнительное оборудование, и перенастройка программ, и работа по их интеграции между собой. Зато у компании появился масштабируемый фундамент для обработки транзакций и заказов по digital-каналам.