Pull to refresh

Comments 58

А еще у него нет нормального API, в результате он не интегрируется ни с чем. Время работы с ним я вспоминаю с ужасом (в не малой степени правда из-за того, что у нас по дефолту стояла тема времен появления интернета, на которую просто не возможно смотреть). Другое дело системы у которых есть плагин к eclipse — это просто рай для разработчика.

Для всех остальных система может и подойти. Ведь вход в рай eclipse им заказан :P.
Я не так силен в программировании, как вы, но на сайте написано
For the more technically minded, RT provides a REST API and even a command-line client to talk to RT from other programs and integrate with other systems. Connections to ArcSight, Nagios, Journyx, MediaWiki, Subversion and more already exist!


Так же есть библиотека API для .NET
Очень вкусные фишки RT:

1) конечно, ответы на заявки через email — в 2-х режимах: ответ (отправляется пользователю) и комментарии (видны только участникам рабочей группы)

2) workflow через произвольные скриплеты и шаблоны — хотя бы для гибкой настройки email-уведомлений в разных случаях — как справку по RT я использовал search.cpan.org/~jlmartin/RT-Client-REST-0.4/

3) сохраняемые запросы — позволяют очень гибкие дашборды создавать, опять же улучшая workflow.

Минусы: не очень юзабелен по дефолту — для оптимума нужно допиливать, благо возможность есть.
workflow — это я понимаю кастомные статусы? После них возникают проблемы с сортировкой ибо отсортировать статусы так как нужно тебе, а не как они зарегистрированы в системе не возможно.
Все бы хорошо, но на перле :(
На обычный виртуальный хостинг фиг засунешь.
Виртуальный хостинг рискует тупо обвалиться под ее весом. Возможно моя информация несколько устарела, т.к. я сбежал от RT несколько лет назад, и с тех пор наверняка утекло много воды. Если кто-то расскажет, какие из обозначенных мной проблем уже в прошлом (или наоборот, подтвердит их наличие), я буду ему благодарен.
Компания, где я работал, была не самая маленькая крупная, и база переписки в RT была довольно объемная. Железяку несколько раз апгрейдили, но саппорт все равно жаловался на скорость работы. Секретов было несколько. Первый — интересная объектная модель, завязанная на собственную реализацию ACL. Объекты при инициализации получали объект текущего авторизованного юзера, и при попытке загрузить что бы то ни было происходил четырехэтажный джойн на таблицы, с правами — так, что на выходе запроса оставались только те данные, которые юзер имел право загрузить. Ну и что? Да в общем-то и ничего, если б не второй секрет: на странице просмотра только что созданного тикета (без аттачей, переписки и прочего — с единственным вопросом) запросов было порядка ста! А поскольку права юзерам можно раздавать на пункты меню и все операции, большинство этих запросов были тоже четырехэтажными. Третий секрет успеха — в хранении аттачей в БД. Не могу сказать сейчас, в чем конкретно была проблема — то ли в кеше мускуля, который работал неэффективно, то ли в чем-то еще — но когда ребята, занимавшиеся поддержкой системы в компании, напряглись и слили из 100гиговой базы все аттачи в файлы, сервер задышал, а база получила шансы поместиться в памяти.
Код модулей проекта в принципе терпимый (хотя ОРМ DBIx::SearchBuilder, на которой все построено, по функционалу и интерфейсам напоминает трехлапую черепаху с двумя головами). Немного покопавшись, все становится более-менее понятным. Масоновские файлы несколько более удручающи, но в целом это не самый страшный код, который мне доводилось видеть, хотя проблем там действительно было много.
Короче, мой диагноз таков. RT — хорошая система, в том плане что она предоставляет пользователю действительно небедные возможности. Это может быть ваш выбор, если:
1) у вас не слишком катастрофический объем переписки (либо вы не ставите себе цели хранить ее по десять лет, либо вы готовы сломать голову когда нибудь потом, чтобы ее оттуда вытащить)
2) вас устраивает ее функционал из коробки (включая возможные баги)
3) вы не собираетесь (вы ДЕЙСТВИТЕЛЬНО не собираетесь) допиливать ее под себя.
Если с этими пунктами что-то не так — советую подумать.
# я буду перечитывать свой ночной бред перед отправкой. Я буду. Буду.
s/была не самая маленькая крупная/была не самая маленькая/;
s/четырехэтажный джойн на таблицы, с правами/четырехэтажный джойн на таблицы с правами/;
Да ладно, хорошо получилось!

четырехэтажный джойн на таблицы с правами
йо-хо-хо и бутылка рома!

Я помню RT во времена второй версии. Бедненько, но чистенько. С тех пор много всего сменилось, для программистских проектов трекера мало, остановились на Redmine.
кстати, полезный ресурс по нему — request-tracker.ru — сообщество пользователей и разработчиков под Request Tracker.

