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

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

Системное администрирование

Опыт создания резервного и кластеризованного заббикс - сервиса

Заббикс - популярная открытая система мониторинга, используется большим количеством компаний.
Я расскажу об опыте создания кластера мониторинга.
В докладе я коротко упомяну о сделанных ранее правках (патчах), которые существенно расширают возможности системы и готовят базу для кластера (выгрузка истории в кликхаус, асинхронный поллинг). И подробно рассмотрю вопросы, возникшие при кластеризации системы - разрешение конфликтов идентификаторов в БД, немного о "CAP theorem" и мониторинге с распределенными БД, и ньюансах работы Zabbix в кластерном режиме: резервирование и координирование работы серверов и прокси, о "доменах мониторинга" и новом взгляде на архитектуру системы.
Коротко расскажу о том, как запустить кластер у себя, где взять исходники, какие доп. настройки потребуются для кластера.

Отказоустойчивость
,
Распределенные системы
,
Логирование и мониторинг
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Программный комитет ещё не принял решения по этому докладу

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

Контейнерные базы Oracle (CDB/PDB) и их практическое использование для разработки ПО

О контейнерных базах Oracle, краткий обзор технологии
- понятие мультиарендности (Multitenant)
- преимущества технологии Multitenant
- особенности реализации в Oracle
Использование контейнерных баз в качестве макетов
- Методика развертывания макетов на PDB
- Создание эталонных баз
- Получение макетов из эталонной базы
- Сравнение макетов на виртуальных машинах и PDB
- по затрачиваемым ресурсам (память, ЦПУ, дисковое пространство)
- по временным показателям (развертывание, обновление, удаление лишних копий)
- по удобству управления макетами
- по пригодности для проведения нагрузочного тестирования

Oracle
,
Базы данных / другое
,
Методы и техника разработки ПО
,
Архитектуры / другое
,
Технологии виртуализации и контейнеризации
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

Causal consistency: from research papers to commercial product.

As a commercial product, MongoDB’s implementation of causal consistency needs to address and balance the entire
spectrum of requirements starting with performance and scalability to database security so malicious attacks cannot
break or compromise the system. I will discuss MongoDB’s multi-dimensional requirements for an applied solution, including performance, scalability, and security. These requirements were used as a guide for implementation decisions and ultimately lead to the need to combine aspects from several research areas. In this talk, I will present in details the key approaches to causal consistency in academic research and how they were combined to match the production requirements.

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

Time series данные в реляционной СУБД. Расширения TimescaleDB и PipelineDB для PostgreSQL. А так можно было?!

В докладе будут рассмотрены популярные расширения TimescaleDB и PipelineDB для PostgreSQL, позволяющие хранить и обрабатывать time series данные.

IT в общем и IoT в частности продолжают непрерывно проникать во все сферы деятельности человека, требуя хранить все больше данных. Если есть экспертиза в PostgreSQL, но пока рано говорить о BIG DATA, стоит посмотреть в сторону расширений для вашей реляционной СУБД. Возможно, этого будет достаточно!

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

PostgreSQL
,
Базы данных / другое
Программный комитет ещё не принял решения по этому докладу

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

Как мы тестируем фичу от ТЗ до пост-продакшна и сохраняем дружеские отношения внутри команды

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

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

Автоматизация разработки и тестирования
,
Большие проекты/команды
,
Тестирование мобильного ПО
Программный комитет ещё не принял решения по этому докладу

В единстве сила: как мы пишем тесты всей командой

Девопс кажется недостижимой мечтой, а лечь в направлении цели хочется уже сейчас? Нам тоже.

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

Расскажу нашу историю успеха и поделюсь лайфхаками и подводными камнями.

Python
,
Code Review
,
Автоматизация разработки и тестирования
,
Функциональное тестирование
Программный комитет ещё не принял решения по этому докладу

Устойчивость GraphQL к нагрузке по сравнению с REST

Прежде чем внедрять GraphQL в наши разработки мы проверяли технологию на предмет разных аспектов: порог вхождения разработчиков, сложность поддержки и, конечно же, устойчивость к нагрузкам. Обкатывать неизведанную технологию на рабочем проекте "в бою" опасно.

Для начала мы провели нагрузочное тестирование на части бизнес логики, переписанной на GraphQL. Результаты, полученные в тестировании, дали нам общие ответы на вопрос - в каких проектах стоит внедрять GraphQL, а в каких эффективнее остаться на Rest.

API
,
PHP
,
Бэкенд / другое
,
Отказоустойчивость
Программный комитет ещё не принял решения по этому докладу

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

