Портал №1 по управлению цифровыми
и информационными технологиями

Инциденты, проблемы и известные ошибки

 

Совсем недавно у Игоря Фадеева вышла статья с разбором разницы между инцидентами и известными ошибками. Действительно запутаться в понятиях очень легко, на курсе ITIL® 4 Foundation мы регулярно с этим «распутываемся». 

Для того, чтобы не путаться в понятиях и разговаривать на одном языке, всем участникам проекта рекомендуем Вам пройти наш курс  ITIL® 4 Foundation.

Например, инциденты часто называют проблемами, хотя в ITIL это совсем разные понятия. Скорее всего это происходит из-за того, что в бытовом языке всё непонятное и неприятное мы называем проблемой.

Значение этого слова в ITIL отличается от бытового, его не стоит использовать для всего подряд, в том числе — для инцидентов. Что же такое инцидент? А остальное? Разберёмся вместе в этой статье.

Инцидент

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

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

Инцидент здесь — услуга «Печать документов» недоступна. Пользователь не может распечатать нужные ему документы.

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

Проблема

Что стоит за этим инцидентом? Почему услуга недоступна?

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

В ITIL проблема — это причина или потенциальная причина инцидента или инцидентов.

Известная ошибка

Наш сотрудник изучил проблему, но ещё не успел решить. Ему нужно срочно бежать и тушить более важный пожар. 

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

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

Известная ошибка в ITIL — это проблема, которая уже была проанализирована, но ещё не была решена.

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

В нашем примере системное решение — обновление версии драйвера принтера с помощью обновления от производителя. Это обновление мы пока ждём, производитель в курсе и обещал предоставить.

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

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

То, как мы работаем с этими ситуациями, определяет то, как потребители и другие заинтересованные стороны воспринимают нашу организацию. 

Именно здесь вступают в игру две важнейшие практики ITIL: управление инцидентами и управление проблемами.

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

Управление инцидентами может быть более заметно пользователям: у меня сломалось, мне быстро починили. А управление проблемами, кажется, не заметно вообще, ведь это внутренняя кухня ИТ. 

На самом деле это не так: косвенно управление проблемами заметно и для пользователей.

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

А зачем так много терминов?

Пользователи и бизнес ожидают «чтобы работало», а не наша терминология. 

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

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

Но если вся система будет состоять из обходных решений, то она будет очень хрупкой. Обходные решения не отменяют необходимость затем найти и устранить корневую причину, проблему. Сделать так, чтобы больше не падало. Вот почему две практики, а не одна. Вот почему они обе важны.

На нашем YouTube канале Вы можете посмотреть видео-версию этой заметки и еще много полезных роликов от экспертов Cleverics.

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Добавить комментарий

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM