Обзор Helpdesk

Текущая модель

Каждый тикет содержит набор основных атрибутов, которые используются во всех экранах Helpdesk:

• Уникальный номер
• Тему и тип тикета
• Статус, приоритет и SLA
• Автора, исполнителя и проект
• Связанные узлы сети
• Историю сообщений, заметок и изменений

Управление тикетами

• Создание тикетов — ручное создание обращений и автоматическое создание инцидентов мониторинга
• Назначение исполнителей — распределение и переназначение тикетов между специалистами
• Изменение статусов — поддерживаются состояния Новый, В работе, Отложен, Ожидание автора и Выполнен
• Установка приоритетов — выбор уровня от очень низкого до критического
• Массовые операции — групповое изменение статусов, приоритетов и исполнителей
• Фильтры — отдельные виды проблем, обращений, инцидентов и состояний тикетов

Коммуникация

• Публичные сообщения — видны автору тикета и службе поддержки
• Приватные заметки — доступны только исполнителям
• Вложения — прикрепление файлов и изображений к сообщениям
• Rich-text редактор — форматирование текста, ссылки и код
• Системные сообщения — автоматические записи об изменениях статуса и исполнителя
• Индикаторы новых сообщений — тикеты с новыми сообщениями от автора выделяются в списке

ИИ-помощник

• Ответы с учётом контекста — ИИ анализирует историю, сообщения и вложения
• Данные мониторинга — ИИ учитывает состояние связанных узлов и инцидентов
• База знаний — ИИ использует статьи и справочные материалы
• Команды диагностики — ИИ может предложить команды для проверки и устранения нарушения

Интеграции

• Мониторинг — автоматическое создание инцидентов при недоступности узла, высокой нагрузке или проблемах с дисками и сертификатами
• Связь с узлами — привязка тикетов к серверам и устройствам для быстрого контекста
• Электронная почта — создание обращений из входящих писем и отправка уведомлений
• Telegram-интеграция — уведомления о новых тикетах, сообщениях и изменениях статуса
• Периодические тикеты — создание повторяющихся задач по расписанию
• NODYX — автоматизация обработки обращений через BPM-процессы, маршрутизация на основе правил и конструктор форм для сбора данных

Ручная работа

• Проблему можно создать обычной формой или из выбранных обращений и инцидентов, в том числе разных проектов.
• На вкладке «Связанные тикеты» можно добавлять, переносить и исключать тикеты, включая проблемы нижнего уровня. Верхняя карточка показывает сводный состав ветви, но каждая связь и каждый тикет остаются у своей непосредственной проблемы.
• Вкладка Узлы сети рассчитывается по текущему составу всей доступной ветви. ИИ-помощник использует тот же чат тикета: сначала получает только агрегаты, затем постранично читает выбранную ветвь, доказательства и ключевые события.
• Связанные тикеты могут быть скрыты из обычных видов списка и представлены карточкой активной проблемы. Перед завершением система показывает фактический состав ветви, может закрыть доступные инциденты и обрабатывает подчинённые проблемы снизу вверх.

Автоматическое обнаружение

В разделе Настройки → Обнаружение проблем доступны системные алгоритмы. Алгоритм выполняется, когда для него сохранена хотя бы одна настройка; для разных проектов и порогов можно создать несколько настроек. Пустой выбор проектов означает всю установку. Важность и способ отсчёта SLA для автоматических тикетов задаются отдельно на вкладке Настройки → Служба поддержки → SLA → Автоматические тикеты. Условия, начальные значения и порядок разбора срабатываний подробно описаны в статье «Автоматическое обнаружение проблем».

