Як ми написали helpdesk (частина 2)


У продовженні частина 1, ми вирішили написати статтю, як вийшли на «новий рівень» по створенню веб-продукту. Хочу відразу уточнити, що це не зовсім хелпдеск, який заснований на створенні заявок клієнтами (хоча така можливість і є), а більше розрахований на внутрішню роботу організації або IT-департаменту. Так само хочу нагадати, що система створювалася конкретно під наші вимоги, тому вона не краще за інших, але й не гірше. Вона просто «інша», у якої є свої функції під конкретні завдання і можливо займе гідне місце в загальному світі продуктів, що роблять IT-світ краще.

Передмова

Після виходу статті про opensource-версії продукту, я побачив віддачу від проекту. Перша — це звичайно ж github. Завдяки йому, я побачив що почали звертати увагу на код і функціонал: хтось критикував, не пропонуючи нічого взамін, а хтось робив хороші зауваження. У будь-якому випадку, віддача була і вона вплинула позитивно.
1. Ми дізнавалися, які функції хочуть люди і потім деякі (необхідні на наш погляд) застосовували у себе.
2. Знаходили баги і усували їх.
3. З'явився деякий список необхідного, який став «шляховим маршрутом розробки» — ROADMAP.

Гостро стало питання про організацію робочого процесу. Я зрозумів, що складно самому кодити, спілкуватися з питань розробки і перевіряти/тестувати знайдені баги. Проект дедалі більше розвивався і в якийсь момент прийшла думка про те, що наш внесок у проект перевершує наші очікування. Ми вирішили отримувати символічну винагороду.

Критика

Було багато критики, що закинули проект і пропонуємо тільки платну версію. Але ми завжди йшли на компроміс — вставайте в дію, допомагайте, будьте частиною нашої команди, робіть внесок і отримуйте за це винагороду. Якщо немає можливості купити продукт, то ми запитуємо: чим ви зможете допомогти розвитку проекту? І тоді був бартер. Люди пропонували ідеї, функціонал, реалізацію, а ми давали дистрибутив у користування і працювали.

Концепція продукту

Насамперед ми прагнули зробити систему простою, зручною і функціональною. Саме ці слова, як основа і змусили нас написати свою систему, а не взяти готову або платне.
Що б зрозуміти, як же все-таки застосовується система, краще всього привести життєвий приклад, коли є начальник, у якого кілька підлеглих. Ці люди працюють за принципом — виконуй завдання або передавай іншому. Що б контролювати виконання завдань і служить саме така система.
Це добре тим, що:
1. Видно результат роботи і завантаженість кожного співробітника
2. Всі дії журналируются (якщо є завдання від начальства форматування HDD, то потім доводити нічого не потрібно)
3. Створюй звіти за будь-який період і дивись, хто що робив

Таким чином, застосування нашої системи вже знайшло в державних органах, it-департаментах, агропромислових підприємствах, служби технічного супроводу, доставки та інших сферах. По своєму призначенню система орієнтується саме на організацію роботи з заявками/завданнями в межах відділу або корпорації, але з можливістю доступу до системи клієнтів з обмеженими правами і функціоналом. Виглядає це приблизно так: ми it-департамент, працюємо з завданнями, які нам створює начальник або координатор. Ці завдання так само можуть створювати самі користувачі системи, отримуючи їх від клієнтів по телефону. Самі клієнти можуть створювати заявки зі свого особистого кабінету.


Що під капотом?

Код був упорядкований більш-менш до концепції MVC і оптимізований. Раніше, основою системи є:
— JS-view (відповідає за дії на сторінці користувача та опрацювання того чи іншого UI-елемента)
— Actions php-файл (приймаючий дії від ajax-запитів і обробляє їх, свого роду частина API)
— Функції і класи (на основі яких працюють і actions та інші файли системи)
Саме такий структурний підхід до організації проекту і був придуманий мною. З використанням NodeJS додалася прошарок для веб-сокета, який постійно перевіряє чергу подій. Декілька скриптів, які виконуються за розкладом і відповідають за чергу повідомлень і перенесення заявок в архів. Система оновлення версій дозволяє за один клік оновити всю систему, створивши при цьому резервну копію поточної системи. Детальніше всі опис системи нижче.

