Хабрахабр

Поддержка в 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, кликабельно

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

R&D RCA 2.

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

Действия 3.

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

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

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

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

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

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

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

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

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

Если вам интересны какие-то детали, смело задавайте вопросы в комментариях, мы ответим или здесь же, или отдельным подробным постом.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть