Pull to refresh

Comments 28

А визуальный интерфейс оставили стандартный? Или есть какие либо интересные плюшки?
Вся стилистика OTRS сохранилась. В основном изменения интерфейса связаны с переработанным блоком информации о тикете и при просмотре заявки. Вместо сухого текста были добавлены динамические иконки, которые меняются (иногда просто в цветовой гамме) в зависимости от состояния тикета, от типа пользователя, блокировки и т.д.
Мне он кажется таким не удобным. Ваши сотрудники не жалуются на него? Например, тот же zendesk гораздо более удобный. (Вопрос в контексте визуального оформления, а не масштабирования, наличия saas и пр.)
Некоторые частые операции мы упростили.
Типа закрытия, переноса тикетов.
В остальном же вполне удобен. А переходить на какую-то другую helpdesk-систему еще более трудозатратное предприятие. Даже в плане привыкания к «новому» интерфейсу.
Абалдеть. Я даже сел почитать. Большая простыня о том, как попунктно с мелочами не надо делать никогда ваще. Хотя уведомления наверное +- Ок. Ну хорошо, ещё плюсики от клиентов. А в остальном — сложный путь решения несуществующих проблем странными методами.

Некстати, а модный стильный молодежный асинхронный API взамен скоммунизженному у Регтайм синхронному будет когда-нибудь? :))
Что не так? После твоего комментария еще раз пробежался по статье одним глазом, вроде всё по делу.
По делу, Миха, это в каком месте? В месте, где зачем-то вообще переносились данные старого OTRS, хотя тут без опыта можно сказать, что это сложное и затратное спасение мусора? :) Или в том, где они пошли строить кастомизацию по второму кругу? Или может в том, где они отказываются от родного API OTRS в пользу JSON только потому что… потому что няшно? При этом они не асилили ни идентификации клиента (я осилил), ни встраивания в панельку (меня заломало) дерева. Или может в системе проверки адреса отправителя вместо 100500 менее пинг-понговских способов? Типа чтобы потом убедиться, что взломали ящик :) Или в храненнии и построении разных никому не нужных графиков и диаграмм? Или может в той рулетке с тикетами " а получает только то, что выдала ему бездушная машина" — т.е. ответит кто попало, даже если он ни сном ни духом в этом. Крутая фишка да. Или может Redis как прослойка перед отправкой тикета? Это шутка такая да? Я думаю туда Оракла не хватает. Ну для серьёзности. А да, забыл эпик вин с Jabber. Пуш в браузер на самом деле не так плох. Но не по причине того, что был плох Jabber-провайдер или руки-крюки не смогли поднять свой jabber-сервер. Ну там вобщем все такое :)
Ну, давай по шагам.

> В месте, где зачем-то вообще переносились данные старого OTRS, хотя тут без опыта можно сказать, что это сложное и затратное спасение мусора?

Какие данные? Пробежался еще раз по статье, не вижу подстрок «перенос» и «данные». Но если данные — это старые тикеты, то всё правильно сделали. История не должна теряться, никогда не знаешь, когда вылезет вредный клиент с претензией по тикету трехлетней давности.

> Или в том, где они пошли строить кастомизацию по второму кругу?

Чо?

> Или может в том, где они отказываются от родного API OTRS в пользу JSON только потому что… потому что няшно?

xml-rpc — это гавно на палочке. В API должен быть только json, ничего другого. Только json, Карл!

> При этом они не асилили ни идентификации клиента (я осилил), ни встраивания в панельку (меня заломало) дерева. Или может в системе проверки адреса отправителя вместо 100500 менее пинг-понговских способов? Типа чтобы потом убедиться, что взломали ящик :)

Ничо не понял.

> Или в храненнии и построении разных никому не нужных графиков и диаграмм?

Это тебе не нужно, пока ты сам себе платишь. А когда у тебя 100500 сотрудников, то ты вынужден считать, на что уходят деньги и с какой эффективностью.

> Или может в той рулетке с тикетами " а получает только то, что выдала ему бездушная машина" — т.е. ответит кто попало, даже если он ни сном ни духом в этом.

Во-первых, не должно быть никакого «ни сном ни духом в этом». Все юниты в техподдержке должны быть полностью взаимозаменяемы и разбираться во всем одинаково. А если проблема совсем другого уровня сложности, так у них есть вторая линия техподдержки, инженеры, коим и будет передан тикет.

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

> Или может Redis как прослойка перед отправкой тикета?

А что не так? Очередь задач — классная штука. Ну и к тому же, я так понял, это не часть OTRS, а отдельная софтина, клиент к OTRS.