Що саме змусило нас перейти на платну розробку?

Структура клієнтів/користувачів
Раніше (в opensource-версії) система мала дві логічно різні сутності і таблиці. З одного боку, це було зручно тим, що повноцінні користувачі системи перебували в одному місці, а клієнти без можливості доступу і прав — в іншому. Але в новій версії ми організували можливість доступу в систему звичайним клієнтам, для створення заявок. Таким чином система дозволяє окремо впровадити шаблони особистого кабінету своїй власній CRM-системи у нашу і інтегрувати два продукту.
Будь-якого користувача можна підключити до LDAP, і призначити йому певні права. Досить часто ми новим клієнтам, з наявною вже Active Directory, переносимо тисячі облікових записів в zenlix, для того що б клієнти, використовуючи свої AD-логін/пароль, могли створювати заявки.

NodeJS і повідомлення — раніше користувачі отримували спливаючі повідомлення завдяки таймеру в js-код, що кожні N секунд часу посилав ajax-запит з ключем на перевірку нових подій користувача. Зараз же, завдяки піднятому nodejs/socket.io-сервера, ми можемо отримувати самі повідомлення від сервера з необхідними командами і обробляти їх на стороні клієнта. Так працює система спливаючих повідомлень на події:
— нова заявка,
— прокоментована заявка,
— заблокована/розблоковану заявка,
— виконана/не виконана заявка,
— повідомлення чату.
Це істотно знизило навантаження на сервер.

Система повідомлень
Це не тільки повідомлення по email, але і з допомогою сторонніх сервісів, таких як pushbullet, sms, jabber та інших. Ми перейшли від процедурного виконання надсилання листа за діями користувачів до логічно-запланованому. Під повідомленнями слід розуміти відправку листів і запуск функцій бібліотек сторонніх сервісів. Як наслідок, після кожного виконаного дії з заявкою, яке вело за собою відправку повідомлень, користувач чекав відправлення повідомлень (листів, pushbullet) та інших, на всіх учасників (а їх близько 20!), тоді створення заявки на відділ (саме відправки повідомлення) забирало стільки часу, що скрипт віддавав timeout.
Сьогодні у нас вже діє система, яка обробляє величезну к-ть повідомлення за короткий період часу, має перевірку виконання відправки повідомлень. Це працює завдяки системи черги. Всі події накопичуються в таблиці БД, яка перевіряється з інтервалом раз в хвилину, з допомогою скрипта, який і виконує відправку всіх повідомлень по всіх сервісів. Таким чином, відправка повідомлень, працює асинхронно від дій користувача з UI.

Шаблон був обраний з серії AdminLTE і як сказано в описі: «Free Premium Admin control Panel Theme That Is Based On Bootstrap 3.x» :) Він дозволяє прекрасно виглядати системі на різних пристроях і має досить приємний набір UI-елементів, які радують очі людей, які постійно працюють з системою.

Планувальник завдань
Це те, що так не хотілося робити, але нас змусило через наполегливого клієнта. Завдяки даному функціоналу, ми маємо можливість створити заявку з певними параметрами і запланувати її створення з необхідною нам періодичністю. Це стосується типових регламентованих завдань наприклад по обслуговуванню техніки або створення резервних копій.

Звіти і графіки
Нас так часто просили написати і вивести звіти за певними критеріями, що ми просто поєднали найбільш часті запити в кілька інформативних звітів. Тепер ми можемо дивитися статистику
— по конкретним користувачам за певний період,
— за обраним відділам за період,
— загальну статистику всього департаменту.
При цьому кожному користувачеві системи доступна і персональна статистика.

