Всем привет! Меня зовут Роза и я MLOps-инженер в Купере. Под катом расскажу, как построить CI/CD-пайплайн для ML-приложений с нуля, поэтапно и без боли. Ну почти :)

Раньше очень часто работа DS-инженера заканчивалась на подготовке кода модели в Jupyter-ноутбуке, а дальше его подхватывали команды разработки и доводили до продакшена. У такого подхода есть минусы. Например, если произойдёт инцидент, непонятно кто ответственен за сервис  — команда разработки или авторы ML-модели?

К счастью, культура разработки меняется: теперь ML-инженер — это специалист, который разрабатывает свой ML-сервис на всем пути от общения с бизнесом до продакшена. Этот подход хорошо описывает принцип «you build it, you run it»: кто построил модель, тот её и запускает. Как раз в этом здорово помогает CI/CD.

Привет, Хабр! Меня зовут Марина, я QA-инженер в Купере. Как специалисту по тестированию, мне часто приходится сталкиваться с задачами, связанными с тестированием микросервисов, использующих асинхронное общение через Apache Kafka. Уверена, многие QA-инженеры, да и разработчики знакомы с подобными вызовами.

На одном из проектов, где я работаю, у меня возникла проблема: используемые инструменты для тестирования Kafka были недостаточно удобными:

Консольная утилита Protokaf не имеет интерфейса и полученные данные для лучшей читаемости нужно отформатировать в json структуру (а это еще одно доп приложение).

UI-приложение Kowl удобно только для мониторинга состояния топиков, и только недавно в нём стала доступна возможность чтения сообщений без сложного флоу для расшифровки, но всё так же нет возможность отправки сообщений в топик. 

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

В этой статье я не буду объяснять, что такое Kafka и как работают брокеры — на эти темы уже есть множество отличных материалов, например, вот. Хочу поделиться своим опытом использования этого инструмента. Я не ставлю цель сравнивать его с другими существующими решениями, а просто расскажу, как Plumber помог мне упростить процесс ручного тестирования Kafka на стейджах. 

Привет! Меня зовут Юрий, я старший разработчик в Купере в команде Ruby Platform, занимающейся разработкой внутренних библиотек, инструментов мониторинга и поддержки микросервисов.

У нас в Купере более 200 микросервисов на разных стеках, а также монолиты. С точки зрения инфраструктуры интеграционное тестирование такого количества компонентов - довольно затратная задача, но при этом хочется обеспечить стабильность системы, не проводя ручные интеграционные регресс-тесты. В таких условиях оптимальным решением являются контрактные тесты.

Из данной статьи вы узнаете:

- общий принцип работы контрактных тестов;

- о проблемах, с которыми мы столкнулись при внедрении контрактного тестирования и как их решали;

- как мы разработали свое решение для контрактного тестирования Ruby-приложений;

- о настройке CI/CD для автоматизации контрактных тестов.

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

Привет! Меня зовут Юрий Беляков, я старший ML-инженер в Купере. Сегодня предлагаю вместе разобраться, что такое плановая доставка и как устроен алгоритм управления слотами в Купере. Обсудим, как проходило тестирование и масштабирование от одного магазина до всех гипермаркетов, на какие грабли мы наступили и как на той же базе реализовать динамическое ценообразование.

Наверняка вы за собой замечали, что иногда какую-то задачу настолько не хочется делать, что курсор мыши сам выпрыгивает из IDE, а пальцы отбивают на клавиатуре «YouTube — шортсы с котами». Возможно, вы пытались разобраться, почему же так?

 А вы точно пытались — на Хабре написано аж 39 (!) страниц статей по запросу «прокрастинация».

Меня зовут Арина, я работаю продуктовым аналитиком в Купере. Поделюсь тем, как сама боролась с прокрастинацией, а в результате узнала о СДВГ, получила диагноз, полюбила его и научилась с ним жить. Расскажу об СДВГ в целом и о своем опыте выживания в IT с таким мозгом.

С помощью поддержки и просвещения можно прийти к пониманию, что у СДВГ помимо минусов так же много и плюсов, и в мире много успешных людей с этим диагнозом. Например, чемпион мира по плаванию Майкл Фелпс, основатель IKEA Ингвар Кампрад, основатель корпорации Virgin Group Ричард Брэнсон, основатель JetBlue Девид Нилеман, режиссерка «Барби» Грета Гервиг, актеры Том Круз, Орландо Блум, Зоуи Дешанель, Эмма Уотсон и еще многие другие люди с этим диагнозом живут и строят успешные карьеры.

