Поддержка в Gett. Как мы делаем так, чтобы всё работало

    Привет! Меня зовут Виталий Костоусов, я работаю в команде Global Tech Heroes, и сегодня я расскажу вам о саппорте — об одной из самых важных составляющей любого сервиса. Можно сделать отличное приложение с прикольными картинками и иногда адекватно шутящими чат-ботами. Можно откровенно демпинговать, на первых порах предлагая клиентам сервис по заниженной цене. Можно нанять прекрасного SMM-щика, за которого не будет стыдно и которого не придется менять так же часто, как бухгалтера в 90-х.

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



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

    Сейчас мы работаем в 3 странах: Россия, Великобритания и Израиль, и у нас сотни тысяч активных пользователей, одних только корпоративных клиентов более 20 000. Ежедневных запросов к нашим приложениям, как вы понимаете, хватает. А еще есть водители и запросы от них. А еще внутренние системы и мониторинг. Все это должно работать, и работать хорошо. Для этого у нас есть команда глобальной технической поддержки, именуемая внутри “Tech Heroes” — команды R&D, операторы и инженеры по эскалации, а также Global Incident Manager. И вот с чем они сталкиваются в работе.

    Команда и пользователи


    Сразу оговоримся, что под конечными пользователями нашей команды подразумеваются не только клиенты и водители, которые в приоритете (как частные, так и корпоративные), но и маркетинг, служба поддержки и наши внутренние департаменты. Само собой, в саппорт они пишут или с помощью приложения, или в социальные сети. Если проблема именно технического характера, то задача внутри SalesForce сразу отправляется к нам. Могут писать не только о приложении и качестве его работы в целом или каких-то функций в частности, но и о работоспособности внутренних сервисов компании. Есть более 1000 сотрудников Gett, которые задают вопросы о рабочем софте, организации процессов.

    В нашей команде 8 человек, распределенных по трем странам — Израиль, Великобритания и Россия. Специалист из России работает удаленно, в его обязанности входит работа с операционными процессами: контроль и внесение изменений в наши основные сервисы. Остальные семеро занимаются и операционными вопросами, и многим остальным: тестированием, багами, спецификациями, оперативно решают обращения, которые поступают со стороны операционных специалистов и менеджеров, а также мониторят все наши БД, сервисы и микросервисы. Эта команда обрабатывает все тикеты, из какой бы страны они ни прилетали. По большей части работать приходится с локальными проблемами, но бывает такое, что находится какой-то серьезный баг в работе глобальных сервисов, тогда работа переходит в режим Global.

    Еще нужно учитывать, что у нас много b2b-клиентов по миру — в системе заложены очень гибкие настройки и возможности бизнес-интеграции с сервисами компании. То есть классов авто намного больше, чем видят частные пользователи сервиса. Важно понимать, что все это влияет как на работу сервисов, так и на количество транзакционных операций. B2B-сегменту доступно использование личного кабинета на сайте компании.

    Софт


    Для работы с тикетами на рынке существует несколько систем, которые уже доказали свою полезность: LiveAgent, ZenDesk, ZohoDesk и другие. Можно выбирать по удобству, можно по привычке, можно — отталкиваясь от того, с каким софтом работают коллеги, дабы не городить кучу прослоек и костылей (которые тоже придется поддерживать и допиливать). Поэтому мы работаем на SalesForce, так как его используют основные операционные направления компании (продажи и поддержка). Это позволяет отслеживать статус каждого кейса со стороны его создателя. Есть автоматическая приоритезация кейсов на основе тематик обращений. А еще SalesForce интегрирован в Jira и, если создан таск или заведен баг в разработку — его статус также отображается в кейсе. Так мы добиваемся прозрачной коммуникации между Поддержкой и Разработкой


    SalesForce, кликабельно

    Выделенная система заявок позволяет отслеживать SLA для каждого тикета, поступающего к нам.

    Тикеты и запросы


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

    Мониторинг


    Мониторингов у нас много. Как только один из них срабатывает, будь то newrelic (работоспособность системных служб), grafana (мониторинг конкретных сценариев), datadog (работоспособность компонентов инфраструктуры), нам сразу падает уведомление в Slack и мы по очереди получаем звоночек (спасибо pagerduty). И на определенный период времени назначается один дежурный. Так как это происходит автоматически, то есть вероятность, что именно этот назначенный человек прямо сейчас недоступен или просто не ответил, тогда звонок переадресуется дальше по цепочке.

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

    Поэтому мы всегда онлайн.

    Управление инцидентами


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

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

    Цель — узнавать о проблемах на нулевых стадиях. Это когда о проблеме узнал именно ты как сотрудник, обеспечивающий работоспособность. А не когда тебе о ней сообщил клиент. Поэтому мы активно используем инструментарий APM (Application Performance Monitoring). Еще разок озвучу их.

    NewRelic

    • Мониторинг всех наших микросервисов и шлюзов
    • 50x, 4xx errors
    • Redis Apdex
    • DBs Apdex


    NewRelic, кликабельно

    Grafana. Events monitoring (дает понять что именно перестало работать или поведение отличается от нормального).


    Grafana, кликабельно

    DataDog. Мониторинг аппаратных компонентов нашей системы (БД, балансировщики нагрузки).


    DataDog, кликабельно

    AirBrake. Code Exceptions for apps / microservices (есть список исключений, например, при исполнении кода или запросов в базе, если что-то идет не так и это есть в списке – мы это отслеживаем).

    Kibana — мониторинг логов микросервисов / приложений (водитель / клиент).

    А чтобы все работало не только на обнаружение, но и на своевременное оповещение (тут же чем быстрее — тем лучше), все это связано с рядом каналов уведомлений, от Slack и PagerDuty до старых добрых уведомлений по email. Поэтому о любых аномалиях узнает сразу вся команда. Оповещения можно отправлять в разные каналы. Критичные для работы приложений мониторинги всегда отправляют алерты в команду техсаппорта и выборочно в каналы команд разработки, ответственных за конкретные фичу / сервис. Все это способствует оптимизации временных затрат на реагирование

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

    Поэтому мы создали удобный каталог с перечислением всех service owner-ов (вообще по всей компании). Как показала практика, одно это помогло нам сократить время решения каждого инцидента примерно на 20%.

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

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

    Поэтому, если коротко, сам процесс управления инцидентами выглядит так:

    1. Определяем причины произошедшего.
    2. Находим ответственное лицо.
    3. Координируем с ним усилия по максимально быстрому исправлению проблемы.
    4. Принимаем все нужные решения во время инцидента.
    5. Уведомляем об этом бизнес, доносим до них всю проблематику.
    6. Когда пыль рассеивается, запускаем анализ первопричин, RCA (Root Cause Analysis).

    Отчеты об инцидентах мы строим в Jira, есть соответствующий модуль, Incidents, мы вписали туда еще ряд дополнительных полей.

    Этапов RCA всего три.

    1. Первоначальный RCA

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

    2. R&D RCA

    Самая важная часть процесса, надо заполнить в течение 48 часов после завершения инцидента. Здесь уже полный технический анализ первопричины — почему это случилось, почему не было обнаружено (проглядели тестировщики или нет соответствующего мониторинга), есть ли вероятность, что повторится, и что сделать, чтобы не повторялось.

    3. Действия

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

    Вот так мы в Gett работаем с инцидентами.

    Цифры и технологии


    Работаем, само собой, 24/7 с SLA 99.99%. Основной стек у нас на GoLang / Ruby, это дает необходимую скорость обработки сложных алгоритмов. Микросервисов суммарно более 150, и все они тоже на GoLang и Ruby. В качестве баз данных используем MySQL, Postgres, и Presto. Хранилище у нас на AWS.

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

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

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



    Нет, не то. Вот:

    • Проверяем данные в сервисах, логи и аудиты.
    • Тестируем и проводим операции обновления на Scrum-ах.
    • Готовим таск для команды и мониторим выполнение задачи на продакшене.

    Если вам интересны какие-то детали, смело задавайте вопросы в комментариях, мы ответим или здесь же, или отдельным подробным постом.
    Gett
    37,76
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 11

      0

      Спасибо.
      Подскажите, что у вас с картами? В Петербурге около 2х лет не обновляете.
      Каждый раз бегаю по округе и ищу водителя которого тянет к соседнему дому. Комментарии водители, конечно, не читают.

        +1
        Мы работаем с картами Google / maps api. Т.е. адреса нет именно там. Можно написать о поддержке в приложении или в сетях и наши коллеги из клиентской поддержки добавят адреса, либо, зайтйи в апп google maps и добавить адрес (через приложение почему-то это реализовано более удобно, хотя на картах Google такая возможность тоже есть)
          0

          Спасибо, попробовал добавить.
          Жаль конечно, что у партнёра такое время реакции.

            0
            Россия большая, Google в России не такой большой, но дает возможность внести изменения на карты. Добавив свой дом Вы как минимум помогли не только себе — всем жителям дома, и сервисм, котрые так же используют карты Google. От себя как минимум Спасибо

            Проблемы есть, но те, кто не знает как это делать — всегда могут написать в службу клиентской поддержки.
        +1

        А кто у вас занимается разработкой и сапортом gettpartner.ru и API для партнёров? Там реализация и фидбэк такой, что пользоваться вообще никаких сил нет. Вам бы с теми парнями пообщаться, опыт передать, что ли.

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

          Спросил коллег, вернусь к вам с личным сообщением в робочее время. А за обратную связь спасибо, всегда рады
          0
          Немножко оффтопик, но раз других постов про Gett особо нет, спрошу тут.
          Есть ощущение, как у пользователя, что приложение не особо обновляется. Т.е. технически оно обновляется — от 28 мая апдейт с какими-то правками по дизайну, но ux застрял там, где он был три-четыре года назад, функционал по сравнению с конкурентами очень страдает.
          Есть какие-то глобальные планы по развитию приложения?
            0
            Вот этот блог — шаг стать немного ближе к подобным обсуждениям в России в проф среде. Я могу с уверенностью сказать, что изменения есть, например, UI поиска такси и информации о заказе изменился координально, кроме того, есть водители и для них так же стараемся выкатывать большое количество фичей. Делать изменения ради изменений — не самое продуктивное занятие. Мы всегда стараемся учесть замечания и комментарии на разных платформах, так что при наличие адекватных предложений будем и их учитывать тоже.

              0
              Можно изменения ради конкуренции, а не ради изменений. Поделюсь двумя частыми кейсами, когда я хотел бы воспользоваться Gett, но не могу и, соответственно, пользуюсь другим приложением
              1) Два адреса — нужно или подобрать человека по пути или развести по 2 адресам из одного места (пять раз в неделю и чаще)
              2) Очень запоздалое обновление карт (3 года и больше ). Нет адреса на карте — можно колхозить в комментарии, вызывать, условно но Ленина 13, а в комментарии писать 13а, но не хочется.
                0

                Поддержу ваш комментарий… Хотелось бы дополнительных опций при заказе: указать, что нужна машина с кондиционером, или с детским креслом, или обязательно с пустым багажником… Так и не нашёл, где это делается… И так и не понял, на что влияют баллы лояльности...

                  0
                  ох, сорри, немного упустил из виду блог в отпуске)

                  1 — классно, когда можно не просто ввести 2 адреса, но и разделить поездку по стоимости автоматически. По-настоящему это у нас есть как carpool решение, в России его использовать не получается, если честно, не помню точно причину, однако, это что-то локальное на уровне вопрсов законодательной части.

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

                  2 — ну тут больше зависит от Google Maps team, как объяснял в комментарии ранее. Если адреса нет, то можно просто написать нам в поддержку в приложении, наши коллеги обязательно добавят адрес.

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое