Управление ИТ-инфраструктурой: процессы и аналитика

ИТ-инфраструктура крупной компании давно перестала быть набором серверов в одной серверной. Сегодня это десятки сервисов в облаках, гибридные сети, сотни конфигурационных единиц и тысячи заявок в Service Desk каждый месяц. Классические ITSM-инструменты фиксируют формальный поток инцидентов, но не показывают, что реально происходит с заявкой между статусами. Управление ИТ-инфраструктурой превращается в задачу, где недостаточно регламентов и тикет-системы — нужна процессная аналитика на реальных данных. В статье разберем, из чего состоит управление ИТ-инфраструктурой, какие подходы и процессы работают в enterprise, и как Process Mining и Task Mining помогают видеть фактическую работу ИТ-службы, а не отчетный срез.

Что такое управление ИТ-инфраструктурой и зачем выстраивать процессы

Управление ИТ-инфраструктурой — это согласованная работа с оборудованием, сетями, ПО, сервисами и облачными ресурсами компании ради непрерывной доступности бизнес-сервисов. Это не только администрирование серверов, а полный цикл: учет активов, контроль изменений, обработка инцидентов, мониторинг, аналитика.

Точечное администрирование закрывает локальные задачи: поднять сервис, заменить диск, настроить VPN. Управление ИТ-инфраструктурой решает другие вопросы:

сколько стоит доступность каждого бизнес-сервиса;
где регулярно ломается процесс обработки заявок;
какие линии поддержки перегружены;
какие активы используются неэффективно;
какие операции инженеров можно автоматизировать.

Анализ информационных процессов предприятия превращается из эпизодической задачи в постоянную функцию ИТ-блока. Цель — связать ИТ-метрики с бизнес-результатом: доступностью сервисов, скоростью обработки заявок, контролем затрат.

Из чего состоит ИТ-инфраструктура: четыре слоя

Четыре слоя ИТ-инфраструктуры

Чтобы говорить об управлении предметно, ИТ-инфраструктуру удобно разложить на слои. Аппаратный слой. Серверное оборудование, СХД, рабочие станции, периферия, сетевое железо. Здесь работают процессы инвентаризации, гарантийного обслуживания, замены и утилизации. Сетевой слой. Локальные сети, каналы между офисами и ЦОД, межсетевые экраны, балансировщики, VPN. Сеть определяет доступность всего остального — без нее не работают ни приложения, ни облака. Программный слой. Операционные системы, СУБД, прикладные системы — ERP, CRM, BPM, ITSM. К этому же слою относятся внутренние ИТ-сервисы: почта, файловые ресурсы, корпоративный портал. Облачный слой. Публичные и частные облака, SaaS-сервисы, контейнерные платформы. В гибридной инфраструктуре облако и on-prem связаны общими процессами обслуживания и единой моделью данных. Управление ИТ-инфраструктурой объединяет четыре слоя в одну сервисную модель: за каждой бизнес-функцией стоит цепочка компонентов, и сбой в любом из них влияет на конечного пользователя.

Подходы к управлению: функциональный, процессный, сервисный

Три подхода к управлению ИТ

Исторически в ИТ сложились три подхода. Функциональный. ИТ-служба разделена по специализациям: сетевые инженеры, администраторы баз данных, поддержка пользователей. Заявка передается из рук в руки по функциям. Подход быстрый для типовых задач, но непрозрачный: ответственность за конечный результат размыта. Процессный. Работа выстроена вокруг сквозных процессов: обработки инцидента, изменения, запроса на обслуживание. У каждого процесса есть владелец, метрики, регламент. Анализ бизнес процессов в ИТ ведется не по подразделениям, а по типам процессов. Сервисный. Все ИТ-активности сгруппированы в каталог сервисов с понятным SLA для бизнеса. За каждым сервисом стоят процессы, активы, команды. ITIL — самая распространенная модель сервисного подхода, на ее идеях построены практически все ITSM-платформы. В крупных компаниях встречается комбинация: процессный подход внутри ИТ, сервисный — на стыке с бизнесом, функциональный — для глубоких экспертных задач. Управление информационными технологиями цифровая трансформация требует именно такого баланса.

Ключевые ITSM-процессы: инциденты, проблемы, изменения, конфигурации, SLA

ITSM регламентирует обработку всего, что происходит между пользователем и ИТ-службой. Базовый набор процессов:

Управление инцидентами. Восстановление сервиса после сбоя в нормативные сроки. Метрики — MTTR, доля решений на первой линии, нарушение SLA.
Управление запросами на обслуживание. Стандартные заявки: доступ, оборудование, ПО. Метрики — скорость выполнения, доля автоматизированных запросов.
Управление проблемами. Поиск и устранение коренных причин повторных инцидентов. Метрики — снижение числа повторных обращений по типу проблемы.
Управление изменениями. Контроль модификаций инфраструктуры с оценкой риска и согласованиями. Метрики — доля успешных изменений, число откатов.
Управление конфигурациями. Поддержание актуальной CMDB — модели связей сервисов, активов и инцидентов.
Управление уровнем услуг (SLA). Договоренности с бизнесом о доступности и скорости реакции, регулярная сверка фактических показателей с целевыми.

