OTRS на прокачку в стиле REG.RU

    image

    Наверное, нет необходимости рассказывать, что такое OTRS. Многие компании используют его как средство управления услугами и для осуществления поддержки своих клиентов. История этого проекта берет своё начало аж в 2001 году. И в этом есть свои плюсы и свои минусы. Очень мощный инструмент с огромным количеством функционала практически под любые нужды малого и среднего бизнеса. Причём бесплатно. Платная поддержка только для тех, кому недостаточно базового функционала или нужна помощь в настройке.

    Об этом инструменте, который активно используется в нашей компании с 2008 года, и пойдёт речь. А точнее, о том, что с ним стало в руках нетерпеливых Perl-программистов компании REG.RU.

    Для чего мы используем OTRS?


    Да для того же, что и все остальные:
    • приёма заявок и писем (тикетов) от клиентов;
    • решения задач на основе полученных тикетов;
    • передачи сведений о багах и задач для программистов, если в тикете указали на ошибку на нашем сайте;
    • сбора статистики о количестве обращений и других метриках, позволяющих анализировать качество работы нашей техподдержки и многого другого.

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

    Немного статистики и интересных фактов


    image
    Уже давно прошли те времена, когда мы большую часть клиентов узнавали по голосу в телефонной трубке. Да-да, было такое время на заре становления, когда, услышав знакомый голос в трубке, говоришь: «Здравствуйте, Иван Иванович! Рад Вас слышать», а не дежурную фразу, и параллельно уже открываешь карточку нужного клиента, готовый выслушать новую просьбу или описание проблемы. Сейчас по многим показателям среди регистраторов и хостинг-провайдеров в России мы уже первые (ну не буду я считать Hetzner российской компанией, уж простите), а значит и количество обращений в день давно превысило объёмы, которые может удержать в голове рядовой сотрудник клиентской службы.

    За 2014–2015 годы


    • Всего создано тикетов (включая спам и системные уведомления): 2 287 701.
    • Тикетов, на которые хотя бы раз отвечали: 769 344.
    • Всего ответов по тикетам: 1 008 714.
    • В среднем ответов клиентам в день: 1 867.
    • Среднее количество ответов для решения проблемы по тикету: 1.3.
    • В среднем обрабатываемых тикетов в день: 1 424.
    • В среднем за месяц новых тикетов: 42 741.

    Количество активных тикетов по годам


    Активными считаются тикеты, созданные реальными клиентами, — не спам и не служебные автоматические уведомления.
    • 2014 г. — 799 476
    • 2013 г. — 386 604
    • 2012 г. — 118 704
    • 2011 г. — 13 886
    • до 2011 г. — 1 602

    На данный момент


    • В среднем на сотрудника приходится 8-10 ответов в час.
    • Минимальное время ответа на новый тикет — 1 минута.
    • Среднее время решения проблемы по тикету — 5-7 минут.
    • Максимальное время реакции на тикет (2015 год) — 24 часа.

    Графики за август 2015 г. по максимальному времени реакции


    Техническая поддержка хостинга




    Техническая поддержка по доменам




    Техническая поддержка облачных услуг




    Техническая поддержка по биллингу




    Кому-то эти объёмы покажутся большими, кому-то — мизерными. Но мы и не поддержка World of Warcraft ;-)

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

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

    Два года назад была произведена попытка мигрировать тогда ещё на новый OTRS 3.3, при этом сохранив все собственные наработки. Операция проходила тяжело, длилась несколько месяцев и в итоге её результат не стоил тех усилий, которые мы на это потратили. Горький опыт, но со своими плюсами. Благодаря этому опыту мы покопались практически в каждом файле OTRS, поняли, как работают многие механизмы, наметили несколько десятков мест, которые стоит отрефакторить или переписать полностью. Не обошлось и без откровенно плачевных конструкций (не наших), которые ввергали в ужас не только новичков в языке Perl и веб-программировании, но и опытных ведущих программистов. Хотя всё это вполне ожидаемо, ведь мощный продукт, который живёт уже 14 лет, не мог полностью избавиться от некоторых частей в коде, тянущихся с самого зарождения продукта.

    К этому моменту мы уже окончательно поняли несколько вещей:
    • у нас собралась команда, готовая улучшать и развивать OTRS всё своё рабочее время (2-3 человека);
    • у нас есть понимание, как должны работать такие вещи как кэш, поиск, роли etc в контексте данного инструмента;
    • нужна интеграция с другими ресурсами REG.RU для упрощения и автоматизации работы клиентских служб;
    • нам проще вручную вытаскивать полезные фишки из основной ветки OTRS и внедрять их, не поддерживая полную совместимость.


    Большие переработки


    Поиск


    Самой большой проблемой на протяжении длительного времени был, конечно же, поиск по тикетам. Вы же помните цифры из предыдущей главы? А теперь представьте, что сотрудник в поле полнотекстового поиска вводит слово «reg.ru» (или любой другой домен) для поиска по всей базе без указания диапазона дат. Вполне, кстати, обычная задачка для сотрудника. А что при этом делает OTRS на базе mysql? Она делает запрос примерно такого вида:

    SELECT * FROM ticket, article WHERE from LIKE ‘%reg.ru%’ OR to LIKE ‘%reg.ru%’ OR title LIKE ‘%reg.ru%’ OR body LIKE ‘%reg.ru%’ — и ещё несколько менее значимых полей с таким LIKE.


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

    Поэтому первой и важной доработкой стал поиск через Sphinx. Писали его мы достаточно долго, но результат был отличным. Итогом стал модуль на CPAN OTRS::SphinxSearch, который поможет таким же энтузиастам развернуть у себя поиск через Sphinx. Автор модуля, я уверен, обязательно ответит на ваши вопросы или отреагирует на найденные баги.

    База индексов Sphinx, как известно, хранится в оперативной памяти. На наши тикеты со всеми сообщениями, кроме очереди SPAM и Raw, потребовалось около 4,5 гигабайт ОЗУ. Достаточно низкая цена за моментальный поиск.

    Кроме того, сначала Sphinx работал с дельта-индексами, создаваемыми по крону: пятиминутки, пятнадцатиминутки, часовые, шестичасовые и, наконец, суточные. «Сложно и запутанно», — скажете вы и будете абсолютно правы. Кроме того, это имело несколько неприятных следствий. Во-первых, от момента появления сообщения до возможности поиска по нему проходило до 5 минут. Во-вторых, в моменты индексации сильно нагружался CPU, из-за чего весь OTRS стабильно подтормаживал, что сказывалось на производительности всех сотрудников службы поддержки.
    В какой-то момент мы вернулись к тому, от чего уходили: запросы переиндексации Sphinx вешали намертво mysql. Это нужно было срочно исправлять.

    Вторая реинкарнация поиска была уже на RealTime индексах. Она работала уже гораздо шустрее, не нагружала CPU, лишь добавляла один sql-запрос к интерфейсу Sphinx в виде INSERT или REPLACE, в зависимости от ситуации.

    Такой поиск работает у нас до сих пор. Было несколько незначительных правок в коде и только. С нетерпением ждём Sphinx 3.0, чтобы воспользоваться всеми его крутыми фишками.

    Мотивация «Решай всё подряд»


    Вторая проблема, которая волновала уже не только сотрудников, но и клиентов — это время ответа на тикет. Особенно, если вопрос был сложный.

    Раньше оценка качества работы сотрудника технической поддержки базировалась на количестве обработанных им тикетов в месяц. Это имело свои недостатки, ведь если в очереди 10 тикетов, из них 2 сложных, а 8 остальных лёгкие, то в первую очередь в работу шли самые лёгкие и зачастую не самые старые тикеты. В статистике у сотрудника красовались 8 выполненных тикетов. А пока он на них отвечал, появлялись новые лёгкие тикеты и он продолжал решать только самые несложные вопросы. В то время как сложные тикеты могли висеть часами и даже днями, пока суровый руководитель не приходил и лично не тыкал в этот, наводящий так много страха, тикет.

    Для того чтобы сотрудник имел мотивацию взять самый верхний тикет в очереди (верхний — это самый старый), невзирая на его сложность, была разработана система баллов. Честно скажу: как она используется в мотивации я не очень представляю, это всё хитрости руководителей клиентских служб. Но с программистской точки зрения было сделано следующее:
    1. Каждому тикету назначается определённое количество баллов, в зависимости от позиции в очереди. Все просчёты баллов тикета происходят в режиме реального времени для каждого сотрудника отдельно, базируясь на ролях. Чем старше тикет, тем выше он в очереди, тем больше за него баллов.
    2. За каждый взятый тикет сотруднику начисляются баллы на его счет. Если сотрудник ответил на тикет, эти баллы закрепляются за ним. Если сотрудник разблокировал тикет и не дал ответ клиенту, то начисляется штраф, в несколько раз превышающий количество баллов. Таким образом можно уйти даже в минус.
    3. В конце месяца по собранной статистике руководители определяют, кто работал хорошо, а кто не очень. И, наверное, даже дают денежные премии или выписывают штрафы.


    Данная задача, на самом деле, очень обширная и затрагивает множество небольших нововведений.

    К примеру, был добавлен так называемый пул тикетов. Приходя на рабочее место, сотрудник заходит в этот пул и сразу же (или почти сразу) для него открывается тикет, на который он должен ответить. Как только сотрудник отправил ответ на тикет, тут же открывается новый тикет из его очереди. Вот такой конвейер придумали для тикетов.

    Забавная история про то, как мы пришли к пулу
    Сразу после ввода баллов за тикеты была некоторая неразбериха. Оно и понятно: никто не знал, зачем они нужны и на что они влияют. Скажу по секрету: сами руководители ещё толком не знали, зачем они придумали эти баллы и как мы будем их использовать. Что и говорить про рядовых сотрудников технической поддержки, которым не рассказывали всё до последнего момента.

    Увидев в интерфейсе какие-то непонятные «баллы», сотрудники начали поддаваться вполне естественной панике, а потом уже на помощь пришла смекалка: «Если за каждый тикет назначают баллы, значит, чем больше баллов у сотрудника, тем лучше». Ещё хочу заметить, что система баллов была внедрена в летний период, когда по естественным причинам нагрузка на техническую поддержку снижается (клиенты в отпуске и им не до сайтов и доменов). В свете нововведения у всех сотрудников открылось второе дыхание, и они с утроенной силой стали решать задачи по тикетам и брать новые. Произошло невиданное для нас событие: очередь тикетов хостинга, в которой всегда крутилось не менее ста тикетов, опустела за два дня! Были в шоке все, включая клиентов. Скорость ответа на обращения повысилась в разы.

    Теперь перед сотрудниками встала новая проблема: тикетов нет, а баллы нужны. Что же делать? Сначала все лихорадочно нажимали F5 в ожидании нового тикета, чтобы скорее забрать его. Ведь вы помните про баллы, да? Они всё еще начисляются за успешный ответ, а выгода от баллов всё так же неизвестна.

    Особо рукастые сотрудники техподдержки решили упростить себе жизнь и не заниматься обезьяньим трудом: «Зачем мне самому нажимать F5, когда я могу заставить скрипт автоматически делать это за меня». Стали появляться первые боты, написанные на различных языках и работающие по разным принципам. В коллективе была здоровая (а временами и не очень :) ) конкуренция. Практически никто не делился своими ботами и каждый писал своего.
    Боты поражали своим разнообразием и функциональностью. Были плагины для Chrome и Firefox, были скрипты, работающие в фоновом режиме на компьютере сотрудника, были даже демоны, которые крутятся постоянно на собственной VPS сотрудника. Разнообразие языков тоже радовало: Javascript, PHP, Python.

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

    Всё это продолжалось какое-то время, но с ситуацией явно нужно было что-то делать. 5-6 ботов, каждый от 10 до 100 потоков, долбятся на наш бедный сервер OTRS. Я до сих пор не понимаю, каким образом он не падал, а кряхтел, тужился, но обрабатывал такое количество запросов.

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

    Другими словами, это уже не очередь тикетов, а очередь сотрудников. Где каждый получает ровно по одному тикету и встаёт в конец очереди в ожидании новой порции. Саму очередь с тикетами он при этом не видит, а получает только то, что выдала ему бездушная машина, не разбирая, насколько сложный или лёгкий тикет.

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

    Свой API к интерфейсу OTRS


    В процессе развития инструмента нам очень хотелось сократить время получения заявок. Стандартный способ получения тикетов в OTRS — почта. ОТRS может принимать почту по-разному. Может ходить по крону на почтовый сервер и забирать почту оттуда. Может, опять же по крону, читать почту из каталога sendmail и формировать тикеты. В любом случае время между проверками почты составляет не менее одной минуты. А по большому счёту две и более. Стандартный скрипт обработки почты достаточно тяжеловесный и на больших письмах может тратить десятки секунд на парсинг и запись в базу.

    А хотелось чего-то лёгкого, современного, молодёжного. Поэтому написали свой API, который принимает JSON, а также адекватно обрабатывает заявки с вложениями файлов.

    И тут опытный OTRS-программист меня подловит: зачем писать свой API, ведь у них есть rpc.pl? И будет в чём-то прав. API действительно есть, но мы им не воспользовались и сделали это сознательно. Одна из причин — rpc.pl работает в формате xml-rpc, а я говорил о том, что хочется чего-то современного и лёгкого. Да и по факту его разработка заняла всего несколько дней. Кроме того, наше решение позволило не только получать информацию о тикетах, но и создавать новые, вести переписку, открывать/закрывать тикеты и многое другое. Теперь для создания тикетов с сайта REG.RU мы используем этот API и времени на создание заявок тратится гораздо меньше.

    А что делать, если OTRS по каким-то причинам недоступен? Проблемы с сетью или профилактика? Тикеты клиентов не создадутся и вы потеряете все с такой любовью написанные строчки?

    На это у нас есть решение в виде очереди заданий на базе Redis. Более подробно про очередь можно почитать в презентации Ивана Соколова про FastQueue. В случае не 200-го ответа от сервера OTRS мы создаём задание в очереди и складываем в него всё содержимое письма и даже чуточку больше, а также файлы вложения в бинарном виде. В течение нескольких часов происходят попытки отправить информацию о новом тикете. Даже если были кратковременные сбои в работе серверов, за несколько часов уже всё налаживается и новые задачи приходят сотрудникам.
    Но некоторым сотрудникам и этого мало. В головах бродят идеи, как через API передавать пакеты задач.

    Теги


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

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

    Во-первых, это тег источника, т. е. откуда поступила заявка. Источников может быть несколько: с авторизованной части сайта REG.RU (пользователь залогинен в REG.RU), с неавторизованной части, через почту и ещё несколько более редких источников. Это помогает определять популярность того или иного способа.

    Во-вторых, теги участников. Каждый раз, когда сотрудник отвечает на тикет, к тикету прикрепляется именной тег участника. Это также помогает контролировать, как ведётся работа над запросами наших клиентов.

    В-третьих, есть теги уведомлений. Они позволяют быстро производить фильтрацию по письмам, которые были отправлены в автоматическом режиме. В основном к таким уведомлениям относятся предупреждения о превышении лимитов на хостинге или возросших нагрузках.

    Подтверждение e-mail


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

    Этот механизм не раз спасал нас от дерзких запросов «Переустановите мою VPS» от посетителей, которые пытаются выдать себя за одного из наших клиентов.

    Сейчас это уже доработанный инструмент, встроенный в клиентскую часть.

    Своя статистика с метриками и фильтрами


    Серьезная техническая поддержка требует использования серьезных инструментов. Чтобы можно было уследить за каждым ответом и убедиться, что он был качественным и полным, а также для того, чтобы следить за средними показателями скорости ответов, нагрузки на сотрудников, мы разработали свою статистику по тикетам в OTRS.

    Опять же, знатоки скажут, что внутри OTRS есть немало своих отчётов и можно создавать новые. Но и от этого встроенного инструмента мы отказались по множеству причин.

    Встроенные отчёты работают долго, используют всё те же LIKE при выборке, нет возможности вывести их все на одной странице. При изменении параметров фильтрации нужно ждать, пока система всё заново перестроит.

    А хотелось лёгкого инструмента с фильтрами, таблицами, графиками, гистаграммами, пирогами и другими плюшками. И чтобы они заполнялись в риалтайм и не нагружали основную базу. И чтобы был контроль доступа к ним. Да много чего хотелось. Взваливать всю эту красоту на плечи OTRS не хотелось ну никак. Вспомните к тому же, что у OTRS только с версией 4.0 (которая вышла совсем недавно) появился адекватный шаблонизатор Template::Toolkit. Предыдущий был самописный и даже не поддерживал циклов (ну ладно, поддерживал, но их предварительно нужно было написать в контроллере).

    Так и родился ещё один проект по сбору и отображению различных метрик. Среди них собираются такие данные:

    1. производительность сотрудников:
      • уникальные тикеты по сотрудникам;
      • оценка качества ответов;
      • количество ответов, переносов, заметок и т. д.;
    2. производительность отдела:
      • история загруженности очередей;
      • время и количество блокировок тикетов;
      • время реакции отделов;
    3. отчёты:
      • количество тикетов по очередям;
      • почасовое распределение нагрузки.

    И многое другое. Статистика постоянно дорабатывается и добавляются всё новые срезы и фильтры. Надеюсь, это помогает руководителям наших клиентских служб анализировать качество работы отделов в целом и отдельных сотрудников в частности.

    Jabber и SMS-оповещения


    Одно из недавних нововведений, которое наконец-то приняло приличный вид и реализацию. Идея оповещать сотрудников о срочных или важных тикетах была давно, но только недавно (в течение последнего года) мы реализовали её в форме, которая всех устраивает.

    Началось всё с введения услуги «Обратный звонок». Какое-то время нас устраивало, что заявка на обратный звонок сразу появлялась вверху списка, и сотрудник брал её в работу. Но это продолжалось недолго. Хотелось сократить время между появлением заявки и фактическим звонком.

    Для начала было реализовано оповещение в Jabber через модуль Net::XMPP на рабочие аккаунты ответственных сотрудников. Но мы столкнулись с неразрешимыми (по крайней мере пока) проблемами реализации XMPP для нашего провайдера jabber-протокола. Такие частые «бродкасты» на десяток адресатов быстро уводили нас во временный бан и уведомлений не получал никто. Было пролито немало крови, прежде чем решили от этого отказаться в пользу PUSH-уведомлений прямо в браузер.

    Теперь сотрудники, которые уполномочены позвонить клиенту и решить его проблему, в случае, если они на рабочем месте, получают уведомление прямо на экран своего компьютера и могут оперативно среагировать (перейти на страницу с тикетом, узнать подробности, нажать кнопку «Позвонить клиенту»).

    Но, помимо обратных звонков, есть ещё ряд заявок, которые должны быть обработаны незамедлительно, желательно прямо сейчас. К примеру, к таким заявкам относятся просьбы и задачи по услугам Colocation. Не всегда сотрудник, который может решить задачу клиента, находится на своем рабочем месте. Банальный пример: сегодня выходной. Для таких случаев реализовали уведомления на мобильный телефон в виде SMS, в котором указаны номер тикета, идентификатор клиента и тема сообщения.

    Такие SMS-уведомления позволили моментально реагировать на входящие срочные задачи от клиента в нерабочие время и праздничные дни. Кстати, учёт рабочего времени ведётся по календарю специально для отдела, а учёт праздничных дней — с помощью Date::Holidays::RU. Так что мы (да и вы тоже) можем быть уверены, что ни одно срочное сообщение не пробудет без внимания дольше 2-3 минут.

    Небольшие нововведения


    Мы рассказали о наиболее масштабных изменениях, но помимо них есть ещё и куча небольших доработок, которые делают работу в ОТRS удобнее и быстрее.

    Быстрый поиск ответов из корпоративной wiki
    Небольшое, но очень полезное изменение. Как вы уже заметили, очень многие инструменты, которые были доступны изначально в OTRS, мы отмели по тем или иным причинам. Не избежало этой участи и FAQ OTRS. Мы используем свою наработку для поиска и вставки быстрых ответов в нашем внутреннем FAQ на базе Mediawiki.

    Возможность смены очереди при добавлении заметки
    Совсем крохотное изменение — добавили возможность сразу поменять очередь, когда ввели заметку. Позволяет не открывать тикет два раза, а сделать всё за один подход.

    Поиск по базе клиентов REG.RU
    В карточке о клиенте в OTRS отображаем ссылку на его аккаунт в REG.RU с возможностью быстро открыть перечень его услуг. Привязка клиента и обращения идёт по нескольким параметрам, таким как e-mail, логин в REG.RU и некоторым другим.

    Разграничение доступа к очередям
    Здесь вообще вряд ли можно указать на работу программиста. Всего лишь грамотно работаем с ролями и группами, функционал которых идёт в базовой конфигурации OTRS.

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

    Двуязычные подписи, ФИО и другие параметры сотрудника
    Нам пишут не только русскоязычные пользователи, но иностранцы, которые заказывают услуги у нас или просто интересуются какими-либо вопросами. Чтобы стать ближе к клиентам, мы доработали карточки сотрудников, введя вторые поля для ФИО, подписей и некоторых других текстов, и теперь можем отправлять подписи и уведомления на более понятном для клиента языке.

    Дополнительные уведомления о состоянии работы над тикетом
    Помимо стандартных триггеров в OTRS для уведомления клиентов о состоянии тикета, добавили ещё несколько механизмов, отслеживающих состояние тикетов и отсылки почтового уведомления. Клиенты должны знать, что мы о них не забыли и занимаемся их вопросом.

    Дополнительная роль «тим-лид» — администратор с ограниченными правами в рамках своего отдела
    С ростом компании росла и техническая поддержка. И не только в профессиональном, но и в количественном аспекте. Когда сотрудников стало достаточно много, стало ясно, что придётся менять иерархию внутри отдела. Будут те, кто отвечает клиентам, а будут руководители и лидеры, которые помогают новичкам в решении тех или иных задач. Для таких лидеров мы создали урезанную версию администраторских прав на OTRS, которые позволяют только управлять ролями внутри своего отдела.

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

    Звонки из ОТRS клиентам (как мы работаем с SIP-телефонией)
    Одна из моих любимых фишек. В OTRS работают не только сотрудники хостинга, но и все остальные клиентские службы. К примеру, они занимаются консультацией новых и старых партнёров. Для оперативной связи с клиентом у определенной роли есть специальная кнопка «Позвонить клиенту». Нажав на эту кнопку, сотрудник сразу же соединяется с клиентом по номеру телефона, указанному в карточке клиента. Здесь используется Asterisk Restful Interface (ARI) для соединения внутреннего номера сотрудника с номером клиента.

    Помните, что говорит милый робот в трубку? «В целях улучшениях качества обслуживания все разговоры с оператором записываются». Так вот, это не шутка. Мы действительно записываем звонки, а бдительные руководители периодически прослушивают нужные разговоры, оценивают качество и полноту ответа, и принимают меры, если сотрудник где-то ошибся или повёл себя некорректно. Данные о звонках также идут в статистику, про которую я писал выше.

    Кэш на Redis
    Стандартный кэш в OTRS подразумевает хранение его в файлах. А если очень долго не чистить кэш на файлах (есть специальный крон-скрипт), то очень быстро на сервере закончатся все inode и работа сервера встанет. Кроме того, в некоторых случаях с лёгкой руки крон-скрипта мы не можем очищать папку с кэшем.

    Поэтому мы перевели хранение кэша на Redis. Это, во-первых, ещё немного ускорило работу всей системы в целом. А во-вторых, позволило нам более гибко и тонко настраивать механизм кэширования. К слову сказать, реализация заняла всего один рабочий день. Базовый механизм кэша OTRS на Redis был найден в Интернете (готовый модуль), оставалось только протестировать его и сделать несколько корректировок в коде под наши реалии.

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

    LDAP-синхронизация агентов
    Также подключили LDAP-синхронизацию с нашим внутренним сервисом авторизации. Опять же, есть готовый модуль в OTRS, но его функционал не позволял нам сделать всё задуманное. К тому же теперь сотрудникам не приходится вводить свои реквизиты для доступа к OTRS.

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

    Мелочи SQL-жизни
    Тут сложно выделить что-то конкретное, но в целом за весь период активного развития платформы было оптимизировано немало таблиц. Добавлены недостающие индексы, удалены лишние поля (остатки после обновления версии), оптимизированы многие запросы.

    Результаты


    Очень сложно мне написать о результатах, но всё же попробую. За пару лет активной разработки и поддержки платформы было оптимизировано немало внутреннего кода, написаны десятки новых контроллеров, оптимизированы многие страницы. Список задач в нашем баг-трекере с запланированными изменениями и ещё не взятыми в работу никогда не пустеет. В работе параллельно находится от 2 до 5 задач по улучшению, автоматизации, интеграции с другими ресурсами. Кроме того, не стоит забывать про технический долг и тикеты-рефакторинги, которых у нас уже тоже порядочно накопилось, но мы не можем за них взяться по причине нехватки времени. Воистину неисчерпаемы идеи в головах руководителей наших клиентских служб! На каждую реализованную задачу приходят две новые. Спасибо им за это.

    Благодаря нововведениям удалось существенно ускорить время реакции на тикеты. До них клиент мог ждать ответ на свой вопрос сутками и не факт, что он ещё оставался нашим клиентом, когда получал запоздалый ответ. Теперь же в большинстве случаев клиент получает ответ в тот же день.

    Кратко о планах


    Многие части нашего кода достаточно грубо вторгаются в экосистему OTRS. Хотя мы и отказались от перехода на новые релизы проекта, использовать новые нужные фичи мы всё же хотим. Для этого мы в обозримом будущем собираемся переводить весь наш код из ядра OTRS на EventHandler, который дал бы нам более модульную структуру наших изменений.

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

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

    Где самое важное?


    Уверен, многих наших клиентов последние несколько месяцев волнует вопрос: «Куда вы спрятали клиентскую часть ОТRS и где мне посмотреть все свои тикеты?». Действительно, было очень много жалоб на то, что мы скрыли такой важный раздел от всех клиентов, и мы этого не могли не заметить.

    На самом деле мы осознанно пошли на такой шаг, и всё это время активно разрабатывали новую, современную, быструю, безопасную клиентскую часть. Немало времени ушло на её тестирование и «допиливание напильником». Это один из наших самых больших «долгостроев» для OTRS. Ни одна другая фича не занимала у нас так много человеко-часов во всех задействованных отделах. Где-то мы просчитались по срокам, где-то было переосмысление концепции и, следовательно, переписывание отдельных частей кода с нуля. Но я надеюсь, всё это мы делали не зря.

    Сегодня уже доступна новая клиентская часть для OTRS, которая позволяет следить за всеми тикетами, писать ответы, прикладывать файлы и уведомлять о сообщениях. Сейчас она вшита в интерфейс REG.RU и доступна в Личном кабинете. Теперь всё общение клиентов и техподдержки происходит именно через неё, а на почту приходит только ссылка для перехода в тред.

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

    Весь процесс общения между клиентской частью и OTRS происходит через то самое внутреннее API, про которое я уже рассказывал, что снова даёт нам прирост в производительности и удобстве обслуживания.

    Благодарности


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

    Статья является коллективным творением Chips, banaking, shikin, imir. Спасибо всем, кто принимал участие в подготовке и сборе материала, вычитке и контроле фактической точности. А также всем тем, кто реализовывал все эти нововведения.
    REG.RU
    Каждый день мы делаем Рунет лучше! Вы с нами?
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 28

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

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

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

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

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

              Чо?

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

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

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

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

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

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

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

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

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

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

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

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

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

                Я нигде не сказал «удалить». Хотя давай будет откровенными — весь этот мусор уже через год никому не нужен. Вспомни как мы с 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 вы можете посмотреть вот тут».
                  0
                  > А да, забыл эпик вин с Jabber. Опять же — что не так?

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

                            P.S. спасибо за инвайты.
                              0
                              Спасибо за ответ, желаю успехов!

                          Only users with full accounts can post comments. Log in, please.