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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет, Хабр! Меня зовут Евгений Узянов, я продуктовый аналитик в команде геймификации Купера (ex СберМаркет). Когда я только начинал изучать методы количественного тестирования, я искал информацию в большом количестве источников: университетские лекции, онлайн-курсы, литература разной степени глубины и, конечно же, ютуб. В значительном количестве случаев при знакомстве с очередной статистикой информация преподносилась в следующем формате:

- Держи страшную формулу

- Вот какие-то графики с хвостами

- Ну а дальше все понятно

- Иди работай

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

Привет, Хабр! Я Евгений Малышев, SRE-инженер в Купере (так теперь называется СберМаркет). Моя основная задача — это надежная работа сервисов фронтенда, и немалую роль в этом играют правильно построенные пайплайны CI/CD. В этом нам помогает Gitlab CI. В компании мы широко используем этот инструмент для создания общих шаблонов для сервисов на различных языках. На уровне отдельного репозитория легко расширить или настроить шаблонные джобы и добавить свои.

До этого у меня был опыт с Jenkins и Azure Devops, так что Gitlab CI мне показался довольно простым: есть стадии, есть правила запуска джоб с shell-подобным синтаксисом, да и скрипты джоб тоже используют bash-интерпретатор. Но в процессе близкого знакомства не раз возникали ситуации, когда поднимается то одна бровь, то обе, а то и руки в праведном гневе. Заходите посмотреть, какую коллекцию граблей собрал я.

Весь код с примерами граблей можно посмотреть в репозитории.

Всем привет! Меня зовут Аня Власова, я работаю ML-инженером в Купере (ex СберМаркет), а именно — в команде поиска. Сегодня я расскажу про нашу нейросетевую модель, которая стои́т на страже корректных поисковых запросов. Вы наверняка найдете пару инсайтов в этой статье, если тоже разрабатываете сервисы поиска или просто интересуетесь языковыми нейронками.

Привет, Хабр! Это Оля Муттер, руководитель IT-проектного офиса в Купере (ex СберМаркет). Жизнь заставила меня научиться настраивать процессы как боженька. Я стартовала карьеру в роли бизнес-аналитика, доросла до директора продукта в финтехе, успела побывать наставником для проджектов, создать несколько проектных офисов и центров компетенций — всего за десять лет.

Сейчас я рулю проектным офисом в Купере (ex СберМаркет) — это 1300+ человек в IT-команде. Как понять, работает ли такая большая система эффективно? И что делать, если какая-то веточка этого гигантского дерева растет не в ту сторону? Об этом моя сегодняшняя статья. 

Спойлер: надо дебажить процессы, а для этого придется много работать с цифрами и общаться с людьми. За это у нас в компании отвечают delivery-менеджеры.

Всем привет! Я Стас Дергунов, Head of Product в СберМаркете. В моем портфеле три направления: самовывоз из магазина и авто, покупки в офлайне-магазинах с помощью сервиса ScanPay и новые вертикали non-food (аптеки, бытовая техника и электроника).

В статье расскажу, как мы внутри компании проверяем простые и сложные гипотезы на основе данных, что позволяет поддерживать рост в 1,6 раз год к году.

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

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

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