Ветви проблем и завершение

Зачем нужна ветвь

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

Как устроена ветвь

Пример

Общий сбой сети — вышестоящая проблема.

  • Недоступность узлов — подчинённая проблема с инцидентами проверки доступности.
  • Недоступность агентов — подчинённая проблема с инцидентами связи с агентами.
  • У каждой подчинённой проблемы могут быть собственные обращения пользователей и инциденты.

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

Во вкладке «Связанные тикеты» первая группа относится к открытой карточке. Остальные группы подписаны номерами и названиями подчинённых проблем. Счётчики активных и закрытых элементов помогают понять, где ещё остались последствия.

Меняйте состав у его владельца

Если инцидент находится в группе подчинённой проблемы, откройте эту проблему и исключайте либо переносите инцидент там. Это не даёт случайно изменить чужой уровень ветви.

Доступ и видимость

Ветвь раскрывается вниз только от доступной вам проблемы. Вы видите лишь те проекты, обращения, инциденты и проблемы, на которые у вас есть права. Количество скрытых элементов и названия недоступных проектов не раскрываются.

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

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

Опубликуйте подтверждённую проблему, если пользователи могут столкнуться с тем же сбоем. В форме создания обращения они увидят известную проблему и смогут указать, что их случай относится к ней.

Условия публикации

  • предложение уже подтверждено, проблема открыта и находится в работе;
  • есть понятное описание для пользователей;
  • выбрана услуга;
  • указано ожидаемое время решения в будущем.

Пользователь видит только безопасную сводку: название, описание, услугу, состояние и ожидаемое время решения. Внутренняя переписка, состав ветви, узлы и служебные сведения не публикуются.

Что происходит при выборе известной проблемы

В INFRAX или пользовательском приложении Nodyx создаётся обычное обращение со своим номером, сроками и перепиской. Оно сразу связывается с выбранной проблемой. Оператор видит новый симптом в составе, а пользователь продолжает общаться в своём обращении.

Пишите для пользователя

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

Что проверить перед завершением

  1. Причина устранена или принято обоснованное решение прекратить работу по проблеме.
  2. В описании или переписке зафиксированы причина, выполненное действие и способ проверки.
  3. Состав просмотрен на всех доступных уровнях, ошибочные связи исключены.
  4. Определено, нужно ли закрыть инциденты и запросить подтверждение у заявителей.
  5. Если проблема опубликована, пользовательское описание и ожидаемое время больше не вводят в заблуждение.

Не переводите проблему в завершённое состояние обычной сменой статуса, не просмотрев расчёт. Кнопка завершения показывает последствия для всей доступной ветви до применения изменений.

Единое окно завершения

Откройте проблему и выберите завершение. При массовом действии отметьте несколько проблем: система один раз посчитает все выбранные ветви и не обработает один связанный элемент дважды.

ПереключательЕсли включёнЕсли выключен
Сообщить заявителям и ждать ответаПодходящим обращениям отправляется одно сообщение о решении; они переходят в ожидание заявителяОбращения не меняются и могут остаться открытыми
Закрыть все инцидентыВсе доступные открытые инциденты ветви закрываютсяИнциденты не меняются и могут помешать закрытию подчинённых проблем

Если включена работа с обращениями, текст сообщения обязателен. Компактная сводка показывает количество обрабатываемых обращений, открытых инцидентов и Проблем нижнего уровня. Раскрывайте «Связанные тикеты», только если нужно проверить отдельные элементы, пропуски или препятствия. Подготовленное сообщение можно изменить перед подтверждением.

Оба переключателя можно выключить

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

Что происходит с обращениями

  1. Каждому обычному обращению с известным заявителем или адресом электронной почты отправляется одно сообщение о решении.
  2. Обращение переходит в состояние «Ожидание», а отсчёт SLA приостанавливается.
  3. Срок ответа берётся из настройки проекта или общего значения «SLA → Сроки решения → Ожидание ответа по обращениям». Начальное значение — 7 дней.
  4. Если пользователь ответит, обращение вернётся в активную работу, а автоматическое завершение будет отменено.
  5. Если пользователь подтвердит решение, обращение завершится сразу. Если ответа не будет до срока, система завершит его автоматически.

Обращения без заявителя, недоступные оператору или принадлежащие выполняемому процессу Nodyx пропускаются. Они не получают сообщение и не меняют состояние. Причина пропуска показывается в предварительном расчёте.

Зачем ждать подтверждения

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

Закрытие подчинённых проблем

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

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

Связи после закрытия не удаляются: они остаются историей расследования. Завершённые элементы отмечаются как закрытые и не считаются активными последствиями.

Автоматическое закрытие предложений

Система может самостоятельно закрыть только проблему, которую создал алгоритм и которую оператор ещё не подтвердил. Это происходит, когда в ветви никогда не было обращения любого вида, все инциденты уже закрыты и нет подтверждённой открытой проблемы.

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

Почему предложение исчезло из активных

Если все его последствия восстановились до разбора оператором и к ветви не было пользовательских обращений, предложение могло закрыться автоматически. Откройте закрытые проблемы: состав, системное описание и связи сохраняются.