Каждый процесс генерирует логи в ITSM-системе. Эти логи — основной источник данных для процессной аналитики.

ITAM и CMDB как фундамент управления активами

Без точного учета активов и связей между ними процессы ITSM теряют управляемость. ITAM (IT Asset Management) отвечает за жизненный цикл активов: от закупки до списания, с учетом стоимости владения, лицензий, гарантии. CMDB (Configuration Management Database) хранит логическую модель: какие сервисы зависят от каких серверов, какие приложения связаны с какими БД, какие пользователи привязаны к каким лицензиям.

CMDB позволяет:

быстро оценить влияние сбоя одного компонента на бизнес-сервисы;
планировать изменения с пониманием связанных рисков;
проверять обоснованность затрат на инфраструктуру;
готовить сценарии восстановления после аварий.

На практике CMDB часто заполнена частично и не отражает реальное состояние. Это первый источник «узких мест»: процессы регламентированы, но опираются на устаревшие данные. Восстановление качества CMDB — отдельный проект на стыке ITAM и процессов управления конфигурациями.

Мониторинг и зонтичные системы наблюдаемости

Технический мониторинг отвечает на вопрос «работает ли инфраструктура»: загрузка процессоров, доступность сервисов, ошибки приложений. Зонтичные системы наблюдаемости собирают сигналы из десятков источников — инфраструктурного мониторинга, APM, логов, метрик сетевого оборудования — и сводят их в единую картину состояния бизнес-сервисов. Мониторинг эффективности бизнес процессов — отдельный класс задач. Здесь важно не «работает ли сервер», а «сколько заявок прошло за SLA», «где процесс встал», «какая линия поддержки перегружена». Автоматизация процесса мониторинга на уровне инфраструктуры решает первую задачу, но не закрывает вторую — для этого нужна процессная аналитика по логам ITSM и рабочих станций. Совмещение двух уровней мониторинга дает целостную картину: видно и техническую первопричину сбоя, и его процессное последствие — какие заявки задержались, какие SLA нарушены, сколько времени инженеры потратили на ручные обходы.

Аналитика ИТ-процессов: Process Mining и Task Mining в ИТ-службе

Process Mining и Task Mining — двухуровневая картина

Здесь начинается зона, где автоматизация ит процессов переходит от регламентов к работе с фактическими данными. Process Mining и Task Mining дополняют ITSM-инструменты тем, чего в них нет: реальной картиной выполнения.

Как Process Mining восстанавливает фактические маршруты заявок Service Desk

Process Mining работает с логами событий ITSM. Каждый переход заявки между статусами — отдельная запись с временной меткой и исполнителем. Из миллионов таких записей восстанавливается граф фактических маршрутов.

Что показывает Process Mining в Service Desk:

реальные пути инцидентов от регистрации до закрытия, включая отклонения от регламента;
петли возврата заявок с L2 на L1, повторные эскалации, скрытые передачи;
доля заявок, проходящих через «теневые» статусы — ожидание, переоткрытие, согласование;
разница в скорости обработки между командами и инженерами на одинаковых типах заявок;
влияние массовых инцидентов на длину очереди и SLA по другим обращениям.

Регламент ITIL описывает, как должен выглядеть процесс. Process Mining показывает, как он выглядит на самом деле, — без интервью и опросов, на основе фактов.

Task Mining: на что уходит время ИТ-специалистов и где автоматизировать

Task Mining собирает данные с рабочих станций инженеров: какие приложения открыты, какие действия выполняются, сколько времени уходит на каждую операцию. Все данные обезличены до уровня ролей и команд — речь идет о процессах, не о слежке за людьми.

На уровне ИТ-службы Task Mining отвечает на вопросы:

сколько времени уходит на типовую заявку — заведение пользователя, выдачу доступов, восстановление пароля;
какие операции инженеры повторяют десятки раз в день и какие можно автоматизировать через RPA или скрипты;
какая доля времени тратится на переключение между ITSM, мониторингом, почтой, чатами;
какие шаги отсутствуют в регламенте, но выполняются всеми инженерами;
где ручные операции с большой вероятностью приводят к ошибкам.

Связка Process Mining и Task Mining дает двухуровневую картину: процесс целиком и каждая операция внутри него. На этой базе строится автоматизация информационных процессов предприятия — от маршрутизации заявок до подключения ИИ-сотрудника на типовых обращениях.

Метрики эффективности ИТ: MTTR, FCR, SLA-compliance, утилизация

Метрики эффективности ИТ-службы

Без метрик управление ИТ-инфраструктурой превращается в субъективную оценку. Базовый набор показателей для Service Desk и эксплуатации:

