Комментарии 28
А визуальный интерфейс оставили стандартный? Или есть какие либо интересные плюшки?
Вся стилистика OTRS сохранилась. В основном изменения интерфейса связаны с переработанным блоком информации о тикете и при просмотре заявки. Вместо сухого текста были добавлены динамические иконки, которые меняются (иногда просто в цветовой гамме) в зависимости от состояния тикета, от типа пользователя, блокировки и т.д.
Абалдеть. Я даже сел почитать. Большая простыня о том, как попунктно с мелочами не надо делать никогда ваще. Хотя уведомления наверное +- Ок. Ну хорошо, ещё плюсики от клиентов. А в остальном — сложный путь решения несуществующих проблем странными методами.
Некстати, а модный стильный молодежный асинхронный API взамен скоммунизженному у Регтайм синхронному будет когда-нибудь? :))
Некстати, а модный стильный молодежный асинхронный API взамен скоммунизженному у Регтайм синхронному будет когда-нибудь? :))
НЛО прилетело и опубликовало эту надпись здесь
По делу, Миха, это в каком месте? В месте, где зачем-то вообще переносились данные старого OTRS, хотя тут без опыта можно сказать, что это сложное и затратное спасение мусора? :) Или в том, где они пошли строить кастомизацию по второму кругу? Или может в том, где они отказываются от родного API OTRS в пользу JSON только потому что… потому что няшно? При этом они не асилили ни идентификации клиента (я осилил), ни встраивания в панельку (меня заломало) дерева. Или может в системе проверки адреса отправителя вместо 100500 менее пинг-понговских способов? Типа чтобы потом убедиться, что взломали ящик :) Или в храненнии и построении разных никому не нужных графиков и диаграмм? Или может в той рулетке с тикетами " а получает только то, что выдала ему бездушная машина" — т.е. ответит кто попало, даже если он ни сном ни духом в этом. Крутая фишка да. Или может Redis как прослойка перед отправкой тикета? Это шутка такая да? Я думаю туда Оракла не хватает. Ну для серьёзности. А да, забыл эпик вин с 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 вы можете посмотреть вот тут».
Я нигде не сказал «удалить». Хотя давай будет откровенными — весь этот мусор уже через год никому не нужен. Вспомни как мы с 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 или подобного отдельным сервисом. С экранчиком на стене как в юлмарте :)
Не так? «Мы не смогли поставить корпоративный джаббер (ни у кого не было 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 функционала было значительно больше, насколько я помню.
Интересно, почему в своё время вы выбрали OTRS, а не RT? На тот момент у RT функционала было значительно больше, насколько я помню.
Видимо, в своё время кто-то «пропихнул» именно этот инструмент. К нему привыкли, он оброс своими фишками, а дальше уже и не смотрели на другие продукты. Думаю, было именно так.
RT «течет» страшно. И так вроде и не поборол этого. У РТ что-то помню слабее настраивается. Поэтому большинство провайдеров сидит на OTRS.
Интересно было почитать, есть что взять из идей на вооружение. К допилам тройки мы сами пришли через год использования, мигрировали на четверку и тутже нарисвалась необходимость кастомизироваться. Пока пошли по пути наименьшего сопротивления и не меняя схему БД и кода модулей дописываем отдельные интерфейсные плюхи. Так, например, очень полезным инструментом стало Kanban представление дэшборда, на котором при определенном объеме заявок становится малопонятна ситуация с задачами. Дело в на 10 минут, а пользы для руководителя и забегавшегося сотрудника на мульён.
Вот Вы пишете: активные тикеты — тикеты, созданные реальными клиентами.
Если просуммировать по годам, получается 1 320 272.
И в то же время «тикетов, на которые хотя бы раз отвечали» — 769 344. Это порядка 58% от общего числа.
Получается, что без малого половина ваших клиентов, реальных клиентов, обращавшихся в поддержку, не были удостоены хотя бы формальным ответом саппорта, тикет молча закрывался? Фи, товарищи.
Или я что-то неправильно понял из Ваших цифр?..
Если просуммировать по годам, получается 1 320 272.
И в то же время «тикетов, на которые хотя бы раз отвечали» — 769 344. Это порядка 58% от общего числа.
Получается, что без малого половина ваших клиентов, реальных клиентов, обращавшихся в поддержку, не были удостоены хотя бы формальным ответом саппорта, тикет молча закрывался? Фи, товарищи.
Или я что-то неправильно понял из Ваших цифр?..
769 344 — это на которые хотя бы раз отвечали за 2014-15 года, а не за всё время. Поэтому суммировать все тикеты от клиентов за все года не правильно.
За 2015 год статистика не представлена, т.к. год еще не закончен.
Кроме того, в тикеты от реальных клиентов попадают различные абузы, письма информационного характера (не требующие ответа), дубли и т.д.
За 2015 год статистика не представлена, т.к. год еще не закончен.
Кроме того, в тикеты от реальных клиентов попадают различные абузы, письма информационного характера (не требующие ответа), дубли и т.д.
Насколько я понял, вы весьма расширили функционал OTRS, по сути сделав свой продукт (форк). Вы как-то планируете делиться разработками, вливая их в OTRS или вынужденно придете к своему продукту?
Очень мощный инструмент с огромным количеством функционала практически под любые нужды малого и среднего бизнеса.
Начнём с того, что в начале прошлого года мы отказались от обратной совместимости с основной веткой OTRS, поддерживаемой разработчиками.
Поэтому написали свой API
мы разработали свою статистику по тикетам в OTRS.
Хочется спросить, а был ли OTRS? Если вы взяли и большую часть функционала написали с нуля. Что осталось-то? Факт сохранения тикетов в базе?
Оглядываясь назад, как вы считаете, надо было допилить OTRS, или написать свой Service Desk с нуля? Бесспорно, в плюсах OTRS остается быстрый старт, пока недостаточно инвестиций в дополнительный функционал. Но если бы времени, ресурсов было бы достаточно с самого начала?
Писать свой helpdesk — это минимум полгода, а то и год. И всё равно не будет и 30% тех возможностей, которые есть в готовом продукте. К тому же придется пройти все те грабли, которые уже пройдены разработчиками других opensource хелпдесков. Я слабо представляю компанию, у которой есть время и ресурсы на разработку вспомогательного инструментария от которого продажи косвенные, а не прямые.
Оглядываясь назад, могу сказать что желания написать свой helpdesk с нуля всё равно не появилось. Просто потому, что проще и быстрее поправить существующее, чем писать это самому.
И еще далеко не весь базовый функционал выпилен, многое работает как и задумано разработчиками.
Оглядываясь назад, могу сказать что желания написать свой helpdesk с нуля всё равно не появилось. Просто потому, что проще и быстрее поправить существующее, чем писать это самому.
И еще далеко не весь базовый функционал выпилен, многое работает как и задумано разработчиками.
Очень интересная статья! Спасибо что провели такую работу и не поленились написать об этом. По-сути получился доведенная до ума высоконагруженная система. Жаль только, что ваш труд вложенный в OpenSource проект не попадает назад в комьюнити.
Системы отчетов всех OpenSource систем тикетов являются по-настоящему больной темой. Только из-за этого приходится обращаться к коммерческим поделкам. Судя по комментариям даже нормальные разработчики не понимают для чего это нужно и насколько важно для бизнеса. Планируете ли вы опубликовать код модуля построения отчетов? Может быть отправить его в основную ветку разработки?
И второй, философский вопрос. Скажите какой объем занимает вся база данных трекера? Не пришло ли время взять и сделать систему, которая будте работать на выборках ключ значение с использованием какой нибудь NoSQL системы типа Redis? Не в роли кеша, а в роли полноценной БД?
Ваше мнение опытных разработчиков интереснее чем сотня маркетинговых статей на эту тему.
Ну я сделал что мог — отправил приглашения вашим соавторам.
Системы отчетов всех OpenSource систем тикетов являются по-настоящему больной темой. Только из-за этого приходится обращаться к коммерческим поделкам. Судя по комментариям даже нормальные разработчики не понимают для чего это нужно и насколько важно для бизнеса. Планируете ли вы опубликовать код модуля построения отчетов? Может быть отправить его в основную ветку разработки?
И второй, философский вопрос. Скажите какой объем занимает вся база данных трекера? Не пришло ли время взять и сделать систему, которая будте работать на выборках ключ значение с использованием какой нибудь NoSQL системы типа Redis? Не в роли кеша, а в роли полноценной БД?
Ваше мнение опытных разработчиков интереснее чем сотня маркетинговых статей на эту тему.
Ну я сделал что мог — отправил приглашения вашим соавторам.
Когда будем переходить на EventHandler, то скорее всего получим несколько модулей, которые уже можно будет выложить в открытый доступ, как с модулем поиска.
Система отчетов, к сожалению у нас полностью отделена от кодовой базы OTRS и работает на фреймворке Mojolicious. У нее есть доступ к базе OTRS, но какие то тяжелые отчеты у нас хранятся уже в готовом виде в базе статистики(эти отчеты формируются крон скриптами).
Размер базы на данный момен > 30G. Переходить на NoSQL пока нет никакого смысла, с переходом на поиск Sphinx, нагрузка на базу данных минимальна.
P.S. спасибо за инвайты.
Система отчетов, к сожалению у нас полностью отделена от кодовой базы OTRS и работает на фреймворке Mojolicious. У нее есть доступ к базе OTRS, но какие то тяжелые отчеты у нас хранятся уже в готовом виде в базе статистики(эти отчеты формируются крон скриптами).
Размер базы на данный момен > 30G. Переходить на NoSQL пока нет никакого смысла, с переходом на поиск Sphinx, нагрузка на базу данных минимальна.
P.S. спасибо за инвайты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OTRS на прокачку в стиле REG.RU