Привет, Хабр!

Меня зовут Максим Шевченко и последние два года я занимаюсь развитием платформы экспериментов в Okko, одном из ведущих онлайн-кинотеатров в России. Наша команда разрабатывает инструменты, которые позволяют продуктовым командам самостоятельно проводить А/В тесты и анализировать их результаты. Мы отвечаем за весь цикл экспериментов – от помощи в дизайне и выдаче пользователям разного опыта до предоставления рекомендаций по принятию решений.

Когда речь заходит об А/В-тестах, первыми в голову приходят статистические методы: различные параметрические или непараметрические критерии и многое другое. Но если взглянуть шире, становится понятно, что статистика – лишь часть экспериментов. Довольно важная часть, но не единственная. В контролируемых онлайн-экспериментах также важны сплитование трафика, удобное управление изменениями пользовательского опыта, обработка данных, дашборды, система мониторинга и многое другое.

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

Привет, Хабр! Меня зовут Александр Абрамов и я ML Lead продукта в SberDevices. Эта статья — про обучение core-моделей retrieval-based диалоговых систем, поговорим про хинты для ускорения обучения и сходимости, также затрону тему общей схемы inference и оптимизации её компонентов. Речь пойдёт о ML с позиции пайплайнов и продакшена виртуального ассистента Салют.

Делимся лучшими по мнению зрителей докладами с TechLead Conf 2024 в Санкт-Петербурге, прошедшему в рамках TeamLead Conf++ 2024. Насколько это объективно, решайте сами. Премьера!

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

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

А потом я заставляю себя шагнуть на сцену и говорю заученное “всем привет, меня зовут Олег Федоткин”. Примерно после этих слов я попадаю в поток и прихожу в себя только после фразы “спасибо за внимание, буду рад ответить на ваши вопросы”.

Пять минут после выступления — одни из лучших в моей жизни. Легкая эйфория, живые эмоции от реакции публики и вопросов. Я обожаю публичные выступления.

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

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

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

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

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

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

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

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

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

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

Привет, Хабр! В двух предыдущих статьях здесь и тут мы рассказывали историю создания одного из компонентов платформы экспериментов в компании Okko — сервиса сплитования трафика. В тех статьях говорилось о множестве изменений и улучшений, которые претерпел Python-код, чтобы работать достаточно быстро. Но как бы качественно не был написан код, все усилия могут сойти на нет, если он будет запущен в неправильной среде. В этой статье продолжим рассказ об оптимизациях и улучшениях, но сейчас речь будет идти не столько об особенностях предметной области и решаемой бизнес-задачи, сколько о том, как мы архитектурно организовали работу сервиса для получения минимального времени ответа.

Кому пришла в голову идея отправлять SQL запросы в data lake? Оказывается, это позволяет компаниям более гибко и эффективно анализировать свои данные за счёт уменьшения потребности в ETL и снижения нагрузки на корпоративное хранилище. Рассмотрим, какие популярные SQL-движки умеют это делать и как им это удаётся.

Меня зовут Владимир Озеров, я руковожу компанией Querify Labs. Мы уже порядка 10 лет занимаемся распределённым SQL, делаем всевозможные SQL-движки, в частности CedrusData — коммерческий движок на основе опенсорс проекта Trino. Сегодня поговорим про то, каким образом устроен ряд SQL-движков, которые обрабатывают данные от data lake.

По образованию я инженер разгонных блоков и космических аппаратов, и погружение в производство началось еще в институте. Меня учили разрабатывать ракеты и спутники. А дальше оказалось, что в России это крайне малооплачиваемая отрасль. В итоге хобби админство в институте, стало работой, но знания полученные в ходе обучения очень помогают в текущих задачах. В производстве у меня было много проектов. Я реализовывал системы по техосмотрам и ремонтам в энергетике, участвовал в проектах на Уралхиммаше и на Дальневосточных распредсетях и много где ещё. Был даже опыт управления командой на рынке оптовых продаж электроэнергии России. А потом друзья позвали присоединиться к команде цифровизации в СИБУР.

Меня зовут Максим Горозий. Я тимлид в Т-Банке, работаю над нашей образовательной платформой, которая служит для разных направлений бизнеса. В ИТ больше 10 лет и успел поработать в двух GameDev-компаниях, где управление памятью занимало весомое время в оптимизации производительности кода. Люблю строить системы и взаимосвязи между ними, а также EdTech и преподавание, а еще больше — работать над инструментами обучения. Хотя начинал с C, я идеологический фанат Go, DDD и Agile.

«Оно тормозит» — классическая цитата разработчиков. Расскажу, как разобраться в причинах и научиться управлять памятью, медитируя над профайлингом, чтобы все работало быстро.

В прошлой статье мы начали историю создания одного из компонентов платформы экспериментов в компании Okko — сервис сплитования трафика.

Там были описаны небольшие, но эффективные оптимизации Python-кода, которые могут быть полезны в практически любом сервисе на этом языке.

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

Привет, Хабр! Это Александр Капитанов и Александр Нагаев из Sber Devices. Мы занимаемся задачами компьютерного зрения: генерацией, матированием и редактированием изображений, сегментацией, портретной гармонизацией, заменой лиц, распознаванием жестов. А с недавних пор ещё и распознаваниtv русского жестового языка.

Поговорим о том, что заставило нас решать данную проблему. Затронем теорию жестового языка — подозреваю, что мало кто с ней знаком. Расскажем, как мы собирали собственный датасет для распознавания русского жестового языка и затронем тему обучения моделей для решения данной задачи. Также поделимся с вами результатом и немного расскажем про семейство наших моделей signflow. 

