Наверх ▲

Высоконагруженный сервис - высоконагруженная служба поддержки

Николай Кондратов Николай Кондратов Технический руководитель почтовой службы Mail.ru.

Николай Кондратов: Здравствуйте! Меня зовут Николай Кондратов (компания “Mail.Ru”). Я отвечаю, в том числе, за службу поддержки.

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

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

 

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

Если попробовать применить этот цикл к построению «живой» службы, то на этапе требований все понятно. Определяем бизнес-требования, метрики, которым должна соответствовать служба, ее потребность в масштабировании, надежности и резервировании.

На этапе проектирования мы выбираем структуру, программные продукты и инструменты, которые будем использовать.

Разработка – это набор и формирование команды, а также разработка или доработка тех инструментов, которые  будем использовать.

В нашем случае отладка - это, скорее, аттестация команды и тестирование инструментов (в том числе нагрузочное).

Этап внедрения – это запуск службы и принятие потока входящих заявок.

Оптимизация – это пересмотр бизнес-процессов по итогам запуска, их корректировка и доработка инструментов.

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

Начнем с требований. На этапе проектирования службы поддержки требования у нас были следующие.

  • Служба должна была выдерживать не менее 20 тысяч входящих запросов в день (в данном случае - писем).
  • Были определены некоторые бизнес-метрики для службы. Я не буду на них детально останавливаться. Это, например, время жизни заявки, процент обрабатываемых заявок в заданные промежутки времени и так далее. Их достаточно много.
  • Масштабируемость. Причем географическая масштабируемость, в том числе. Для нас было важно, чтобы служба была построена таким образом, чтобы ее можно было географически распределять.
  • Отказоустойчивость. В нашем смысле мы понимаем, что это - отсутствие «узких» мест (как в бизнес-процессах, так и при использовании инструментов).
  • Резервирование – это некий запас производительности, кадров и инструментов, которые помогают справляться со всплесками нагрузки. 

Итак, начинаем с проектирования архитектуры. Естественно, мы проанализировали запросы, которые к нам приходят. Обнаружилось, что, в принципе, входящие запросы очень легко укладываются в известное правило Парето: 80% результата может быть достигнуто 20%-ми усилий.

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

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

Дальше мы выбираем программные средства. Проанализировав аналоги,  используем в качестве системы обработки заявок OTRS. Это система с открытым исходным кодом, построенная на Perl и MySQL. Perl мы в Mail.Ru очень любим. Это был один из хороших аргументов в пользу системы. Она много где используется, в том числе в Яндексе.

Какие ее основные преимущества? Во-первых, конечно, веб-интерфейс. Сотрудник не привязан к рабочему месту.

Вся переписка собирается в цепочки. Это означает, что вся переписка по конкретной проблеме (письмо пользователя, наш ответ ему, следующее письмо) собирается в тикет. В терминах систем обработки заявок это называется «тикет». У него есть уникальный номер. Вся информация, которая необходима (например, письмо, ответ, заметки сотрудников, флаги), все, происходящее с тикетом, находится в одном месте. Это очень удобно.

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

Также существуют развитые механизмы шаблонов, которые можно настраивать как угодно.

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

Плюс в «коробке» уже были довольно хорошие средства для отчетов и мониторинга. В общем, система весьма хорошая. Кому интересно заходите на сайт www.otrs.org.

Переходим к отказоустойчивости и резервированию. Если говорить об отказоустойчивости, это отсутствие «узких мест». Что мы для этого делаем? У нас обучение построено таким образом, что сотрудник может перемещаться между группами. Речь идет о второй линии. Это позволяет в случае увеличения нагрузки гибко варьировать количество людей в группах. Благодаря этому, у нас всегда существует кадровый резерв. Работа организована по сменному графику.

Еще один важный момент – это резерв рабочих мест, чтобы можно было сразу безболезненно увеличить состав группы, если это необходимо.

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

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

Этап разработки включает в себя набор и формирование команды. Но я не буду об этом долго рассказывать. У меня был доклад на «Whale Rider». Если кому-то интересно, то найдете презентацию.

Основная часть разработки – это усовершенствование OTRS. На момент старта, мы работали с версией 2.2.6. Сейчас вышла уже 3-я версия - достаточно старая по текущим меркам.

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

Что было изменено в OTRS?