Многие из них, если речь заходила про СДВГ, говорили, что в конечном итоге это стало их сильной стороной. Ведь на самом деле это не про отсутствие самодисциплины или лень, а просто про другой механизм работы мозга. И если знать, что с этим делать, то все сложности можно нивелировать или даже обратить себе во благо.

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

Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.

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

Здесь хочу поделиться своей логикой и тем, как искал аргументы, чтобы реализовать свой эксперимент. Любые менния по теме приветствую в комментариях.

Привет! Я Максим Коровенков, DevSecOps Lead в Купере (ex СберМаркет). Хочу поделиться мыслями по поводу минимально необходимого набора процессов, сопутствующих внедрению сканеров безопасности в пайплайны разработки. 

В результате попытаюсь ответить на вопрос: «А что, собственно, стоит иметь в виду под фразой “Мы внедрили сканеры безопасности в пайплайны разработки”?» 

Да, в тысячный раз про пайплайны, но, как вы, думаю, догадываетесь, желание поделиться казалось бы очевидными мыслями появилось не случайно! Не так давно я завершил найм и укомплектовал свою DevSecOps-команду. В рамках поиска пришлось провести достаточное количество интервью, на которых я любопытствовал, как обстоят дела у соискателей с пайплайнами безопасности на текущем/предыдущем месте работы. Это удивительно, но для 90% респондентов фраза «внедрение сканеров безопасности в пайплайны» означает только факт внедрения. Лишь некоторые кандидаты упоминали отправку результатов в VMs/ASOC систему. 

Ведь действительно кажется, что все просто: запаслись вокабуляром из нескольких аббревиатур, внедрили инструменты, SAST, SCA, может что-то еще, настроили отправку результатов для AppSec-ов и, как-будто, можно идти бить баклуши. Но я на своем опыте убедился, что DevSecOps — это про глубокую проработку процессов. Поэтому в данной статье сконцентрируюсь больше на процессах, нежели на технике. 

Предлагаю наконец переходить к сути!

Привет всем! Меня зовут Таня Конюшенко, и я — продуктовый дизайнер в Купере. В этой статье я рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в моей продуктовой команде. Мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.

Ещё год назад я ничего не знала о Discovery, потому что работала в заказной разработке. О том, в чем разница между дизайнерами в агентстве и продукте, рассказывала в своей прошлой статье.

Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…

Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?

Привет! Меня зовут Сергей Реусин и последние пять лет я занимаюсь эксплуатацией production-систем с непрерывной практикой инцидент-менеджмента. Каждый день, сталкиваясь с аномалиями и проблемами, невольно спрашиваешь себя: «Почему это происходит? А главное — как с этим дальше жить?». Три нелегких года работы в Купере ( ex СберМаркет), где мне доверили строить культуру инцидент-менеджмента, помогли мне утвердиться во мнении и подходах, которые действительно помогают справляться с подобными вызовами. О них и поговорим!

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

1. Определим, ради чего вся эта «доступность» и «стабильность» нужна

2. Попробуем устаканить терминологию, чтобы говорить на одном языке

3. Посмотрим на понятие системы с позиции устойчивости

4. Обратимся к историческому опыту

5. Изучим возможные паттерны отказов систем и способы их митигации

6. Визуализируем модель восприятия аномалий

7. Познакомимся с ключевыми личностями в подходах Resilience Engineering

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

Меня зовут Олег Федоткин, я программист и менеджер в ИТ. Я провел более сотни собеседований (мне HR даже толстовку «Hiring Hero» по такому случаю подарили) и нанял десятки человек: программистов, тим лидов, юнит лидов, архитекторов — да всех. После всех интервью я выделил три качества, которые неизменно определяют классного специалиста.

Привет, Хабр! Меня зовут Аня Южанина, я работаю ML-инженером в Купере (ex-СберМаркет). Сегодня я расскажу о межретейлерном поиске. Это когда вы ищете какой-то товар и Купер показывает этот товар в ассортименте разных ретейлеров. Зачем вообще нужен такой поиск и как внедрить умное ранжирование магазинов?

Привет, Хабр! Меня зовут Капитолина Кузнецова, я Ruby-разработчик и на своём текущем месте работы в Купере (ex СберМаркет) доросла до роли тимлида. За 2,5 года я, так сказать, освоилась в этом статусе и, если верить моей команде, руководитель из меня получился неплохой, но вьетнамские флэшбэки о своих первых месяцах работы в новой роли ещё свежи.

