Привет, Хабр! С вами Максим Коровенков, DevSecOps Lead в Купер.техе. Продолжаем цикл статей про построение DevSecOps с нуля. Это большой гайд from zero to, надеюсь, hero.
Всем привет! Меня зовут Роза и я MLOps-инженер в Купере. Пока одни учат модели, а другие пытаются их запустить, наша команда строит «мост» между этими мирами — и сегодня под катом расскажу, как мы создавали нашу ML-платформу: от тренировочных стендов до продакшн-инференса, который не падает в пятницу вечером.
Отдельное внимание мы уделим тому, как выстраивать взаимодействие между разными стейкхолдерами платформы — от собственно ML-инженеров до DataOps и Security-инженеров.
В этой статье вы найдете немного личных наблюдений и советов о том, как сохранить проект живым и здоровым с течением лет. Без иллюзий всезнания. С лёгким, здоровым цинизмом.
Мой личный опыт связан с разработкой сервисов в рамках продуктовой разработки. В данной статье я говорю именно о такой разработке, а не о создании библиотек, фреймворков, баз данных и других замечательных вещей. Также я не касаюсь проектной разработки, где код пишется на заказ и передаётся в поддержку другим.
Привет! Меня зовут Александр Баранов, я аналитик данных в команде поиска Купера. Цель этого рассказа, поделиться наработками в деле оптимизации разметки текстовых данных при помощи большой языковой модели (LLM). Если после прочтения вы захотите что-то добавить или спросить, буду только рад!
В IT-сообществе только и разговоров об эмбеддингах, metric learning, косинусных расстояниях и семантическом поиске. На конференциях все хвастаются красивыми слайдами про нейросети и векторные пространства. Но если заглянуть под капот и посмотреть, что реально работает в поиске крупных маркетплейсов и e-commerce платформ, то там, как правило, он — добрый, старый полнотекстовый индекс.
Почему? Потому что полнотекстовый поиск — это стабильно, быстро и понятно. Минус только один, его уже недостаточно. Да, он классно ловит точные совпадения, но синонимы, переформулировки и небольшие ошибки прощает пользователям уже с большим трудом.
Меня зовут Игорь Самарин, я Machine Learning Engineer из команды поиска в Купере, где уже полтора года занимаюсь проектами, связанными с векторами. В этой статье я расскажу, как на самом деле работает поиск внутри компании, поведаю о полнотекстовом поиске — его сильных сторонах и недостатках. Затем объясню специфику векторного поиска и разберу, какие именно проблемы старого подхода он решает и продемонстрирую, как обучить векторную модель на своих данных, чтобы она понимала специфику каталога. А в конце вас ждут реальные результаты из A/B тестов и небольшой панч о перспективах.
Всем привет! Меня зовут Марина Гончарова, и я IT-проджект-менеджер в Купере.
На моем проджект-веку было много разных компаний, разных продуктов, и весь этот опыт можно разделить на две большие категории. Первая — классика: я нахожусь внутри продуктовой команды, управляю бэклогом, распределяю загрузку, руковожу процессами разработки. Вторая: своей команды у меня нет, но есть проекты, которые нужно оценить, спланировать по бюджету, выполнить и запустить в срок.
Именно во второй роли я сейчас работаю в Купере. Легко ли это? Нет, но безумно интересно и драйвово!
Сначала был звонок. «Здравствуйте, мне нужно перевести документ с английского на русский. Только он не совсем обычный». Разберемся, подумал я. А вечером увидел на почте это.
Пока вы спорите о скруглении углов в новой дизайн-системе и попиваете лавандовый раф, где-то в Челябинске ослепленный бликами от раскаленной стали оператор пытается разглядеть ваш элегантный серый шрифт на мониторе 2012 года выпуска. Спойлер: у него не получается.
Дизайнеры, приходящие из разных сфер в Heavy Digital, совершают одни и те же ошибки. Они становятся очевидными только тогда, когда ты снимаешь белые кроссовки, надеваешь каску, проходишь инструктаж по технике безопасности и заходишь в реальный цех.
С 2020 года я адаптирую стерильную эстетику Figma под суровую реальность промышленных мониторов.
Добро пожаловать в цех! Давайте разберем, как не провалить проект на этапе компонентов.
На Хабре уже выходило множество статей о том, что наш мир — это симуляция. Но, несмотря на это, прошу дать мне шанс с этой статьёй, в которой мы рассмотрим фундаментальные вещи, к которым все давно привыкли и не подвергают сомнению, хотя они толсто намекают…
А также мы рассмотрим практический вопрос: что это может значить лично для нас, если симуляционная теория верна.
Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.
Однажды мы в Диске переносили общие данные из шардированного MongoDB в шардированный же PostgreSQL. После переноса пользовательских данных у нас осталась часть данных про общие папки.Их было сложно изолировать внутри шарда пользователя, и они остались в общей БД на MongoDB, которую мы так и назвали — CommonDB. Спустя время мы заметили, что общая БД не справляется с нагрузкой: все запросы перед выполнением должны были сначала получить информацию об общих папках, и только после этого они начинали работать. Поэтому надо было дублировать информацию ближе к другим данным пользователей — на их шарды.
Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.
В статье я хочу поделиться опытом этой масштабной миграции. Под катом покажу, как вообще устроены сложные миграции и как к ним подходить. А также перечислю те пункты, на которые нужно обратить внимание, если вам предстоит миграция под нагрузкой.
Привет, Хабр.
Красивый и интуитивно понятный интерфейс — это моя личная страсть. Я тратил дни, чтобы докрутить свои проекты до нужного мне уровня. В итоге я начал систематически собирать приёмы HTML и CSS, которые мгновенно улучшают восприятие пользователя.
Сегодня я решил показать вам несколько проверенных трюков. Выбрал самые лёгкие в освоении, чтобы вы смогли внедрить их уже сегодня, не отвлекаясь на сложности.
Давайте посмотрим, что я вам подготовил.
Всем привет! Меня зовут Никита Звонарёв, я работаю в команде Яндекс 360 и занимаюсь разработкой бэкенда Яндекс Мессенджера. В статье я расскажу о том, как устроен наш ключевой сервис Fanout, через который проходят все запросы чатов, и как наша команда шаг за шагом дорабатывала алгоритмы балансировки, чтобы выдерживать сотни тысяч RPS без сбоев и утренних страданий дежурного инженера.
Fanout можно считать сердцем Мессенджера: он отвечает за такие запросы, как «выдать историю сообщений чата», «обработать отправленные сообщения», «посчитать количество непрочитанных сообщений» и тому подобное. Fanout держит большую нагрузку — несколько десятков машин обрабатывают более 300 тысяч RPS. Сервис написан на C++, а его особенность в наличии собственной системы балансировки нагрузки. Долгое время она работала хорошо, но в какой‑то момент команда столкнулась с трудностями — расскажу о том, как мы их разруливали.
Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.
Пришло, пришло время (экспертов по опенсорсу) моей истории опенсорс-проекта. Было столько всего, что до технических деталей (почти) не дойдёт – они есть и в более древних свитках статьях.
Началось всё в 2010 году. Я только закончил аспирантуру и попал в новый для меня проект в Интеле фулл-тайм разработчиком. Мне нужно было внедрить автоматическое тестирование десктопных GUI приложений для внутреннего пользования. Опыт подобный уже был накоплен с середины 2006-го тоже в Интеле, но подходящий инструмент надо было еще найти или даже создать. Получилось что-то среднее: найти и воскресить!
КДПВ
Обычно сервер ассоциируется с чем-то дорогим и недоступным обычному человеку. Даже на вторичном рынке они пока еще стоят весьма существенно (если не рассматривать совсем уж допотопные экземпляры). Однако, есть и такие, которые можно приобрести весьма недорого.
Это так называемые блейд-серверы. Блейд-сервер (от англ. blade — лезвие) – концепция использования нескольких компактных серверов в одной общей корзине (шасси). Некоторые узлы сервера (такие как блоки питания, охлаждение, сетевые адаптеры, управление) вынесены за пределы сервера и сделаны общими для всех. Благодаря этому исключается излишнее дублирование и, соответственно, уменьшаются габариты и общее энергопотребление всей сборки. Увеличивается плотность вычислительной мощности на единицу объема серверной стойки. Из-за того, что единичный блейд-сервер бесполезен без корзины, а в корзине избыточен, они не пользуются спросом на вторичном рынке, а потому стоят весьма недорого.
Фото важных семейных событий и видео из путешествий, копии важных документов, музыка, фильмы, которых не найти на стримингах — многие задумывались, как сохранить все самое важное так, чтобы ситуация с не вовремя сломавшейся флешкой не обернулась потерей ценных данных навсегда. Кому-то для спокойствия достаточно Google Drive или Яндекс.Диска, но я решил пойти чуть дальше и построить собственное домашнее облако с приложениями Immich и Nextcloud.
Кстати, привет, Хабр! Я Денис Петухов, Python-разработчик в Cloud.ru и сегодня я расскажу, как построил облако в шкафу. По ходу дела дам практические рекомендации по архитектуре, выбору оборудования, приложений, настройке сети и даже приведу расчеты того, что выгоднее, и сколько электричества «съедает» домашняя хранилка в месяц.
Недавно я перешёл в новую команду и столкнулся с классической задачей — рефакторингом сложной продуктовой фичи. Путь от диагностики проблемы до «продажи» решения был тернист... и нереально интересен. Всеми знаниями, что из него вынес, делюсь в этой статье.
Текст будет полезен не только разработчикам продуктовых команд. Участникам core-команд расскажу про общие принципы рефакторинга, а менеджерам помогу понять, чем отличается зрелое предложение о рефакторинге от обычного «хочу всё переписать».
На сегодняшний день трансформеры правят балом хайпа в мире машинного обучения, особенно после появления ChatGPT и ему подобных языковых моделей. Это стало возможным благодаря лежащему в основе их архитектуры механизму внимания (attention), однако он же и является слабым местом с точки зрения производительности и потребления памяти. Хотя в связи с этим и была разработана изящная концепция Flash Attention (Tri Dao), её существующие реализации имеют ряд ограничений.
Поэтому представляю вашему вниманию первую и единственную open-source реализацию Flash Attention 2 на Triton с поддержкой Linux и Windows, Turing-Blackwell архитектур (теперь можно работать в Google Colab и Kaggle), гомо и гетерогенных кластеров, опциональным детерминизмом, а также возможностью ручной кастомизации ядер (kernels) для более гибкой настройки под каждую GPU архитектуру отдельно. Более подробно о том как это устроено и не только — далее в статье.
Ну и пара свежих новостей внутри для пущего реализма.
Повестка, конечно, застала всех врасплох: с одной стороны люди видят и чувствуют тенденцию, когда крупные компании второпях пытаются внедрить AI для автоматизации бизнес-процессов. Безоса можно понять — ведь если не он, то кто-то другой.
Как эта контора OpenAI появляется из ниоткуда и Google в попыхах пытается...
С момента публикации предыдущей статистики прошел год и пора опять обновить данные, провести анализ по предложениям работы в сфере системного администрирования для планирования индексаций на 2026 год.
У нас уже есть статистика за 2022, 2023 и 2024 года, будем смотреть динамику изменений с ними, пока позволяет ширина таблиц на Habr.
Цели, условия, методика и формат анализа остались без изменений, их можно прочитать в предыдущих статьях или спойлером ниже. Данные по каждой должности сравним с предыдущими периодами по количеству вакансий и по заработным платам.