Управление жизненным циклом обращений

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Управление обращениями

Инцидент

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

Инциденты носят реактивный характер: они возникают спонтанно и требуют немедленного вмешательства. Причины могут быть разными: ошибка пользователя, дефект программного кода, сбой оборудования, сетевая аномалия, внешняя атака и т.д.

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 помогают классифицировать обращения уже на этапе создания тикета, что значительно ускоряет дальнейшую обработку.

---