ГлавнаяСтатьиУправление и учет событий. Процесс мониторинга систем. Процедура оповещения

Управление и учет событий. Процесс мониторинга систем. Процедура оповещения

Компании, которые внедрили у себя службу поддержки и предоставления ИТ- сервисов (Service Desk) в начальный период времени руководители ИТ-служб могут столкнуться с такой проблемой, как классификация работ выполняемых по сервисам. Чаще всего в таких случаях классификация начинается  с обращения пользователя, которое, в свою очередь, может быть запросом на обслуживание, консультацией, инцидентом и т.д.  Но что в случаях, когда необходимо выполнять внутренние работви в ИТ-инфраструктуре, которые «не видят» пользователи, но при этом данные работы имеют влияние на вероятность появления инцидентов?

С появлением нового стандарта билиотеки ITIL v.3, появился шанс решать такие задачи, как учет инфраструктурных инцидентов. Это связано с тем, что помимо процессов Incident, Change и Problem Managements, в классическом варианте исполнения Service Desk, в ITIL v.3 описывается еще такой процесс, как Event Management (процесс управления событиями). Благодаря этому, можно более систематически подойти к вопросу классификации внутренних работ и влияния этих работ на появление обращений пользователей.

По определению, Event Management, процесс наблюдающий за событиями, связанными с изменениями в ИТ инфраструктуре и(или) оказываемых ИТ сервисах.  А событие – поддающееся обнаружению явление, имеющее значение для управления инфраструктурой ИТ или предоставления ИТ сервисов.

Проще говоря, ранее учитывались в базе данных Service Desk только обращения от пользователей, которые впоследствии классифицировались либо как инцидент, либо как запрос на обслуживание, как идентифицированные. И это всегда носило реактивный характер решения задач ИТ (т.е. появился, к примеру, инцидент, то его надо как можно быстрее решить и закрыть). Это говорит о том, что при таком подходе, ИТ-службы не могут уделять достаточно внимание для мониторинга основных систем компании т.к. все ресурсы были бы брошены на «тушение пожара» (закрытие инцидентов пользователей), что приводило не к всегда оправданному использованию ИТ ресурсов компании. Реактивный характер решения обращений в Service Desk хорошо работает при единичных  инцидентах  у пользователей. Но в случаях, когда какая-либо бизнес критическая система компании в какой-то момент находится в простое а количество пользователей данной системой достаточно велико, может привести к временному коллапсу обслуживания ИТ-службами на первой линии поддержки. 

Что же в этом случае делать?  Ответ однозначен. Необходимо в компании внедрять процесс управления событиями (Event Management) и строить разумно оправданную систему мониторинга основных систем компании, как превентивную меру до появления инцидентов пользователей.  Таким образом, у нас в базе данных Service Desk могут появляться некие события, который появляются ранее, чем пользователи «заметят» неработоспособность систем и отреагируют на это, и которое в свою очередь может быть классифицировано как авария или простой системы. 

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

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

Соотношение количества аварий по отношению к простоям, как метрика, дает возможность оценить насколько управляемой является ИТ-инфраструктура компании.

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

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

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

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

Наши фотографии:

Контакты

Украина:

+38 068 767 62 16

        Skype: ISSadvance Consulting center

Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.

г. Киев

Казахстан:

+7 777 293 3313

Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.

г. Алматы

Беларусь:

+375 29 646 00 60

Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. skype: ISS-Advance

г. Минск