Управление инцидентами - 3

Записаться

Конфигурационная база данных

Назначение и состав

Конфигурационная база данных (Configuration Management Database, CMDB) должна включать не только информацию об оборудовании, программном обеспечении или локальных сетях. Она содержит все сведения, которые когда-либо могут понадобиться другим процессам. Прежде всего это данные об услугах: какая услуга оказывается какими ИТ-активами. Сюда же могут входить соглашения об уровне услуг (Service Level Agreement, SLA), сведения о сотрудниках и ИТ-персонале, который обслуживает актив или отвечает за услугу, а также документация об услуге, активе, программном модуле или приложении.

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

Связь с процессами

Если пройти по процессам, состав базы становится понятнее:

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

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

ITIL (ITIL) не задаёт обязательный перечень того, что должно быть в базе. Он говорит об этом косвенно, описывая процессы, но не определяет точные задачи каждого процесса. Например, управление уровнем обслуживания должно исходить из наличия ресурсов для оказания услуг — человеческих и иных. Однако степень детализации не оговаривается. Может быть указано, что для мониторинга и взаимодействия с пользователем достаточно одного ИТ-специалиста. Если это конкретный специалист, он привязывается в базе к SLA и услуге. Если подойдёт любой специалист, жёсткой привязки нет: достаточно, чтобы был тот, к кому можно обратиться. Организация сама решает, какие требования установить.

Управление инцидентами

Этапы процесса

Процесс включает:

• приём и регистрацию инцидента;
• классификацию;
• начальную поддержку;
• присвоение типа, статуса, приоритета, степени воздействия и срочности;
• привязку к SLA.

Затем анализируют SLA, чтобы понять важность инцидента. Если инцидент типовой, пользователю могут сразу предложить решение на уровне сервис-деска (Service Desk). Пример: рабочая станция не включается — советуют выключить и включить снова. Появляется синий экран Windows — советуют перезагрузить систему. Если поступает запрос на обслуживание, запускается соответствующая процедура.

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

Расследование и диагностика начинаются, если готового решения нет. Этим занимаются линии поддержки. Когда решение найдено, пользователя уведомляют. Пользователь обязательно подтверждает, что инцидент разрешён, после чего инцидент закрывают. ITIL запрещает закрывать инцидент без участия пользователя. Единственный, кто может закрыть инцидент, — пользователь. В конце выполняется мониторинг хода работы, отслеживание работ и сбор статистики.

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

Приоритет, воздействие и услуги

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

ITIL не требует, чтобы инциденты обязательно эскалировались строго по порядку линий поддержки. В большинстве случаев нормальный ход разрешения идёт слева направо — от первой линии к последней. Но это не обязательно. У каждого инцидента может быть свой маршрут обработки и эскалации, заранее спланированный и назначенный сервис-деском. Это делается на основании природы инцидента, его категории и других признаков.

Номер, статусы и отслеживание

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

Статусов может быть много. Их определяют в зависимости от инцидента, его связи, источника и влияния. Каждая организация задаёт статусы по-своему. Примеры статусов:

• новый инцидент;
• принят в работу;
• запланирован;
• в работу не принят, но поставлен в очередь;
• назначен исполнителем;
• активен, то есть работа идёт;
• отложен по какой-то причине;
• разрешён;
• закрыт.

Это этапы жизненного цикла инцидента.

Краткие итоги

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

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

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