Привет! Меня зовут Виталий Костоусов, я работаю в команде 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). Еще разок озвучу их.
- Мониторинг всех наших микросервисов и шлюзов
- 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, который работает как хаб для серьезных инцидентов. Он занимается контролем и изменением в основных системах для исключения ошибки, которая может привести к костам бизнеса, и отвечает уже перед первыми лицами компании, предоставляя им подробные отчеты по анализу первопричин.
Поэтому, если коротко, сам процесс управления инцидентами выглядит так:
- Определяем причины произошедшего.
- Находим ответственное лицо.
- Координируем с ним усилия по максимально быстрому исправлению проблемы.
- Принимаем все нужные решения во время инцидента.
- Уведомляем об этом бизнес, доносим до них всю проблематику.
- Когда пыль рассеивается, запускаем анализ первопричин, 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-ах.
- Готовим таск для команды и мониторим выполнение задачи на продакшене.
Если вам интересны какие-то детали, смело задавайте вопросы в комментариях, мы ответим или здесь же, или отдельным подробным постом.
Автор: VikKostousov
