Заявки на доклады

Поиск по тегам:

Аппаратное обеспечение, инфраструктура

Мы 10 лет занимались софтом для видеостриминга и увидели возможность спроектировать и разработать программно-аппаратный комплекс для транскодирования. Т.е. железо+софт.

Что нас сподвигло на это? Насколько страшно влезть в такую разработку? Обязательно ли надо минимизировать стоимость железа до последней копейки? Можно ли ввязываться в такой проект, если стартовая партия меньше миллиона экземпляров?

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

Как проектировать материнку в расчете на автоматизацию тестирования?

Программный комитет ещё не принял решения по этому докладу

Цифровая культура / CTO-трек

Уже много было сказано про "распил монолитов". Много было дискуссий про то, переписывать или нет. Активно идут обсуждения о том как и от чего отталкиваясь нужно бороться с возрастающей сложностью микросервисов.
Поговорить об этом хорошо, но когда это делать. Реинжиниринг, техдолг, рефакторинг.
Все эти движения в рамках успешного, активно развивающегося, высоконагруженного сервиса - очень болезненно вписываются в беклог продукта. Который расписан может быть на два года вперёд, и у продакта возникает острое желание послать к черту всю эту "новую этику" и тупо утилизировать ресурс команды.
Если на это пойти, сломаться, поддаться темной стороне силы - то со временем продукт превращается в сильно связанного кровоточащего Левиафана, к которому сильно выросшая в размерах команда со всех сторон пытается наживую прибить новые части тела.
Но взять и посадить этот самолёт, у которого SLO 24/7, в ангар для исправления накопленного техдолга шансов нет никаких.
Как быть? Строить самолёт на лету! И да, это возможно. Управление техдолгом это не сказка о розовых пони, это болезненный для техдиректора процесс, который вытягивает из него все соки, заставляет непрерывно находить компромисс, верить настраивать и вдохновлять, когда кажется никто не верит.
И это норм, это просто такая работа.
Про это как раз и расскажу. Как сделали техдолг видимыми и осязаемым. Как боролись за реальное понимание в головах как менеджеров, так и разработчиков - что из этого действительно страшно, а что пока ещё норм. Как меняли методы и способы выделения времени, ресурсов, людей на решение задач. На какие уловки я иду что бы это все протаскивать.

Программный комитет ещё не принял решения по этому докладу

Блокчейн

1) Архитектура корпоративных блокчейн приложений.
2) Мастерчейн - первая сертифицированная платформа блокчейн.
3) Финансовые сервисы на Мастерчейн.
4) Особенности внедрения и эксплуатации распределенных приложений - построение модели управления блокчейн сети.
5) Будущее блокчейн приложений.

Программный комитет ещё не принял решения по этому докладу

Импортозамещение

Хочется завести трактор, но не понятно за что хвататься или просто страшно?
Приходи на этот доклад, где мы обсудим:
- Какая бывает релокация и что он неё ожидать.
- О чем на самом деле не стоит переживать, а на что обратить внимание.
- Самому или через работу?
- Чем тебе могут помочь, а что твои фантазии.

Программный комитет ещё не принял решения по этому докладу

Бэкенд, теория программирования

Есть множество способов поймать спам-письма за информацию об отправителе или аномалии в заголовках письма. Но как быть, если письмо было отправлено через форму обратной связи крупного сайта? Или через зараженную машину в доверенной сети?
Единственное, что остается в таких случаях - это анализировать текст сообщения.
В своем докладе я расскажу про то, как мы исследовали миллионы спам-писем и разработали систему под названием Spam Term Generator. Эта технология объединила в себе использование CTPH (Context Triggered Piecewise Hashing), DBSCAN (Density-Based Spatial Clustering of Applications with Noise) и адаптированный LCS (Longest Common Substring) алгоритм для того, чтобы автоматически определять похожие спам-письма и извлекать из них кусочки повторяющегося текста, которые могут быть использованы для детектирования спам-рассылок.
Во время презентации я расскажу, как наша технология устроена изнутри, с какими сложностями мы столкнулись в процессе разработки, как мы избежали "brute force" анализа исходных текстов и каких результатов нам удалось достичь.

Программный комитет ещё не принял решения по этому докладу

Нейронные сети, искусственный интеллект

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

Программный комитет ещё не принял решения по этому докладу

BigData и машинное обучение

