Компании, которые выстраивают свой конфигурационный учет впервые всегда сталкиваются с вопросом: “Как нам учитывать приложения при построении моделей конфигурации наших ИТ-услуг”.
Для иллюстрации приведем абстрактный пример: в компании есть некоторая многофункциональная информационная система. Пользователи используют ее для осуществления своих рабочих обязанностей, потребляя какие-то ресурсы: лицензии, подключения, мощности хранения и/или производительности. Система размещена на пуле виртуализированной вычислительной архитектуры и мощностях хранения данных, использует сетевые возможности и каналы связи для работы на различных площадках. Компания хочет уметь рассчитывать себестоимость ИТ-услуг, а также уметь оценивать влияние сбоев и изменений в инфраструктуре и приложениях.
Схема, изображенная на рисунке выше, хороша только для того, чтобы показать неискушенному менеджменту укрупненную схему “ERP, и как мы ее используем”. Для решения задач, стоящих перед ИТ-департаментом, таких как расчет и обоснование стоимости ИТ-услуг, например, или оценка влияния инцидентов и изменений, эта схема уже не подходит. Давайте посмотрим почему.
Разделяй и властвуй
Первое, что нужно отметить, это то, что пользователи, использующие в своей работе ИТ-систему, различаются. Они потребляют предоставленный им ИТ-ресурс каждый по своему. Кто-то непрерывно выполняет всю свою работу в системе, кто-то использует её раз в квартал для свода отчетности, кто-то загружает и просматривает данные и файлы большого объема, кто-то даже не знает, что использует ИТ-систему, но она есть “под капотом” отдельных потребляемых ИТ-услуг. Специфика и профиль использования ИТ-ресурсов всегда определяется бизнес-процессами, для автоматизации которых и используется целевая ИТ-система.
Разработчики приложений давно осознают эту потребность, поэтому монолитные приложения практически канули в лету и архитектурно распались на некоторый набор подсистем. Если приложение не построено полностью на микросервисах, то, исторически, эти подсистемы подразделяются на базовые и на профильные. Базовые обеспечивают некоторую общую функциональность, например MDM, механизмы ведения ролевой модели доступа к данным, хранение свойств пользовательской сессии, интеграцию с СУБД. Профильные обеспечивают функциональные возможности для непосредственной работы пользователей в тех или иных профессиональных областях.
Такое увеличение детализации может позволить чуть более определенно ответить на вопрос какие укрупненные блоки системы используются для тех или иных бизнес процессов.
Очевидно, что в реальной жизни ни в одной подобной сложной системе профильные подсистемы никогда не работают обособленно. Мы будем предполагать наличие некоторого API, позволяющего обмениваться данными между подсистемами. Функции которые реализуют публичные методы этого API являются частью своих предметных подсистем, даже если транспорт этого API является общесистемным. Поэтому будем считать, что API является неотъемлемым компонентом подсистем.
Молекулярный слой
Следующий очевидный факт, который не обозначен на схеме выше, – это взаимозависимость подсистем. Стрелки должны были обозначать зависимость (и потребление ресурсов) одних элементов схемы другими. Мы не отказывались от этой семантики, но на этой схеме сейчас нельзя отобразить качество и природу зависимости одной подсистемы от другой, это вынуждает нас дробить подсистемы на детальные компоненты.
С одной стороны, теперь, обладая детализацией до уровня отдельных компонент, мы можем ответить на вопрос о влиянии одних компонент на другие и использовать это знание для оценки влияния изменений. С другой стороны для расчета себестоимости услуги такая детальность конфигурационной модели может стать избыточной, т.к. определить правила и способ измерения “потребляемого ресурса” между всеми компонентами, измерить автоматизированным образом фактическое потребление “ресурса” для каждого включенного в схему элемента может быть затруднено. В любом случае, для целей оценки стоимости услуг всегда производится строгое определение детализации финансового конфигурационного учета.
Нельзя забывать, что при ведении конфигурационного учета мы говорим не о логической модели приложения, а о ее физическом действующем воплощении, поэтому нужно отражать на схеме все её элементы. Например, если данные о продажах филиалов и аффилированных компаний хранятся в нескольких распределенных географически одноименных таблицах или даже экземплярах приложения, связанных каналами связи, то для корректной оценки влияния инцидентов или изменений это должно быть отражено в конфигурационной модели.
Ведение такого детального конфигурационного учета может отпугивать компании, эксплуатирующие сложные и при этом слабо документированные приложения из-за колоссальной сложности и трудоемкости формирования такой карты. Работа по ее составлению может инициировать проведения тотального рефакторинга тех областей где техническая реализация связей и взаимозависимостей нарушает принятые стандарты разработки или соглашения об организации взаимодействия компонент.
Для компаний, разрабатывающих свои ключевые бизнес-приложения на основе микросервисной архитектуры, формирование карт взаимодействия компонент (или монофункциональных “контейнеров”), наоборот, является естественной потребностью.
Если же компания пользуется приобретенным ПО как “черным ящиком” и не управляет его разработкой, то необходимость в дроблении такого ПО на компоненты отсутствует. Действует принцип разумной достаточности, в рамках которого в конфигурационном учете выделяют только те элементы, которыми компания в силах управлять: например, отдельные интеграционные интерфейсы с коробочным ПО. Эти интерфейсы могут быть отражены как часть этого ПО или в форме самостоятельных приложений, в зависимости от их природы.
Решение о необходимости ведения столь же детального учета для сред тестирования и разработки остается за компанией.
Современная циклическая разработка, а, в особенности, реализация конвейеров непрерывного развертывания, накладывает практически обязательные требования на механизмы автоматического тестирования. Наличие конфигурационной модели приложения может способствовать организации такого тестирования, помочь в структурировании тестовых сценариев, определении критичных областей.
Атомный вывод
Если компания хочет успешно управлять рисками, связанными с теми или иными приложениями, то ей не стоит отходить от принципа “Сделал – записал”!