аналог по мощности — я так понимаю, только OTRS и Bugzilla (в свое время между ними тремя выбирал).

В продолжении было бы особо интересно про workflow с несколькими очередями, несколькими ответственными в них, с ролями: 1) пользователь — автор заявки, 2) координатор — распределяет заявки из общей очереди, 3) ответственный за очередь, 4) супервизор (получает все то же, что и пользователь, и ответы пользователя)
Mantis, Eventum?
Хотя все это не то, если необходим хороший ITIL то только ServiceDesk Plus.
Сам занимался этой проблемой, доделав LDAP для Eventum понял что это все больше багтрекеры.
Вернулся к ServiceDesk Plus, ну сколько же там всего вкусного и ITIL и сканирование AD и просмотр софта на машине и полнйо информации о хосте и пользователе и так далее. Одно но, глаза разбегаются при его натсройке, банашльно незнаешь за что взяться.
Eventum — показался перегруженным, Mantis — честно говоря, не помню, из-за чего, возможно, не нашел, что там можно произвольный Workflow организовать — с произвольными текстами оповещений и действиями. Eventum — думаю, так же.

В результате просто взял 2 наиболее зрелые по моей оценке системы — RT и OTRS — и выбирал между ними (цель — хелпдеск для пользователей веб-сервиса — easyfinance.ru), т.е. не корпоративный хелпдеск.
В результате просто взял 2 наиболее зрелые по моей оценке системы — RT и OTRS

Почему из этих двух выбрали именно RT? Если бы делали выбор сейчас, то выбрали бы RT повторно?
При выборе они котировались примерно одинаково, точные причины не помню.

Руководствовался принципом «в первый раз взять хоть что-то»: при построении процесса 80% успеха — в дисциплине, только 20 — в удобстве инструмента, поэтому важно не искать идеальный инструмент — взять хоть какой-то и постепенно углублять использование, а когда начнет «жать», или других проблем не останется, можно выбирать заново.

Сейчас уже с точки зрения юзабилити, и зная RT, мог бы плотнее анализировать OTRS и при желании перейти, но пока насущной нужды нет — неюзабельность RT не сильно жмет.
OTRS на такая уж и панацея в виде юзабельности.
Я работал и с тем и с тем в разных компаниях. Обе системы на перле — если считать это удобством для допиливания то в этом плане они одинаковы.
Но во всем остальном каждая и хороша и плоха по своему.

Что я поставлю если надо будет выбирать? Не знаю. :) По настроению. Последний раз выбирал OTRS
Интересно было бы подробную статью по полноценной интеграции, например, с доменом Active Directory, чтобы таким решением полностью закрыть хелпдеск обычной виндовой сети.
в виндовой сети использую ServiceDesk Plus 8.0
www.manageengine.com/products/service-desk/

Демка demo.servicedeskplus.com/ (у меня правда версия постарее, но тоже выглядит не плохо )

из плюсов — очень гибкая в настройках, удобные отчеты, гибкий мастер… и т.д. )
Ну и конечно прекрасная интеграция с АД
RT легко прикручивается к AD, здесь я рассмотрел только базовую установку
Прекрасная вещь. С удовольствием используем в работе.
mod_perl вместе с RT течет как водопад. Лучше пускать в fcgi.
> у нас RT крутится в виртуалке 2x1,5Ghz и 512Mb RAM
вывод TOP:
Mem: 97M Active, 206M Inact, 83M Wired, 20K Cache, 60M Buf, 104M Free
Swap: 991M Total, 991M Free


у нас крутился на 2048 МБ, бд размером 4ГБ, в день резолвится сотня-другая тикетов, 20 очередей, 20 привилегированных учетных записей.

Поверьте мне — память течет. За недельку доходит до состояния неоперабельности.
Ну у нас не так масштабно, перелазайте на lighty + fcgi или nginx
Вы не переживайте, я все правильно сделал (с). У меня давно ничего не тормозит.
Вы бы прокомментировали, я бы в статью добавил, или сами бы написали…
2 года уже у меня работает. Конечно, под него надо разработчика держать, чтобы всякие процессы в нем автоматизировал и с системами разными интегрировал.
Что-то как-то слабовато по функциям.
Посмотрите на Manage Engine ServiceDesk plus — он подходит для ITIL, который вам, думаю, просто необходим, при такой сфере работ.
Попробуйте TeamWox — там не только багтрекинг есть. Ставится за 10 минут без шаманства с командными строками.
Бесплатный для 10 пользователей.
В нем не только сервисдеск, но и таски, документооборот (версионный + webdav), почта, чаты (включая онлайн обслуживание), crm, кадровый учет, корпоративный форум, корпоративный мультиязычный поиск, sdk и тд.

До 10 пользователей полностью бесплатный, а остальное за деньги. Есть и SaaS версия.
Увязанный со всеми сервистикетами, документами и клиентами?

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