> А да, забыл эпик вин с Jabber. Пуш в браузер на самом деле не так плох. Но не по причине того, что был плох Jabber-провайдер или руки-крюки не смогли поднять свой jabber-сервер.

Опять же — что не так? Не понял претензию.
> то всё правильно сделали. История не должна теряться,

Я нигде не сказал «удалить». Хотя давай будет откровенными — весь этот мусор уже через год никому не нужен. Вспомни как мы с RT на OTRS переходили. Ты даже не вспомнишь скорее всего даже факт существования RT. Просто RT какое-то время поработал вместе с OTRS.

>> Или в том, где они пошли строить кастомизацию по второму кругу?
> Чо?

Переработка и доработка OTRS. И явно не плагинами. Когда 3.x совсем устареет — история повторится.

> xml-rpc — это гавно на палочке. В API должен быть только json, ничего другого. Только json, Карл!

Но там XML-RPC. Понимаешь, есть только одна ОС и Ритчи пророк её — Plan9. Но действительность такова, что, хотя и половина веб-разработчиков используют UTF-8 и пишут на откопанном Alef, всё же Plan9 пока не вариант. Возможно, я бы понял, если бы эта переработка закрыла бы остальные пункты (интеграцию истории в панельку, связь кастомера и ОТРС). Но нет. Она просто потому что «Карл». Потратили время, подогрели воздух.

> Ничо не понял.

Система проверки адреса отправителя, чтобы идентифицировать клиента — вещь конечно рабочая, но сомнительная :) Т.е. если например сделать многофакторную авторизацию в панель управления (я имею ввиду юридически, а не технически), а не только по паролю, который может быть выслан на email, то это становится вообще нерабочей штукой (проверка email становится не достаточной, потому что юридически требуется многофакторная). Но это ладно. Главное — человек пишет, нервничает, а ты ему такой: «Пинг». Не хотел, но таки похвастаюсь — у нас с тобой очень элегантное решение. Только я ещё прямо средствами OTRS в OTRS ставлю меточку и показываю её себе на экране — кто, что, когда, какой тариф. JSON вобщем у них моден, а интеграция хотя бы костылями и палками в панельку — нет. И этим надо похвастаться на пять экранов на хабре :)

> А когда у тебя 100500 сотрудников, то ты вынужден считать, на что уходят деньги и с какой эффективностью.

Ты начитался хрени всякой? Ну-ка, давай поговорим за эффективность. Кто, например, был эффективнее — раздолбай Вася, или вдумчивый упрямый ответственный, но не очень сообразительный Марат? Нарисуй это на графиках и схемах. Чушь всё это. Собственно единицы крупных фирм могут организовать хотя бы примелимую СТП. А неприемлима она с графиками или без — это разве что только для собственного успокоения руководства.

Для i-компании хороший показатель эффективности СТП — плачет пиарщица в углу перед публичной акцией, или ты её уже уволил без зарплаты в одних трусах, а она всё ещё хвастается везде, что твоя пиарщица :) Вот это и график, и диаграмма, и вот это всё :)

> Все юниты в техподдержке должны быть полностью взаимозаменяемы и разбираться во всем одинаково.

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

> А если проблема совсем другого уровня сложности, так у них есть вторая линия техподдержки, инженеры, коим и будет передан тикет

Есть ещё горизонтальная сложность. Да и вертикальная весьма абстрактна. Совершенно бессмысленно напрягать чувака, который не умеет прочесть drill -T его делать и объяснять клиенту. Я думаю ты до сих пор не умеешь. А упомянутый Марат кстати себя прокачал. Другой вопрос, что нужно всех пытаться хотя бы делать не ниже какой-то планки. Но специфика всё равно будет.

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

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

А так будет отписка, которую мы часто кстати и видим в ответах различных СТП (включая меня, когда я устал), или пинг-понг между линиями поддержки. Ну вобщем, это попытка пригладить волны. Хотя и популярная.

В этом смысле вот эти баллы и прочие рюшечки кстати эффективнее бездушного раскидывания :)

> Ну и к тому же, я так понял, это не часть OTRS, а отдельная софтина, клиент к OTRS.

Угу :) Знаешь да, как называется встроенный клиент к OTRS? :) Mail Sender Programm :) А можно ещё развесить OTRS на несколько нод (немного допилив конечно). А ещё почту можно слать в несколько мест (ящиков на разных серверах) и забирать каждой нодой из каждого. А ещё можно сделать просто асинхронный посыл тикета изначально. Хотя посмотрел презенташку — они тиражируют это решение на всё, так что внезано тут я может быть и не прав. Это оправдано. С технической стороны. С маркетинговой мариновать несколько часов «ваш тикет очень важен для нас»… Очень сомнительное решение против «извините, у нас проблемы, issue вы можете посмотреть вот тут».
> А да, забыл эпик вин с Jabber. Опять же — что не так?