В этой презентации мы представим DeepQuarantine (DQ), облачную технологию для обнаружения и карантина потенциальных спам-сообщений. Спам-атаки становятся все более разнообразными и могут нанести вред пользователям электронной почты. Несмотря на высокое качество и производительность систем фильтрации спама, обнаружение спам-кампании может занять некоторое время. К сожалению, в этом случае некоторые нежелательные сообщения доставляются пользователям. Чтобы решить эту проблему, мы создали DQ, который обнаруживает потенциальный спам и некоторое время хранит его в специальной папке карантина. Полученное время позволяет нам дважды проверять сообщения, чтобы повысить надежность решения по борьбе со спамом. Из-за высокой точности технологии большая часть почты, помещенной на карантин, является спамом, что позволяет клиентам использовать электронную почту без задержки. Наше решение основано на применении сверточных нейронных сетей на заголовках MIME для извлечения нетривиальных признаков из большого объема исторических данных. Мы оценили предложенный метод на реальных данных и показали, что DQ снижает на 30% False-Negative вердикты.

Программный комитет ещё не принял решения по этому докладу

Управление командой разработки (тимлиды)

Команда реализовывает приходящие идеи продакт менеджера одной компании и делает сайт по таймингу для другой. Для структурирования, приоритизации, распределения, планирования таких задач они подтягиваются в общий Jira-проект с универсальным flow, трекерами и интеграцией с Bitbucket.

Кроме прозрачности процессов мы получили прирост эффективности в среднем на 13 500 рублей в месяц в команде из 9 человек. В докладе расскажу о том, как перестраивались инструменты и люди.

Программный комитет ещё не принял решения по этому докладу

Лет 15-20 назад трава была зеленее, а аутсорс совсем другой. Знаете страшилку про то, что человек отправил Pull-request на open-source, и его штрафовали? А если съездил на конференцию или о, ужас - на сбор frontend-сообщества, то его сразу увольняли?

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

Не знали? Вот и многие не знают, а мы хотим поделиться и рассказать, как оно бывает)

Программный комитет ещё не принял решения по этому докладу

Тестирование, нагрузочное тестирование

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

В этом докладе я расскажу о методике online-оценки ёмкости сервиса и планирования ресурсов, применяемой в Яндекс.Маркете.

Программный комитет ещё не принял решения по этому докладу

Базы данных и системы хранения

Душещипательная история о том как мы выбирали кластерную файловую систему под виртуалки и контейнеры, с какими трудностями столкнулись и почему остановили свой выбор на LINSTOR.

Хранилище LINSTOR построено на свободных технологиях: ZFS, LVM, DRBD и ориентрировнно на максимальную производительность и высокую доступность данных.

В данном докладе я расскажу про наш опыт его использования в Kubernetes, Proxmox и OpenNebula:

• На наглядном примере посмотрим как оно работает и чем отличается от того же Ceph и других решений.
• Под какие цели стоит использовать LINSTOR, а когда его внедрение может быть нецелесобразным.
• Разберёмся как работает тонкая настройка и планирование ресурсов.
• Проблемы DRBD и их решения.

Программный комитет ещё не принял решения по этому докладу

Архитектуры, масштабируемость

Программный комитет ещё не принял решения по этому докладу

В OZON мы разработали и успешно внедрили инструмент DMP (Data Management Platform), который автоматизирует процесс создания сегментов через фильтрацию пользовательских событий. DMP - программная платформа для сбора, хранения, систематизации и анализа данных о взаимодействии пользователей с OZON. Ежедневно мы обрабатываем более 1,5 млрд. событий от миллионов пользователей. Эти данные мы используем для построения сегментов с целью планирования рекламных кампаний, проведения маркетинговых акций и персонализированных коммуникаций.

В своем докладе я расскажу:
- как мы пришли к необходимости разработки собственной платформы DMP;
- об архитектуре платформы;
- как обеспечивается время ответа < 10 мс;
- как мы используем ClickHouse для хранения пользовательских событий;
- каким было сегментирование до внедрения конструктора и как используем сегменты для повышения бизнес метрик.

Программный комитет ещё не принял решения по этому докладу

Публичное Облако != Ваш локальный ДЦ. И относится к нему надо по другому.

Я расскажу чем публичное облако отличается от вашего локального ДЦ в плане особенностей сети , предоставления compute ресурсов и реализаций managed сервисов ( таких как Kubernetes и Databases).
Дальше мы посмотрим как на основе этих особенностей строить масштабируемую и высокодоступную инфраструктуру для различных типов сервисов.

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

Программный комитет ещё не принял решения по этому докладу