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

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

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

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

Да для того же, что и все остальные:

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

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

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

Уже давно прошли те времена, когда мы большую часть клиентов узнавали по голосу в телефонной трубке. Да-да, было такое время на заре становления, когда, услышав знакомый голос в трубке, говоришь: «Здравствуйте, Иван Иванович! Рад Вас слышать», а не дежурную фразу, и параллельно уже открываешь карточку нужного клиента, готовый выслушать новую просьбу или описание проблемы. Сейчас по многим показателям среди регистраторов и хостинг-провайдеров в России мы уже первые (ну не буду я считать 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. Спасибо всем, кто принимал участие в подготовке и сборе материала, вычитке и контроле фактической точности. А также всем тем, кто реализовывал все эти нововведения.