Быть начинающим тимлидом — это...

- когда встречи занимают по семь, восемь, а то и девять часов подряд;

- когда ты целый день что-то делаешь, дико устаешь, а в конце не видишь никакого результата;

- когда о Jira знаешь больше, чем о собственной семье, а встречи с друзьями планируешь на новогодние праздники 2025 года.

Эта статья — попытка структурировать всё, что может помочь вам в новой роли. А также моя рефлексия о том, какие способы помочь себе, реально облегчат вам жизнь и помогут быстрее справиться с новым масштабом. Знаю, что такие проблемы были не только у меня, но и у многих других ребят, которые раньше просто писали код, а не вот это вот всё. В общем, надеюсь, мои заметки будут вам полезны :)

Привет, меня зовут Марина Гончарова, я старший менеджер проектов в Купере (ex СберМаркет). Я работаю в IT с 2008 года, а проджектом — с 2015, и за эти годы у меня накопилось много знаний, приёмов и лайфхаков, которыми хочется делиться. Одна из таких животрепещущих тем — как сделать даже короткие встречи эффективными и результативными для всех участников. 

При работе в разных компаниях я сталкивалась с тем, что все встречи по умолчанию ставятся минимум на час, и даже за час мы не всегда успеваем всё обсудить. 8 рабочих часов, 7-8 встреч — и вот весь день занят, а работать некогда, ну или приходится перерабатывать вечером. Лёд тронулся во время пандемии, когда компании перешли на удалёнку, и стало ясно, что с таким обилием часовых встреч нужно что-то делать. 

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

Привет, Хабр! Я Александр Непомнящих, QA в СберМаркете. Мы с командой кодим программу лояльности, которая позволяет списывать в заказах бонусы «Спасибо», а также запускать различные акции с повышенным начислением бонусов. 

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

Если вы занимаетесь тестированием, заходите под кат — расскажу, как мы в итоге автоматизировали процесс до 1 команды в Rails-консоли.

Привет, Хабр! Меня зовут Даша Кряжева, я продакт-менеджер, сейчас занимаюсь исходящим голосовым роботом в СберМаркете. С его помощью нам удалось автоматизировать 30% клиентских и партнерских обращений в контактный центр, но это не только про цифры. Проактивная коммуникация — это всегда про повышение лояльности и открытый диалог с пользователями.

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

Привет, Хабр! Меня зовут Павел Родичев, и я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.

Привет, Хабр! Меня зовут Диана, я продуктовый дизайнер в СберМаркете. Наша команда развивает личный кабинет ресторанов, чтобы администраторам было удобно в нём работать и принимать заказы на доставку. В этой статье хочу поделиться, как мы улучшали раздел Заказы: «полечили» звуковые уведомления, сделали анимированную фавиконку, чтобы наша вкладка не терялась среди остальных, и добавили возможность создавать тестовый заказ для обучения новых сотрудников ресторанов.

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

Всем привет. Меня зовут Нияз Кашапов, я AppSec Lead в СберМаркете. Улучшаю процессы безопасной разработки уже более 5 лет. Начинал карьеру в финтехе, где занимался безопасностью кода, фич и бизнес-процессов в онлайн-банкинге. А сейчас продолжаю начатое в одном из самых быстрорастущих игроков на рынке e-com.

Думаю, у многих в практике встречалась уязвимость, которую просто так не пофиксить — ведь она заложена глубоко внутри разрабатываемого решения, обвешана кучей зависимостей и требует полного ребилда самого решения. Чаще всего такие уязвимости остаются в проде навсегда и удерживаются от «падения» множеством костылей. Возникает резонный вопрос: «Как они возникли?» Чаще всего ответ — «Так исторически сложилось», а истоки проблемы давно забыты. Боролься с таким лучше превентивно, а как это сделать — попробую рассказать в этой статье.

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

Привет! На связи Миша Меркушин. Я тимлид команды Ruby Platform, ответственной за разработку внутренних библиотек и улучшение архитектуры микросервисов на Ruby в СберМаркете. Эта статья про архитектурный паттерн Outbox и инструмент, который мы создали и итерационно развивали внутри команды и лишь недавно «выпустили» его в мир. Он решает проблему обеспечения надежной и согласованной отправки сообщений из приложения, гарантируя, что сообщение будет отправлено после успешного завершения транзакции базы данных.