Не так? «Мы не смогли поставить корпоративный джаббер (ни у кого не было 15 минут), поэтму запарились и сделали пуш в браузер». Хотя в даннм случае я скорее всего бы сделал что-то вроде нагиоса (а может и его), который пиликает на весь офис и на эскалированные тикеты, и на запросы звонка. Возможно разными голосами. Это просто с одной стороны, и эффективно с другой. Более того, таких евентов есть определенное количество для СТП, и как раз можно даже пуш сделать или ещё чего именно на основе nagios или подобного отдельным сервисом. С экранчиком на стене как в юлмарте :)
Переработка и доработка OTRS. И явно не плагинами. Когда 3.x совсем устареет — история повторится.


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

Но там XML-RPC.Но нет. Она просто потому что «Карл». Потратили время, подогрели воздух.


XML-RPC — работает напрямую с ядром, а наше API идет через GenericInterface, предварительно работая с кастомером (Создание и обновление данных которые идут из наших сервисов ). Так же пропадает необходимость писать монструозные запросы к rpc, так как используются уже готовые контроллеры для обработки, например создания заявки, которые проводят всю валидацию данных ( возвращая читаемые ошибки), работу с динамическими полями, создание артиклей, работа с аттачами и т.д.

И этим надо похвастаться на пять экранов на хабре


Интеграция пользователя имеется, все необходимые данные передаются в API. Речь идет о пользователях, которые не авторизованы на сайте, а просто через форму отправляют нам заявки, оставляя произвольный email. По email и дополнительным полям из формы, вытаскиваются данные об услугах, пользователе и т.д. Тут мы просто проверяем, что это не случайный человек хочет удалить свой сервер, указав email и услугу другого пользователя.

Ну-ка, давай поговорим за эффективность.


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

А так будет отписка, которую мы часто кстати и видим в ответах различных СТП (включая меня, когда я устал), или пинг-понг между линиями поддержки. Ну вобщем, это попытка пригладить волны. Хотя и популярная.


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

«Мы не смогли поставить корпоративный джаббер (ни у кого не было 15 минут), поэтму запарились и сделали пуш в браузер».


Могли, конечно же. Но держать джаббер-сервер только для того чтобы один скриптик периодически писал
другим сотрудникам? И еще просить всех сотрудников добавить его к себе в buddy-лист? Слишком большой инструмент для слишком маленькой задачки. Кроме этого, нахождение в jabber не означает что сотрудник реально может отреагировать на тикет. Поэтому PUSH-и для сотрудников на смене, SMS — для критических тикетов в определенные очереди или в не рабочее время.
Статистики нормальной в ОТРС не было. Поиска тоже.
Ну ок, можно какие-то вещи взять из плагинов, которые в интернете в некотором количестве присутствуют.
Поэтому мне не совсем понятно что мы такого сделали, что делать никогда не нужно. Может подробнее опишите? Мнение со стороны полезно будет узнать.
Встревайте в наш диспут с Иванычем выше :)
В своё время очень много усилий и времени тратил на RequestTracker, от полного перевода, до дописывания всяких модулей (включая подтверждение получения заявки) и создания систем рассылок тарифов на его базе, тоже с подтверждениями и прочими плюшками для VoIP-оператора.
Интересно, почему в своё время вы выбрали OTRS, а не RT? На тот момент у RT функционала было значительно больше, насколько я помню.
Видимо, в своё время кто-то «пропихнул» именно этот инструмент. К нему привыкли, он оброс своими фишками, а дальше уже и не смотрели на другие продукты. Думаю, было именно так.
RT «течет» страшно. И так вроде и не поборол этого. У РТ что-то помню слабее настраивается. Поэтому большинство провайдеров сидит на OTRS.
RT клеит тикет к сотруднику и вроде как его не настроить по-другому. Вроже так было.
Интересно было почитать, есть что взять из идей на вооружение. К допилам тройки мы сами пришли через год использования, мигрировали на четверку и тутже нарисвалась необходимость кастомизироваться. Пока пошли по пути наименьшего сопротивления и не меняя схему БД и кода модулей дописываем отдельные интерфейсные плюхи. Так, например, очень полезным инструментом стало Kanban представление дэшборда, на котором при определенном объеме заявок становится малопонятна ситуация с задачами. Дело в на 10 минут, а пользы для руководителя и забегавшегося сотрудника на мульён.
Вот Вы пишете: активные тикеты — тикеты, созданные реальными клиентами.
Если просуммировать по годам, получается 1 320 272.
И в то же время «тикетов, на которые хотя бы раз отвечали» — 769 344. Это порядка 58% от общего числа.
Получается, что без малого половина ваших клиентов, реальных клиентов, обращавшихся в поддержку, не были удостоены хотя бы формальным ответом саппорта, тикет молча закрывался? Фи, товарищи.