Выявление и решение проблем производительности Java Backend’a

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

Java
,
Оптимизация производительности
,
Профилирование
,
Логирование и мониторинг
,
Нагрузочное тестирование
,
Профилирование и отладка кода
Программный комитет ещё не принял решения по этому докладу

On-boarding пользователей из CSV-файла - за пару дней сделаете?

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

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

JavaScript
,
Фронтенд / другое
,
Java
,
Бэкенд / другое
Программный комитет ещё не принял решения по этому докладу

Транзакции и блокировки: практические кейсы

Даже у опытных разработчиков иногда случаются проблемы с транзакционными базами данных: неконсистентность данных, долгие блокировки, дедлоки, плывущая статистика. Расскажу с самого начала о транзакциях, как их правильно применять, в том числе в сложных случаях, как избежать частых проблем и повысить производительность приложения.

Миграции данных
,
Бэкенд / другое
,
Базы данных / другое
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Рефакторинг
,
Архитектура данных, потоки данных, версионирование
Программный комитет ещё не принял решения по этому докладу

Контракт тесты и Spring Cloud Contract. Вы все еще пишете E2E тесты? Тогда мы идем к вам!

В распределенных системах, таких как микросервисные приложения, тестирование взаимодействия между различными ее составными частями является очень важной задачей. Зачастую для ее решения используются End-To-End тесты, но существует специализированный подход - использование паттерна Consumer Driven Contract (CDC). Основная идея паттерна CDC - это публикация контракта взаимодействия, и написание на его основе тестов для всех сторон, использующих и реализующих этот контракт. Одним из инструментов, который применяет принцип CDC для Java приложений является Spring Cloud Contract. В своем докладе я подробно расскажу о возможностях этого инструмента, а также поделюсь нашим опытом его использования

API
,
Java
,
Микросервисы, SOA
,
Юнит-тестирование
Программный комитет ещё не принял решения по этому докладу

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

Практика

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

https://habr.com/ru/company/avito/blog/446710/


Доклад осветит плавный переход с монолитной архитектуры в Авито к микросервисной архитектуре. Как различными командами и составами мы постепенно избавлялись от монолита. Опишу схему архитектуры, к которой мы движемся и что уже удалось реализовать. На примерах расскажу, какие плюсы мы получили сразу, над чем пришлось поработать достаточно много и с какими проблемами мы столкнулись в процессе распила.
Постараюсь вдохновить слушателей доклада начать применять микросервисный подход в своих ежедневных задачах и уделять больше внимания верхнеуровневой архитектуре.

PHP
,
Микросервисы, SOA
,
Отказоустойчивость
,
Lua
,
GO
Программный комитет ещё не принял решения по этому докладу

Инфраструктура поиска Яндекс.Маркета

Доклад расскажет об основных аспектах управления трафиком в поиске на Яндекс.Маркете.
- Балансировка трафика и отказоустойчивость сервиса;
- Надёжные обновления;
- Параллельные мониторинги;
- Эксперименты и отладка новых технологий в продакшене;
- Инструменты для тестирования производительности на всех этапах разработки и выкатки.

Отказоустойчивость
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
Программный комитет ещё не принял решения по этому докладу

Как перейти на микросервисы и не попасть в hell

1. Зачем нужен переход на микросервисы, или А чего вам в монолите-то не жилось, динозаврики?
2. Что такое microservices hell, или Как мы вляпались в оборотную сторону Луны.
3. Пути снижения рисков, или Ищем свою Ариадну.
4. Что получилось в итоге, или Папа, а правда, что солнце каждое утро всходит, а вечером заходит?
5. Пути потенциального роста, или Road to h... hell or happiness?

На опыте проекта по разработке сервисной службы управления таксопарками (аналог Яндекс-такси) я расскажу, как мы переходили на микросервисы и решали все сопутствующие проблемы. И что из этого получилось.

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

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

Ставка на новеньких, или Как мы выращиваем PHP-синьоров из студентов

1. Школа программистов. Сколько времени и какие усилия нужны для становления полноценного разработчика из студента - hello world.
2. Онлайн-обучение как ключевой канал обучения программистов из регионов и привлечения талантливых ребят в коммерческую разработку.
3. Развитие штатных специалистов внутри компании, внутренняя политика, основанная на обучении.
4. Выявление талантов на ранних этапах и быстрый путь в тимлиды. Какими качествами должен обладать разработчик, чтобы быстро расти.

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

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

