Как стать автором
Обновить

Комментарии 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. спасибо за инвайты.
Спасибо за ответ, желаю успехов!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.