Если иметь на каждую функцию (документооборот, сервисдеск, CRM и тд) отдельные системы, то зоопарк из софта мало кому понравится. Да, все круто по отдельности, но вместе не работает :)))
К сожалению для TeamWox нужна винда, а это тянет за собой лицензию (или ее аренду) и в некоторых случаях «отдельного админа». Именно из-за этого пришлось от нее отказаться.
Так же на отказ повлияло, что на тот момент там было очень плохо с API и нужные нам доработки сделать просто нельзя было.

Ну и — нам нужен был не SaaS
Стоимость 1 копии Windows для сервера компании — это абсолютно нормально.

Причем выделенного админа как раз не нужно по сравнению со случаями, приведенными выше — биться в рукопашную с командной строки не придется практически никогда. Тимвокс специально разработан для минимизации ручных операций по администрированию и настройке. Мы даже бесплатно для всех DNS серверы хостим в зонах *.tmwox.ru/net/com.

Сам TeamWox на 90% написан с помощью открытого TeamWox SDK. Модули задач, документов, почты, сервисдеска, организаций, контактов, банк, расчеты, продукты, форум, сотрудники, чат — все это сделано исключительно на SDK. Это доказывает, что SDK не только мощный, но и полностью отлажен за последние 3 года.

Отличительной особенностью TeamWox является то, что он работает как отдельный сервер, так и в режиме SaaS. Любой может скачать инсталлятор системы и поставить себе отдельную копию (даже DNS бесплатно предоставляется). Все версии до 10 пользователей абсолютно бесплатные.

Посмотрите еще раз на систему — наверняка понравится!
А почему вы считаете что нам надо купить лицензию на WindowsServer? Нам для работы в компании он совершенно не нужен, а покупать его ради одной «программки» как-то глупо, вы не находите?
Можете использовать любую версию Windows, начиная с XP SP2 и выше. Серверные лицензии покупать не обязательно — ничего из их дополнительных функций TeamWox не использует, только ядро.

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

Речь идет об эффектах для бизнеса, а не о точке зрения отдельного принципиального противника лицензионного софта, которого не интересуют эти самые бизнес результаты.
Почему вы считаете, что я противник лицензионного софта? Наоборот — в нашей компании весь софт лицензионный, официально купленный (ну и плюс свободное ПО. Но я против необоснованной траты денег (пусть даже это 5-6 тысяч) на что-то (лицензию) помогающее работать чему-то (тимвокс). Ибо есть куча других решений которые можно спокойно поставить на *nix системы. При этом я не говорю, что они бесплатны и мы даже используем платное решение. Но а нашем случае оно оказалось значительно лучше тимвокса на момент приобретения и принятия решения.

Надеюсь вы не станете уговаривать нас посмотреть на тимвокс опять и потратить уйму времени на переезд на него. Ибо это уже будет смешно слышать от человека столь ратующего за эффективность работы компании.
А разве кто-то заставляет всех переходить на TeamWox?

Разговор об мизерных лицензиях на Windows лучше оставить — это откровенно холиварная тема. «Куча других бесплатных уникс решений» обычно упирается в такой расход средств на конфигурирование, прикручивание и администрирование, что реально расходы будут не 5000 рублей, а все 50 000 — 100 000 на круг :)) Все это многократно пройденный этап. В этом мало кто признается, но это именно так.

Лучше расскажите, какое именно решение Вы выбрали вместо Тимвокса?
Не совсем понятен чем был обусловлен выбор именно данной системы? Есть не мало аналогов — OTRS, HP HelpDesk(могу ошибиться в название), большое кол-во платных.
Можно было бы и указать в статье что умеет, что не умеет, требуется ли напилинг и тд.
я не хочу разжигать холивар, но выбор между OTRS и RT был сделан просто после просмотра двух страниц who uses RT и who uses OTRS
рекламка сделала свое дело

p.s. так же есть печальный опыт работы с OTRS (хотя это и было более 3х лет назад, и я уверен, что система очень сильно изменилась и стала лучше, но все же осадок остался)

Чем опыт печален то был? Можете вкратце описать узкие места или действительные проблемы с которыми вы столкнулись.
я не буду сейчас говорить про эту систему, я уверен что сейчас эти проблемы у них исчезли
Я давно в Kayako влюбился, на двух предыдущих работах внедрял, обоим нравится :) Правда, щас они уже зажрались, цены под потолок накрутили. Пару лет назад Kayako Esupport Suite без ограничений по количество операторов стоил около 400 баксов.
Может не совсем в тему, но кто может вкратце дать характеристику OmniTracker'у? Стоит ли он таких денег, и есть ли достоиные аналоги ему. Нужна система именно для ITIL.
А чем он лучше при сравнении с OTRS?
Если вы сравнивали, конечно…
Пробовали RT, показался тяжелым, с кучей всего ненужного… сейчас пользуемся glpi… и внутри фирмы teamer'ом)
Only those users with full accounts are able to leave comments. Log in, please.