2.07. Управление обращениями
Управление обращениями
Инцидент
Инцидент — это любое незапланированное событие, которое приводит к полному или частичному нарушению нормальной работы ИТ-услуги или угрожает её стабильности. Основная цель при работе с инцидентом — как можно быстрее восстановить работоспособность сервиса, минимизировав влияние на бизнес.
Инциденты носят реактивный характер: они возникают спонтанно и требуют немедленного вмешательства. Причины могут быть разными: ошибка пользователя, дефект программного кода, сбой оборудования, сетевая аномалия, внешняя атака и т.д.
ITIL 4 определяет инцидент как любое событие, которое вызывает или может вызвать прерывание предоставления услуги или снижение её качества.
Примеры
Примеры инцидентов:
| Категория | Пример |
|---|---|
| Серверы | Падение сайта, недоступность API |
| Авторизация | Пользователь не может войти в систему |
| Базы данных | Ошибка чтения/записи, потеря данных |
| Сеть | Проблемы с подключением, DDoS-атаки |
| Приложения | Краш программы, ошибка выполнения команды |
Управление инцидентами
Существует процесс управления инцидентами (Incident Management), цель которого как раз таки эффективное и своевременное реагирование на инцидент с быстрым восстановлением работоспособности системы. Это процесс, направленный на быструю идентификацию, регистрацию, диагностику, временное или окончательное решение, закрытие инцидента. Цель — восстановить сервис. Глубокий анализ первопричины выносится за рамки Incident Management и передаётся в Problem Management.
Запрос на обслуживание
Запрос на обслуживание (Service Request) — запланированное обращение, связанное с предоставлением стандартной ИТ-услуги, изменением конфигурации или использованием существующих возможностей системы. В отличие от инцидента, он не связан с отказом или сбоем и выполняется в рамках заранее определённых процедур.
Такие запросы предсказуемы, стандартизированы и часто автоматизированы. Они регулируются процессом Request Fulfilment, который обеспечивает их выполнение в установленные сроки и с соблюдением политик безопасности и доступа.
Пример
Примеры запросов на обслуживание:
| Категория | Пример |
|---|---|
| Управление доступом | Добавление нового пользователя, изменение прав |
| Настройка | Изменение параметров системы, конфигурация интеграций |
| Обучение | Запрос на проведение обучения сотрудников |
| Документация | Получение справочных материалов, отчетов |
| Актуализация | Обновление программного обеспечения, смена тарифа |
Управление запросами
Управление запросами (Request Fulfilment) является процессом, целью которого выступает выполнение запроса в срок и в соответствии с установленными стандартами. Часто реализуется через каталог услуг (Service Catalog), может обрабатываться автоматически (например, self-service portal), имеет фиксированный workflow и SLA, но обычно менее жёсткие, чем для инцидентов.
Если пользователь пишет: «Я не могу отправить документ», это инцидент — нужно срочно разобраться. А если он пишет: «Как добавить нового пользователя?», это запрос на обслуживание — можно дать инструкцию или направить в KB. Причём, это даже можно квалифицировать как консультацию, что будет ещё проще.
Консультации
Хотя в ITIL консультации не выделены как отдельный тип, на практике они составляют значительную долю обращений. Консультация — это запрос информации, не требующий изменения состояния системы или вмешательства в инфраструктуру.
Примеры: «Как экспортировать отчёт?», «Есть ли мобильное приложение?», «Где находится настройка уведомлений?». Бывают системы, где консультаций просто нет, и пользователи хорошо знают предметную часть и ориентируются в системе.
На моем же опыте было сложнее, 90% проблем были консультациями, так как на юзеров накидывали море информации. Консультации можно рассматривать как подтип запроса на обслуживание или как самостоятельную категорию в гибридных моделях. Их особенность — минимальная операционная нагрузка: решение чаще всего сводится к ссылке на документацию или базу знаний.
Правильная классификация позволяет, например, направить первый запрос в L2-поддержку с приоритетом P1, а второй — автоматически обработать через портал самообслуживания.
Проблемы
Также можно рассказать о проблемах.
Важно понимать, что инцидент ≠ проблема. Инцидент — это симптом, а проблема — это скрытая, потенциальная или реальная корневая причина одного или нескольких инцидентов.
Управление проблемами
Процесс управления проблемами (Problem Management) направлен на долгосрочное устранение источников сбоев. К примеру, 50 пользователей не могут войти в систему, и анализ показывает, что ошибка повторяется при каждом обновлении конфигурации. Корневая причина (RCA — Root Cause Analysis): после обновления шаблона конфигурации в CI/CD pipeline некорректно применяются настройки LDAP-синхронизации.
Значит, инциденты и проблемы связаны. Выделяют следующие виды связей:
- Иерархические: одна родительская проблема порождает множество дочерних инцидентов.
- Параллельные: одна скрытая ошибка вызывает разные проявления в разных сервисах.
- Каскадные: сбой в одном компоненте приводит к цепочке инцидентов в зависимых системах.
Координатор
Координатор проблемы (Problem Manager) — специалист, отвечающий за идентификацию потенциальных проблем, организацию расследования (investigation), проведение RCA, контроль внедрения постоянных решений.
Современные системы управления ИТ-услугами (например, ServiceNow, Jira Service Desk, Zendesk) позволяют автоматически определять тип обращения, назначать приоритет, перенаправлять в нужный отдел, предлагать готовые решения из базы знаний и отслеживать выполнение по SLA (Service Level Agreement). AI и NLP помогают классифицировать обращения уже на этапе создания тикета, что значительно ускоряет дальнейшую обработку.