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