тикет что это значит у программистов
5 правил работы с тикетами
1. Правило «один на один»
Каждый тикет (он же — «баг») представляет собой взаимосвязь между двумя людьми: тем, кто заявил о проблеме, и тем, кто будет ее решать. Если это баг — сообщает о нем, разбирается, если это вопрос — задает его, отвечает. Неважно, какое количество людей с обеих сторон вовлечено в решение вопроса, в этой коммуникации участвуют только двое.
Ответственность того, кто создает тикет — рассказать о проблеме. Когда вы создаете тикет, вы настаиваете на том, что проблема существует: может сказать, что все работает, может утверждать, что у него такой ошибки нет, еще — что описание проблемы слишком мутное и никто не понимает, в чем, собственно, дело. Задача создающего тикет — обеспечить его жизнеспособность. Если вы создали тикет — вы его до самого момента закрытия.
Задача второй стороны — обеспечить решение. Если тикет назначен вам — ваша задача убедить вторую сторону, что ваше решение — самое лучшее. Вам могут говорить, что этого решения недостаточно, что оно неэффективно или не до конца решает проблему. Конечно, ваша задача — исследовать корни проблемы, просчитать все возможные варианты и предложить хорошее решение, но все это второстепенно, ведь ваша главная задача — закрыть тикет.
В один всегда продает другому свое видение вопроса.
2. Закройте его!
— это не чат, и вы здесь не для того, чтобы разговаривать. Вы здесь для того, чтобы решить свой вопрос. Тикеты, которые не закрываются неделями, это настоящий ночной кошмар как для заявителя, так и для технического специалиста: их сложно отслеживать и еще сложнее контролировать. Тикет может иметь сотни комментариев, которые в конце концов заставляют забыть, в чем же, собственно, была проблема.
Все это — ошибка обеих сторон. Тикет должен быть сформулирован кратко и по существу. Сценарий идеального тикета таков: проблема — уточняющие вопросы — короткое объяснение — решение — закрытие тикета, всем спасибо.
3. Не закрывайте его!
Каждый раз, когда вы обнаруживаете баг и создаете тикет, вы тратите свое время. Каждый раз, когда сотрудник техподдержки обрабатывает ваш тикет, тратит массу ресурсов.
Если вы подтверждаете закрытие тикета, а проблема толком не решена, вы выбрасываете свои деньги и деньги провайдера в мусорное ведро. Если тикет создан, нельзя сказать «Ладно, разберемся позже». Если он запущен, должны быть предприняты все меры для решения возникшей неполадки.
Посмотрите на это с такой стороны: когда вы создали тикет, у вас в голове была определенная задача, пошло не так. Если у вас в данный момент недостаточно времени, и вы закрываете вопрос, другой в будущем найдет то же баг и будет снова тратить время — свое и провайдера — на решение этой проблемы. Сделайте мир немного лучше, не закрывайте тикет до тех пор, пока вы не получили полноценный ответ на свой запрос.
4. Тсс….Не шумите!
Каждый раз, когда вы оставляете комментарий по тикету, адресуйте его — в ином случае ваш комментарий посчитают просто высказыванием своего мнения, тем, что называется в психологии «коммуникационным шумом». Помните, тикет — это общение между двумя участниками.
Всегда адресуйте свой вопрос/просьбу/требование конкретному человеку, с которым вы общаетесь для закрытия своей проблемы. Все остальное просто усложняет процесс решения проблемы, но ни в коем случае не помогает в нем.
5. Говорите громче
Всегда говорите о том, что вас не устраивает. Каждый раз, когда вы сообщаете о проблеме, объясните, что именно пошло не так. Это ваша задача — объяснить, что именно в продукте работает некорректно, что не задокументировано, в чем есть вопросы. Вы получили услугу, и это ваше право — сообщить о проблеме, и ваша обязанность — объяснить, что конкретно не соответствует вашим ожиданиям.
Формула тикета такова: «Вот что мы имеем, а вот что мы должны иметь». Вы как бы передвигаете проект из точки, А в точку Б: пошло не так в точке, А, и для всех нас было бы лучше оказаться в точке Б. Очевидно, что ваша задача — нарисовать эту линию из точки, А в точку Б.
Скажем, если у вас вопрос, это значит, что в документах недостаточно информации — и это корень проблемы. Вместо того, чтобы спрашивать: «Как подключить Х?», скажите: «В текущих документах нет информации о том, как подключить Х. Пожалуйста, дополните их».
Каждый раз, создавая тикет, чувствуйте себя художником — рисуйте четкую линию из точки А в точку Б.
Тикет-системы: как бесплатная OTRS три платных уделала?
Бесплатный софт для бизнеса — спорная история. Компания, которая выбирает такое ПО, должна понимать, что либо ей придётся столкнуться с open source и искать разработчика на поддержку программы, либо принять бесплатную версию программы как есть, без надежды на поддержку, доработку и обучение. Так себе перспектива. Но это с позиций околоайтишного обывателя, который слова «open source» и «вендорское внедрение» выучил, а глубоко не погружался. А мы вот взяли и решили растолковать всё на примере одного популярного ПО, которое может пригодиться и большим, и маленьким компаниям. Давайте разбираться вместе.
Морали не будет, а вот выбор есть
Всё начинается с тикета
Всё началось недавно. Мы в RUVDS внедрили маркетплейс — платформу, на которой можно найти предварительно сконфигурированные приложения и решения, чтобы начать работу с необходимыми программами на виртуальных серверах в один клик. Первым запустили OTRS Community Edition — тикет-систему с открытым исходным кодом, основанную на системе OTRS.
Знаете, почему? Потому что она нужна абсолютно всем. Ну в смысле тикет-система, а какая — дело вкуса, бизнес-требований и выбора.
Все компании каким-то образом взаимодействуют с клиентами, но нередко переписка по проблемам и заявкам ограничивается электронной почтой или диалогом в социальных сетях. Это, конечно, неграмотное управление заявками клиентов по каким бы то ни было проблемам.
▍Необходимость использования тикет-системы по мере развития бизнеса
Если фирма небольшая и поддержку осуществляют 1 — 2 сотрудника, то особой необходимости в тикет-системе нет. Они могут просто отвечать на email, в соцсетях и на телефонные звонки. Когда объем заявок растет, то необходимо большее число сотрудников поддержки и здесь возникает ряд проблем.
Перейдём к сравнению
▍Участники
Мы решили рассмотреть несколько тикет-систем международного уровня.
▍OTRS и его «команда»
OTRS — самая строгая, функциональная, лаконичная и деловая из перечисленных: минимум «примочек», максимум пользы. OTRS Community Edition — тикет система с открытым исходным кодом, основанная на системе OTRS. Это значит, что вы сможете дорабатывать систему так, как вам нужно (ну или заказывать доработку). Первый релиз состоялся 18 лет назад, система стабильна, проверена временем, используется многими крупными и не очень фирмами. Ещё у OTRS есть важное преимущество — развитое международное коммьюнити, готовое помочь, подсказать, дать сотню ссылок на GitHub и, в случае необходимости, поработать с конфигурацией за плату. Все мы знаем, насколько важно коммьюнити для такого ПО и наличие большого сообщества уже многое говорит о самой системе.
Как мы уже говорили выше, Zendesk, Freshdesk, Kayako — это системы, похожие между собой. Они работают по модели SaaS (Software as Service), то есть необходимо оплачивать подписку за каждого сотрудника ежемесячно.Так как системы сильно похожи, то мы не будем вдаваться в детали (для каждого бизнеса они очень разные и обусловлены текущими бизнес-процессами) и рассмотрим 2 варианта:
▍Стоимость
Логичное допущение, что даже небольшая фирма хочет, чтобы поддержка пользователей оказывалась в домене, принадлежащем компании — это серьёзно, весомо, престижно и выглядит безопасно. В этом случае у всех SaaS тикет-систем необходима подписка. Предположим, что у нас 5 сотрудников, отвечающих на заявки пользователей. В этому случае стоимость составит:
Самое интересное начинается при увеличении числа сотрудников: например, если за год число сотрудников поддержки удвоилось и стало не 5, а 10. Тогда у всех тикет-систем стоимость возрастет в 2 раза. У всех, кроме OTRS CE. В случае OTRS CE вы по прежнему платите 20$ / месяц — за свою виртуалку. По нашему опыту такая конфигурация эффективно обслуживает несколько десятков сотрудников поддержки при большом объеме заявок.
▍Простота установки и обслуживания
Онлайн сервисы поддержки изначально заточены под то, чтобы от пользователя требовались минимальные технические знания для использования. Т. е. от пользователя просто требуется привязать банковскую карту и указать параметры доступа к аккаунту электронной почты.
В случае OTRS требуются базовые знания работы с Linux. На официальном сайте поставляется установочный пакет для CentOS. Необходимо установить базу данных и этот пакет. Далее настройка производится через веб интерфейс. Если в фирме есть сотрудник, обладающий навыками администрирования Linux, то установка и настройка не должна вызвать сложностей и занимает пару часов. Чтобы упростить данную задачу в RUVDS подготовили образ с установленной OTRS и необходимым ПО для его работы. После создания образа пользователю просто нужно зайти в веб-интерфейс мастера установки и указать необходимые параметры. Данный образ позволяет сократить время установки и даёт возможность как можно быстрее попробовать, насколько данный продукт подходит для нужд вашей компании.
Интеграция с сервисами компании
Почти все тикет-системы имеют API для интеграции или интегрируются с другими приложениями посредством плагинов и аддонов. OTRS имеет некоторое преимущество за счет открытости кода — всё, чего вам не хватает, может быть доработано и перенесено в вашу конфигурацию на сервере.
▍Что по функциям?
В тикет-системе OTRS сть учёт клиентов, собственно ведение тикетов, календарь, отчётность, дашборд, панель администратора. Тикеты имеют скромный интерфейс, но в них есть всё, что необходимо: тело тикета, приоритет в очереди, статус, функции делегирования и эскалации и т.д. Есть шаблоны, подсказки, чат. Кроме того, напомним, что это открытый код и вы можете допились себе всё, что нужно для вашего экземпляра OTRS (разово заплатив программисту Perl).
Zendesk
Zendesk включает в себя возможности для службы поддержки, CRM для продаж, базу знаний, чат и т.д. — в зависимости от выбранной конфигурации. Выбранная нами для сравнения содержит управление тикетами с помощью почты, настройку бизнес-правил (урезанный вариант привычных бизнес-процессов), несколько дашбордов, базовые платформенные возможности. Кстати, Zendesk есть в том числе и на русском языке.
Freshdesk
Freshdesk в рассматриваемой нами версии содержит базовую функциональность, экспорт тикетов, отмену отправленного сообщения внутри тикета (эх!), публичные и приватные заметки операторов по тикетам, шаблоны, теги, быстрые действия, to-do листы с напоминаниями, создание тикетов по расписанию, базовые бизнес-правила SLA и т.д. В целом эта система функционально наиболее отзывчивая, содержит массу триггеров и важных мелочей для работы с тикетами. Однако нельзя сказать, что это экономит ресурсы или время — это просто удобно.
Kayako
В рассматриваемой нами версии Kayako доступны самые базовые возможности, огромное количество интеграций на базе Zapier, омниканальность, включая социальные сети, настройки для разграничения групп тикетов по операторам, некоторые макросы и шаблоны. По сути, это самое доступное решение из платных, но все его фичи и фишки начинаются в старших редакциях.
Итак, подведём черту. Чем хороша тикет-система OTRS, доступная по лицензии GPL v.3? Её можно самостоятельно доработать, она простая и надёжная как автомат, вам не нужно платить за лицензии (даже при масштабировании!), у неё нет ограничений по количеству тикетов и операторов (как на стандартных SaaS-тарифах), при этом она ничем не уступает аналогичным «тарифицируемым» системам по базовым функциям и безопасности. Ну а мы упростили обращение с ней, создав образ в маркетплейсе RUVDS. Новый год — новый сервис, предлагаем вам не откладывать. Мы-то знаем — ваши конкуренты не дремлют 🙂
Как я решаю тикеты
Так уж вышло, что последние 3 года я исключительно решаю проблемы пользователей. Не как эникейщик, на более высоком уровне, но это не меняет самого факта.
Проблемы бывают разные. Те, которые связаны с багами софта, железа или мозга клиента приходится локализовывать и передавать кому следует. Это не так интересно.
Гораздо интереснее заморочистые задачки.
Как то:
OSPF пиринг поднимается и падет через некоторое время.
Маршруты, полученные Route Reflector’ом по BGP не анонсируются клиентам.
Не работает Inter-AS Option C.
Это проблемы конфигурации, как правило. Я смотрю на формулировку запроса, понимаю, что я в этом абсолютно ничерта не смыслю, руки опускаются. Это нормальная ситуация, когда задача кажется огромной и не знаешь, с какой стороны к ней подойти.
Самое сложное — это взять телефон и позвонить заказчику. Он ведь заведомо опытнее меня, раз уж он это настраивал, а я ещё нет.
Ну давайте, в качестве иллюстрации возьмём какой-нибудь несложный тикет.
Не работает MPLS TE FastReroute (FRR). Это технология, которая позволяет переключиться трафику на другой путь в течение несольких миллисекунд, пока IGP не простроит новый маршрут.
Я не знаю, какой вопрос ему задать? Как понять суть проблемы, если я даже работу этого механизма ещё не представляю.
Это первый этап — беру документацию и начинаю курить. Что там у нас? Traffic engineering?? Ок 🙁 3-4 часа на чтение и вникание (ну тут нужно отметить, что это всё-таки не первое знакомство с темой — в общих чертах я знаком со всем).
Запрос с приоритетом Minor, поэтому я могу себе позволить такое расточительство по времени.
Когда поимел представление, уже можно позвонить заказчику и осторожно разузнать детали. Звонок — второй этап.
В этот момент он начинает сыпать терминами, рассказывать про свою сеть, о которой на данном этапе я ещё имею очень смутные представления. Если я в этой теме хоть сколько-то разбираюсь, задаю вопросы, наводящие меня и инженера на правильное русло.
Нужно не бояться показаться глупым. Я боюсь, но вопрос-то решать надо).
Когда проблема прояснилась, повторяю её инженеру так, как я понял и жду подтверждения, что я прав.
Тут кроется интерсная проблема: не все готовы меня слушать или понимать:
Одни перебивают и снова рассказывают своё видение, которое в целом совпадает с моим, но хотелось бы придерживаться правила двойного рукопожатия — 1) я понял его, 2) он понял, что я правильно понял.
Другие говорят: «Да, да, всё верно» и после этого объясняют что-то явно противоречащее. После уточняющих вопросов они снова говорят «Да» и опять объясняют всё иначе.
Тут важно не поддаться слабости и добиться полного понимания с обеих сторон, иначе я буду решать другую проблему или уйду в неверное русло.
В случае моего примера была вот такая схема:
И мне важно было понять, что FRR не работает именно между указанными двумя узлами, а внутри кольца вполне себе работает. После моих вопросов инженер подтвердил это.
В конце разговора, я прошу выслать какую-нибудь информацию мне (схему сети, диагностическую информацию, логи и т.д.).
Обязательно после звонка нужно написать письмо, где повторить свои мысли и просьбы. Потому что телефоный разговор — это телефонный разговор, а почта хоть как-то протоколируется и остаётся на экране инженера.
В противном случае он вообще забудет выслать или вышлет не всё.
Кроме того, это очень важно для сохранения истории запроса. Я мог бы вести экселевский файлик со всей информацией по тикету: когда писал, кому, что ответили, когда эскалировал или замораживал. Но у меня не хватает собранности — слишком много ему надо внимания.
Зато история переписки хранится годы. И если через 9 месяцев менеджер спросит меня, почему была такая задержка при решении, я открою архив и покажу, что запросил данные я 01.01.2013 в 00:20, а инженер мне ответил только 10.01.2013.
Но и тут опять есть место фейспалму. Пишешь в письме по пунктам, например:
1) Когда возникла проблема впервые? Производились ли перед этим какие-то изменения?
2) Предоставьте схему сети с указанием IP-адресов и интерфейсов
3) Вышлите файл логов с карты памяти
4) Вышлите диагностическую информацию.
5) Есть ли возможность удалённого доступа?
Схему я описал вам по телефону: роутер-коммутатор-роутер2-коммутатор2-(STP)-клиент.
Во вложении один файл с диагностикой и всё. Что он полезного мне дал? Только понимание, что будет тяжело и надо снова ему звонить.
Слава IP, таких немного.
В примере инеженер оперативно выслал и конфигурацию, и схему, и желаемый алгоритм работы.
Итак, сейчас, у меня есть общее представление о проблеме, схеме сети и желаниях клиента.
Третий этап — более подробное вычитывание документации, примеров конфигурации. Поиск информации по теме в кейсах, которые писали другие инженеры для упрощения нашей жизни, и общая информация из гугла для общего развития и посмотреть, как это реализовано у других вендоров.
Обычно после этого возникают новые вопросы, повторяем итерацию со звонком и письмами, если нет удалёнки.
Часто на этом этапе проблема решается. Найдена ошибка в конфигурации или (надо признать, значительно реже) дыра в головном мозге инженера.
Что касается последнего пункта, яркий пример:
Я: «У вас одинаковые Router ID в OSPF»
Инженер: «Ну да, и что? Они же в разных зонах»
Я: «Router ID должны быть уникальны в пределах всего домена OSPF»
Инженер: «Да нет же. Конечно же, в разных Area могут быть одинаковые Router ID».
Я: Ссылка на документацию и википедию.
Инженер: «я проверю, но раньше я так делал — проблем не было».
Но бывают и совсем сложные проблемы — настроено всё правильно, по всем данным, логам и статистикам всё в порядке, но проблема есть.
И вот тогда начинается TShoot — четвёртый этап.
Отлично, если есть удалёнка. Но иногда заказчики отвечают: «мы вам уже не в первый раз говорим — никакой удалёнки нет. Мы вам предоставили конфигурацию и диагностику.»
Помимо копаний в чужой консоли, подключаю программный симулятор оборудования.
Смотрю, как бегут пакеты, снимаю дампы, проверяю, на каком этапе сбоит протокол.
Если проблема фиксируется только на определённом оборудовании или версии софта, обращаюсь к реальной лабе с настоящим железом.
Случается, что для воспроизведения проблемы нужно задействовать восемь устройств, обновить на них софт, залить лицензии.
В примере явная зацепка — наличие деления OSPF на зоны. При этом у заказчика FRR работает нормально внутри зоны и не работает между Area 0 и 1
Тут включаю психологию — открываю аутлук и начинаю писать заказчику письмо с подробным объяснением того, что происходит и что я обнаружил. Расписываю всё словами, с выдержками из логов, конфигурации и вайршарка.
Описывая, я упираюсь в какой-то непонятный вопрос, который я не могу объяснить заказчику. Тогда я колупаю симуляцию дальше, читаю мануалы, пока не получится разрешить трудность. Описываю её и новый цикл.
В итоге письмо я часто не отправляю, но значительно приближаюсь к корню проблемы.
Логикой я понимаю, что CSPF (Constrained Shortest Path First) опирается в своей работе на алгоритм SPF, который, как известно работает только в пределах одной зоны. Про остальные зоны он знает только суммаризированые маршруты — не топологию. Соответственно, он не может простроить кратчайший end-to-end путь.
Эту схему я собрал, проверил, что всё действительно так. Нашёл в документации упоминание об этом и выслал заказчику.
Я: «выполните следующую команду: [R1]Make me feel good»
Заказчик: 
Однако не всегда озвученный в тикете запрос — суть. Ответив «нет, так работать не будет» нужно предложить решение. И итерации по новой.
Решение по моему запросу: вместо FRR применять в рамках одного TE-туннеля два LSP — основной и резервный. Для этого строятся explicit-path в режиме loose. Это является end-to-end защитой между двумя узлами.
Вот парочка запросов, которые решались таким путём:
1) Не строятся новые LSP.
Примечение: до сегодняшнего утра всё работало и строилось. Старые LSP также функционируют и не флапают.
2) Через сеть MPLS организован L2VPN. Со стороны клиента не пропускаются пакеты размером более 1546 байтов.
3) Имеется сеть, по которой передаётся видео через мультикаст. При настройке VRRP на двух маршрутизаторах клиент, для которого они являются шлюзами, получает две копии видеотрафика (по одной с каждого маршрутизатора).
Как управлять обращениями в ИТ-отдел
По мере роста числа устройств, которыми необходимо управлять, возрастает число обращений сотрудников компании в ИТ-отдел по разным вопросам. Как централизованно управлять ими, чтобы документировать их и координировать работу сотрудников ИТ-отдела? Рассмотрим на примере облачного RMM-решения Panda Systems Management.
В предыдущих наших статьях про RMM-системы мы рассказывали о том, как такие комплексные решения позволяют автоматизировать многие ИТ-задачи и повысить эффективность обслуживания ИТ-сетей за счет удаленного и централизованного мониторинга, контроля и поддержки устройств и пользователей: мониторинг работы устройств, управление мобильными устройствами (MDM), удаленная установка ПО, инвентаризация, управление патчами и многое другое.
Но все эти задачи – это непосредственная работа с ПО и «железом», и за их использованием стоят конкретные люди, сотрудники предприятия, которые в своей массе не обладают серьезными ИТ-навыками и знаниями, а потому периодически сталкиваются с теми или иными проблемами. Как им оптимальным и формальным образом взаимодействовать с ИТ-отделом? Как ИТ-отделу принимать такие запросы, не терять их и не забывать про них? Как руководству ИТ-отдела контролировать обработку всех этих запросов?
Очевидно, что грамотная, оперативная и качественная обработка обращений сотрудников в ИТ-отдел не только повышает показатели работы самого отдела в целом и его сотрудников в частности, но в глобальном смысле непосредственно влияет на производительность работы сотрудников предприятия, эффективность и конкурентоспособность всего предприятия.
Кстати, Вы можете бесплатно зарегистрировать лицензии Panda Systems Management на сайте www.cloudav.ru/enterprise/solutions/cloud-systems-management и вместе с нами настроить управление обращениями непосредственно в Вашей сети.
Задача: системное управление обращениями в ИТ-отдел
Рост числа устройств в компании, которыми необходимо управлять, и рост числа технических специалистов, которые выделены для решения ИТ-проблем, рано или поздно потребует внедрение системы, которая позволяет ИТ-отделу системно управлять каждым инцидентом, документировать его и координировать.
Тикет-система (Ticketing system или система по обработке заявок/обращений) используется для отслеживания каждого инцидента с момента его создания и до момента его закрытия, записывая все промежуточные этапы, через которые он проходит.
Таким образом, можно назначить обращение определенному ИТ-специалисту или переназначить его другому специалисту, если предыдущий занят или он не обладает специальными знаниями и навыками для решения данной проблемы. Кроме того, у данного обращения тикет-система сохраняет всю переписку, документацию и данные по выполненным работам, а потому при переназначении технического специалиста или при возникновении похожей проблемы в будущем можно не отвлекать конечных пользователей (сотрудников предприятия) для повторного уточнения и запроса требуемой информации.
Во-вторых, принудительное документирование инцидентов позволяет повторно использовать процедуру решения проблемы для будущих аналогичных инцидентов, что также сокращает время отклика ИТ-отдела.
И наконец, тикет-система позволяет руководителю ИТ-отдела определять нагрузку на сотрудников отдела, выбирая открытые обращения в требуемый период времени, чтобы можно было выделить дополнительные ресурсы при необходимости.
Вполне логично, что такая тикет-система интегрирована в комплексное RMM-решение, где взаимосвязаны все аспекты управления, контроля и обслуживания ИТ-ресурсов предприятия.
Итак, рассмотрим тикет-систему на примере комплексного облачного RMM-решения Panda Systems Management.
Описание тикета
Каждый тикет (по сути дела – это инцидент или обращение конечного пользователя, кейс) содержит набор полей, которые его описывают:
Creator: Создатель тикета. Это может быть устройство (если тикет создан пользователем из локального Агента) или системный аккаунт (если тикет автоматически создан соответствующим монитором Panda Systems Management и назначен техническому специалисту).
Site: Группа устройств, к которым принадлежит тикет.
Date Created: Дата создания тикета.
Status: Существует четыре статуса:
• New: недавно созданный тикетс описанием проблемы и назначенным техническим специалистом. Еще никакие работы по данной проблеме выполнены не были.
• In progress: Технический специалист из ИТ-отдела, кому назначен данный тикет, управляет инцидентом.
• Waiting: Решение инцидента было приостановлено какими-то внешними причинами (недостаток информации, подтверждение изменений пользователем и пр.).
• Complete: Инцидент был решен и закрыт.
Severity: Степень важности тикета. Если тикет был сгенерирован монитором, то будет скопирована степень важности, определенная для данного монитора.
Assigned to: Технический специалист, которому был назначении данный инцидент для решения.
Summary: Сводная информация по инциденту.
Content: Описание инцидента.
Comments: В этом поле технические специалисты и конечные пользователи могут добавлять записи, которые обновляют этап инцидента или завершают его.
Техническим специалистам и конечным пользователям рекомендуется чаще использовать данное поле с комментариями, документируя изменения в инциденте и выполненные действия, проведенные проверки и другие данные, которые могут представлять интерес. Это необходимо для того, чтобы эти данные можно было использовать в будущем для повышения скорости решения аналогичных инцидентов.
Создание тикета
Тикеты создаются тремя способами:
1. Вручную конечным пользователем (сотрудником предприятия) из локального агента Panda Systems Management, установленного на его компьютере
2. Автоматически монитором Panda Systems Management, который зафиксировал условие, определенное как аномалия для устройства пользователя
3. Вручную сотрудником ИТ-отдела из консоли управления Panda Systems Management
1. Вручную конечным пользователем
Если конечный пользователь заметил, что его устройство работает некорректно, он может вручную создать тикет (обращение в ИТ-отдел), чтобы сообщить о данном инциденте и описать наблюдаемые симптомы.
Чтобы зарегистрировать тикет вручную, пользователь должен открыть установленного на его компьютере Агента, нажав правой кнопкой на его иконке, в выпадающем меню выбрать Open, затем в интерфейсе локального агента выбрать закладку Tickets и нажать кнопку New Ticket.
В открывшемся диалоговом окне необходимо указать заголовок тикета и его описание и нажать кнопку ОК.
После создания тикета конечный пользователь может добавлять в него комментарии:
Или закрывать его, если инцидент, по его мнению, решен:
2. Автоматически монитором
При настройке политики монитора в разделе Ticket Details можно настроить опции автоматического создания тикета в том случае, если монитор зафиксирует какое-то аномальное условие на устройстве конечного пользователя:
В этом случае вы можете включить опцию автоматического создания тикетов, назначить соответствующего технического специалиста и поставить приоритет у создаваемых тикетов, а также отправлять оповещение о создании тикета по электронной почте.
3. Вручную сотрудником ИТ-отдела
Как правило, это напоминания или задачи, которые добавляются в список тикетов для ИТ-отдела.
Чтобы создать тикет, необходимо на уровне аккаунта или сайта перейти на закладку Support и нажать на кнопку New Ticket для создания тикета.
Тикеты, созданные на уровне всего аккаунта, не привязываются к сайтам внутри аккаунта и не показываются на уровне какого-либо сайта.
При добавлении тикета вы можете указать его заголовок, описание, приоритет, а также назначить или переназначить технического специалиста для решения инцидента (задачи) по данному тикету:
Управление тикетами
Созданные тикеты управляются на закладке Support на уровне аккаунта, сайта или конкретного устройства. При этом необходимо учесть, что тикеты, созданные на более низких уровнях, отображаются в списке тикетов на более высоких уровнях (т.е. если создали на уровне устройства, то будет отображаться на уровне сайта или всего аккаунта), но не наоборот.
Опции управления в панели Actions позволяют вам фильтровать тикеты (показывать только открытые тикеты, мои тикеты, все тикеты) или редактировать их статус с помощью иконки с изображением карандаша. Чтобы изменить приоритет, статус или назначенного технического специалиста, необходимо нажать на номере тикета в таблице.
Заключение
Комплексное облачное RMM-решение Panda Systems Management позволяет централизованно и удаленно обслуживать корпоративную ИТ-систему, автоматизируя и решая практически весь комплекс ИТ-задач, от мониторинга и инвентаризации до удаленной установки ПО и MDM.
Среди прочих задач с помощью данного решения можно также системно управлять обращениями и инцидентами в рамках тикет-системы. Такой подход позволяет упростить и ускорить выявление и решение инцидентов для обеспечения должного уровня функционирования ИТ-системы в целом. А это напрямую влияет на рост производительности труда и конкурентоспособности предприятия.
Добивайтесь большего, делая меньше!