MTTR (Mean Time To Repair / Resolve) — среднее время восстановления сервиса. Считается как сумма времени от регистрации до закрытия инцидента, деленная на количество инцидентов. Снижение MTTR — прямой эффект работы с маршрутами в Process Mining.
FCR (First Contact Resolution) — доля заявок, решенных на первой линии без эскалации. Рост FCR разгружает L2 и L3, ускоряет обслуживание пользователей.
SLA-compliance — доля заявок, выполненных в нормативные сроки. Декомпозируется по типам заявок, командам, периодам.
Утилизация — загрузка инженеров и оборудования. По людям показывает баланс нагрузки, по технике — обоснованность затрат на инфраструктуру.
Доля повторных обращений — индикатор качества решения. Высокая доля говорит, что инциденты закрываются формально, а не по сути.

Метрики работают, когда они привязаны к процессам и обновляются автоматически. Ручные расчеты в Excel дают ретроспективный отчет, но не позволяют управлять процессом в моменте.

Автоматизация ИТ-процессов и цифровая трансформация инфраструктуры

Цифровая трансформация инфраструктуры — это не разовый проект и не замена оборудования. Это переход к управлению на данных и автоматизация процессов управления на каждом уровне ИТ-службы.

Типичный порядок автоматизации:

Типовые заявки. Сброс паролей, выдача стандартных доступов, развертывание ВМ — кандидаты на самообслуживание и боты.
Маршрутизация. Автоматическое определение группы исполнителей по содержанию заявки, тегам, истории.
Инвентаризация и CMDB. Сбор данных об активах из агентов, гипервизоров, облачных API — без ручного ввода.
Мониторинг и реакция. Автоматическое создание инцидентов из событий мониторинга, корреляция сигналов, обогащение данными CMDB.
Процессы изменений. Шаблонные изменения с автосогласованием по матрице рисков.
Аналитика и отчетность. Регулярные дашборды по метрикам, автоматический поиск аномалий в логах процессов.

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

Типичные «узкие места» и риски в управлении ИТ-инфраструктурой

В большинстве проектов по аудиту ИТ-процессов всплывают одни и те же зоны риска:

ручная маршрутизация заявок между линиями поддержки;
неполный или устаревший CMDB, расхождение учетных данных и фактического состояния;
скрытые повторные обращения, замаскированные под новые инциденты;
разрозненный мониторинг, в котором сигналы не связаны с бизнес-сервисами;
отсутствие метрик процессов или их ручной расчет с задержкой;
неучтенные действия инженеров: ручные обходы, операции вне регламента;
слабая связь между ITSM, мониторингом и системами автоматизации.

«Узкие места» редко видны без процессной аналитики — формальные отчеты ITSM показывают плановую картину, а не реальную.

Пошаговый план внедрения управляемой ИТ-инфраструктуры

Универсальный путь, который проходит большинство enterprise-компаний:

Инвентаризация активов. Полный список оборудования, ПО, сервисов, облачных ресурсов с владельцами и контрактами.
Сборка CMDB. Логическая модель связей: сервисы — приложения — серверы — пользователи.
Регламентация ITSM-процессов. Инциденты, запросы, изменения, проблемы, SLA с владельцами и каталогом услуг.
Технический мониторинг и наблюдаемость. Сбор метрик, событий и логов в единую платформу с привязкой к сервисной модели.
Процессная аналитика. Подключение Process Mining к логам ITSM, разворачивание Task Mining на ключевых ролях.
Автоматизация. Самообслуживание, маршрутизация, реакция на события, типовые изменения, ИИ-сотрудник на массовых обращениях.
KPI и пересмотр. Регулярный анализ MTTR, FCR, SLA, утилизации; пересмотр регламентов и приоритетов автоматизации.

Шаги связаны: пропустить инвентаризацию и сразу запустить аналитику — значит работать с данными, которым нельзя доверять.

Кейсы и эффект: что меняется после внедрения аналитики процессов

Реалистичные ориентиры эффекта по проектам Process Mining и Task Mining в ИТ:

сокращение MTTR по типовым инцидентам за счет устранения петель на L1/L2;
рост FCR после правильной маршрутизации и обогащения карточки данными CMDB;
снижение доли повторных инцидентов после анализа коренных причин;
экономия времени инженеров на типовых операциях после автоматизации;
сокращение затрат на инфраструктуру после анализа утилизации.

Кейсы Proceset показывают: эффект дает связка ITSM, CMDB, мониторинга и процессной аналитики, а не один инструмент.

Process Mining и Task Mining для ИТ-инфраструктуры

Покажем на ваших данных Service Desk и рабочих станций инженеров, где теряется время, нарушаются SLA и какие операции можно автоматизировать в первую очередь.

Заключение

Управляемая ИТ-инфраструктура держится на двух опорах. Первая — каркас: ITSM, CMDB, ITAM, мониторинг. Вторая — процессная аналитика по фактическим данным. Без первой аналитика работает с хаосом, без второй каркас живет отдельно от бизнес-сервисов. Совмещение двух уровней превращает ИТ-блок в управляемую функцию с прозрачными метриками.