Начнем с поиска. Прежний поиск был реализован просто запросами по базе. Это очень медленно и неудобно. Поэтому для начала мы переделали поиск и прикрутили Sphinx. У нас двухэтапная индексация. Каждую ночь происходит индексация всей базы и раз в минуту – инкрементальная индексация изменений.

Следующий этап – это запросы. OTRS «из коробки» использует собственное ORM. При всех плюсах у ORM есть очевидный минус. Это решение - медленное. Особенно в плане осуществления выбора. Структура базы такова, что для того, чтобы вытащить информацию по тикету, приходится делать серию join, которые не всегда хорошо и просто там работают.

Поэтому начали отбирать из ORM основные запросы. Это позволило ускориться при работе с базой.

Переделали интерфейс и «прикрутили» AJAX, где было возможно.

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

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

Поэтому начали делать кэширование. Мы использовали memcached. Один раз собранный тикет помещали в memcached в виде JSON-объекта. Дальше работали только с ним. Если его статус менялся (например, на него отвечали), он просто удалялся из кэша. Это позволяло составлять список только 1 раз. Дальше любые перемещения по списку и другие операции происходили очень быстро.

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

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

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

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

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

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

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

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

Что хочется рассказать о внедрении? Так же, как и в нагруженных системах, важен плавный пуск. 100% нагрузки давать также нельзя. Как в нашем случае это обеспечивали мы. Когда мы переносили службу, сотрудники в Москве и Нижнем Новгороде работали параллельно. Мы постепенно наращивали нагрузку, передавая поток нижегородской службе. Естественно, очень важно внимательно следить за тем, что происходит при увеличении нагрузки.

Этап оптимизации предполагал проверку многих процессов. Больше всего изменения коснулись интерфейсов первой линии.

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

Мы отслеживали движения мышки, частоту операций. Частота операций – это статистика выполнения тех или иных действий, переходов по ссылкам. Естественно, выслушивали предложения сотрудников, потому что это очень хороший канал обратной связи. Людям, которые работают с интерфейсом постоянно, сразу видно, что неудобно.

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

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

Что касается интерфейса, то он был полностью написан на AJAX. Самое главное – у человека нет списка тикетов. Каждый тикет ему приходит по-одному. Это позволяет экономить время на том, чтобы выбрать тот самый тикет, который я хочу сейчас обработать. Открывается все время один.

В первой версии тикеты каждый раз подгружались. Это здорово тормозило процесс. Мы сделали кэширование. Прямо в интерфейс загружаются подготовленные 100 тикетов в виде JSON-объектов со всеми флагами, текстами и так далее. Дальше человеку уже не нужно ждать тикета от сервера. Они у него уже есть. Это не очень большой «перегруз» в плане памяти и торможения браузера. Асинхронно по мере ответов на тикеты происходит их подгрузка.

Использование полного AJAX также весьма полезно.

Что такое подсказки? Это возможность на уровне фильтров подсказать сотруднику, какое действие надо произвести с определенным тикетом. Подсказки помогают избежать банальных ошибок.

Больше психологический момент – это наличие показателя производительности. Человек видит уровень своей производительности и насколько она отличается от среднего значения в группе. Это своего рода «морковка», которая стимулирует его работать.

Что является объектом мониторинга? Мы отслеживаем динамические параметры. Это динамика входящих потоков, состояния очередей и произведенных операций, разделенная по группам, типам и так далее.

Есть набор статических показателей. Это либо временные срезы (например, на границе суток), суммарные срезы (например, суммарное количество тикетов, обработанных в определенной очереди, в определенной группе) и различные статистические срезы (например, среднее время обработки тикетов в одной очереди). В действительности статистических показателей гораздо больше.

Как осуществляется мониторинг? Как я уже говорил, в OTRS была ORM (она осталась). В основном нас интересовали селекционные запросы. Все изменения по-прежнему происходили через ORM. Соответственно, в ORM было легко осуществить встраивание, чтобы учитывать каждое действие по тикетам.

Соответственно, у нас ведется учет каждого действия и по заявке, и по действиям оператора. Включая изменения флагов, статусов. Это позволяет вести разного рода статистику.

Как обрабатываются данные? Мы используем графики в реальном времени, такой инструмент, как graphite. Сейчас я про него чуть-чуть расскажу. По статическим данным готовим разнообразные отчеты — уже по базе.

