Главная > Путешествия и туризм > Otrs присылать все сообщения о завершении. Что же такое OTRS

Otrs присылать все сообщения о завершении. Что же такое OTRS

В статьях попробую раскрыть особенности внедрения практик ITIL, в том числе и с использованием OTRS.

Что хочет пользователь от ИТ отдела в первую очередь?

Попробую ответить, с оглядкой на ITIL, словами пользователя (это должен быть очень хороший пользователь), следующим образом: Пользователь хочет, чтобы ИТ-услуги предоставлялись в соответствии с согласованными с ИТ-отделом или внешней организации, предоставляющей услуги, ожиданиями. Если есть сбои в предоставлении услуг, то он должен знать куда обратиться и услуга должна быть восстановлена максимально быстро. Кроме этого пользователь хочет хочет получать некие ИТ-услуги, такие как установка ПО, поэтому в качестве базовых процессов, которые можно внедрять сразу, это:

Incident management (Управление инцидентами)
Request Fulfillment (Управление запросами на обслуживание)

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

Чтобы предотвратить холивар в комментариях: установка ПО может быть как изменением, так и запросом на обслуживание, а предоставление прав может регулироваться Access Management (Управление доступом). Все это зависит от задач, стоящими перед ИТ отделом и описания тех Услуг, которые отдел предоставляет.

Немного терминологии ITIL

Инцидент-незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.
Цель процесса Incident Management: скорейшее восстановление ИТ-услуги для пользователей.

Немного об OTRS

На Habr были упоминания данной системы, тем не менее немного напомню о ней:
Как говорит Wiki - это открытая система обработки заявок, хотя ее функционал выходит далеко за рамки только обработок заявок.
Скачать систему можно на официальном сайте www.otrs.com Там же можно найти руководства по установке, настройке.

Настройка OTRS

Определяем типы ticket’ов. Точнее оставляем те, которые нам необходимы для внедрения указанных выше процессов, так как система уже имеет предопределенный набор настроек.


При желании можно определить очереди, например Аппаратное обеспечение, Печать, Программное обеспечение. К каждой очереди есть возможность настроить доступ агентов. Агенты - это сотрудники, которые выполняют работу по устранению инцидентов, как правило, это сотрудники ServiceDesk.
Для очередей должны быть определены календари, т.е. время доступности агентов, отвечающих за конкретную очередь, в соответствии с их графиком работы.

Настройки календаря производятся в модуле:

Core::Time::Calendar1

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

Определяем Услуги (т.е. Каталог услуг) и соглашение об уровне услуг SLA.

Минимально достаточно одного SLA, в котором будут определены время первой реакции и время решения.

Заявки поступают через WEB-Interface, по телефону, через интерфейс агентов ИТ-отдела.
Не смотря на то, что в OTRS есть пользовательский интерфейс для работы с запросами, мы реализовали взаимодействие через внутренний сайт, который крутится на joomla, которая имеет плагин OTRS Gateway (в доме, который построил Джек). Плагин позволяет создавать заявки, и просматривать “свои”, ранее созданные запросы.


Поступившая заявка получает состояние new. В агентском интерфейсе доступно время до первой реакции и до решения.

Факт начала работы с заявкой фиксируем ответом, созданном на основании шаблона
После чего заявка блокируется и она получает состояние open. В этот же момент пользователю отправляется сообщение о том, что заявка поступила на рассмотрение. Счетчик времени до первой реакции сбрасывается.
Запрос должен быть описан, при необходимости исправлены неверно введенные пользователем данные.
После решения переводим заявку в состояние pending auto close+.
Время ожидания устанавливается параметром:

$Self->{"Ticket::Frontend::PendingDiffTime"} = "14400"

В случае если от пользователя не поступит дополнений к запросу она будет переведена в состояние closed successfull. Да, может не совсем честно, но с другой стороны не будешь просить пользователя вынуждать дополнительно заходить в WEB-Interface и писать комментарии к выполненному запросу.