Или я что-то неправильно понял из Ваших цифр?..
769 344 — это на которые хотя бы раз отвечали за 2014-15 года, а не за всё время. Поэтому суммировать все тикеты от клиентов за все года не правильно.

За 2015 год статистика не представлена, т.к. год еще не закончен.

Кроме того, в тикеты от реальных клиентов попадают различные абузы, письма информационного характера (не требующие ответа), дубли и т.д.
Насколько я понял, вы весьма расширили функционал OTRS, по сути сделав свой продукт (форк). Вы как-то планируете делиться разработками, вливая их в OTRS или вынужденно придете к своему продукту?
Целиком систему отдавать во всеобщее пользование мы вряд ли будем. Отдельные наработки мы стараемся писать максимально независимо от общего кода, чтобы можно было выделить их в расширение для официальной версии OTRS. К примеру, OTRS::SphinxSearch является таким изделием.
Очень мощный инструмент с огромным количеством функционала практически под любые нужды малого и среднего бизнеса.

Начнём с того, что в начале прошлого года мы отказались от обратной совместимости с основной веткой OTRS, поддерживаемой разработчиками.

Поэтому написали свой API

мы разработали свою статистику по тикетам в OTRS.


Хочется спросить, а был ли OTRS? Если вы взяли и большую часть функционала написали с нуля. Что осталось-то? Факт сохранения тикетов в базе?

Оглядываясь назад, как вы считаете, надо было допилить OTRS, или написать свой Service Desk с нуля? Бесспорно, в плюсах OTRS остается быстрый старт, пока недостаточно инвестиций в дополнительный функционал. Но если бы времени, ресурсов было бы достаточно с самого начала?
Писать свой helpdesk — это минимум полгода, а то и год. И всё равно не будет и 30% тех возможностей, которые есть в готовом продукте. К тому же придется пройти все те грабли, которые уже пройдены разработчиками других opensource хелпдесков. Я слабо представляю компанию, у которой есть время и ресурсы на разработку вспомогательного инструментария от которого продажи косвенные, а не прямые.

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

И еще далеко не весь базовый функционал выпилен, многое работает как и задумано разработчиками.
Спасибо за ответ, очень познавательно.
Очень интересная статья! Спасибо что провели такую работу и не поленились написать об этом. По-сути получился доведенная до ума высоконагруженная система. Жаль только, что ваш труд вложенный в OpenSource проект не попадает назад в комьюнити.

Системы отчетов всех OpenSource систем тикетов являются по-настоящему больной темой. Только из-за этого приходится обращаться к коммерческим поделкам. Судя по комментариям даже нормальные разработчики не понимают для чего это нужно и насколько важно для бизнеса. Планируете ли вы опубликовать код модуля построения отчетов? Может быть отправить его в основную ветку разработки?

И второй, философский вопрос. Скажите какой объем занимает вся база данных трекера? Не пришло ли время взять и сделать систему, которая будте работать на выборках ключ значение с использованием какой нибудь NoSQL системы типа Redis? Не в роли кеша, а в роли полноценной БД?

Ваше мнение опытных разработчиков интереснее чем сотня маркетинговых статей на эту тему.

Ну я сделал что мог — отправил приглашения вашим соавторам.
Когда будем переходить на EventHandler, то скорее всего получим несколько модулей, которые уже можно будет выложить в открытый доступ, как с модулем поиска.

Система отчетов, к сожалению у нас полностью отделена от кодовой базы OTRS и работает на фреймворке Mojolicious. У нее есть доступ к базе OTRS, но какие то тяжелые отчеты у нас хранятся уже в готовом виде в базе статистики(эти отчеты формируются крон скриптами).

Размер базы на данный момен > 30G. Переходить на NoSQL пока нет никакого смысла, с переходом на поиск Sphinx, нагрузка на базу данных минимальна.

P.S. спасибо за инвайты.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.reg.ru
Employees
101–200 employees
Registered