У нас есть пороговые значения. При превышении неких заданных показателей к нам приходит уведомление (в том числе по СМС).

Graphite - это отличный инструмент для отображения динамических данных. Чем он хорош? Он очень прост. Он состоит из двух компонентов. Мы по очень простому текстовому протоколу передаем буквально значение, метку времени и тип, название параметра. На другой стороне - демон на Python, который собирает данные, кэширует их и складывает в собственное RRD-подобное хранилище.

Есть клиентская часть, веб-интерфейс, который очень удобен тем, что у него есть возможность работать в командной строке. Можно очень легко, не прибегая к помощи серверной части, получить любые графики, комбинации, срезы по времени и так далее. Плюс – у него есть функция обработки данных. Графики можно суммировать, преобразовывать.

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

Что дал нам новый подход? Служба поддержки была развернута меньше, чем за полгода. Всем исходным требованиям (имеется в виду бизнес-требованиям) она отвечает. Прогресс по спирали позволяет постоянно наращивать новый функционал.

Сейчас, например, мы движемся к следующему этапу. Мы его называем «поддержка 2.0». Это возможность интеграции в единый процесс поддержки наших смежных проектов.

Если есть вопросы, рад буду на них ответить.

Вопросы и Ответы

Вопрос из зала: Добрый день! Илья Чесноков, компания “Reg.Ru”. Мы тоже используем OTRS и недовольны его медленной работой. Скажите, пожалуйста, вы вносили какие-либо изменения в третью версию?

Николай Кондратов: Третья версия, к сожалению, пока только в планах. Мы используем версию 2.2.6.

Вопрос из зала: Вы не планируете устанавливать обновления?

Николай Кондратов: Планируем.

Вопрос из зала: Вы не планируете выложить разработку в открытый доступ? Хотя бы часть, конечно.

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

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

Вопрос из зала: Понятно. Все слишком специализированно. 

Николай Кондратов: Тот продукт, который есть у нас сейчас, основывается на OTRS, но во многом он уже «заточен» специально под нас.

Вопрос из зала:  Вы говорите, что рассмотрели достаточно много систем типа OTRS (тикет-систем). Рассматривали ли вы RT (Request Tracker)?

Николай Кондратов: Да, но сделали выбор в пользу OTRS. На тот момент он показался легко поддерживаемым с точки зрения изменений.

Вопрос из зала: Вы сказали, что у вас новые заявки автоматически назначаются на человека, который работает в этот момент времени. А если работает несколько человек?

Николай Кондратов: В смысле?

Вопрос из зала: У вас первая линия обрабатывает 60% потока. Группа – это несколько человек. Первая линия – это тоже, наверное, несколько человек.

Николай Кондратов: Безусловно. В службе сейчас порядка 60-ти человек.

Вопрос из зала: Как в первой линии определяется, кому направляется заявка?

Николай Кондратов: Методов может быть много. Главное – равномерное распределение. Сейчас Васе, потом – Пете, потом…

Вопрос из зала: Чтобы у каждого было одинаковое количество заявок? Как учитывается, кто как работает?

Николай Кондратов: Не учитывается. Существует некий средний показатель. Получается примерно одинаково. Это просто рандом по весам.

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

Николай Кондратов: Про формирование команды я рассказывал на Whale Rider очень подробно.

У нас существует внутренняя информационная система. Новые люди проходят многоэтапное обучение. Они не просто что-то читают, а садятся за рабочее место и начинают отвечать. Они попадают исключительно на первую линию. Дальше по результатам работы их могут перевести на вторую линию. 

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

Вопрос из зала: Скажите, как у вас происходит эскалация со второй линии в разработку, интеграция с Jira, Bugzilla и так далее?

Николай Кондратов: У нас в разработке используется Jira, это правда. Эскалация происходит следующим образом: только вторая линия может давать соответствующие задания. Может быть, вы уточните вопрос?

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

Николай Кондратов: Через постановку задач в Jira. 

Вопрос из зала: Тикет-система интегрирована?

Николай Кондратов: В этом смысле нет. Очень маленькое количество запросов необходимо переводить в задачи. Есть обратная связь. Есть в Jira отдельные поля, которые можно привязывать к тикетам, чтобы исполнение задачи можно было связать с пользователем.

Вопрос из зала: Просто у нас есть еще третья линия поддержки.

