Pet-проект для обучения или как я в одиночку писал Helpdesk

Доброго дня! Меня зовут Антон, я работаю инженером, в отделе технического обслуживания и администрирования. Языки программирования начал изучать совсем недавно, хотя всегда очень хотелось.

С чего всё началось.

История началась примерно полтора года назад. Блуждая по просторам сети, наткнулся на какой-то курс по программированию (на самом деле достаточно известный), подумал, что давно хотел мигрировать из поддержки в разработчики и записался на пробную часть. Курс был по программированию на Python. Достаточно быстро прошёл вводную часть, научился некоторым азам и понял, что это интересно. Дальше решил уже самостоятельно, с помощью материалов из сети, совершенствовать свои навыки.

Первое что пришло в голову, написать десктопную программу для мониторинга IP-видеокамер. Логика была следующая, если ping до камеры есть, то всё хорошо, если иначе – что-то пошло не так и нужно оповестить об этом специально обученного человека (для оперативности, желательно в Telegram). Задача простая, но полезная для обучающегося программиста. В основу лёг фреймворк PyQt5. Пришлось конечно немного помучатся с мультипроцессингом и зависанием приложения, но итоге приложение было написано и передано в пользование специалисту по видеонаблюдению. Он был рад и пользуется приложением до сих пор. Проект закончен, но хочется дальше развиваться и чем-то помочь коллегам. Вот тут-то и пришла в голову мысль, написать свой Helpdesk.

Проблема и идея

В нашем управлении ИТ работает всего 10 человек – это отел технического обслуживания, отдел разработки и участок связи. Все, в какой-то степени, занимаются технической поддержкой пользователей. На тот момент все заявки приходили, либо по электронной почте, либо по телефону. Мне показалось что это жутко не удобно и плохо контролируемо:

• не было чёткого представления о текущих задачах

• о многих заявках можно было попросту забыть

• для пользователей не очень понятно в каком состоянии их заявка сейчас

• нет никакой очерёдности выполнения, всё по принципу, «кто успел, того и тапки»

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

Ранее, у меня уже был опыт использования Helpdesk систем, на базе:

1. Microsoft SharePoint 2007

2. OTRS

Первый проработал не долго, в связи с неудобством и отсутствием человека, который бы занимался его поддержкой. Второй, был поднят и настроен мной, но руководство по каким-то причинам, так его и не внедрили. Попытка номер 3, подумал я, и преступил к проектированию, своего helpdesk’a.

Проектирование Helpdesk

Итак, исходные данные:

1. В организации примерно 500 пользователей, в планах, что все они будут пользоваться helpdesk’ом

2. 10 сотрудников, в 3 отделах, которые также будут использовать helpdesk в работе

3. Все пользователи делятся на группы, по компаниям и входят в один домен (Active Directory)

4. Для пользователей системы нужны уведомления по email (для сотрудников ещё в Telegram)

5. Система будет использоваться только внутри предприятия

Начал с базовой схемы:

То есть сервис, как минимум, должен иметь:

• сквозную авторизацию через контроллер домена, форму заявки,

• интерфейс пользователя,

• интерфейс сотрудника,

• уметь уведомлять о новых заявках и о результате их выполнения,

• формировать отчёты по заявкам, за определённый период времени, с группировкой по компаниям, отделам, работникам и т.д. И выгружать это, например, в Excel.

Так как я начал изучать Python, было решено делать это всё на Django. Первым делом начал искать и изучать подобные системы, и что они в себя включают. Получилась примерно такая структура:

Вперёд к знаниям

Согласно схеме БД:

• Пользователь имеет основной профиль и дополнительный

• Каждая заявка привязана к пользователю

• К заявке можно оставлять комментарии

• К заявке можно прикрепить файл

• Каждый пользователь имеет доступ к уведомлениям о своих заявках

На основе этого, были созданы соответствующие модели и проведены миграции.

Авторизация

