Меня зовут Михаил Кузнецов, я product owner в команде, которая развивает внутреннюю платформу разработки Mindbox. В этой статье я расскажу, как мы отказались от легаси-фреймворка, который пронизывал все микросервисы. И убедились — такая трансформация осуществима даже в компании на 100+ разработчиков и 1000+ корпоративных клиентов.
Новый микрофронтенд за 20 минут вместо часа: как работает система автоматической сборки
Микрофронтенды могут казаться идеальным решением, которое облегчает разработчику жизнь. Но только до тех пор, пока система не разрастется и не придется тратить час, чтобы запустить новый микрофронтенд. Мы в Mindbox узнали это на своем опыте.
Чтобы ускорить сборку, разработали систему из шаблона и CLI утилиты. Теперь новый микрофронтенд со всей обвязкой создается за 20 минут. В статье — подробное решение для тех, кто захочет повторить.
Техдолг: как разгребать задачи, чтобы не тормозить развитие продукта. Инструкция с шаблоном
Привет! На связи Ира Белица и Святослав Сычев. Мы работаем в Mindbox над высоконагруженным продуктом рассылок: более 850 наших клиентов генерируют свыше 20 тысяч RPS. Такой продукт требует много ИТ-поддержки, при этом клиенты постоянно запрашивают новые функции. Отсюда рассинхрон в команде: разработчикам важно поддерживать стабильность рассылок, менеджерам продукта — помогать клиентам решать их проблемы, зачастую с помощью новых фичей.
В этой статье расскажем, как научились договариваться между собой и выстроили процесс работы с техдолгом. Теперь разработке не приходится постоянно тушить пожары, менеджеры продукта знают, когда получат очередную доработку, а клиентам гарантирован надежный сервис и инструменты для решения задач.
Внутри — шаблон модели для автоматического скоринга техдолга. Копируйте его, чтобы приоритизировать бэклог и систематически его вычищать.
Как джуну отрастить софты: советы и реальные истории. Часть 3. Развиваться
Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее.
О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах.
Некоторые советы могут звучать очевидно: например, у нас есть пункт «выполнять обещания» — понятно, что никто обычно не собирается набрать задач и смотреть, как они горят. Но часто именно таких простых советов тяжело придерживаться. Поэтому в статье мы «приземлили» их реальными историями, чтобы читатель мог узнать ситуацию, если столкнется с ней сам, и применить наш гайд.
Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!
Медленная сборка кода с .NET Roslyn: как найти и устранить причину
.NET разработчики знают, что такое ждать сборки кода. Работать при этом невозможно: пока не увидишь, как обновится приложение, — не перейдешь к следующему шагу. А переключиться на другую задачу за это время не успеешь. Получается, если в день переписать код 5 раз, можно потерять полчаса при сборке, а то и больше.
Теперь на примере платформы автоматизации маркетинга Mindbox. Основное программное решение — это монолит на C#: несколько миллионов строк, 50 проектов, над которыми одновременно работают десятки команд. Даже сэкономленная при сборке минута выливается в кучу продуктивных человеко-часов. Поэтому, когда речь зашла о переходе всей компании на MacBook в будущем, мы решили выяснить, как это отразится на производительности.
Без денег, репликации и кеша: ограничиваем нагрузку на сервисы, используя подходы из TCP
При росте нагрузки одна из частей системы может подтормаживать. Часто уязвимым местом оказывается база данных. Так произошло и в нашем случае.
Я работаю в Mindbox в команде, которая отвечает за выдачу товарных рекомендаций. Наша база периодически деградировала, заливать ее деньгами (скейлить) не хотелось, а кешировать запросы не позволяла специфика данных.
В этой статье расскажу про комплексное решение, к которому мы пришли — динамически ограничивать конкурентные запросы и менять лимит в зависимости от времени ответа базы.
Как джуну отрастить софты: советы и реальные истории. Часть 2. Отвечать за результат
Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это вторая часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке, а в этой поговорим об ориентации на результат.
О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах.
Некоторые советы могут звучать очевидно: например, у нас есть пункт «выполнять обещания» — понятно, что никто обычно не собирается набрать задач и смотреть, как они горят. Но часто именно таких простых советов тяжело придерживаться. Поэтому в статье мы «приземлили» их реальными историями, чтобы читатель мог узнать ситуацию, если столкнется с ней сам, и применить наш гайд.
Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!
Как джуну отрастить софты: советы и реальные истории. Часть 1. Думать о пользе, а не о коде
Привет! На связи Митя Кожевников и Юра Соколов из Mindbox. В этой статье мы делимся внутренним гайдом, как джунам нарастить софскилы, быстрее закрепиться в команде и вырасти. Эта часть посвящена пользе.
О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах.
Некоторые советы могут звучать очевидно: например, у нас есть пункт «сначала разобраться в задаче» — понятно, что никто не бросится писать код, не понимая, какой результат нужен. Но часто именно таких простых советов тяжело придерживаться. Поэтому в статье мы «приземлили» их реальными историями, чтобы читатель мог узнать ситуацию, если столкнется с ней сам, и применить наш гайд.
Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!
Релизный цикл без компромиссов: надежно для клиентов, удобно для разработки
При построении релизного цикла приходится балансировать между двумя крайностями. С одной стороны, хочется по максимуму отлавливать баги и дотошно проверять каждый релиз. С другой — быстрее выпускать обновления и приносить клиентам больше пользы.
Мы в Mindbox долго решали это противоречие и, кажется, добились баланса: презентуем несколько релизов в день и каждый проходит несколько этапов проверки, чтобы баги не дошли до клиентов. Пайплайн удобен и для команды: больше сотни разработчиков работают одновременно и не блокируют действия друг друга, а обновления происходят автоматически.
О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.
Слышать клиентов и решать их задачи вовремя: гайд по управлению бэклогом B2B-продукта
Всем привет! Меня зовут Марина, я product manager в Mindbox — сервисе автоматизации маркетинга.
Моя команда отвечает за развитие ядра Mindbox — платформы клиентских данных, или CDP. Нам важно соблюдать баланс между поддержкой имеющихся функций и внедрением новых. С этим должен помогать бэклог: он выступает связующим звеном между желаниями клиентов и развитием продукта. Но в какой-то момент мы поняли, что это перестало работать: наш бэклог стал похож на гараж, в который складывают все без разбора. В итоге мы перестали слышать наших клиентов, отклонились от целей компании и вызвали недоверие коллег.
Полгода мы наводили порядок в бэклоге и выстраивали процессы по работе с ним. Сейчас продуктовые команды сфокусировано работают и регулярно выпускают обновления. В статье расскажу, как пришли к этому.
Если у вас компания на стадии масштабирования или небольшая организация, которая только строит продуктовые процессы, статья поможет выстроить порядок, не допустив наших ошибок.
Как разработчику использовать ChatGPT: разберемся, когда нейросеть помогает, а когда вредит
Может показаться, что ChatGPT работает непредсказуемо: то уверенно пишет документацию к коду, то не может решить школьную задачу по математике. Самое опасное, что во втором случае нейросеть умеет ввести в заблуждение. Чтобы понимать, какие задачи можно доверить чат-боту ChatGPT, важно знать особенности его работы.
В этой статье data scientist Mindbox, в прошлом преподаватель и научный сотрудник РАН, без лишнего философствования расскажет о работе нейросетей типа ChatGPT. На своем примере он покажет, как упрощать повседневную работу с помощью ChatGPT и подобных моделей. А в конце приведет ссылки на полезные статьи.
Как развивать продукт и не сгорать от поддержки — опыт работы по Pipedrive Agile Framework
На связи Антон Бевзюк и Дмитрий Кожевников, инженерные менеджеры Mindbox.
В Mindbox большая команда, и мы долгое время искали способ, как масштабировать Agile. Пробовали Kanban, Scrum, XP, LeSS — все не то. Полгода назад перешли на Pipedrive Agile Framework и остались довольны: уменьшили количество рутинных задач, повысили уровень счастья среди разработчиков и стали быстрее выпускать фичи — реализовали обновления, которых клиенты ждали годами. Готовы поделиться опытом.
Статья будет полезна тем, кто хочет организовать работу команды из более чем 100 разработчиков и сбалансировать развитие продукта и поддержку. Мы подробно расскажем, какие сложности испытывали и как Pipedrive Agile Framework помог с ними справиться, какие ошибки допустили во время внедрения, поделимся советами, как их не повторить, и дадим подробные гайды по запуску фреймворка.
Из менеджера клиентов во frontend-разработчика: как менять свои роли в компании
Привет! Меня зовут Петя Никитин. Я пришел в Mindbox менеджером клиентского сервиса и за четыре года перешел во frontend-разработку. Расскажу, как я учился и что помогло мне проходить внутренние собеседования.
Бесперебойный деплой микрофронтендов с Kubernetes: как настроить
Фронтенд-разработка может жить без независимого деплоя, пока у нее не больше 7 микрофронтендов. Но, чем выше число, тем сильнее страдают процессы. Наша команда в Mindbox прошла через это с Octopus, когда деплоила в Yandex Cloud S3. Причем на все обновления был один свободный бакет. Заливаешь код в мастер, а в это время то же самое делают еще пять разработчиков. Скапливается очередь, код еле ползет, а через час деплой вообще обваливается — Octopus не справился с нагрузкой. Пока чинишь это, оказывается, что твои обновления уже попали в продакшен заодно с чужими.
Когда число проектов возросло до 14, все это повторялось с каждым разработчиком по несколько раз в день. Поэтому мы решили вслед за коллегами-бэкендерами перейти на независимый деплой в Kubernetes.
В этой статье собран опыт платформы автоматизации маркетинга Mindbox по реформированию фронтенда:
Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев
Автоматизированный вывод метаданных: экономим ресурсы разработки
Постепенный переход: меняем деплой без вреда для пользователей
Хот-тестинг: ускоряем обновление фронтенда
Советы: как улучшить деплой без микрофронтендов и Kubernetes
Как инженеру выбрать работу
Даже на текущем рынке кандидата, каждая смена работы — это серьезное решение, инвестиция нескольких лет жизни или — неприятная строчка в резюме, причина для неудобных вопросов вроде «А почему вы ушли из компании X, проработав там немногим более года?».
Основные риски при неправильном выборе работы — сложности с поиском работы в будущем. Резюме без достижений или лоскутное, несоответствие квалификации запросу по деньгам и уровню потребления, другие нерыночные требования к работодателям. Результат — выгорание и демотивация, необходимость революции в середине карьеры.
При этом большинство людей выбирают работу скорее на чуйке, чем логически, или на каком-то одном факторе, например деньгах. Особенно в начале карьеры. Я и сам так делал. Это нормально: трудно выстроить систему на том небольшом количестве компаний, с которыми знакомится средний кандидат в жизни. С другой стороны, интуиция, тренированная на малом количествах точек, работает не лучшим образом.
За 18 лет в индустрии, в том числе на роли исполнительного директора и позднее CEO, мне удалось познакомиться с большим количеством бизнесов и поучаствовать примерно в тысяче инженерных интервью. На основе этого опыта и опыта коллег по Mindbox сложилась система, которой тут делюсь. И буду благодарен за предложения в комментариях, как ее улучшить.
Хоть я лицо и заинтересованное, надеюсь помочь и себе, и вам. Благо, в моих интересах не заманить всех и каждого, а чтобы приходящие к нам делали свой выбор рационально. Работали у нас долго, были довольны и мотивированы.
gRPC в .NET — рецепты счастья
Массовый переход от монолитов к микросервисам решает ряд проблем:
• раздельный деплой и рефакторинг;
• удобное масштабирование частей системы;
• прозрачное разграничение ответственности команд;
• снижение бласт-радиуса;
• снижение когнитивной нагрузки на разработчика.
При этом создает другие проблемы: взаимодействие сервисов существенно сложнее и дороже, чем взаимодействие объектов в памяти. Частично упростить его можно с помощью протокола gRPC.
gRPC дает возможность зафиксировать в репозитории контракты межсервисных вызовов, строгую типизацию, стриминг, кросс-платформенную кодогенерацию и множество других полезных для межсервисного общения вещей.
Из этой статьи вы узнаете, когда стоит применять gRPC, а когда лучше воздержаться, как решаются типичные задачи, включая конфигурирование, отладку, healthcheck, а также то, о чем умалчивает документация.
По материалам выступления на конференции DotNext.
Миллиард отправок в неделю и 730 тысяч запросов в минуту. Как справляемся с ежегодным удвоением и не унываем
Маркетинговая CDP — это не только коммуникации, приносящие значимую долю выручки, но и механики реального времени: расчет чеков, персонализация мобильных приложений и сайтов. Mindbox задуман и всё чаще работает как центральная back-end система бизнеса, интегрирующая другие. Так, например, выглядит схема интеграций одного из давних и продвинутых клиентов:
Поэтому клиентам важно понимать, можно ли на нас положиться сегодня и в будущем. Ниже приглашаю прочитать:
- как справляемся с надежностью при росте нагрузке (кажется, неплохо);
- что для этого уже сделали;
- что будем делать дальше: планы по технике и продукту.
Как грумить задачу: чек-лист с примерами
Все примеры ниже — специфичные и подойдут не каждому, они построены в основном на продуктах Mindbox «Рассылки» и «Программа лояльности». Продукты помогают нашим клиентам запускать автоматические рассылки по триггерам (действиям или событиям), чтобы не спамить пользователей, выдавать промокоды и выстраивать бонусные системы. Если поймете, что чек-лист полезен, можете заменить примеры на свои и использовать.
Ниже подробнее о том, как сделать качественный грум:
- цель грума,
- необходимый минимум,
- уточнение требований и контекста,
- типичные этапы,
- особенности при доработке механик.
Как уменьшить размерность метрик в Prometheus, если вы не DevOps
Эта статья не подойдет опытным DevOps-инженерам, но будет полезна разработчикам, которые хотят уменьшить размерность метрик и не желают погружаться в документацию. Или тем, кто намеренно отказывается от иерархической федерации и ищет обходное решение, но не хочет наступить на наши грабли. Расскажем:
- как в два шага уменьшить размерность метрик с помощью двух ServiceMonitor,
- какой есть эталонный способ уменьшить размерность метрик без «костылей»,
- почему не стоит тратить время на снижение размерности метрик с помощью Pushgateway.
Как масштабировать разработку при 400 000 RPM и не надорваться
Mindbox 15 лет развивает B2B-продукт и вырос с 3 до 70 человек в разработке. Мы тестировали разные подходы к масштабированию и готовы поделиться опытом, чтобы вам не пришлось наступать на те же грабли. Ниже расскажу, как попробовали полную автономию команд и централизацию, роняли надежность, демотивировали команды, как в результате с этим справились и выработали свою систему масштабирования.
По материалам выступления на Agile Days 2021: