Совсем недавно у Игоря Фадеева вышла статья с разбором разницы между инцидентами и известными ошибками. Действительно запутаться в понятиях очень легко, на курсе ITIL® 4 Foundation мы регулярно с этим “распутываемся”.
Для того, чтобы не путаться в понятиях и разговаривать на одном языке, всем участникам проекта рекомендуем Вам пройти наш курс ITIL® 4 Foundation.
Например, инциденты часто называют проблемами, хотя в ITIL это совсем разные понятия. Скорее всего это происходит из-за того, что в бытовом языке всё непонятное и неприятное мы называем проблемой.
Значение этого слова в ITIL отличается от бытового, его не стоит использовать для всего подряд, в том числе — для инцидентов. Что же такое инцидент? А остальное? Разберёмся вместе в этой статье.
Инцидент
Пользователь звонит в службу поддержки и сообщает, что не получается распечатать документ. Специалист службы поддержки отправляется на помощь.
Если прерывание этой услуги не входило в наши планы, то это — инцидент. Произошло незапланированное прерывание или снижение, если более официально — деградация качества услуги.
Инцидент здесь — услуга «Печать документов» недоступна. Пользователь не может распечатать нужные ему документы.
Исключением может быть ситуация в которой происходят плановые работы, из-за которых услуга недоступна. В таком случаем произошедшее не будет являться инцидентом. Хотя, конечно, мы можем задать себе вопрос: а почему пользователь не знает об этих плановых работах?
Проблема
Что стоит за этим инцидентом? Почему услуга недоступна?
Наш сотрудник отправляется к принтеру и изучает, что случилось. По ходу диагностики сотрудник обнаруживает, что диспетчер печати Windows время от времени “теряет” определённые сетевые принтеры из-за конфликта с драйвером данной модели сетевого принтера. Это — проблема, которая привела к инциденту.
В ITIL проблема — это причина или потенциальная причина инцидента или инцидентов.
Известная ошибка
Наш сотрудник изучил проблему, но ещё не успел решить. Ему нужно срочно бежать и тушить более важный пожар.
Убегая, он вспомнил, что почти всегда помогает перезагрузка компьютера и предложил такой вариант пользователю. Действительно, всё заработало. Инцидент решён, и мы нашли обходное решение: перезагрузка клиентского ПК или перезапуск диспетчера печати помогут нам на какое-то время.
Теперь, когда мы уже проанализировали проблему — знаем, чем она вызвана, как она проявляется, но еще не решили, а только нашли обходное решение, мы можем назвать её известной ошибкой.
Известная ошибка в ITIL — это проблема, которая уже была проанализирована, но ещё не была решена.
Системное решение мы можем применить не всегда. Иногда нам нужно время на подготовку. А иногда мы не видим возможности или экономической целесообразности. И нам приходится использовать обходные решения.
В нашем примере системное решение — обновление версии драйвера принтера с помощью обновления от производителя. Это обновление мы пока ждём, производитель в курсе и обещал предоставить.
Управление проблемами и управление инцидентами
При управлении ИТ-услугами мы неизбежно сталкиваемся с перебоями в работе, снижением производительности, нарушениями структур данных и прочим.
То, как мы работаем с этими ситуациями, определяет то, как потребители и другие заинтересованные стороны воспринимают нашу организацию.
Именно здесь вступают в игру две важнейшие практики ITIL: управление инцидентами и управление проблемами.
Управление инцидентами — это способность максимально быстро восстановить нормальную работу услуги после инцидента, а управление проблемами нужно, чтобы снизить вероятность возникновения и негативное влияние от инцидентов.
Управление инцидентами может быть более заметно пользователям: у меня сломалось, мне быстро починили. А управление проблемами, кажется, не заметно вообще, ведь это внутренняя кухня ИТ.
На самом деле это не так: косвенно управление проблемами заметно и для пользователей.
У меня редко ломается, у меня никогда не ломается снова то, что уже чинили. Мне не нужно обращаться в поддержку каждый день из-за поломок.
А зачем так много терминов?
Пользователи и бизнес ожидают «чтобы работало», а не наша терминология.
Разделение «чего-то плохого, что случилось с нашими услугами» на инциденты, проблемы и известные ошибки нужно именно нам, чтобы уделять одинаковое внимание двум одинаково-важным активностям.
Поскорее поднять то, что упало и при этом не допустить падения снова. Ведь когда что-то упало нужно скорее поднимать. И здесь обходные решения — отличная практика.
Но если вся система будет состоять из обходных решений, то она будет очень хрупкой. Обходные решения не отменяют необходимость затем найти и устранить корневую причину, проблему. Сделать так, чтобы больше не падало. Вот почему две практики, а не одна. Вот почему они обе важны.
На нашем YouTube канале Вы можете посмотреть видео-версию этой заметки и еще много полезных роликов от экспертов Cleverics.
