Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

События, которые могут перерасти в инциденты

События, которые могут перерасти в инциденты

Одна из проблем в управлении ИТ, это то, как справляться с потенциальными инцидентами и как их отличать от обычных событий. Какие события могут послужить сигналом того, что может произойти инцидент? Например, если утилизация интернет канала выросла с 60% до 70%, а лимиты, скажем, были 75% (допустимый лимит) и 80% (критический лимит), и утилизация возрастает до 70% по вторникам и средам, разве не должен быть создан инцидент, т.к. понятие инцидента включает в себя, в том числе и деградацию сервиса.

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

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

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

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

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

Должен отметить, что ситуация немного отличается в случае потенциальных инцидентов безопасности. В идеале инциденты безопасности  должны создаваться для любых потенциальных дыр в безопасности.

На основе поста в блоге Vinod Kumar Agrasala, управляющего директора индийской компании Wings2i IT Solutions, ITSM специалиста с многолетним опытом.

Дополнительные материалы

Комментарии (0)

    Также рекомендуем