Инцидент в ITSM: не просто сбой, а точка…

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

Что внутри

Определение инцидента даётся по ITIL и сразу разводится с запросом на обслуживание — на примере, а не через противопоставление терминов: почта не работает — инцидент, нужен новый ящик — запрос. Приём рабочий, именно на этой границе путаются чаще всего.

Дальше жизненный цикл в пять этапов, роли участников, матрица приоритизации через влияние и срочность, отдельным разделом критичные инциденты — с оповещением каждые пятнадцать-тридцать минут и обязательным разбором после. Метрики названы четырьмя: время до реакции, время до восстановления, доля решённого первой линией и соблюдение соглашения об уровне услуги. Замыкает статью разведение инцидента и проблемы: симптом против причины.

Кому пригодится

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

На что обратить внимание

Цифры даны как отраслевые ориентиры: доля решённого первой линией в семьдесят-восемьдесят процентов, интервал оповещения в пятнадцать-тридцать минут. Источник этих чисел в статье не назван, и брать их как норматив для своей компании нельзя — это порядок величины, а не цель.

Материал опубликован поставщиком системы автоматизации. Прямой рекламы в нём нет, но выбор акцентов у поставщика всегда свой.

Что читать рядом

Наш разбор управления инцидентами отвечает на те же вопросы подробнее и с указанием источника у каждого утверждения. Про границу с соседними практиками — раздел «Что рядом и чем отличается».