Так как все пользователи на предприятии работают на компьютерах, находящихся в домене и авторизуются на компьютерах с помощью Active Directory, то и на helpdesk’e авторизация должна быть через Active Directory. Причём это должно происходить без участия пользователя. То есть, если пользователь вошёл на компьютер под своей учётной записью, то при открытии helpdesk’a он автоматически авторизуется.

Начитавший информации в интернете приступил за дело. Для такого функционала мне понадобился:

• Nginx, собранный с модулем SPNEGO

• дополнительные библиотеки для Django – django-auth-ldap и django-remote-auth-ldap

Ещё хотелось, чтобы информация о пользователях хранящаяся в Active Directory (компания, подразделение, телефон и т.д.) автоматически подтягивалась в профиль пользователя. К счастью это, достаточно просто получилось реализовать с помощью тех же средств и сигналов Django.

Как это всё настроить есть информация в Интернете. У меня это работает так:

1. Пользователь заходит на сайт

2. Nginx авторизует его, и передает параметр REMOTE_USER в Django

3. Если такого пользователя ещё нет, Django, с помощью django-auth-ldap, создаёт новую учётную запись. Если есть, проверяет соответствие данных в учетной записи и в Active Directory и обновляет их.

Как итог, пользователи попадают на helpdesk уже авторизованными.

Создание заявки

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

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

Список всех заявок

Список всех заявок решил сделать в виде таблицы с некоторыми фильтрами.

Так выглядит интерфейс всех заявок в кабинете пользователя. Пользователь видит только заявки, созданные непосредственно им.

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

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

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

Редактирование заявки

Редактирование заявки было решено выводить с помощью модального окна, в виде обычных форм.

Для сотрудников и руководителей форма более содержательная и с большими правами на редактирование:

Уведомления

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

Для уведомления по эл. почте использовалась стандартная библиотека send_mail. Иногда происходило подвисание интерфейса, при каких-либо действиях с заявкой. Пришлось покопаться и как позже выяснилось, это происходит из-за долгого ответа почтового сервера. Пришлось искать выход, и он был найден в лице Celery. Настроил Celery таким образом, чтобы он создавал таски на отправку и формировал очередь. Это позволило не подвисать интерфейсу при долгом ответе почтового сервера и работать более стабильно.

Для большей оперативности, для сотрудников было реализовано уведомление в Telegram с помощью библиотеки pyTelegramBotAPI. Пример уведомления ниже:

Как только происходят изменения c заявкой, backend даёт команду боту отправить уведомление в соответствующую отделу группу в Telegram. Группы в Telegram для соответствующих отделов, были созданы предварительно.

Отчёты по заявкам

Для отчётов по заявкам была выделена отдельная страница с формой:

После выбора параметров генерируется отчёт, который можно скачать в формате Excel. Доступ к отчётам доступен только руководителям подразделений.

Введение в работу

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

С помощью групповых политик раскидал ярлык Helpdesk’a на рабочие столы пользователей и написал инструкцию «Как пользоваться Helpdesk’ом»

Старт Helpdesk’a был назначен. В назначенный день всем по электронной почте разослали инструкцию. С тех пор система заявок работает. Сначала пользователи по привычке пытались оставлять заявки по телефону и по электронной почте, но со временем почти все привыкли и стали использовать Helpdesk.

Заключение

На этом первая часть Pet-проекта для обучения, была закончена. Система Helpdesk получилась вполне рабочая, люди ей пользуются, многим это даже нравится. Я же немного продвинулся в сторону разработки и это радует.

Пишу в первый раз, поэтому не судите строго.

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

• Nginx - в роли обратного прокси сервера, с SSO авторизацией в Active Directory,

• Django (DRF) – backend с LDAP авторизацией,

• Django Channels – для работы с WebSocket,

• Celery - для очереди заданий,

• Redis,

• PostgreSQL,

• React (React Redux) – в качестве frontend’a,

• Docker (Docker-compose) - для сборки всего вышеперечисленного.