В среде ИТ-специалистов сложился устойчивый миф: «Если нужна система управления ИТ-процессами — бери JIRA, она всё потянет». Давайте посмотрим правде в глаза: JIRA — действительно отличный трекер задач. Но только до тех пор, пока вы не пытаетесь построить на её основе CMDB-систему. Здесь и далее под JIRA, с одной стороны, мы понимаем конкретный продукт, а, с другой, объединяем класс подобных развитых ITSM-систем, которые выпустили модули ITAM и на хайпе пытаются автоматизировать процессы управления конфигурациями как в сервис деске.

Под CMDB мы понимаем не просто набор форм и полей, которые администраторы заполняют вручную (если не забудут) или импортируются из других источников, а полноценную CMDB, где каждая конфигурационная единица (CI) имеет актуальные атрибуты, корректные связи и понятное место в ресурсно-сервисной модели. Речь идёт об управлении конфигурациями с правилами поведения объектов — прямыми и косвенными зависимостями, которые система должна отслеживать автоматически. И, наконец, о приоритизации инцидентов, когда сообщение системы мониторинга превращается не в ещё один тикет, а в точное указание: где, что и как сломано и насколько это критично для бизнеса. Перед таким набором требований JIRA как трекер задач пасует: она не просто показывает низкую эффективность — она принципиально не предназначена для этого.

Как только ваш ИТ-ландшафт перешагивает определённую планку сложности, повышаются требования к работе ИТ-специалистов, обеспечивающих оперативное управление ИТ-сервисами, специалистов, которые выполняют задачи администрирования и развития информационных систем. Их деятельность начинает измеряться в количестве изменений, которые они способы реализовать, сроках и качестве таких изменений, скорости реакции и устранения аварий, переход на мероприятия по проактивному предотвращению аварий. И все эти показатели напрямую завязаны на CMDB. Формальное наличие списка серверов никого не устроит. JIRA загрузила из zVirt список виртуалок — это хорошо, осталось понять, что из этого прод и тест, что к какой системе относится и какие сервисы там крутятся. Без этой информации — это просто список виртуалок.

Можно ли даже в больших и сложных инфраструктурах управлять конфигурациями в JIRA или даже на экселе? Опыт показывает, что нет. И в таких организациях, где хвалятся, что управляют всем с помощью подобных систем, на заднем плане торчит какой-нибудь Netbox, который держит на себе реальное управление, с большими ограничениями, но держит.

В связи этим, для инфраструктур и ИТ-подразделений, которые выполняют реальные задачи по обеспечению работы ИТ-сервисов обладание «ИнфраМенеджером» или другой профессиональной системой управления конфигурациями перестаёт быть просто альтернативным решением на рынке ITSM-систем. Он становится единственным технологически и экономически обоснованным выбором.

Именно поэтому профессионалы, переросшие уровень «списки серваков в трекере», выбирают «ИнфраМенеджер». И вот почему.

Когда JIRA начинает «уезжать в небытие»

Во-первых, давайте определимся, что такое «уезжать в небытие» — достаточно понаблюдать за действиями специалистов и их руководителей, как только данные начинают брать из источников, отличных от вашей CMDB, значит там либо нет актуальных данных, либо, что чаще, «нужных» данных.

Опираясь на реальную практику эксплуатации, можно вывести чёткий бенчмарк — порог, за которым JIRA начинает «задыхаться»:

• от 500 серверов и сетевых устройств;

• свыше 2 000 конфигурационных единиц (КЕ);

• более 500 кросс-связей между КЕ;

• от 200 ежемесячных изменений в ИТ-инфраструктуре.

При таких объёмах нативная платформа без тяжёлой кастомизации и без автоматизации специфических для подобных систем сценариев перестаёт обеспечивать необходимую актуальность данных, стремительно теряет полезность и превращается в зомби. CMDB формально есть, а по факту своей функции не выполняет, что самое опасное, что она может быть при этом:

1. как артефакт в голове руководства ИТ. Как часто в случае катастроф или масштабных инцидентов к ней прибегают как к спасению и понимают, что в жизни уже давно все не так;