$Self->{Ticket::StateAfterPending} = {
"pending auto close+" => "closed successful",
"pending auto close-" => "closed unsuccessful"

За перевод состояний отвечает Unix-планировщик cron, в котором необходимо установить частоту обновления статусов меньшее чем, указанное по-умолчанию 2 часа:

check every 120 min the pending jobs
45 */2 * * * $HOME/bin/PendingJobs.pl >> /dev/null

Меняем параметр, в нашем случае установив время, равное 5 мин. При этом помним о производительности системы.

check every 5 min the pending jobs
*/5 * * * * $HOME/bin/PendingJobs.pl >> /dev/null

Для удобного отображения запросов в агентском интерфейсе выставляем параметр:
Core::Ticket::ViewableStateType,
оставив только состояния new и open, тем самым скрыв состояния ожидания в агентском интерфейсе.

Challenges

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

Отчетность

Отчетность формруется при помощи стандартного функционала при помощи мастера создания отчетов, например такие:
Среднее время реакции по исполнителям
Среднее время реакции по услугам
Среднее время решения по исполнителям
Среднее время решения по услугам
Количество запросов за отчетный период (месяц) по исполнителям
Количество запросов за отчетный период (месяц) по услугам
Процентное соотношение выполненных в соответствии с SLA запросов к общему числу запросов.

Отчетность по исполнителям необходима для оценки(мотивации) специалистов, вовлеченных в Эксплуатацию Услуг.
Отчетность по Услугам предоставляется заинтересованным лицам.

Кроме этого используются отчеты, полученные путем SQL запросов к базе данных и именно они являются основным показателем работы ИТ-службы:
Процент выполненных запросов в соответствии с SLA. (в нашем случае это 80%, стремимся к 90%)

Совсем недавно появилась светлая мысль систематизировать роботу нашей службы HelpDesk, или как теперь называют ServiceDesk, на сколько это возможно с помощью системы автоматизированного сбора и обработки заявок (носящую одноименное название).
Итак, приступим.
1. Начнём с анализа наиболее подходящих систем для такой службы

  • Изучив таблицу сравнения ПЛАТНЫХ HelpDesk систем и БЕСПЛАТНЫХ , на первый взляд самого специализированного сайта про HelpDesk, я понял, что данные как показалось ужасно устарели и не содержат полной картины.
  • Обратившись к поиску, наткнулся на сравнение на ру-борде . Тут уже было все намного подробней и не ангажировано. Но актуальность тоже страдала, шапка обновлялась в последний раз в начале 2008 года. Еще одна попытка соорудить подобную ветку , так же умерла не дождавшись своего апогея, но успев собрать довольно много информации, хоть и без ссылок.
  • Еще один большой ресурс - http://netdocs.ru/ , но его мне полностью прошерстить не удалось.
  • Так же есть темы на форуме nowa.cc, но там как всегда всё закрыто для "проходящего мимо", да и информации не много.
  • Больше мне обнаружить ничего не удалось.
2. Вооружившись этими четырьмя сравнениями начал анализировать, какие системы подходят под мои требования наиболее. Список по убыванию важности характеристик:
  • Возможность протестировать систему до покупки
  • WEB морда заявителя
  • WEB морда специалиста
  • E-mail оповещение заявителя и специалиста
  • Возможность изменения интерфейса
  • Время запуска в тестовую эксплуатацию
  • Русификация
  • Учет материальной базы
  • Импорт пользователей из глобальных служб каталогов
  • Лицензия
3. Вооружившись десятью критериями озадачился на первом. Он оказался решающим.
Из вроде бы удовлетворяющих систем, взятых на тест:
  • (Бесплатная, лицензия GNU) - http://otrs.org
  • PerlDesk v2.25 (Платная) http://www.perldesk.com/
  • Кларис (Платная) - http://saas.claris.su/
  • Итилиум (Платная) - http://www.itilium.ru/
  • (Платная) - http://www.adventnet.com
  • HP OpenView (Платная) - ru-board
  • Kayako (Платная) - http://www.kayako.com/
  • IPI.HELPDESK (Платная) - http://ipi-helpdesk.ru/
4. Удалось установить для тестов только половину:
  • OTRS - Open Ticket Request System (Бесплатная, лицензия GNU) - http://otrs.org
  • Итилиум (Платная) - http://www.itilium.ru/
  • ManageEngine ServiceDesk Plus (Платная) - http://www.adventnet.com
  • HP OpenView (Платная) - ru-board
Из-за отсутвия триала или таблеток...
  • HP OpenView (Windows), которую мне удалось найти, версии 4.5 оказалась очень устаревшей и не поддерживаемой. HP оттолкнулась от версии 5.1 и создала очередного гиганта версии 7.5, установив который я понял, что это по большей степени система мониторинга серверов и для организации моей службы HelpDesk она совершенно не подходит.
  • Итилиум (Windows), основанной на платформе 1С, удалось найти, установить, промучившись несколько дней с поиском нужной версии, подходящей к версии уставленной платформы 1С. В конце концов у меня было установлена С-ка 8.0, 8.1, 8.2 и Итилиум версии 8.3.1 установился на 1С 8.2, прикрутив к 1С специальное WEB расширение, версии 8.0.11.1. Кстати следующая версия Итилиума уже становится неизвестно как, потому что WEB расширение в 1С 8.3 будет переработано и интегрировано внутрь 1С.
  • OTRS (Windows, Linux), как ни странно, оказалось непроста в установке. Т.к. я устанавливал её третьей, то порты, по которым обычно ходит WEB уже были заняты и установка из инсталяционного пакета не удалась. Странно, но в инсталяционном конфигураторе такой серьёзной системы не придусмотрено варианта установки "Advanced". Инсталится по умолчанию и вылетает с ошибкой. Но есть вариант установки отдельными пакетами. Меня это устроило, но вот найти эти пакеты оказалось не так просто! Т.к. версия 2.4.7 уже практически не пооддерживается в следствии ожидания в средине августа 2010 года новой версии 3.0. То и эти пакеты почему-то поисчезали с официального сайта (видать решили сэкономить 50 мегабайт на хостинге). Мне с трудом удалось раздобыть необходимые версии: 1. дистрибутив необходимой версии Perl 5.6.1.633 , с трудом но нашел - http://crymchaks.at.ua/files/ActivePerl-5.6.1.633-MSWin32-x86.msi.7z . 2. Ссылка на Apache 1.3.27 - http://www.filewatcher.com/m/apache_1.3.27-win32-x86-no_src.msi.2192896.0.0.html . 3. А вот пакет OTRS-Win32-Perl-Packages найти так и не удалось. (Нерабочая ссылка - ftp://ftp.otrs.org/pub/otrs/misc/win32/OTRS-Win32-Perl-Packages.zip , если кто найдёт - поделитесь пожалуйста, тут уже очередь!) Пришлось устанавливать на другой сервер из инсталяционного пакета. Без проблем.
  • ManageEngine ServiceDesk Plus (Windows)- Версию 7.6.0 устанавливал в последнюю очередь. И слава Богу, поставилась с первого раза без всяких бубнов, правда обратившись за таблеткой на ру-борд.
5. Две недели у меня ушло на тестирование этих систем. Не буду строить графиков и таблиц с балами. Скажу вкратце:
  • Итилиум - мне так и не удалось получить ни одного уведомления на почту о создании или обновлении тикета (ticket заявка). В 1С они сформировали настолько длинные ветки справочников и столько обязательных полей к заполнению, что для того чтобы создать первую заявку мне пришлось несколько дней заполнять самый минимум. А заполнить всё и разобраться со всеми возможностями просто не хватило времени, тем более читать 2 мануала по установке и пользованию системой в размере 250 и 90 страниц... Сделал вывод, что для внедрения этой системы нужно не только ЗАПЛАТИТЬ ЗА МАНУАЛЫ, но и за внедрение ихними специалистами, не говоря уже про то что за саму систему тоже заплатить придется.
  • OTRS - Первую заявку удалось сформировать на 10-й минуте работы в системе, а вот получить почтовое уведомление до сих пор никак. :(В общем это самая быстрая из протестированных систем. Правда пришлось долго переводить все, все, все правила, названия инцидентов, потому что кроме меню и админского интерфейса. Очень мало описаний меню в администрировании, пришлось долго ломать голову чтобы понять для чего какие группы служат и что с чем связано, хотя хватило бы буквально пары фраз. Если не считать что у меня не вышло с почтой, то Open Ticket Request System довольно хорошая, не сложная система, подходящая многим. Но вот чтобы её расширить нужно копаться не только в PHP, но и в бизнес правилах, организующих работу этой системы, да и любой похожей.
  • ManageEngine ServiceDesk Plus - На запуск первой заявки пришлось уделить где-то день, но потом пошло как по маслу. Почти всё хорошо описано, да и работает при минимальном заполнении справочников. В шаблонах можно менять не только текст, но и расположение окон, да и вообще их наличие, буквально одним кликом мыши, как говориться Drag&Drop. Остановился я на этой системе, так как уведомления о тикетах быстро настроил на почту, а может еще и на смс. Замечательная работа с материальной базой (инвентаризация техники IT системы), с привязкой к пользователю, которые в свою очередь импортируются из Active Directory или LDAP. Так же стандартную авторизацию можно дополнить без особого труда доменной и оставить возможность выбора метода логина пользователю.
В общем одни положительные эмоции от работы с ManageEngine ServiceDesk Plus 7.0 , чего и вам желаю.
Единственное, что не по одной системе нет хорошего неофициального сайта:(
Если что, пишите в тему на ru-board , будем делиться опытом использования.
Надеюсь эта статья поможет вам сохранить немного такого драгоценного времени, которое лучше потратить на изучение истории вымирающего крымского народа этнической группы крымчаков .
Всем удачи!

PS (спустя 2 года): На данный момент использую OTRS 3.1.3 для приема, обработки заявок (ticket) и доволен своим выбором.

Плюсы:

  1. работает быстро (Linux)
  2. гибко-настраиваемые отчеты
  3. около 1300 продвинутых разделов настройки системы с полнотекстовым поиском по ним
  4. нет проблем с обновлением работающей системы
  5. горячие кнопки
Минусы:
  1. из-за такого обилия продвинутых разделов настройки иногда очень сложно найти нужную
  2. так и не смог настроить, что бы при ответе на заявку статус по умолчанию был "закрыт успешно"
  3. не смог уменьшить размер текстового поля для ввода содержимого заявки при ответе на заявку (во вновь открывшемся окне не помещается кнопка "Ответить").
Добавлю так же недавно появившийся обзор платных и бесплатных систем отслеживания ошибок большинство из которых представляют собой HelpDesk или ServiceDesk системы.

Так что же представляет из себя OTRS ?

Как следует из названия "Open source Ticket Request System", OTRS является системой по учету (приему и обработке) заявок (тикетов). Под заявкой (тикетом) я понимаю обращение кого-либо к кому-либо. Таким образом, возможности использования OTRS гораздо шире, нежели Helpdesk в отделе ИТ. Например, в идеологию системы отлично ложится работа отдела поддержки чего угодно, работа отдела продаж по получению запросов на выставление коммерческого предложения или счета, работа службы контроля качества и т.д. Но пока я бы хотел ограничиться отделом ИТ, службу Helpdesk которого и хотелось бы автоматизировать, поэтому дальнейшее описание будет описывать решения именно для Helpdesk.

Какие задачи призвана решить OTRS для Helpdesk:

  • Регистрацию обращений. Сотрудникам ИТ необходимо знать, что обращение было; пользователям необходимо понимать, что обращение дошло по адресу и не потеряно. Кроме того, для пользователя удобно, чтобы любые обращения можно было оформить одним и тем же унифицированным способом.
  • Учет и обработку обращений. Сотрудники ИТ должны знать, какие обращения имеются в каждый момент и предпринимать действия для их выполнения; пользователи должны понимать, что происходит с их обращением.
  • Автоматизацию выполнения заявок. Существует тезис о том, что любая проблема может быть решена компетентным специалистом в течение 1 часа. Нужно только, чтобы проблема сразу попала в руки такого специалиста. Поэтому если автоматизировать обработку поступающих обращений, можно резко сократить путь обращения к соответствующему специалисту.
  • Борьба с "Тайным Знанием". Информация заявках и действиях по заявкам должна фиксироваться, для того, чтобы она была известна НЕ только тому сотруднику, который взялся за ее выполнение. В противном случае выполнение заявок может споткнуться о человеческий фактор, и заявка не будет выполнена потому, что о ней банально не знают, хотя людей, которые могли бы ее выполнить, более чем достаточно.

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

  • Клиент — тот, кто формирует заявку. Это внешний пользователь системы.
  • Агент — тот, кто обрабатывает заявку. Это внутренний пользователь системы.

Фиксирование обращения представляет собой идентификацию Клиента, присвоение заявке уникального номера и предварительную обработку с целью категоризации обращения и уведомления Агента(ов) о новой заявке.

Заявки располагаются в очередях.

  • Очередь — место расположения заявки.

Очереди позволяют:

  • Разделить общий массив заявок.
  • Предоставить различный доступ Агентов к заявкам.
  • Извещать о событиях с заявкой определенный Агентов.
  • Настраивать различные автоматические ответы Клиентам в зависимости от параметров заявки

Каким же образом заявки появляются в системе? Предлагается 3 способа:

  1. Сообщение по электронной почте. OTRS проверяет почтовый ящик(и) и превращает каждое сообщение в заявку
  2. Заполнение формы Клиентом через web-интерфейс
  3. Создание заявки Агентом на основании личного обращения, например, по телефону или на словах в курилке.

На этом пока прервемся. Следующая статья будет посвящена краткому описанию опыта установки и более подробного описания первоначальной настройки системы.

Видимо, ошибка в файле локализации. Находим файл c:\otrs\Kernel\Language\ru.pm, в нем ищем текст «Выход из системы» и меняем %c %c на %s %s.

Перезапускаем службу Apache — поправилось.

Настройка очередей.

В Управлении очередями выбираем Postmaster. Меняем имя очереди на Системная поддержка, нажимаем Отправить.

Настройка почты.

Настроим возможность принимать заявки по электронной почте.

Для возможности регистрации заявок по электронной почте, необходимо знать логин и пароль от учетной записи, на почтовый ящик которой будут приходить эти заявки. В настройках этого ящика нужно указать «Удалять письма с сервера, когда письма загружаются с помощью IMAP (POP)».

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

Переходим в Администрирование – Настройка почты – Учетные записи почты для PostMaster. Служба IMAP должна быть запущена.

Указываем тип, сервер почты. Выбираем Перенаправление по выбранной очереди, где очередь – Системная поддержка. Нажимаем Отправить.

Идем в Администрирование – Настройка почты – Адреса email.

В разделе Управление системными адресами электронной почты выбираем адрес [email protected] Меняем его на тот адрес, на который будут приходить новые заявки. Меняем отображаемое имя на «Службы системной поддержки», указываем нужную очередь. Нажимаем Отправить.

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

В данном руководстве в качестве почтового сервера используется MS Exchange 2008. Переходим в Администрирование – Администрирование системы – Конфигурация системы. Выбираем Framework, затем Core::Sendmail. Настраиваем:

SendmailModule — выбираем SMTPTLS;

SendmailModule::Host – указываем сервер исходящей почты;

SendmailModule::Port – указываем порт;

SendmailModule:AuthUser – указываем логин учетной записи;

SendmailModule::AuthPassword – указываем пароль учетной записи;

SendmailNotificationEnvelopeFrom – указываем системный адрес электронной почты.


Настройка рабочего календаря службы поддержки пользователей.

Переходим в Администрирование – Администрирование системы – Конфигурация системы – Framework – Core::Time.

Выбираем общие рабочие часы. В данном примере поддержка осуществляется с 8.00 до 17.00.

Нажимаем кнопку Обновить.

Возвращаемся в конфигурацию системы – Framework- Core::Time::Calendar1.

Можем изменить имя календаря.

Настраиваем рабочие часы, праздники.

Добавим группы для разграничения прав доступа.

Администрирование – Управление агентами – Группы.

В разделе Управление группами выбираем Добавить группу. Указываем имя группы – Системная поддержка. Нажимаем кнопку Отправить.

Далее связываем эту группу с агентами службы поддержки, устанавливая нужные галочки.

Добавляем еще одну группу для обычных агентов поддержки, которые будут иметь ограниченные права в OTRS.

Устанавливаем необходимые галочки. Жмем Отправить.

По аналогии создаем другие группы, которые нам необходимы.

Здесь же добавим агентов, которые будут иметь права для администрирования OTRS в группу admin.

Настройка очередей

Настроим ответы, при помощи которых специалисты смогут отвечать на заявки пользователей в системе.

Администрирование – Настройка очередей – Шаблоны.

В разделе Управление шаблонами удаляем ответ test answer.

Теперь выбираем шаблон empty answer и редактируем его. Меняем имя ответа на Новый ответ. Тело письма оставляем пустым. Нажимаем Отправить.

Настроим приветствие, которое будет отображаться в теле письма при ответе специалиста.

Переходим в Администрирование – Настройка очередей – Приветствия. Выбираем system standard salutation (en) и изменяем его. Нажимаем Отправить.

Настроим подпись, которая будет отображаться в конце письма при ответе специалиста.

Администрирование – Настройка очередей – Подписи. Выбираем system standard signature (en) и меняем его.

Теперь настроим собственно сами очереди.

Администрирование – Настройка очередей – Очереди.

Выбираем очередь Системная поддержка. Указываем имя, группу, адрес системы, Параметры повторных ответов – возможно, указываем наш календарь.


По аналогии настраиваем остальные очереди.

Настройка автоответа, который будет приходить пользователю при регистрации новой заявки.

Администрирование – Настройка очередей – Автоответы.

В разделе Управление автоответами выбираем default reply (after new ticket has been created) и изменяем его. Нажимаем Отправить.

Имя: Создание новой заявки

Тема: RE:

Тело письма:

Здравствуйте, !

Ваша заявка зарегистрирована.
Текст заявки :

———————————————

Привяжем автоответы к очередям.

Администрирование – Настройка очередей – Автоответы-Очередь.

В разделе Связь Очереди с Автоответами выбираем очередь Системная поддержка, в пункте авто-ответ выбираем Создание новой заявки. Нажимаем Отправить.

По аналогии добавляем авто-ответы для всех очередей.

Настроим учетную запись агента

Администрирование – Агенты – Управление агентами.

Выбираем агента. Убедитесь, что заполнено поле email.

Включаем все уведомления, чтобы специалист мог оперативно реагировать на новые события.

В пункте Время обновления обзора выбираем 2 минуты. В поле комментарий можно указать номер телефона специалиста службы поддержки.

В поле Мои очереди выбираем (выделяем) нужную очередь (или несколько).

Нажимаем Отправить.

Настроим уведомления для специалистов

Администрирование – Настройка заявок – Уведомление агентов.

В разделе Управление уведомлениями меняем дефолтный текст на свой для каждого уведомления.

ru::Agent::AddNote – данное уведомление будет приходить в случае добавления новой заметки к заявке.

Тема: Новая заметка! ()

Тело письма:

Здравствуйте, ,

добавил новую заметку к заявке номер .

Заметка:

:///

—————————————
Служба уведомлений Helpdesk

ru::Agent::Escalation – уведомление об эскалации заявки (закончилось время, отведенное на решение заявки)

Тема: Заявка эскалирована! ()

Тело письма:

———————————————————————————————-

Здравствуйте, ,

Заявка номер [] эскалирована!

Эскалирована в :
Эскалирована с :

Написал (а ):


Обратите внимание :

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::EscalationNotifyBefore – уведомление о скорой эскалации заявки (заканчивается отведенное время на выполнение заявки)

Тема: Уведомление о скорой эскалации заявки! ()

Тело письма:

———————————————————————————————-

Здравствуйте, ,

Заяка номер [] скоро будет эскалирована!

Эскалирована в :
Эскалирована с :

Написал (а ):


Обратите внимание :

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————-
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::FollowUp – уведомление о том, что пользователь не согласен с решением по заявке и вернул ее в работу

Тема: Закрытие заявки отклонено! Заявка возвращена в работу! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

Закрытие заявки номер отклонено!

написал(а):



:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::LockTimeout – уведомление о том, что срок блокировки заявки окончен

Тема: Период блокировка заявки истек! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

Период блокировки заявки номер [] окончен.
Заявка разблокирована.

написал(а):



:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::Move – уведомление о том, что специалист направил заявку в другую очередь

Тема: Заявка направлена в очередь ! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

направил заявку номер [] в очередь .



:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::NewTicket – уведомление о том, что в очереди появилась новая заявка

Тема: Новая заявка в очереди! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

Новая заявка в очереди !

написал(а):



:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::OwnerUpdate – уведомление о том, что специалист назначен владельцем заявки

Тема: Вы назначены владельцем заявки! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

Заявка номер [] передана Вам.

Комментарий:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::PendingReminder – уведомление о том, что настроено напоминание о заявке

Тема: Напоминание о заявке! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

Заявка [] напоминает о себе!

Написал(а):


Обратите внимание:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::ResponsibleUpdate – уведомление о том, что специалист назначен ответственным по заявке

Тема: Вы назначены ответственным по заявке! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

Вы назначены ответственным по заявке номер [].

Комментарий :

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————-
Служба уведомлений Helpdesk

———————————————————————————————-

ru::Agent::ServiceUpdate – уведомление о том, что служба обновлена

Тема: Сервис изменен на ! ()

Тело письма:

———————————————————————————————-

Здравствуйте, !

обновил заявку номер [] и изменил сервис на



:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————-
Служба уведомлений Helpdesk

———————————————————————————————-

Настроим уведомления для пользователей

Администрирование – Настройка заявок – Уведомление о событии.

Нажимаем кнопку Добавить уведомление.

Указываем имя события.

Указываем событие, при выполнении которого пользователю придет уведомление.

Указываем, кто получит уведомление о событии.

Примерный текст сообщения:

——————————————————————————————

Здравствуйте, !

Ответственным по Вашей заявке номер назначен .
Телефон:

Сервис:
Услуга:
Крайний срок решения:

———————————————
Служба поддержки пользователей
—————————————————————————————-

Аналогично создаем уведомление для закрытия заявки.

Нажимаем кнопку Добавить уведомление, указываем имя – Заявка закрыта.


Примерный текст сообщения:

——————————————————————————————

Заявка номер переведена в статус «Закрыта успешно «!

Решение :

Тема заявки:

Ответственный :
Телефон:

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

Если Вы согласны с решением, пожалуйста, не отвечайте на это письмо!

———————————————
Служба поддержки пользователей
——————————————————————————————

Переходим в раздел Администрирование – Администрирование системы – Конфигурация системы – Tickey – Core::Ticket.

В параметре Ticket::Hook меняем значение на Заявка №.

Значение параметров Ticket::Service (для поддержки SLA) и Ticket::Service::Default::UnknownCustomer выбираем Да.

Параметру Ticket::NumberGenerator устанавливаем значение Автоинкримент – чтобы знать, сколько заявок прошло через систему.

Нажимаем Обновить.

Настроем сервисы.

К этому сервису нужно добавить SLA.

Переходим Администрирование – Настройки заявок – Соглашение об Уровне Сервиса – Добавить SLA.

Добавим SLA для установки нового программного обеспечения. Задаем имя для SLA, выделяем сервис, к которому относится SLA, выбираем наш календарь, устанавливаем 7200 минут на выполнение запроса; эскалация будет происходить по истечении 60% отведенного времени. Нажимаем Отправить.


Настройка заданий.

Переходим Администрирование – Администрирование системы – Планировщик задач – Добавить задание.

Добавим задание, которое будет автоматически блокировать разблокированные заявки. Заявки будет назначена на специалиста в случае, если пользователь вернул заявку в работу.

Имя задания — Блокировка открытых заявок

Автоматическое выполнение – в столбце Запускать в минуты выбираем каждые 10 минут, в столбцах Запускать в часы и Запускать в дни выбираем все значения.

Выбрать заявки –Состояние – Открытый. Блокировка заявки –Разблокирован.

Обновить/добавить атрибуты заявки – Установить новое состояние блокировки – Блокировать.

Нажимаем Отправить.

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

Автоматическое выполнение – в столбце Запускать в минуты выбираем каждые 20 минут, в столбцах Запускать в часы и Запускать в дни выбираем все значения.

Выбрать заявки – Агент/Владелец – выбираем специалистов по технической поддержке.

Обновить/добавить атрибуты заявки – Установить новую очередь – Системная поддержка.

Нажимаем Отправить.

Продолжим настраивать систему.

Администрирование – Администрирование системы – Конфигурация системы – Framework – Core.

SecureMode устанавливаем в значение Да.

Нажимаем Обновить.

Проверяем значения параметров FQDN, AdminEmail, Organization, NotificationSenderEmail, NotificationSenderName.

Переходим в Framework – Frontend::Customer

CustomerHeadline – указываем название службы поддержки

CustomerPanelLostPassword – Нет (отключим функцию восстановления пароля, так как у нас сквозная авторизация)

CustomerPanelCreateAccount – Нет (данные у нас берутся из активного дерева)

Нажимаем Отправить.

Настроим возможность специалистам наблюдать за заявками.

Специалисты смогут получать уведомления об изменениях в заявках коллег.

Конфигурация системы — Ticket – Core::TicketWatcher

Ticket::Watcher – Да

Настроим единицу измерения рабочего времени.

Конфигурация системы – Ticket – Frontend::Agent

Ticket::Frontend::TimeUnits – (минуты)

Нажимаем Обновить.

Настроим показ уведомлений

Конфигурация системы – Ticket – Frontend::Agent::ModuleNotify

Включаем галочку напротив Frontend::NotifyModule###5-Ticket::TicketEscalation.

Настройка интерфейса для комфортной работы с заявками

Администрирование – Администрирование системы – Конфигурация системы – Ticket – Frontend::Agent::ModuleRegistration

Администрирование – Администрирование системы – Конфигурация системы – Ticket – Frontend::Agent::Ticket::ViewClose

Ticket::Frontend::AgentTicketClose###Service – Да

Администрирование – Администрирование системы – Конфигурация системы – Ticket -Frontend::Agent::Ticket::ViewForward

Ticket::Frontend::AgentTicketForward###RequiredLock – Нет

Ticket::Frontend::AgentTicketForward###StateDefault — open

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Agent::Ticket::ViewMerge

Ticket::Frontend::AgentTicketMerge###RequiredLock – Нет

Ticket::Frontend::MergeText – «Заявка «» объединена с заявкой «

Ticket::Frontend::AutomaticMergeSubject – «Заявки объединены»

Ticket::Frontend::AutomaticMergeText – «Заявка «» объединена с заявкой «».»

Нажимаем Обновить.

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Agent::Ticket::ViewOwner

Ticket::Frontend::AgentTicketOwner###Service – Да

Ticket::Frontend::AgentTicketOwner###Queue – Да

Ticket::Frontend::AgentTicketOwner###Note — Нет

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Agent::Ticket:: ViewPending

Ticket::Frontend::AgentTicketPending###RequiredLock – Нет

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Agent::Ticket:: ViewPriority

Ticket::Frontend::AgentTicketPriority###RequiredLock – Нет

Ticket::Frontend::AgentTicketPriority###Note — Нет

Добавим дополнительные кнопки в интерфейсе агента в левый верхний угол

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Agent::ToolBarModule

Устанавливаем галочки напротив:

Frontend::ToolBarModule###1-Ticket::AgentTicketQueue

Frontend::ToolBarModule###2-Ticket::AgentTicketStatus

Frontend::ToolBarModule###3-Ticket::AgentTicketEscalation

Frontend::ToolBarModule###4-Ticket::AgentTicketPhone

Уберем лишние пункты из личного кабинета пользователя

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Customer::TicketViewNew

Ticket::Frontend::CustomerTicketMessage###QueueDefault – Системная поддержка

Ticket::Frontend::CustomerTicketMessage###Service – Нет

Ticket::Frontend::CustomerTicketMessage###SLA – Нет (этот пункт станет доступным, когда наберется достаточная база данных заявок для составления SLA)

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

Администрирование – Администрирование системы – Конфигурация системы – Ticket — Frontend::Customer::TicketOverView

Ticket::Frontend::CustomerTicketOverview###Owner – Да

На этом базовая настройка OTRS закончена.

(O pen source T icket R equest S ystem) – это открытая система обработки заявок, которая предоставляет единую точку контакта для пользователей, IT-персонала, IT-услуг, а также любых внешних организаций. Программа написана на Perl. OTRS поддерживает множество баз данных (MySQL, PostgreSQL и т.д.) и интегрирование с каталогами LDAP.

Данное руководство поможет установить и настроить OTRS на сервере CentOS 7.

Требования

  • Сервер CentOS 7;
  • Не-root пользователь с доступом к sudo (о привилегиях пользователей можно прочитать здесь);
  • 4 GB своп-пространства (о настройке swap – в этом руководстве).

1: Установка MariaDB

Сначала нужно установить все зависимости OTRS.

Для этого понадобится репозиторий EPEL (Extra Packages for Enterprise Linux). Добавьте его:

sudo yum install epel-release

Обновите систему:

Установите MariaDB (ответвление MySQL):

sudo yum install mariadb-server mariadb

Для корректной работы OTRS нужно изменить стандартные параметры MySQL. Откройте конфигурационный файл в редакторе vi:

sudo vi /etc/my.cnf

Добавьте в раздел следующие строки, которые определяют размеры некоторых файлов:


max_allowed_packet = 20M
query_cache_size = 32M
innodb_log_file_size = 256M
datadir=/var/lib/mysql
. . .

Сохраните и закройте файл.

Примечание : Внести эти изменения нужно до запуска MySQL.

Запустите MariaDB:

sudo systemctl start mariadb.service

Запустите скрипт MySQL, который устранит все небезопасные параметры.

sudo mysql_secure_installation

Скрипт задаст несколько вопросов. Чтобы принять стандартные значения, просто нажмите Enter. Обязательно нужно изменить только стандартный root-пароль. Выберите надёжный пароль.

2: Установка OTRS

Установить OTRS можно при помощи предварительно скомпилированного RPM-пакета. Загрузите этот пакет из официального репозитория программы.

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

wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/7/otrs-5.0.7-01.noarch.rpm

Установите OTRS:

sudo yum install otrs-5.0.7-01.noarch.rpm

Программа OTRS написана на Perl, потому для её работы необходимы некоторые модули Perl. Чтобы определить недостающие модули, используйте скрипт CheckModules.pl (он поставляется в пакете OTRS):

sudo /opt/otrs/bin/otrs.CheckModules.pl

Вывод выглядит примерно так:

o Apache::DBI......................ok (v1.12)
o Apache2::Reload..................FAILED! Not all prerequisites for this module correctly installed.
. . .
o XML::LibXSLT.....................ok (v1.80)
o XML::Parser......................ok (v2.41)
o YAML::XS.........................Not installed! Use: "yum install "perl(YAML::XS)"" (required - Very important)

Некоторые модули нужны только для дополнительных функций (например, для связи с другими базами данных или обработки почты с китайскими символами). Чтобы установить недостающие модули, используйте команды yum, предложенные в выводе.

sudo yum install "perl(Apache2::Reload)" "perl(Crypt::Eksblowfish::Bcrypt)" "perl(Encode::HanExtra)" "perl(JSON::XS)" "perl(Mail::IMAPClient)" "perl(ModPerl::Util)" "perl(Text::CSV_XS)" "perl(YAML::XS)"

Установив все необходимые модули, запустите скрипт повторно, чтобы убедиться, что все требования соблюдены.

3: Настройка OTRS

Теперь нужно настроить БД и почту OTRS. Сначала перезапустите Apache, чтобы обновить настройки с учётом настроек OTRS.

sudo systemctl restart httpd.service

Теперь откройте веб-страницу инсталлятора:

http://your_server_ip/otrs/installer.pl

На экране появится приветственная страница. Нажмите Next. После этого нужно принять лицензию; прочтите её и нажмите Accept license and continue.

На следующей странице нужно выбрать БД. Выберите MySQL в выпадающем меню и нажмите Create a new database for OTRS (как правило, БД MySQL выбрана по умолчанию). Нажмите Next.

После этого нужно указать созданные ранее учётные данные БД MySQL. Чтобы убедиться, что данные указаны верно, нажмите Check database settings.

Инсталлятор сгенерирует учетные данные для новой базы данных. Запоминать этот сгенерированный пароль не нужно, поскольку в дальнейшем он не понадобится, поэтому просто нажмите Next, чтобы продолжить. После этого инсталлятор создаст новую БД. Нажмите Next.

После этого нужно указать параметры системы:

  • FQDN: доменное имя или IP-адрес сервера.
  • Admin Email: электронный адрес системного администратора. Сюда программа будет отправлять извещения об ошибках.
  • Organization: название организации.

Остальные параметры по умолчанию можно оставить без изменений.

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

Найдите раздел Configure Inbound Mail и укажите необходимые учётные данные. К примеру, если вы используете почтовый провайдер Google, вы можете создать пароль для приложения и ввести следующие данные:

  • Inbound mail type: IMAPS
  • Inbound mail host: imap.gmail.com
  • Inbound mail user: your_email_address
  • Inbound mail password: your_app_password

Чтобы проверить конфигурацию, нажмите соответствующую кнопку. В течение нескольких секунд появится сообщение:

Mail check successful

Чтобы перейти к последнему экрану, нажмите OK.

Установки и настройка OTRS завершена!.на экране появится ссылка для доступа к панели инструментов администратора и учётные данные суперпользователя.

Важно! Не забудьте записать сгенерированный пароль для пользователя [email protected] и URL-адрес стартовой страницы.

Теперь осталось только запустить демон OTRS и включить его cronjob:

sudo su - otrs -c "/opt/otrs/bin/otrs.Daemon.pl start"
sudo su - otrs -c "/opt/otrs/bin/Cron.sh start"

4: Защита OTRS

На данный момент у вас есть полностью функциональное приложение. Однако использовать учетную запись суперпользователя с OTRS небезопасно. Потому необходимо создать нового агента.

В OTRS агентами называются пользователи, у которых есть доступ к функциям системы. В данном примере мы создадим одного агента, у которого будет доступ ко всем функциям OTRS.

Чтобы создать нового агента, войдите как пользователь [email protected] Откройте ссылку, полученную в конце установки, и введите имя пользователя [email protected] и пароль (см. конец раздела 3).

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

Сначала нужно создать нового агента. В верхней части панели управления будет предупреждение, выделенное красным:

Don’t use the Superuser account to work with OTRS! Create new Agents and work with these accounts instead. →

Чтобы создать нового агента, нажмите на это сообщение, а затем кликните Add agent. На экране появится множество полей. К счастью, заполнять все эти поля необязательно – большинство опций по умолчанию подходит для работы. Заполнить нужно только поля First Name, Last Name, Username, Password и Email.

После этого нужно изменить групповые отношения нового агента. Новый агент также будет администратором, потому ему необходимы права на чтение и запись во всех группах. Для этого установите флажок рядом с RW в настройках Change Group Relations for Agent.

Нажмите Submit. Теперь вы можете выйти из учётной записи суперпользователя и использовать для работы нового агента. Нажав на значок шестеренки в верхнем левом углу экрана, вы можете изменять параметры агента (изменить пароль, выбрать язык интерфейса, настроить уведомления, очереди, тему интерфейса и многое другое).

5: Управление билетами

Теперь рассмотрим управление билетами. Клиенты могут отправлять билеты на OTRS двумя способами: с помощью интерфейса или по электронной почте.

http://your_server_ip/otrs/customer.pl

Здесь можно создать пользовательский аккаунт и отправить билет.

Можно также создать новый билет, отправив письмо по электронному адресу, указанному во время установки. По умолчанию все билеты, полученные по почте, хранятся в одной очереди и имеют обычный приоритет. Все билеты клиентов можно просматривать в веб-интерфейсе клиента независимо от того, как они были отправлены.

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

На приборной панели агента можно найти информацию о всех текущих билетах: их статус (новый, открытый, эскалация и т.д.), их «возраст» (время, прошедшее с момента получения билета) и тему.

Чтобы просмотреть подробности билета, можно кликнуть на его номер в столбце Ticket #. В этом окне агент также может взаимодействовать с билетом (изменить его приоритет или состояние, переместить его в другую очередь, закрыть его и так далее).

Примечание : Узнать больше о программе OTRS можно в официальном руководстве.

Tags: ,

Рекомендуем также