• Одновременная недоступность узлов объединяет не менее заданного числа узлов одной сети, которые почти одновременно перестали отвечать на проверку доступности.
• Агенты не установлены отдельно группирует узлы, которые ни разу не передали данные агента после времени на установку. Ранее работавший и переставший отвечать агент — другой инцидент.
• Недоступны ранее работавшие агенты объединяет потерю связи с несколькими работавшими агентами одной сети. Инциденты проверки доступности учитываются отдельно.
• Нестабильный сигнал мониторинга выявляет повторные переходы одного сигнала доступности, агента, процессора, памяти или конкретного диска в аварию и обратно.
• Одновременные нарушения ресурсов узла требуют заданного числа инцидентов процессора, памяти или дисков и могут учитывать два направления: вычислительные ресурсы и хранилище.
• Сохранённая настройка выполняется автоматически; удаление настройки прекращает будущие проверки, но сохраняет уже созданные проблемы.

Система сопоставляет точный узел, вид сигнала и конкретный объект, например диск. Значения и временные ряды показателей в проблему не копируются. Внешние уведомления ненадолго задерживаются, чтобы вместо множества однотипных сообщений отправить одну понятную сводку. ИИ не участвует в обнаружении и остаётся дополнительным помощником оператора.

Общая проблема сетевой доступности

Отдельный алгоритм сопоставляет уже созданные проблемы недоступности узлов и агентов. Если сеть совпадает, а время начала отличается не больше заданного значения, INFRAX создаёт вышестоящую проблему в состоянии «Новая».

• В верхнем списке и уведомлении остаётся одна вышестоящая проблема; подчинённые доступны внутри карточки и в режиме «Все уровни».
• Внешнее уведомление может ожидать общую проблему не больше 180 секунд. Если совпадение не найдено, система отправит отдельную сводку исходной проблемы до истечения этого срока.
• Перевод вышестоящей проблемы в состояние «В работе» подтверждает новые автоматические проблемы всей ветви. Отклонение завершает только верхнее предложение и возвращает подчинённые проблемы в список.
• Связанные инциденты не копируются. Состав, узлы, счётчики и хронология вычисляются по всей ветви; исключение строки из верхней карточки изменяет её непосредственную проблему.
• Совпадение сети и времени указывает на общую область сбоя, но не доказывает неисправность маршрутизатора или другую физическую причину.

Публикация известной проблемы

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

• Пользователь видит только безопасные сведения опубликованных проблем своего проекта в INFRAX и Nodyx. Состав, узлы, внутренние сообщения, алгоритм, исполнитель и SLA проблемы не раскрываются.
• Выбор известной проблемы создаёт обычное обращение пользователя и связь с проблемой в одной операции. Обращение сохраняет собственные состояние, услугу, SLA и переписку.
• При завершении проблемы подходящее обращение получает один обычный ответ и переходит в ожидание заявителя. Завершённая или повторно открытая проблема снимается с публикации.

Завершение проблемы и обработка состава

Перед завершением оператор видит числа открытых инцидентов, подчинённых проблем и подходящих обращений всей доступной ветви. В едином окне можно сообщить заявителям о решении и закрыть все доступные открытые инциденты. Срок ожидания ответа задаётся для проекта или всей установки в настройках SLA; начальное значение — 7 дней.

• Каждое обращение получает ровно один обычный ответ через INFRAX, Nodyx или электронную почту; отсчёт SLA приостанавливается.
• Ответ заявителя означает, что симптом сохранился: обращение возвращается в работу, а SLA продолжается.
• Завершение обращения заявителем подтверждает решение. Если ответа нет до выбранного срока, обращение завершается автоматически.
• Доступные открытые инциденты можно закрыть той же командой. Подчинённые проблемы закрываются снизу вверх, когда их непосредственный состав уже закрыт или обработан текущей командой.
• Обращения процессов Nodyx, обращения без заявителя и недоступные проекты пропускаются и могут помешать закрытию подчинённой проблемы.
• При массовом завершении нескольких проблем показывается одно общее подтверждение, а совпадающие ветви не обрабатываются повторно.
• Сообщение, состояние, SLA и срок остаются обычными данными обращения. Повтор команды не дублирует сообщение. Полный порядок описан в статье «Ветви проблем и завершение».

Автор тикета

Автор — это пользователь, от имени которого создан тикет.