2. новички, руководствуясь знаниями такой зомби CMDB вносят не изменения, выливающиеся в инциденты;

3. регулярные трудозатраты по попытке инвентаризации в такие зомби-CMDB — только пустая трата времени ИТ-специалистов и источник их демотивации.

Все это — прямая дорога к росту времени восстановления и недовольству со стороны бизнеса.

Цена компромисса: последствия для ИТ-департамента

Во-первых, чтобы построить CMDB, недостаточно просто программиста на JIRA или на другой аналогичной ITSM-платформе. Если говорить простым языком, то CMDB знает об инфраструктуре не просто, что там есть «какие-то штуки» и даже не то, что у этих «штук» есть IP-адрес. Настоящая CMDB точно знает, что сервер монтируется в стойку, на программное обеспечение устанавливается на ноутбук, а не на манипулятор мышь. Это кажется очевидным, но когда вы пытаетесь сделать из JIRA управление конфигурацией, вам необходимо формировать перечень атрибутов и параметров, которые относятся к тому или иному классу объектов. А сколько таких классов нужно вам?

Если перевести проблемы в плоскость конкретных последствий, то мы получим пугающую картину. Начнём с отсутствия настраиваемых правил поведения классов объектов. В JIRA инженер меняет одну конфигурационную единицу, имея слабое представление о прямых зависимостях (сама система не может подсказать ему об этом). Результат предсказуем и жесток: расхождение данных и, например, внеплановый простой двух бизнес‑критических сервисов на четыре часа и более, а следом — разбор полётов с руководством — простой случай из жизни администраторов.

Рассмотрим следующий кейс — невозможность визуализировать не только прямые, но и косвенные связи между КЕ. Самый простой кейс — это частая ситуация с IPAM системами — у одних выделенный диапазон IP‑адресов, VLANы и маршрутизация между ними, а у других перечень серверов, сервисов и приложений. Команда вынуждена действовать вслепую, перебирая гипотезы одна за другой, как в чёрном ящике. Итог закономерен: среднее время восстановления упавших сервисов (MTTR) вырастает примерно с 40 минут до двух с половиной часов, а то и больше. Бизнес ждёт, клиенты нервничают, инженеры вновь отправляются на разбор полётов. Возможно, для кого‑то 2,5 часа простоя и не так страшно, но вопрос не в конкретном времени, а в том, что CMDB дает способность на это время влиять, не благодаря карточкам, а заложенной в ней компетенции управления конфигурациями.

Теперь о дискаверинге — или о том, что в JIRA за него выдают. Да, есть удобный и классный механизм «запихнуть» туда любые данные. Только суть в том, чтобы не просто записать буковки и цифирьки и другие спецсимволы, а в том, чтобы получить данные, которые можно использовать, помощь в момент серьезного инцидента. И накопление мусора не поможет в этих задчах. Нужны механизмы нормализации, реконсиляции данных. Даже если вы не берете дискаверинг, а импортируете данные из AD или данные физической инвентаризации, такие механизмы должны участвовать в обработке данных..

И это даже не говоря о визуализации. JIRA выдаёт информацию исключительно в виде плоских списков. Чтобы понять топологию сервисов и связи между компонентами, команда собирает совещания, на которых теряется от пяти до восьми человеко‑часов в неделю. Не на решение проблем — на объяснение того, как устроена собственная ИТ‑инфраструктура.

Вывод: каждая из перечисленных проблем — не досадная мелочь, а прямой удар по скорости, качеству и предсказуемости ИТ‑сервисов. JIRA не просто неудобна — она системно провоцирует простой, рост MTTR, «мусор» в данных и часы бесполезных поисков. По сути, это то,что превращает профессиональные команды в сборище гадалок и экспериментаторов.

Что JIRA умеет, а где начинается зона «ИнфраМенеджера»

Справедливости ради: с двумя задачами JIRA справляется отлично. Она ведёт список ИТ‑систем с их реквизитами и позволяет перечислить конфигурационные единицы, входящие в состав системы. Всё. Дальше начинаются трудности.

