Сегодня технологические компании стоят перед выбором без выбора: если перед нами не стоит узкоспециализированная задача, то мы по дефолту идем работать в Kubernetes. Эта система универсальна и проверена годами, поэтому обойтись без нее практически невозможно.
Привет! Меня зовут Игорь Титов, я Product Lead системных инженеров в Garage Eight. В этой статье расскажу, что такое контейнеризация, как с ней помогает Kubernetes и почему важно уметь правильно его готовить.
Вот уже 24 года мы используем сложный для понимания, завязанный на особенности HTTP REST-протокол. Не пора ли переходить к чему-то более современному?
Привет! Меня зовут Игорь Алексеев и я работаю бэкенд-разработчиком в компании Garage Eight. Некоторое время назад я внедрил gRPC для части своих сервисов. В этой статье поговорим о том, что такое gRPC, сравним его с возможными альтернативами, рассмотрим преимущества gRPC и пробежимся по проблемам, которые возникают почти в каждом проекте, где этот протокол приходится внедрять.
Всем привет! Меня зовут Даша, я продуктовый аналитик и Product Owner в команде Garage Eight.
Во время A/B-тестов у меня часто возникает вопрос о долгосрочном эффекте от изменений в продукте. Для меня ГКГ (она же Глобальная Контрольная Группа) стала незаменимым инструментом анализа таких изменений. В этой статье не будет занудной статистики и замысловатых формул, только практика.
Я расскажу о том, что такое ГКГ, как этот инструмент помогает упростить оценку эффективности и как избежать популярных ошибок при его внедрении. Надеюсь, что мой опыт принесет пользу и вашим проектам.
Оффер в классную IT компанию на интересную позицию иногда кажется какой-то недосягаемой вершиной, сегодня мы разберем несколько лайфхаков, которые приблизят вас к заветной цели. Пройти весь квест найма можно значительно проще и быстрее, если правильно к нему подготовиться.
Меня зовут Ира Руттенберг, я Recruitment Lead в международной IT-компании Garage Eight. В этой статье рассказала, почему работодатель может отказать на каждом из этапов отбора и как этого избежать.
Рассказ о том, как в феврале 2024 мы провели конкурс «Бандитский Сыроград», который расширил нашу воронку найма и пополнил наш резерв новыми резюме.
Какие цели ставили:
1) Развить аналитический бренд компании Garage Eight
2) Получить контакты продуктовых аналитиков для рекрутмента
В результате о нас и нашей аналитике узнали как минимум 169 новых человек. Именно столько специалистов зарегистрировалось в конкурсе. О том, как это было, читай в статье.
Приветствую всех! Меня зовут Александр Бондаренко, я — CPO в компании Garage Eight. В своей работе я постоянно исследую новые подходы к продуктовой разработке, чтобы повышать эффективность команд и помогать продуктам быстрее достигать бизнес-целей. Мы используем широкий спектр продуктовых метрик, таких как Retention, MAU, LTV и другие. Однако каждая команда имеет свои собственные критерии успешности, что часто приводит к размыванию общей стратегии и несбалансированной оценке роста продукта.
Чтобы этого избежать, внедряем петли роста — Growth Loops. Этот метод уже успешно применяют такие гиганты как Google, Amazon и LinkedIn. Благодаря этому подходу, их сервисы приобретают мировую популярность, что способствует значительному росту доходов и созданию развитых экосистем
Growth Loops — это модель, которая доказала свою эффективность в управлении продуктами. В отличие от устаревших пиратских воронок, которые требуют больших затрат на привлечение клиентов и затрудняют анализ их поведения, Growth Loops предлагают ряд значительных преимуществ:
Основное предназначение A/B тестов — оценить эффективность вносимых изменений и, в случае увеличения целевых метрик, зафиксировать эти изменения, а в случае снижения — откатить. Как правило, один из критериев хорошего дизайна A/B-теста — это конкретное и реалистичное с практической точки зрения время его проведения.
Такой подход логичен, довольно хорошо изучен и не нуждается в очередном обсуждении. В этой же статье предлагаю обсудить не самые популярные подходы к тестированию: тесты, у которых есть начало, но нет конца, где эффект изменений может меняться за короткий промежуток времени, а тестируемые изменения — всегда в процессе частичного релиза.
Рост команды требует большего вовлечения в процессы и договорённости, которые, в свою очередь, требуют автоматизации и инспекции. Можно взять bash‑скрипты и закрыть ими эту потребность, но насколько это будет удобно? Тут нужен инструмент, который упростит разработку и будет поддерживать команду в будущем. Сегодня расскажу про один из таких инструментов — Fastlane — и его возможности.
Статья будет полезна для ознакомления с Fastlane, тем, кто ищет решения для разработки автоматизации или рассматривает альтернативные решения по автоматизации сборок и процессов внутри компании. Для наглядности все примеры запускаются локально, это же решение можно перенести на CI/CD (Gitlab, Jenkins, Github Actions и тп).
Всем привет! Меня зовут Игорь Титов, я системный инженер в компании Garage Eight и сегодня я расскажу о том, как мы увеличили скорость разворота в два раза и значительно повысили эффективность нашей dev-инфраструктуры.
Звучит как начало истории про успешный успех, где в конце будет предложение купить курс… Но нет!
Каждая стратегия масштабирования имеет свои плюсы и минусы. Почему бы не начать комбинировать их и оставить только плюсы? Поговорим об этом — как сделать хорошо, когда нельзя просто закопать — в контексте PHP.
В этой статье мы рассмотрим, как и почему изменилась реализация примитивов синхронизации из стандартной библиотеки Java и пакета java.util.concurrent для Kotlin Coroutines и для языка Kotlin в целом.
Разберемся, какие реализации примитивов синхронизации потоков актуальны в контексте корутин, а какие надо использовать с осторожностью.
Оценим готовность текущих решений к использованию в Kotlin Multiplatform.
Разработаем аналоги нескольких полезных классов пакета java.util.concurrent, до которых еще не добрались разработчики корутин.
В рамках статьи будут разобраны следующие примитивы синхронизации: критические секции, атомарные переменные, реактивные переменные и барьерная синхронизация.
«Он рассмеялся, весьма довольный своим остроумием. Но смеялся он один», — Рафаэль Сабатини.
Очень давно мне хотелось опубликовать эту статью, но я откладывал и публиковал технические материалы. Если вы видите ее в ленте, значит, пришло время. Статья не несет интеллектуальную нагрузку, кроме, возможно, той, которую придадите ей вы. Любители ставить минусы за низкий технический уровень материала — можете смело пролистывать (но мы-то знаем: вы мимо не пройдете). А остальным предлагаю заглянуть под кат и ознакомиться с репортажем про жизнь морских свинок в IT-компании Garage Eight. Репортаж отражает мою личную интерпретацию событий.
В начале 2021 года в Garage Eight было 900+ тестов, около 80 job в pipeline с автотестами на RobotFramework и больше 15 фича-команд. Отчёты о прогонах мы отправляли в Slack, при этом не использовали системы сбора и отображения отчётов (Allure, Report Portal и др). Всё работало отлично, пока… пока часть наших микросервисов не была перенесена в Kubernetes, и пока однажды нам не пришлось искать причину регулярных падений двух десятков тестов из разных сьютов.
Всем привет! В прошлой статье я рассказывал про жизненный цикл машинного обучения, когда его внедрение происходит стихийно. Теперь поговорим про более осознанный подход, к которому я пришел через хаотичное внедрение и боль.
Ниже будет инструкция по поиску проекта для ML-инженера с амбициями PM или для PM с пониманием ограничений сферы ML. Хотя для тех, кто «просто спросить», тоже есть что почитать.
В этом материале я постараюсь описать один из способов организации алертов в микросервисной архитектуре.
Далее речь пойдет о системе, которая работает на основе стека prometheus alertmanager + с учетом того, что микросервисы развернуты в кубере. Итак, приступим.
В незапамятные времена, когда еще не вышла последняя серия «Во все тяжкие», алерты чаще всего хранились в одном месте — будь то icinga, zabbix, TICK stack или тот же самый Prometheus. В этом есть свои плюсы — можно легко отслеживать изменения, грепнуть нужный алерт, накидать CI и так далее. Но когда речь заходит о микросервисной архитектура, где бизнес логика представлена отдельными сервисами, было бы логичным держать бизнес алертинг рядом с микросервисов.
Что ж, давайте попробуем реализовать такой подход.
При разработке чат-бота мы столкнулись с задачей планирования этапов автоматизации. Эта задача возникает, когда охватить все темы невозможно из-за их многочисленности и постоянного изменения их содержания. Поэтому перед реализацией сценариев важно понимать, какое множество тем чатов необходимо покрыть в первую очередь, чтобы за фиксированный период времени и с ограниченным количеством ресурсов достичь максимального эффекта. В статье разберем постановку задачи, ее формализацию и одно из решений.
Привет, Хабр! Меня зовут Даниель, я занимаюсь машинным обучением в Garage Eight.
Решил рассказать о работе ML команды в горизонтальной структуре и особенностях такого подхода.
Всем привет!
Меня зовут Родион, я занимаюсь улучшением бизнес-процессов компаний с помощью данных. Сегодня хочу поделиться опытом внедрения машинного обучения: как компании работают с бизнес-метриками и данными, где в иерархии потребностей компании находится ML и как довести проект до реальной бизнес-пользы.
Всем привет. Меня зовут Женя, я работаю, как это сейчас модно говорить, DevOps-инженером в компании Garage Eight.
В этой статье я бы хотел поделится опытом внедрения и эксплуатации брокера сообщений NATS в нашей инфраструктуре — настолько понравилась эта технология.
Однажды перед нами встала задача максимально быстрой доставки сообщений из пункта A в пункт B. Условия были таковы:
* Перед тем как сообщение достигнет пункта назначения, оно проходит ряд сервисов;
* Каждый сервис выполняет определенный набор действий над этим сообщением;
* Скорость прохождения сообщений через весь путь должна быть минимальной;
* Брокер сообщений должен работать стабильно 24\7.
В статье я расскажу, как мы это делали
Привет, Хабр! Меня зовут Андрей Гончаров, я дата-инженер в Garage Eight, и сегодня я расскажу о том, как мы подходим к батч-процессингу и нашей self-service платформе данных. Почему self-service? Традиционный подход к работе с данными подразумевает, что данные готовят и перемещают между информационными системами дата-инженеры.
Однако, с ростом data-driven компаний растут и потребности бизнеса, нужно анализировать и перемещать все больше данных между все большим количеством информационных систем, и требуется это все большему количеству потребителей данных: аналитикам, продакт-менеджерам, разработчикам и другим. В связи с чем растет и нагрузка на дата-инженеров, они работают со всё растущим количеством данных, бизнес-сущностей, и, по сути, владеют ими. Остается мало времени на модернизацию дата-инженерных инструментов, растет техдолг. Для снижения нагрузки можно увеличивать дата-инженерный штат, что является не лучшим вариантом — в таком случае, нам потребуется дата-департамент, растущий пропорционально с бизнесом.
Давайте посмотрим, как мы решаем описанные проблемы.
