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

Мы выросли с 2 сотрудников до 88 менее чем за шесть лет и с 2 клиентов до 800. Наша общая цель — стать следующей компанией-единорогом 🦄 и привлечь 2,5 миллиона пользователей. Для этого мы концентрируемся на нашем продукте и должны убедиться, что он передовой. Узнайте больше о том, как мы, инженеры, стоящие за всем этим, помогаем сотням тысяч людей оставить отзыв о своем самочувствии на работе.

Одним из основных элементов того, что мы делаем в Winningtemp, является рассылка опросов сотрудникам наших клиентов. Мы хотим измерить, как они себя чувствуют на рабочем месте, поэтому рассылаем каждому сотруднику от 3 до 5 вопросов. Настраивается, как часто и сколько именно вопросов отправляется. Они исходят из 9 тем и банка из примерно 60 вопросов, и существует вполне логика, за которой набор вопросов отправляется каждому пользователю каждый раз. Как только будет проведен опрос, сотрудник получит электронное письмо или push-сообщение на свой телефон, что приведет к самому опросу.

Пока все хорошо.

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

Старая система — откуда мы пришли

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

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

Новая система — куда мы идем

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

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

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

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

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

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

Проблемы и уроки

«Нет ли недостатков у этой распределенной структуры?» — спросите вы. Ну конечно есть.

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

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

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

Мы растем, как никогда раньше. Не верите нам? Ознакомьтесь с этой последней статьей о том, как нам удалось собрать 157 миллионов шведских крон во время пандемии Covid-19.

Ищем новых коллег! Присоединяйтесь к нашей команде и оставьте свой след в одной из самых быстрорастущих технологических компаний Европы!

В Winningtemp вы будете работать с новейшими технологиями и иметь возможность влиять на то, как мы работаем. У нас позитивная культура сотрудничества, в которой все проявляют сердце и хотят добиться успеха вместе как одна команда. Посетите нашу карьерную страницу или свяжитесь с любым из нас в технической команде через LinkedIn.