Выстраивание взаимного влияния КЕ друг на друга в JIRA — это уже самодельная разработка. Фактически вы начинаете создавать CMDB с нуля, тратя от 6 до 12 месяцев и несколько десятков миллионов рублей. Настройка правил поведения для классов объектов — включая косвенные связи — это ядро любой CMDB, но у JIRA нет встроенного движка правил. Стоимость такой кастомизации стартует от 5–10 миллионов рублей, и это не предел.

Особенно больно бьёт визуализация. JIRA выдаёт плоские списки или подключает сторонние плагины, которые при 5000+ узлов работают недопустимо медленно. «ИнфраМенеджер» строит интерактивные графы в реальном времени, позволяя увидеть полную ресурсно‑сервисную модель. И, наконец, дискаверинг. JIRA умеет импортировать — через REST, CSV, что угодно. Но привести данные из разных систем мониторинга к единому стандарту, разрешить дубли и конфликты — нет. А без нормализации данных CMDB не может стать «единым источником правды».

Одна возможность, которая меняет всё

Зачем, собственно, все эти сложности? Дело в том, что наличие грамотной CMDB даёт ИТ‑подразделению то, чего невозможно достичь никакими другими средствами, — переход от реактивного тушения пожаров к упреждающему управлению ИТ‑сервисами.

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

И здесь CMDB становится незаменимой. Представьте: система мониторинга сообщает, что на сервере STORAGE01 заканчивается место на разделе /var/cache. В JIRA вы увидите просто ещё одну строку в списке. В «ИнфраМенеджере» через CMDB инженер за 20 секунд выясняет, что этот раздел принадлежит компоненту кэширования, который входит в состав АСУ ТП, от которой зависит отгрузка готовой продукции. Инцидент мгновенно получает критический приоритет, и команда действует согласно ситуации.

Цифры, которые говорят сами за себя

Ряд клиентов провели аналитику по времени устранения техсбоя до внедрения полноценной CMDB и после. Да, техсбой техсбою рознь, но общая динамика впечатляет.

Среднее время восстановления сократилось с 1,5 часов до 15 минут.

Причём большая часть из прежних 90 минут уходила даже не на саму диагностику, а на сбор объективной информации о текущем ИТ‑ландшафте. Инженеры просто не понимали, что именно сломано и где искать. Кроме того, экономится время на проверку решений, которые заведомо не подходят из‑за схемы организации ИТ‑инфраструктуры.

Переход с JIRA‑подхода на «ИнфраМенеджер» — это не смена «вывески». Это переход от гадания к знанию. От списков к графам. От часов простоя к 15 минутам восстановления.

Визуализация — не «плюшка», а инструмент управления хаосом

JIRA работает со списками. Списки прекрасны для задач. Но для ресурсно‑сервисной модели с тысячами взаимосвязей они катастрофичны.

«ИнфраМенеджер» строит графы зависимостей: сервис → приложение → сервер → диск → кэш. Он позволяет создавать карты влияния при изменении конфигурации и карты рисков с «подсветкой» единичных точек отказа. Без такой визуализации крупный сбой гарантированно приводит к часу совещаний только для понимания топологии. И это ещё до начала реальной работы по поиску и устранению проблем.

Если ваша ИТ‑инфраструктура насчитывает более 500 серверов, свыше 10 тысяч конфигурационных единиц и множество сервисов с перекрёстными зависимостями, JIRA как ITSM‑платформа исчерпывает себя. Вы получаете не управление конфигурациями, а дорогостоящую кастомизацию с непредсказуемым результатом.

«ИнфраМенеджер» изначально спроектирован как профессиональный инструмент для управления CMDB — с правилами поведения объектов, нормализацией данных, дискаверингом и визуализацией связей, которая позволяет видеть всю картину целиком. ИТ‑департамент перестаёт гадать и начинает предупреждать сбои.

Хотите сократить MTTR с полутора часов до 15 минут? Уберите JIRA из контура управления конфигурациями.