В приложении «Магнит: акции и доставка» можно оставлять отзывы на товары. Отзывы модерируются: мы публикуем те, которые считаем полезными для других покупателей, — они должны описывать потребительские свойства товара. Отклоняем все остальные: как правило, это жалобы на ценники, сервис в магазине, условия хранения либо просто нерелевантные тексты. Отзывы с жалобами обрабатывают службы поддержки и сервиса.
Рассказываем о том, как мы попробовали применять большие языковые модели, чтобы автоматизировать модерацию отзывов.
Иногда это целая проблема — найти товар с редкими свойствами. Информация о товаре должна быть доступна для поиска, но в лучшем случае особые характеристики указываются в текстовом описании. Даже если для интересующего свойства сделали отдельное поле, то его заполняют левой задней пяткой без гарантий достоверности. В результате покупатель может плюнуть и уйти из магазина, так и не найдя то, что искал. А секрет прост: чтобы все получилось, нужно правильно приготовить мастер-данные.
Рассказываем, чем грамотно построенные процессы управления мастер-данными могут помочь продажам.
По мере развития проекта в целом и дизайн-системы в частности дизайн-токенов становится очень много. Для примера, у нас уже около четырёхсот иконок, больше двухсот цветов и перспектива внедрения нескольких тем в приложении. Что ещё, если не автоматизация, позволит держать в консистентности всю эту систему?
Рассказываю про наш тернистый путь к собственному генератору токенов дизайн-системы.
Проверка потенциальных контрагентов на благонадёжность — неотъемлемая часть ведения бизнеса. Она нужна, чтобы эффективно управлять рисками, соблюдать должную осмотрительность, исключить репутационные риски и финансовые потери.
Мы создали систему, которая позволила оптимизировать работу по проверке контрагентов из открытых источников. Рассказываем, как она устроена.
Автоматическое обновление зависимостей становится все более важным аспектом в процессах непрерывной интеграции и непрерывной доставки (CI/CD) в сфере разработки программного обеспечения. В статье описана настройка автоматического обновления зависимостей в GitLab-проектах с помощью Renovate.
«Магнит» — это не только продукты съедобные, но и продукты цифровые: мобильные приложения, веб-сервисы. Команда пользовательского опыта старается делать их лучше: для этого есть исследователи, которые проводят исследования внутренних (для сотрудников) и внешних (для клиентов) продуктов, и CJE — эксперты по клиентскому опыту, которые строят карты клиентских путей на основе данных исследований и обратной связи.
Наша работа — находить и помогать решать проблемы пользователей. Но мы сами, в свою очередь, сталкиваемся с проблемами при выполнении этой задачи. Об этих проблемах и о том, как мы их решаем, расскажем в статье.
Как на сервисе весом в 10 ТБайт ежедневно обрабатывать 1 Тбайт пользовательских данных и спать спокойно.
В статье описана эволюция системы управления процессами в компании «Магнит». Некоторые детали были упрощены для лаконичности и последовательности повествования, некоторые были изменены по соображениям безопасности. В любом случае, целью статьи является с одной стороны желание поделиться с сообществом техническим опытом, с другой — оставить ретроспективный взгляд на историю компании.
Пару лет назад в отделе, ответственном за развитие корпоративного хранилища данных «Магнита», работало 5 системных аналитиков: они полностью закрывали весь набор задач, которые перед ними стояли. Но в 2021 году случился резкий рост: данные стали использоваться не несколькими департаментами, как было до, а сразу всей компанией — для масштабных проектов.
Рассказываю, как мы перестроили процессы онбординга для команды, выросшей в 10 раз.
У нас в команде два системных аналитика с разным бэкграундом и изначально разными подходами к оформлению требований, в том числе к API. Вначале каждый из нас писал требования по-своему, с разным уровнем проработки и детализации. Но быстро стало понятно, что так дальше не пойдет: это приводило к разночтению требований разработчиками и тормозило реализацию. Поэтому мы в команде решили унифицировать формат описания требований к API.
В статье расскажу, к какому формату описания в итоге мы пришли, и покажу заполнение шаблона на конкретных примерах.
В «Магните» только по 1С-системам суточный объем логов переваливает за 100 Гб. Их нужно обрабатывать, использовать, выделять ценные данные. Конечно, мы пользуемся Discover и различными дашбордами и визуализациями. Но иногда необходима оперативность. Тогда пригождается система алертингов: она позволяет создавать оповещения и уведомлять пользователей о различных событиях или изменениях в данных.
В рунете не так много материалов по настройке алертингов, поэтому мы решили поделиться своим мануалом в надежде, что это поможет кому-то сберечь драгоценное время. В статье познакомимся с основами работы с алертингами в OpenSearch и настроим один способ доставки оповещений — в Telegram.
При нашей работе мы используем подход «Инфраструктура как код». Однако в процессе его использования мы столкнулись с проблемой написания пайплайнов для инфраструктуры.
Во всём «виноват» terragrunt: каждому модулю terragrunt нужна отдельная джоба в пайплайне на plan и apply, но для каждого модуля они во многом повторяют друг друга. Подобное постоянное написание одинаковых частей CI/CD пайплайна при добавлении новых баз и бакетов навевало тоску.
Рассказываем, как мы создали генератор джоб в Gitlab CI/CD и навсегда забыли о ручном написании пайплайнов для развёртывания элементов инфраструктуры.
Как мы ежа и ужа собирали. Сказ об автосборке разномастных технологий под одну крышу.
Если серьёзно: у нас было много разнообразной ручной работы на пути от разработчика до релиза приложения для сети магазинов.
Мы научились хранить наши приложения в git и собирать их «одним кликом», перешли от подхода «один репозиторий – одна технология» к «один репозиторий – одно приложение». Реализовали установку всех частей приложения «одной командой»; собрали грабли, разложенные в самых неожиданных местах, и создали несколько инструментов, помогающих на разных этапах сборки и установки приложений.
В этой статье рассказываю, с чего мы начали, где находимся сейчас и что было на этом пути.
Как-то в общении с моим другом-разработчиком из одной крупной софтверной компании у нас зашёл разговор о взаимодействии распределённых команд. В его компании было множество достаточно изолированных команд, каждая из которых разрабатывала свой сервис. В ответ на мой вопрос, как команды расшаривают API, я получил ожидаемый ответ: Open API. Open API, безусловно, прекрасный инструмент, но у него есть ряд недостатков.
Меня зовут Андрей Зяблин, я главный разработчик в «Магните». Расскажу о том, как распространять API нативным для Java способом и пользоваться им в объектно-ориентированном стиле без использования генераторов кода.
Сегодня я хотел бы поделиться с вами опытом, который мы приобрели в компании «Магнит» при загрузке данных из внешних источников в корпоративное хранилище данных. Расскажу о проблемах, с которыми мы столкнулись и решениях, которые нам помогли облегчить процесс загрузки, повысить эффективность и ускорить получение доступа к данным.
Бывают случаи, когда инженеры хранят секретные данные, ключи, токены в открытом виде или в переменных Gitlab. В Kubernetes для хранения данных, которые нежелательно показывать широкому кругу лиц, предусмотрены секреты.
В этой статье предлагаю рассмотреть безопасный способ передавать, синхронизировать, интегрировать секреты напрямую из Vault в Kubernetes – с помощью метода аутентификации AppRole, используя external-secrets-operator.
У нас было 2 ТБ данных на 4 информационных системы, 237 таблиц, 221 хранимая процедура, свыше 30 тысяч строк кода, ванильная версия PostgreSQL и потребность в реализации обратного потока данных в Oracle. Не то чтобы мы были экспертами в создании потоков данных между СУБД, но я знал, что рано или поздно нам придется этим заняться.
Привет, Хабр! На связи Андрей Зяблин, Java разработчик компании «Магнит». В статье я расскажу про три решения, которые позволяют реализовать потоковый обмен данными из БД между распределёнными приложениями.
