Рассказ о том, как в феврале 2024 мы провели конкурс «Бандитский Сыроград», который расширил нашу воронку найма и пополнил наш резерв новыми резюме. 

Какие цели ставили: 
1) Развить аналитический бренд компании Garage Eight
2) Получить контакты продуктовых аналитиков для рекрутмента

В результате о нас и нашей аналитике узнали как минимум 169 новых человек. Именно столько специалистов зарегистрировалось в конкурсе. О том, как это было, читай в статье.

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

Меня зовут Ира Руттенберг, я Recruitment Lead в международной IT-компании Garage Eight. В этой статье рассказала, почему работодатель может отказать на каждом из этапов отбора и как этого избежать.

Приветствую всех! Меня зовут Александр Бондаренко, я — CPO в компании Garage Eight. В своей работе я постоянно исследую новые подходы к продуктовой разработке, чтобы повышать эффективность команд и помогать продуктам быстрее достигать бизнес-целей. Мы используем широкий спектр продуктовых метрик, таких как Retention, MAU, LTV и другие. Однако каждая команда имеет свои собственные критерии успешности, что часто приводит к размыванию общей стратегии и несбалансированной оценке роста продукта. 

Чтобы этого избежать, внедряем петли роста — Growth Loops. Этот метод уже успешно применяют такие гиганты как Google, Amazon и LinkedIn. Благодаря этому подходу, их сервисы приобретают мировую популярность, что способствует значительному росту доходов и созданию развитых экосистем

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

В этом материале я постараюсь описать один из способов организации алертов в микросервисной архитектуре.

Далее речь пойдет о системе, которая работает на основе стека prometheus alertmanager + с учетом того, что микросервисы развернуты в кубере. Итак, приступим.

В незапамятные времена, когда еще не вышла последняя серия «Во все тяжкие», алерты чаще всего хранились в одном месте — будь то icinga, zabbix, TICK stack или тот же самый Prometheus. В этом есть свои плюсы — можно легко отслеживать изменения, грепнуть нужный алерт, накидать CI и так далее. Но когда речь заходит о микросервисной архитектура, где бизнес логика представлена отдельными сервисами, было бы логичным держать бизнес алертинг рядом с микросервисов.

Что ж, давайте попробуем реализовать такой подход.

Всем привет. Меня зовут Женя, я работаю, как это сейчас модно говорить, DevOps-инженером в компании Garage Eight. 

В этой статье я бы хотел поделится опытом внедрения и эксплуатации брокера сообщений NATS в нашей инфраструктуре — настолько понравилась эта технология. 

Однажды перед нами встала задача максимально быстрой доставки сообщений из пункта A в пункт B. Условия были таковы:

* Перед тем как сообщение достигнет пункта назначения, оно проходит ряд сервисов;

* Каждый сервис выполняет определенный набор действий над этим сообщением;

* Скорость прохождения сообщений через весь путь должна быть минимальной;

* Брокер сообщений должен работать стабильно 24\7.

В статье я расскажу, как мы это делали

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