• Видит только свои тикеты
• Может добавлять публичные сообщения
• Получает уведомления об изменениях
• Может закрыть тикет после решения проблемы
• Не видит приватные заметки исполнителей

Исполнитель

Исполнитель — это специалист службы поддержки, назначенный на решение тикета.

• Может быть назначен администратором или взять тикет на себя
• Видит все публичные сообщения и приватные заметки
• Может изменять статус тикета
• Может добавлять публичные сообщения и приватные заметки
• Получает уведомления о новых сообщениях от автора

Администратор Helpdesk

Администратор — это пользователь с правами управления всеми тикетами.

• Видит все тикеты всех проектов (при наличии прав)
• Может создавать тикеты от имени других пользователей
• Может назначать и переназначать исполнителей
• Может изменять приоритеты и статусы любых тикетов
• Может выполнять массовые операции
• Имеет доступ к дашборду и статистике

Интеграция с мониторингом

Система мониторинга автоматически создает инциденты при возникновении проблем:

• Недоступность узлов (потеря связи)
• Высокая загрузка процессора (CPU)
• Нехватка оперативной памяти (RAM)
• Переполнение дисков
• Истечение срока SSL-сертификатов

Такие тикеты помечаются как инциденты мониторинга и содержат контекстную информацию о проблеме и связанном узле.

Интеграция с узлами сети

Тикеты могут быть связаны с узлами сети:

• При создании тикета можно выбрать связанный узел
• Тикеты инцидентов автоматически связываются с проблемным узлом
• В карточке тикета отображается информация об узле
• ИИ-помощник использует данные мониторинга связанных узлов
• Из карточки узла можно просмотреть все связанные тикеты

Интеграция с электронной почтой

Система поддерживает работу с электронной почтой:

• Автоматическое создание обращений из входящих писем
• Отправка уведомлений о новых обращениях, сообщениях и смене состояний
• Поддержка вложений из писем
• Обработка ошибок доставки

Telegram-интеграция

Telegram-бот для получения уведомлений:

• Уведомления о новых тикетах
• Уведомления о новых сообщениях
• Уведомления об изменении статуса
• Возможность быстрого ответа через бот

ИИ-помощник

ИИ помогает разбирать инциденты и проблемы:

• Анализ контекста тикета
• Предложение решений на основе истории
• Доступ к базе знаний
• Использование данных мониторинга
• Выполнение команд на узлах (с подтверждением)

Сценарий 1: Обращение пользователя

1. Пользователь создает тикет с описанием проблемы или запроса
2. Администратор назначает исполнителя и при необходимости корректирует приоритет
3. Исполнитель переводит тикет в статус "В работе"
4. Участники обмениваются сообщениями и вложениями для уточнения деталей
5. После решения тикет переводится в "Ожидание автора" или сразу в "Выполнен"
6. Пользователь подтверждает результат и закрывает обращение, если это требуется процессом

Сценарий 2: Автоматический инцидент

1. Система мониторинга обнаруживает проблему, например высокую загрузку CPU
2. Автоматически создается тикет с высоким приоритетом
3. Тикет связывается с проблемным узлом
4. Администраторы получают уведомления
5. Исполнитель использует ИИ-помощника для диагностики
6. ИИ предлагает команды для устранения нарушения
7. После решения тикет закрывается

Сценарий 3: Периодическая задача

1. Администратор создает шаблон периодического тикета
2. Настраивает расписание, например еженедельно
3. Система автоматически создает тикеты по расписанию
4. Исполнитель выполняет повторяющуюся задачу, например проверку резервных копий
5. Тикет закрывается после выполнения
6. На следующей неделе процесс повторяется автоматически

Сценарий 4: обращение по электронной почте

1. Пользователь отправляет письмо на адрес поддержки
2. Система автоматически создает тикет из письма
3. Тема письма становится темой тикета
4. Вложения из письма автоматически прикрепляются к тикету
5. Исполнитель отвечает через систему
6. Пользователь получает ответ по электронной почте
7. Дальнейшая переписка синхронизируется в обе стороны