Управление инцидентами ITIL и CMDB: руководство для профессионалов

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

Управление инцидентами — один из важнейших процессов, направленный на устранение неполадок в ИТ-ландшафте. Эта цель достигается с помощью комплекса мер, которые включают: мониторинг, выявление, регистрацию, уведомление, расследование, устранение.

Важность эффективного управления инцидентами в IT

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

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

Методология ITIL — это сборник лучших и передовых практик по управлению сервисами и услугами. Последняя версия рекомендаций — четвертая — вышла в 2020 году.

Основные процессы и функции

ITIL позволяет построить прозрачную систему сервисного обслуживания. Такая система охватывают не только ИТ-активы, а весь комплекс факторов, которые влияют на предоставление сервисов и услуг.

Методология описывает принципы управления 34 процессами. Основные из них — практики по управлению инцидентами, изменениями, проблемами, событиями и мониторингом, знаниями, уровнем услуг, конфигурациями и активами, доступами, релизами, а также обслуживанием. При использовании ITIL стоит учитывать, что это не пошаговая инструкция. Рекомендации нужно адаптировать, ориентируясь на уровень зрелости ИТ-процессов и специфику конкретного бизнеса. Практики можно внедрять постепенно, когда в них возникает необходимость.

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

Однако функция в ITIL — это не только люди, а вообще все, что потребуется для поддержки процессов, в том числе инструменты и другие ресурсы. Каждая функция решает определенные задачи, но не всегда эти задачи относятся к каким-то одним процессам. Например, служба поддержки — или Service Desk в терминах ITIL — не только отвечает за обслуживание и предоставление услуг, но и влияет на процессы управления проектами, стратегией и т. п.

Роль управления инцидентами в ITIL

Управление инцидентами занимает ключевое место в ITIL, поскольку от него зависит восстановление стабильной работы организации. Рекомендации ITIL позволяют выстроить процесс эффективно: быстро обнаруживать и классифицировать инциденты, находить первопричины и оптимальные (в том числе по стоимости) пути решения, повысить скорость устранения. Один из инструментов, который играет важную роль в процессе управления инцидентами, называется CMDB.

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

Определение CMDB

Если говорить в терминах ITIL: CMDB (Configuration Management Data Base) — это база данных управления конфигурациями, которая включает в себя все элементы ИТ-инфраструктуры и отражает их связи. Одна из главных особенностей CMDB — учет не только оборудования и ПО, но и конфигурационных единиц (КЕ).

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

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

Типы содержащихся в CMDB данных

Связь CMDB с другими процессами ITIL

CMDB выступает основой для некоторых процессов ITIL. В базе содержится вся информация о КЕ, включая данные о событиях, ремонтах и профилактических работах, документах и соглашениях, а также взаимосвязи с другими компонентами. Благодаря этой информации и появляется возможность выстраивать сервисные процессы.

С помощью CMDB можно построить ресурсно-сервисные модели услуг — ключевой инструмент для мониторинга работы сервисов и локализации инцидентов

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

Преимущества использования CMDB

Основной эффект от CMDB — это устранение разрозненности, поскольку все компоненты IT хранятся в единой базе и рассматриваются в комплексе. База содержит стандартизированные данные, которые вовремя обновляются — это позволяет избежать устаревания информации. Также появляется возможность управлять мощностями и ресурсами, планировать бюджет и рассчитывать стоимость услуг.

В ITIL описаны практические рекомендации по организации процесса управления инцидентами.

Этапы процесса: выявление, классификация, расследование, решение, закрытие

Весь процесс разбивается на несколько этапов. Разберем подробнее.

Перечень этапов управления инцидентами по методологии ITIL

Выявление. Уведомление о возникновении проблем может поступить в службу поддержки из разных источников. От пользователей — по почте, в мессенджерах или чате, через заявку на корпоративном портале. Или от систем мониторинга, которые фиксируют сбой и присылают уведомления ответственному за устройство или услугу. Затем инциденты регистрируются в специализированной системе.

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

Расследование. Назначенные ИТ-специалисты получают уведомление об инциденте. Сначала проводят первичную диагностику: опрашивают инициатора заявки или анализируют уведомления из систем мониторинга, изучают историю ремонтов и обслуживания оборудования. В локализации инцидентов также помогают ресурсно-сервисные модели. Специалист предполагает, в чем может быть причина сбоя, и решает — самостоятельно устранять проблему, эскалировать ее специалисту или команде с нужным набором компетенций. Затем подтверждается предварительная гипотеза или выдвигаются новые предположения. Разрабатывается план решения в зависимости от возможных причин сбоя. Заинтересованным пользователям отправляются уведомления о примерных сроках восстановления работоспособности услуги.

Решение. На этом этапе специалисты устраняют проблему. В поиске решения инцидента могут помочь примеры решения похожих инцидентов и инструкции, которые могут храниться в ITSM-системе. После решения инцидента корректность работы оборудования тестируют. Если все штатно, пользователям сообщают о восстановлении сервиса.

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