Swift for machine learning 3.0

Swift появился в 2014 году как новый язык программирования для разработки ПО для устройств Apple. В 2015 году его начали использовать для разработки backend’ов. И вот, в 2018 году до него добрались специалисты по машинному обучению из Google.

В своём докладе я расскажу, почему пора перестать смеяться при упоминании в одном предложении и машинного обучения и Swift’а. Что делает Swift пригодным для машинного обучения, и почему в будущем он сможет конкурировать с Python в этой области.

Мы разберём core-механизмы, позволяющие быстро и просто строить модели машинного обучения на Swift’е.
Построим простенькую нейронную сеть.

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

Менеджмент крупных проектов

План тестирования - рабочий инструмент развития проекта для всей команды

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

И все эти трое могут как лебедь рак и щука тянуть проект в разные стороны (для повышения качества). И у каждого есть какое-то понимание как повышать качество.

Задача доклада - достать эту таску из голов ключевых ролей, смахнуть пыль и сделать уже что-нибудь. Чтобы идти в одном направлении, планировать улучшения в виде задач спринта и вот это всё.

Совместная работа, система контроля версий, организация веток
,
Инструментальная поддержка, декомпозиция задач
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Выбор стратегии долгосрочного развития, KPI
,
Продуктовая разработка
,
Управление / другое
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Как настроить цикл разработки и измерять эффективность продукта цифрами

Эпиграф. Метрика сама по себе не появится. Ее надо разрабатывать

Продуктовый подход к разработке существует не только в продуктовых компаниях. Расскажем, как он выглядит у нас (независимой лаборатории технологических инноваций) и как позволяет нам принимать решения для/за заказчика, о развитии продукта.

Обратная связь, на основе которой мы выстроили процесса разработки продукта – это сбор и отслеживание бизнесовых, технических и технологических показателей.

Бизнесовые – эффект нашего продукта на развитие бизнеса заказчика: количество пользователей, объем продаж в штуках, деньгах и другие значимые для бизнеса заказчика показатели.

Технологические показатели: скорость выполнения операций, количество пользовательских ошибок, текущее количество пользователей, И т.д.

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

Основа доклада — это описание процесса разработки на основе обратной связи. Доклад будет содержать шаги разработки продукта и описание метрик и действий на каждом шаге.

Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Продуктовая разработка
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Как работать с бесконечным бэклогом

Как работать с большим потоком требований: разделяй, но получай системный результат.

Типичный бэклог крупного проекта: 700 незакрытых Story, 150 из них заведены за последние две недели, 15 авторов задач, все срочные. Знакомо?

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

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

• вводим категоризацию задач, чтобы превратить большой бэклог в несколько маленьких, но тематических;
• каждый заказчик принимает в работу свою часть бэклога и ведет приоритизацию;
• PM - администратор процесса, отслеживающий корректность процесса.
• консолидированное принятие решений на основе самых приоритетных задач бэклогов.
• releaseNotes как инструмент описания версии в разрезе каждого бизнес-результата или функционального модуля.

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

• В каждый момент времени мы можем выделить приоритетное направление разработки в большом бэклоге - это ускоряет принятие решений.
• Участники проекта не "пропадают" в большом бэклоге, но работают в контексте - это экономит время и снижает риски.
• На отчетность по динамике проекта и согласование плана спринта тратится 30 минут подготовки PM'ом и 1 час в неделю с заказчиком.
• Сборка ReleaseNotes полностью автоматизирована и использует категоризацию для более полного описания поставки.

Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
Программный комитет ещё не принял решения по этому докладу

Архитектура и производительность фронтенда

RUST + WEBASSEMBLY

* Зачем это нужно?
* О производительности в JavaScript, сильные и слабые стороны браузерных движков.
* Какие проблемы решает WebAssembly.
* Какие выгоды от использования Rust при компиляции в WebAssembly.
* Инструменты для разработки - сборка и публикация модулей, взаимодействие с JavaScript, отладка.
* Прирост производительности по сравнению с JavaScript.
* Внедрение в существующее веб-приложение.
* Опыт применения в реальном проекте.

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

DevOps и эксплуатация

ClickHouse и тысяча графиков

Мы долго жили с самописным подсчётом метрик на местах. «Гибкость» этого подхода приводила нас в уныние. А потом мы попробовали ClickHouse и подсели. Так у нас появились те самые графики о работе:
* нашего CDN — от стандартных rps и трафика до выявления аномалий;
* транспорта статистики — вплоть до поиска потерь и дубликатов.

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

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