incident record

Запись об инциденте — это основной рабочий артефакт в практике управления инцидентами: в ней фиксируется вся информация, необходимая для восстановления услуги и управления коммуникациями. Обычно запись создаётся сервис-деск при регистрации обращения или автоматизировано на основе события из средств мониторинга. В записи отражают что именно затронуто (услуга, сервисное предложение, затронутые пользователи, связанные КЕ), когда и как проявилась неисправность, какому уровню приоритета она соответствует, кто выполняет работу (команда поддержки), какие действия предпринимались, какие обходные решения применялись, как проводилась эскалация и чем завершилось разрешение. Запись также служит основой для измерения и отчётности: можно анализировать время реакции и разрешения, повторяемость, загрузку команд и качество коммуникаций. Важно понимать границы: запись об инциденте описывает конкретный инцидент и его жизненный цикл, но не заменяет запись о конфигурации в CMDB, не является бизнес-кейсом, не предназначена для управления изменениями и не подменяет полноценный анализ причин, который относится к управлению проблемами.

Частая ошибка — путать запись об инциденте с обращением или просто «тикетом». Обращение может быть любым контактом с сервис-деск, а запись об инциденте должна существовать только для инцидента и содержать данные, достаточные для управления его жизненным циклом. Другая путаница — считать, что «инцидент = проблема»: инцидент фиксирует нарушение услуги и работу по восстановлению, тогда как проблема и известная ошибка относятся к причине и знаниям о повторяющихся сбоях; при этом одна и та же проблема может быть связана с множеством записей об инциденте. Также неверно воспринимать запись как формальность «ради отчётности»: неполные поля, отсутствие временных отметок и истории коммуникаций делают невозможными корректные метрики и разбор крупных инцидентов. Важно не превращать запись в журнал технических догадок: следует фиксировать наблюдаемые факты, выполненные действия, результаты и согласованные шаги. Наконец, не стоит «закрывать» запись без подтверждения восстановления услуги и информирования заинтересованной стороны; преждевременное закрытие и отсутствие связей с КЕ, событиями и обходным решением ухудшают повторное использование знаний и качество поддержки.