Вопрос из зала: У вас нет автоматизации: когда запрос пришел и ответ на него получает тот, кто его направил?

Николай Кондратов: Можно считать, что у нас в системе помощи некая автоматизация присутствует. Когда человек "идет" по некоему ведущему серверу, ему предлагаются ответы. Стандартный подход. Он проходит глубже, глубже. Здесь его не устроил ответ, тут непонятно, там не помогло. В конце у него есть возможность написать в службу поддержки. Автоматических ответов нет.

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

Вопрос из зала: У меня вопрос немного философский. По поводу того, как вы модифицировали OTRS. Откуда такая нелюбовь отдавать назад свои наработки в upstream?

Николай Кондратов: Нелюбви никакой нет.

Вопрос из зала: Просто интересно установить последствия... Для вас сейчас переход на третью версию будет гораздо более болезненным.

Николай Кондратов: Переход должен быть чем-то обоснован.

Вопрос из зала: Вы же видели список новых разработок? Наверняка, там есть что-то "вкусное" для вас.

Николай Кондратов: Действительно, видели "вкусные" вещи, но опять же: будем тестировать – будем понимать. Для нас основной проблемой была медленная работа. Тяжелая работа с хранением данных. По сути, нет никакой нелюбви в отдачи разработок обратно в сообщество. Если бы мы исправляли какие-то ошибки, например…

Вопрос из зала: Решение проблемы медленной работы – это полезно для сообщества.

Николай Кондратов: Оно нарушает идеологию исходного продукта. Из одного продукта получаем другой.

Вопрос из зала: Идеология сходного продукта была медленной, и ее трогать не надо.

Николай Кондратов: Идеология предполагала использование ORM (если говорить об ORM), который использовался везде, во всех запросах, существовала определенная структура хранения. По нашему мнению, этот продукт прекрасно работает с другими нагрузками. Он отличный - сам по себе. Его не надо менять, если у вас до 1 тысячи тикетов в день. Он будет работать отлично, если у вас не работает 50 человек с этим продуктом одновременно. 

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

Вопрос из зала: Ок, верю.

Вопрос из зала: Скажите, пожалуйста, как вы осуществляете мониторинг? Ведь заявки обрабатываются правильно? 

Николай Кондратов: Oк. Существует механизм проверки ошибок. Осуществлять мониторинг в автоматическом режиме довольно сложно. У нас используются несколько другие наработки. Руководитель производит обязательную проверку – слепую выборку. Когда сам сотрудник видит неправильную обработку на предыдущем этапе, он может зафиксировать факт ошибки. Понятно, что это происходит анонимно. Вася не узнает, что Петя нашел его ошибку.

Плюс существуют некие метрики, которые косвенно могут показывать наличие ошибок. Некоторые ответы требуют ответа пользователя. Например, уточнение: «Какой у вас браузер?» или «Какой почтовый клиент вы используете?» А есть ответы, которые не требуют обратной реакции. Например, мы просто сообщаем, как решить ту или иную проблему.

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

Вопрос из зала: Немного странный вопрос. У вас вся поддержка работает через e-mail?

Николай Кондратов: Да.

Вопрос из зала: Проблема спама есть?

Николай Кондратов: Когда, грубо говоря, автоматические рассылки попадают в ящик службы поддержки?

Вопрос из зала: Да.

Николай Кондратов: Большой проблемы в этом нет. Во-первых, это не 80% потока, а намного меньше. Во-вторых, у нас используется особый инструмент. Естественно, мы не фильтруем спам, иначе люди не смогли бы нам жаловаться на недоставку своих писем в случае ошибки срабатывания спам-фильтра. Но спам-фильтр, на самом деле, есть. Он просто метит эти письма. Сотруднику на первой линии легче принять решение, спам это или не спам.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Григорий Кнеллер

Григорий Кнеллер

Независимый системный консультант, Германия. 15+ лет в ИТ-индустрии. Прошел через разработку, поддержку и топ-менеджмент.

Опыт построения простой в использовании системы учета рабочего времени. Идеи Глеба Архангельского в действии.

Олег Илларионов

Олег Илларионов

Разработчик социальной сети ВКонтакте.

Олег Илларионов (ВКонтакте) рассказывает об изменениях принципов работы с вебом и отвечает на вопросы о самой популярной российской соцсети.

Денис Бугров

Денис Бугров

Директор в QuattroLab.

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