Всё началось в 2018 году, я сопровождал и развивал проекты американских стартапов из реальной отрасли экономики. Потом меня пригласили в крупнейший в России ритейл запчастей. Там было 250 СТО, 120 городов и 150 складов. Это были реальные склады, реальные продукты, реальные люди. Всё это мы сопровождали командой в 20 человек, и я понял, что объёмы — это интересно. Но в ритейле, в отличие от промышленности, очень короткий горизонт планирования. Я быстро достиг стеклянного потолка и понял, что надо двигаться дальше.

Перешёл в сферу цифрового телевидения, а оттуда в промышленность. Начал DevOps инженером, а через год стал руководить DevOps направлением. Наша команда из пяти человек за год выполнила 250 проектов. Поэтому нужно было срочно наращивать команду и быстро вводить её в процессы. Но на онбординг и вход в проект уходило три недели. Пришлось всё менять.

Когда-то я работал системным инженером в одном из крупнейших российских системных интеграторов. Там внедрял и сопровождал системы электронного документооборота. В 2010 году «Гринатом» искал специалиста с моим опытом, чтобы сопровождать свою отраслевую систему документооборота. Мне понравились условия и возможность развивать новые продукты фактически с нуля, и я согласился. С тех пор работаю там, и за 14 лет работы развитие не останавливается. Растёт мое подразделение, и внедряемые технологии, и компетенции. Мы постоянно привносим новые решения, и это не останавливающееся движение очень мотивирует.

Привет, Хабр! Меня зовут Ирина Николаева и я — руководитель R’n’D отдела машинного обучения в компании Raft Digital Solution. Я внедряла различные ML-модели: от анализа временных рядов и Computer Vision до высоконагруженных дата-инженерных сервисов. Эта статья написана по мотивам моего доклада на Highload ++ 2023.
В статье вас ждёт: обзор LLM-моделей, техники работы с ними через призму MLOps, разбор лицензий и требований к железу. А так же трюки с квантизацией и файн-тюнингом «на сладкое». Главный дисклеймер статьи в том, что данные лидербордов и технических требований актуальны на момент выступления на Highload, то есть ноябрь 2023, но не всё из них актуально до сих пор. Но если бы я обновила всю статью, была ли бы это та же самая статья — вопрос риторический, поэтому было принято решение оставить всё как есть.

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

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

Если говорить про кофе, то он есть))

Работа в Яндексе ставит огромное количество технических вызовов, которые интересно решать. И один из них — это производительность основной очереди сообщений YDB Topics. Посмотрим, может ли опенсорсный продукт от Яндекса конкурировать с Apache Kafka по производительности.

Меня зовут Зевайкин Александр. Я уже практически 20 лет в IT. Начинал с преподавания в вузе, запускал множество стартапов, руководил командами разработки. В текущий момент я работаю в Яндексе в отделе, занимающимся одной из высоконагруженных систем. Это разработка распределённой базы YDB, в частности, функциональности YDB Topic.

Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?

Меня зовут Никита Галушко. Я старший программист-разработчик в отделе высоконагруженных систем и оптимизации ВКонтакте. В статье поделюсь, какие хитрости помогут использовать Go на полную мощность.

Как бороться с типовыми причинами отказа? А самое главное — как их обнаружить? Рассмотрим лучшие элементы инженерной практики, обеспечивающие высокую доступность системы и оперативное расследование инцидентов. Коснёмся памяти, разберём базу данных, поговорим про ТСР-соединения.

Меня зовут Константин, я работаю в Газпромбанке. Занимаюсь транзакционными системами: платежами, переводами, также участвовал в разработке системы СБП в Газпромбанке. В своей практике столкнулся с десятками языков программирования, но в настоящий момент остановился на Java и Kotlin. Поэтому я буду рассказывать про проблемы backend разработки на этих языках.

Привет, Хабр! Меня зовут Георгий Меликов, я из VK Cloud и руковожу там инфраструктурной разработкой (IaaS) облака, где мы создаём SDN (Software Defined Networks) — программно определяемые сети; SDS (Software Defined Storages) — программно определяемые хранилища; и другие решения.

А ещё на досуге я — контрибьютор файловой системы OpenZFS с 2016 года.

В этой статье поговорим о наших подходах к разработке на примере создания нашего SDN. Мы ставим перед собой несколько целей:

1) Разрабатывать быстро, чтобы итерации были явно очерченными  и понятными. Хотим, чтобы у нас вырабатывался дофамин от закрытия спринтов, и было понятно, как жить дальше.

2) Эксплуатировать системы без людей — полностью автоматически.

3) Использовать принцип «Дизайн на отказ». Система должна уметь переживать любой возможный сбой и проблему, т.е.обладать так называемым качеством самовосстановления (self-healing).

Предлагаю пройтись эволюционно от простого примера "облака на минималках" до нашей production среды на несколько ЦОДов, собрав по пути проблемы из нашей реальной жизни.

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

Много интересных кейсов связано с применением ИИ. Например, интеллектуальная видеоаналитика для оценки процента шлака в ковше и качества заготовки. С помощью ИИ нам удалось достичь точности 99,98% и низкого показателя ложных срабатываний. Нейросеть пропускает брак лишь в 0,02% случаев. Конечно, благодаря этому качество продукта выросло. Кроме того, мы получили объективный инструмент анализа. Система помогает человеку обнаружить отклонения и подсказывает об этом своевременно, что повышает выход годного. Если одна за другой идут бракованные заготовки, значит, где-то на предыдущем этапе нарушен техпроцесс, и коллегам нужно об этом сообщить.