Что такое инцидент в itil
Управление инцидентами (Incident management) по ITIL
По терминологии ITIL, инцидент – это событие, которое ставит под угрозу выполнение бизнес-процессов и может снизить уровень предоставления услуг. Нет доступа к серверу, не работает телефония, неустойчивый сигнал Wi-Fi – каждая из этих проблем требует немедленного решения. На помощь приходит управление инцидентами. Его основная задача – как можно быстрее восстановить услугу, минимизировать влияние сбоя на пользователя и компанию, а также предотвратить финансовые потери.
Какие этапы включает управление инцидентами
Этапы управления инцидентами
Первым делом происходит обнаружение и регистрация инцидента. Источником информации о сбое могут быть как пользователи, так и системы мониторинга, зафиксировавшие неполадку. При регистрации указывается проблема, кто ее будет устранять и другие важные данные. От принятого регламента по уровню обслуживания (SLA) зависит время, за которое инцидент необходимо устранить.
Дальше определяется, к какой категории или классу относится инцидент. В зависимости от срочности ему присваивается приоритет. Чем он выше, тем быстрее специалисты примутся за диагностику проблемы и определят ее причины.
Если вопрос сложный, происходит эскалация: обращение передается на более высокий уровень поддержки, при необходимости подключается менеджер процесса, руководитель поддержки или бизнес-заказчик.
Когда решение найдено, сотрудник закрывает инцидент, а пользователь, оставивший заявку, должен подтвердить, что проблема устранена. Если это не так, инцидент возвращается к специалисту на доработку.
В управлении инцидентами один из важнейших критериев – скорость. Не всегда есть возможность оперативно найти основную причину случившегося и устранить ее. Иногда доступ к услуге можно восстановить быстрее, предложив временное решение. В таком случае сотрудник находит, анализирует и устраняет корневую причину уже после закрытия инцидента в рамках другого процесса – управления проблемами. Учет всех инцидентов и вызвавших их проблем в ИТ-системе дает специалистам возможность обращаться к прошлому опыту и легче справляться со схожими обращениями.
Зачем компании автоматизировать управление инцидентами
Автоматизация управления инцидентами позволяет компании быстрее справляться с обнаруженными ошибками и сбоями в сервисах, минимизировать потери и сохранять высокий уровень предоставления услуг.
С помощью инструмента автоматизации работа над инцидентами становится прозрачной и понятной, все обращения регистрируются и распределяются по компетентным специалистам. Благодаря приоритетам у сотрудников нет путаницы: они точно знают, в каком порядке обрабатывать заявки.
В системе фиксируются все действия пользователей. Эти данные помогают формировать отчеты, по которым можно проверять соблюдение SLA, видеть количество решенных инцидентов, и тех, что вернулись на доработку, а также анализировать работу специалистов по различным показателям.
ITSM 365 как инструмент для управления инцидентами
ITSM 365.Support – это облачное сервис деск решение, в рамках которого автоматизируется процесс управления инцидентами.
ИТ-система помогает сотрудникам обрабатывать поступающие инциденты, назначать ответственных за их исполнение, учитывать их загрузку.
Список зарегистрированных инцидентов в сервис деск системе
В свою очередь пользователи получают прозрачный процесс работы над обращениями с уведомлениями о каждом изменении статуса заявки и сроках исполнения.
Кроме того, пользователи услуг могут оценивать выполненные работы, благодаря чему накапливается статистика об уровне удовлетворенности обслуживанием.
«Как близнецы»: 3 пары похожих терминов ITIL
Библиотека ITIL — подробный набор методов управления ИТ-услугами, который применяют с восьмидесятых годов. Но путаница в используемых терминах и их значении до сих пор преследует тех, кто только начинает внедряет у себя соответствующие методологии.
В этой статье мы попытаемся разграничить три пары похожих терминов:
Инцидент и проблема
IT-специалист и автор тренингов по ITIL Майкл Скарборо (Michael Scarborough) подчёркивает, что между терминами установлена следующая зависимость: проблема — причина, инцидент — следствие.
Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. Когда мы говорим «разрешили инцидент», это значит, что временно восстановили какую-то услугу (на 10 лет или всего на 1 минуту). То есть очень вероятно, что подобная ситуация повторится в будущем.
Проблема же, это причина возникновения инцидентов. Эксперт в области ITSM профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему», который вы задаёте себе.
Посмотрим на примеры, которые приводит директор по маркетингу компании Hornbill Питер Саммерс (Peter Summers).
Инцидент: пользователь звонит в службу поддержки и сообщает, что не может распечатать документ. Специалист, который принимает вызов, обнаруживает, что указанный файл вызвал ошибку в очереди печати. Чтобы можно было продолжить работу, специалист предлагает пользователю временно воспользоваться принтером в соседнем офисе.
Проблема: инцидент с принтером — признак глобальной проблемы. Этот пользователь — первый из многих, кто позвонит сегодня в службу поддержки. Допустим, удалось установить, что причиной инцидентов является обновление офисного ПО прошлой ночью. Если исправить баги апдейта, проблема будет решена и отказов в печати по этой причине больше не будет.
Для наглядности возьмём более приземлённый пример. Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.
Другой пример: вы едете на лысой резине — это проблема. Если вы продолжите её игнорировать, вероятность возникновения инцидента будет расти, покрышка, вероятно, лопнет.
Чтобы упростить вопрос с разграничением значений этих двух терминов, Филип Юсон (Philip Yuson), генеральный директор Concept Solutions Corporation, рекомендует задавать следующие вопросы:
Incident Management и Problem Management
Мы уже выяснили, чем отличаются инцидент и проблема, поэтому разграничить эти два процесса будет проще. ITIL определяет эти два термина следующим образом:
Управление инцидентами — управляет жизненным циклом всех инцидентов. Цель: скорейшее восстановление ИТ-услуги для пользователей.
Управление проблемами — управляет жизненным циклом всех проблем. Цель: предотвращение инцидентов в будущем.
Посмотрим на примеры от специалистов Microsoft. Представим сценарий: к специалисту техподдержки обратился пользователь, который не может просмотреть электронное письмо из-за ограничений. Саппорт создаёт новый инцидент с помощью шаблона e-mail incident, чтобы быстро разрешить ситуацию и обрабатывать похожие случаи в будущем.
В сценарии управления проблемами специалист техподдержки создаёт запрос на внесение изменений в код. Когда команда найдёт и устранит причину проблемы, это разрешит проблему и автоматически устранит инциденты с ней связанные.
Для большей ясности приведём пару примеров из жизни. Управление инцидентами похоже на работу пожарных. Они приходят на место происшествия и стараются максимально эффективно погасить огонь. То же самое происходит при управлении инцидентами. Возобновить работу инфраструктуры нужно быстро.
Далее начинается управление проблемами и детальное расследование происшествия. Этот процесс похож на работу эксперта или следователя. Он не был на месте, когда тушили пожар, но может определить причину возгорания и дать рекомендации, которые позволят избежать таких ситуаций в будущем.
Service desk и Helpdesk
Для начала вновь заглянем в официальную терминологию ITIL.
Service Desk — единая точка контакта (SPOC) между поставщиком услуг и клиентами. Функции: управляет инцидентами, запросами на обслуживание.
Help desk — точка контакта для пользователей. Функции: регистрирует инциденты.
Термин «служба поддержки» часто употребляется как синоним службы Service Desk, что является главной причиной путаницы в терминах. Крис Коффи (Cris Coffey), менеджер по маркетингу компании BMC Software, который работает на рыке Help Desk уже 20 лет, выделяет следующие различия между двумя этими службами.
Service Desk: полностью интегрируется с другими ITSM-процессами, помогает организации соответствовать соглашениям об управлении уровнем услуг, интегрируется с базой данных управления конфигурациями и процессом управления активами.
Help Desk: отслеживает все входящие инциденты, автоматически отслеживает уведомления по электронной почте, предлагает ограниченную интеграцию с другими ITSM-процессами, предоставляет услуги самообслуживания для конечных пользователей.
Посмотрим, как это выглядит на практике. Пример работы Help Desk: драйвер для принтера Джо сломался, а ему нужно распечатать копии документов до 10 часов. Help Desk поможет Джо восстановить работу принтера или найдёт другой способ получить распечатки вовремя. Задача службы — сделать так, чтобы распечатки были в руках у Джо до 10 часов.
В той же ситуации Service Desk заметит, что за прошедшую неделю несколько человек с этого этажа обратились в службу с той же проблемой. Это значит, что проблема — глубже, чем кажется. Service Desk отправляет специалиста, чтобы установить корень проблемы с принтером. Задача службы — устранить первопричину.
Напоследок кратко обобщим все разобранные моменты:
Управление инцидентами и проблемами — понятия и принципы
Введение
Управление ИТ-услугами (ITSM) включает работу с инцидентами и проблемами. По мере возрастания роли ИТ в компании растет и потребность в обеспечении хорошего уровня сервиса, обеспечении максимальной доступности ИТ-услуг. Бизнес-пользователь должен иметь возможность получить решение своих проблем, если они возникают, как можно быстрее, и работать в любое время. Реализация процессов управления инцидентами и проблемами нацелена именно на это. В данной статье мы описываем, как может быть устроена работа ИТ-службы в рамках управления инцидентами и проблемами. Это описание основано на предложениях ITIL и опыте наших клиентов.
Язык инцидентов и проблем
ITIL Service Support — признанная в мире модель. Она основана на передовом опыте и используется как руководство ИТ-организациями при разработке подходов к управлению обслуживанием. Эта модель перспективна. Также она определяет дополнительные элементы, необходимые для успешного функционирования ИТ-организации как сервисного бизнеса. Она предоставляет технический словарь для обсуждения службы поддержки, определяет понятия и раскрывает отличия между различными видами деятельности. Например, деятельность, необходимая для реагирования на прерывания сервиса, его восстановления, отлична от деятельности по поиску и устранению причин, из-за которых прерывается обслуживание.
Инциденты
Инцидент — есть любое событие, которое не является частью стандартных операций сервиса и вызывает, или может вызвать, прерывание обслуживания или снижение качества сервиса.
Примерами инцидентов являются:
Проблемы
Проблема — есть неизвестная причина одного или более инцидентов.Одна проблема может породить несколько инцидентов.
Ошибки
Известная ошибка — есть инцидент или проблема, для которой выявлена причина и разработано решение по ее обходу или устранению. Ошибки могут выявляться в результате анализа жалоб пользователей или анализа систем.
Примеры ошибок включают:
Соотношение понятий управления инцидентами и проблемами показано на рисунке 1. Инциденты, проблемы и известные ошибки связаны в своего рода жизненный цикл: инциденты часто являются индикаторами проблем ⇒ выявление причины проблемы определяет ошибку ⇒ ошибки затем систематически исправляются.
Система ИнфраМенеджер – мощная российская система управления инцидентами и проблемами
Управление инцидентами
Управление инцидентами — есть деятельность по восстановлению нормального обслуживания с минимальными задержками и влиянием на бизнес-операции, являющаяся реактивным, сфокусированным на краткосрочную перспективу сервисом восстановления.
Она включает в себя:
Управление проблемами
Управление проблемами — есть деятельность по минимизации воздействия на бизнес проблем, которые вызываются ошибками в ИТ-инфраструктуре, по предотвращению повторения инцидентов, связанных с такими ошибками. Управление проблемами выявляет причины проблем, идентифицирует решения по их обходу или устранению.
Управление проблемами включает:
Контроль проблем
Цель контроля проблем — найти причину проблемы, выполнив следующие шаги:
Контроль ошибок
Контроль ошибок обеспечивает исправление проблем за счет следующих действий:
Анализ проблем
Цель анализа проблем состоит в улучшении процессов управления инцидентами и управления проблемами. Что достигается изучением качества результатов деятельности по устранению основных проблем и инцидентов.
Организационные роли и распределение ответственности
Наиболее часто встречаемой структурой системы поддержки является многоуровневая модель, в которой все возрастающий уровень технических возможностей применяется для решения инцидента или проблемы. Фактические роли и распределение ответственности, используемые в многоуровневой реализации системы поддержки, могут быть различными в зависимости от персонала, истории и политики конкретной организации. Тем не менее, следующее описание многоуровневой системы поддержки типично для многих организаций.
Первый уровень поддержки
Организация (подразделение), представляющая первый уровень поддержки обычно относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Help Desk, Service Desk.
Роли. Владелец процесса
Первый уровень поддержки гарантирует, что установлен и поддерживается хорошо определенный, единообразно исполняемый, измеряемый соответствующим образом, эффективный процесс управления инцидентами. Получение и управление всеми вопросами обслуживания потребителей. Первый уровень поддержки является единственной точкой контакта для передачи вопросов с обслуживанием, и он действует как адвокат конечного пользователя, который гарантирует, что вопросы с обслуживанием решаются своевременно.
Первая линия поддержки
Организация первого уровня поддержки предпринимает первую попытку разрешить вопрос с обслуживанием, о котором сообщил конечный пользователь.
Обязанности
Точная регистрация инцидентов. Первый уровень поддержки гарантирует, что информация об инциденте вносится в журнал системы. Для этого должно быть:
Владение каждым инцидентом. Как адвокат конечного пользователя первый уровень поддержки обеспечивает успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:
Первый уровень поддержки использует базу данных управления проблемами для сопоставления инцидентов известным ошибкам и применения ранее найденных способов разрешения инцидентов. Цель заключается в разрешении 80 процентов инцидентов. Остальные инциденты передаются (эскалируются) на второй уровень.
Непрерывное улучшение процесса управления инцидентами. Как владелец данного процесса первый уровень поддержки гарантирует улучшение при необходимости процесса посредством:
Способности и навыки
Навыки межличностного общения первостепенны. Персонал первого уровня поддержки вовлечен главным образом в расстановку приоритетов и управление проблемами. На этом уровне поддержки проводятся лишь незначительные технические изыскания. Способность применять «консервированные» решения. Персонал первого уровня должен уметь распознавать симптомы, применять поисковые инструменты для обнаружения ранее разработанных решений и помогать конечным пользователям в применении таких решений.
Второй уровень поддержки
Этот уровень также обычно относится к оперативным службам.
Обязанности
Способности и навыки
Третий уровень поддержки
Этот уровень поддержки обычно относится к группе разработки приложений и сетевой инфраструктуры.
Обязанности
Способности и навыки
Процессы
Можно выделить три основных процесса, связанных с управлением инцидентами и управлением проблемами:
Эти основные процессы присутствуют практически во всех передовых организациях, хотя могут иметь и другие названия.
Процесс управления инцидентами
Данный процесс сфокусирован на скорейшем восстановлении прерванного сервиса. В таблице 1 приведены основные параметры этого процесса, а на рисунке 1 показана диаграмма его работы.