Роли и обязанности в управлении инцидентами

Решением запросов могут заниматься один или несколько специалистов, причем они могут входить в разные команды.

Метрики и ключевые показатели эффективности (KPI)

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

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

Примеры качественных KPI:

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

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

В методологии ITIL (IT Infrastructure Library) понятие CMDB описывается во множестве практик и процессов. Это управление конфигурациями, ИТ-активами, инцидентами, запросами на обслуживание и т.д. CMDB — как ключевой реестр всех инфраструктурных компонентов компании — может вбирать в себя различные данные из инструментов инвентаризации, финансового учета, систем мониторинга ИТ и бизнес-сервисов.

CMDB позволяет бизнесу более эффективно выстраивать ITSM-процессы. Благодаря таким базам данных становится легче устранять сбои в ИТ-инфраструктуре, находить проблемы, планировать изменения. Согласно ITIL 4 и ITSM-подходу (IT Service Management), использование CMDB создает ценность услуг для пользователей и бизнеса, которые получают ожидаемые результаты от применения сервисов.

Как CMDB поддерживает управление инцидентами

CMDB играет большую роль в процессе управления инцидентами. С помощью баз данных можно:

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

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

Примеры использования CMDB для анализа причин инцидентов

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

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

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

Например, при передаче оборудования от увольняющегося к новому сотруднику с помощью CMDB можно отследить эксплуатационные данные устройства. Если техника почти выработала свой ресурс, необходимо приобрести другое оборудование, а старое — списать.

Автоматизация процессов с помощью CMDB

Сегодня невозможно предоставлять сервисное обслуживание и ИТ-услуги конкурентного уровня без решений классов Help Desk или Service Desk. CMDB может стать важной частью этих систем. Такая разработка базы данных позволяет в автоматическом режиме:

1. Консолидировать и стандартизировать всю информацию, связанную с ИТ-инфраструктурой, в единой базе.
2. Строить ресурсно-сервисные модели для оценки стоимости услуг и отслеживания взаимосвязей между различными конфигурациями.
3. Управлять ресурсами и мощностями.

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

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

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

Примеры информации, которая поступает в CMDB из ITSM-системы

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

Связка систем позволяет внедрить комплексный подход к управлению ИТ-инфраструктурой.

Реальные кейсы успешного использования ITIL и CMDB

Рассмотрим примеры компаний, которые с помощью CMDB управляют и обеспечивают контроль ИТ-инфраструктуры, а также получают возможность выстраивать сквозные и прозрачные процессы обслуживания.

Кейс 1. Концерн Росэнергоатом внедрил российскую систему ITSM в рамках импортозамещения. С помощью ПО оказывается техподдержка и предоставление ИТ-услуг внутренним пользователям. В рамках проекта была построена база данных CMDB, в которой было учтено 110 тыс. ИТ-компонентов. В итоге в компании внедрен новый подход к учету ИТ и ресурсов, а корпоративные сервисы предоставляются эффективно.

Кейс 2. Почта России создала комплексную систему управления ИТ-процессами с помощью российского поставщика NAUMEN. На начальных этапах внедрения создана база данных, в которой учитывается более 720 тыс. КЕ. С помощью CMDB компания получила возможность централизованно управлять активами, которые находятся в филиалах по всей стране, вовремя обновлять парк устройств, предоставлять услуги сотрудникам.

Советы по настройке и оптимизации процессов

Чтобы CMDB стала надежной основой для организации бизнес-процессов, необходимо:

1. Использовать качественные данные при построении CMDB, поскольку от этого зависит, насколько корректно будут работать процессы. Оптимально настроить автоматические механизмы стандартизации и консолидации данных обо всех элементах ИТ-инфраструктуры с помощью встроенных алгоритмов и интеграций.
2. Определить взаимосвязи между всеми элементами и создать ресурсно-сервисную модель. Так как ИТ-инфраструктура может быть сложноорганизованной и масштабной, стоит построить отдельные РСМ для самых востребованных услуг.
3. Использовать данные CMDB, для анализа причин сбоев и выявления повторяющихся инцидентов. Это позволит своевременно обновлять оборудование, внедрять необходимые изменения и исправлять разные ошибки.
4. Поддерживать базу в актуальном состоянии. Это можно делать вручную, с помощью загрузки файлов с данными из различных систем (например, бухгалтерских) или настроить полностью автоматическое обновление с помощью специализированных систем мониторинга.

Если в CMDB используются качественные данные, появляется возможность сформировать карточки оборудования и их конфигурации с корректной детализацией

Часто встречающиеся ошибки

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

В CMDB загружены данные низкого качества. До CMDB ИТ-активы в компаниях обычно учитываются лоскутно: разные люди ведут несколько разных файлов. Если в систему загрузить данные «как есть» — нестандартизированные и непроверенные, то построить CMDB, выстроить взаимосвязи между КЕ и создать РСМ не получится.

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

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

Наверх ↑