Управление инцидентами (Incident management) по ITIL

4 мин читать

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

Что такое инциденты и зачем ими управлять

По терминологии ITIL инцидент — это событие, при котором происходит внеплановое прекращение предоставления сервиса или снижение его качества. К инцидентам относятся: отсутствие интернет-соединения, недоступность корпоративной почты, поломка офисной техники, аварии на сервере.

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

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

Пример карточки зарегистрированного инцидента в системе сервис деск

Какие этапы включает управление инцидентами

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

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

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

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

Категоризация. Это сортировка инцидентов по разным категориям. Допустим, они могут зависеть от конкретных ИТ-услуг, на которые оказывает влияние возникший сбой. Нередко выбранная категория влияет на то, какие специалисты или команды будут заниматься проблемой, насколько быстро ее нужно устранить.

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

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

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

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

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

Решение. После выяснения причин инцидента начинаются работы по восстановлению услуги. Уложиться в регламентные сроки специалистам поддержки помогает настроенный в ИТ-системе контроль времени реакции и устранения проблемы в соответствии с SLA.

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

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

Главное: что такое управление инцидентами

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

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