Система оновлення
Користувач в адмін-меню клікає по кнопці, у результаті чого спрацьовує JS-функція відправки ajax-запиту до нашого actions-файлу, той в свою чергу запускає стандартну функцію, суть якої сформувати curl-запит до нашого API-сервера оновлень, і отримати відповідь: чи є нова версія і якщо є, то які зміни відбулися. Після цього:
1. Скачується архів необхідних файлів для оновлення.
2. Робиться локально резервна копія всіх файлів БД.
3. Видаляються всі поточні файли.
4. Разархивируются нові файли копіюються у робочу директорію.
5. Видаляється тимчасовий файли і архіви.
6. Оновлення готове.
Звичайно, є мінуси такого підходу. Якщо у Вас своя конфігурація, то у Вас немає можливості оновлюватися, так як нова версія буде видаляти файли колишньою. Можна в ручному режимі відслідковувати і відновлювати файли, але це не так зручно, як хотілося б.
З боку розробників, хедлайнер проекту робить пуш в основний репозиторій, після чого спрацьовує post-receive HOOK, що:
1. Створює основний дистрибутив останньої версії продукту.
2. Створює архів для системи оновлення тільки з необхідними для оновлення файлами.

Питання ліцензування

Як тільки ми зрозуміли, що система переходить в платне русло, ми задумалися про ліцензування. Точніше про контроль за розповсюдженням коду. Так як 90% коду це PHP, ~8% — JS, ~2% — CSS, то можна було б скористатися Zend Guard або ioncube. Але вартість цих продуктів досить висока, як для нашого стартапу. До того ж ми не хотіли клієнтів і користувачів спантеличувати зайвими діями по встановленню необхідного софта і потім постійних перевірок продукту. Ми довіряємо нашим клієнтам так само, як вони довіряють нам, купуючи цей продукт. Тому, у нас немає прив'язок по ip або доменним іменам.

Паралельні розробки

У нашому продукті ми паралельно розробляємо і найближчим часом випустимо IOS-додаток, яке дозволить з мінімальним функціональним інтерфейсом, максимально зручно обробляти заявки. Основний акцент робився на прийом push-повідомлень про нові події, щодо заявок. Для розробки такого додатка, був написаний API-скрипт, обробний основні функції: авторизація, отримання поточного списку заявок, перегляд заявки, блокування/розблокування та виконання/невиконання конкретної заявки.

Звідси, ми вирішили і далі розвивати API, створюючи при цьому основу для розвитку функціоналу мобільного додатка і нового об'єкта системи API-інтерфейсу, для інтеграції з різними сервісами і системами.

Які залишилися відкриті проблеми і не вирішені питання?

Вся підтримка поточних клієнтів поки в ручному режимі, тобто це skype/email. Планується створити платформу, яка дозволить створити співтовариство користувачів, для подальшого розвитку проекту. Можливо, з'явиться ще один продукт на основі цього.
Документація для розробників так само поки не доступна, що в свою чергу ускладнює розвиток продукту для нових розробників, які набрали команду. Перше це API, архітектура роботи проекту, основні функції та модулі системи.
Інсталяція nodejs і його підтримка зобов'язує проводити в ручному режимі встановлення nodejs, socket.io, mysql. А так само forever — для постійного контролю і підтримки сервера. Для деяких ці дії є проблемними. Ми працюємо над написанням інсталяційного скрипта, який дозволить полегшити цей процес. Так само ми переходимо з forever на PM2.

Підхід до клієнтів

Дуже часто ми ловили себе на думці, що віддаємо більше, ніж отримуємо. Скоріше це так і є досі. Тому, як ми безкоштовно або з великими знижками поширюємо продукт в освітні установи, допомагаємо впровадити нові інфраструктури організації, проконсультувати з можливим нюансам роботи. Наше завдання не заробити на даному продукті, що звичайно є природним бажанням, а отримати досвід робочого процесу розробки, спілкування з клієнтами та їх віддалена підтримка. Ми завжди пропонуємо безкоштовну віддалену установку, не дивлячись на те, що є документація і простий скрипт установки. Наш продукт не є ідеальним, але ми прагнемо цього постійно, завдяки відгукам та коментарям. Так само й мета цієї статті — отримати максимальну базу для подальшого розвитку проекту.

Підсумок

Ми дуже сподіваємося, що наш продукт займе своє місце у світі продуктів для оптимізації та організації робочого процесу. У будь-якому разі, для нас це ще один прекрасний досвід. Раді будемо почути коментарі в стилі: «можна було б зробити так..», «ще не погано було б зробити...», «у нас це реалізовано так...». Ми не будемо давати консультаційні відповіді, так як мета цієї статті не реклама і не пропозиція купити наш продукт, а поділитися досвідом робочого процесу, створенням нового продукту.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.