* Бизнес каждый день участвует в борьбе за пользователей. В высококонкурентной среде во главу угла ставится скорость реализации бизнес-идей. Если выпуск новых фич затягивается, то вы можете потерять своих клиентов — самое ценное, что есть у любого бизнеса.
* В нашем процессе слабым звеном было тестирование, которое затягивало время прохода задачи на прод от нескольких недель до нескольких месяцев.
* За последние полгода мы автоматизировали, изменяли приемочное тестирование, отменили ручное тестирование на промежуточных этапах выливки задачи и отказались от тестирования того, что не имеет ценности для бизнеса.
* В результате нам удалось увеличить среднюю скорость прохода задачи с 65 до 19 дней и определить направления для дальнейшего ускорения без потерь для бизнеса.

Очевидно, что от ошибок в коде никуда не деться. В то же время их раннее обнаружение и исправление – одна из ключевых задач для повышения качества продукта. Статический анализ – это ещё один ответ на вопрос о том, как можно повысить качество и безопасность кода.

В докладе речь пойдёт о преимуществах и недостатках использования статического анализа кода, о принципах работы, правильных и неправильных сценариях использования, а также о том, как получить максимум пользы от использования анализатора. Будут затронуты важные вопросы борьбы с ложными срабатываниями и внедрения в существующий проект. Дополнительно слушатели смогут насладиться примерами ошибок в коде C++ / C# из различных opensource-проектов.

Популярные реализации cdc-тестирования создают дополнительные проблемы программистам: трата времени на описание контрактов взаимодействия, неактуальность этих контрактов, собственный DSL.

Для того, чтобы избежать всех этих проблем, мы в Avito используем нативные тесты, написанные на языках сервисов-потребителей, которые собираются в docker-образ и запускаются при изменениях в сервисе, от которого они зависят.

В докладе я расскажу, как мы реализовали свое cdc-тестирование и почему мы пришли к такому решению.

Unit-тестирование — это замечательно, но его одного часто недостаточно. Часто хочется дополнительно убедиться, что запущенное предложение будет работать. На помощь приходит интеграционное тестирование.

В докладе я расскажу, как мы тестируем связку из большого числа сервисов и целого зоопарка технологий. Какие варианты пробовали и к чему пришли. Будет про Docker, Testcontainers, а также про Scala.

Облачные сервисы для баз данных (Amazon RDS, Google Cloud SQL) уже автоматизируют существенную часть DBA-задач: разворачивание и базовую настройку новой БД, добавление реплик, создание бэкапов, автоматический failover. Но, в то же время, задачи, связанные с тонким тюнингом, контролем производительности и её оптимизацией, в данный момент не то, что не автоматизированы, но и требуют глубоких знаний «потрохов» конкретной СУБД и множества повторяющихся ручных действий.

Этот доклад будет состоять из двух частей. В первой я представлю новый проект с открытым исходным кодом — "postgres_dba" (https://github.com/NikolayS/postgres_dba). Это набор инструментов для Postgres, обеспечивающий полуавтоматическую диагностику узких мест производительности БД, не требующий глубоких знаний реализации Постгреса.

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

Пройдя по следующим пунктам, вы сможете построить Continuous Database Administration pipeline в своём проекте из доступных компонентов:
- почему сейчас так непросто находить узкие места производительности Postgres, если вы не являетесь экспертом;
- какие конкретно действия делают эксперты, осуществляя поиск узких мест и соответствующих решений;
- как эти действия можно и нужно автоматизировать;
- проведение автоматизированных экспериментов в облаках;
- доступные на данный момент opensource-компоненты для построения Continuous Database Administration pipeline: pg_stat_statements, pg_stat_kcache, auto_explain, pgBadger, pgreplay, docker, patroni.

Ну, и напоследок, мы затронем вопросы создания AI, который мог бы помочь DBA и разработчикам быстрее находить и решать проблемы.

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

Мы разрабатываем платформу IPTV/OTT-телевидения. У платформы около 10 миллионов пользователей.

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

Существующие решения, такие как Elastic Search или Tarantool, нам не подошли либо по функциональным возможностям, либо по производительности.

В результате мы создали и опубликовали в Open Source новую in-memory БД - Reindexer, которая по поисковому функционалу не уступает Elastic или MongoDB, а по скорости работы превосходит их в разы, а иногда и на порядки.

Я расскажу о том, что "умеет" Reindexer, покажу примеры использования в проектах и, конечно, в докладе будет сравнение производительности с существующими на рынке БД.

MySQL 8.0 - это новая версия СУБД MySQL, которая недавно объявлена стабильной. Одними из интересных возможностей MySQL, которые доступны, начиная с этой версии, являются обобщенные табличные выражения (Common Table Expressions) и оконные функции.

Данный доклад расскажет о том:
- Что такое обобщенные табличные выражения?
- В чем разница между нерекурсивными и рекурсивными выражениями?
- Как можно использовать рекурсивные выражения для работы с иерархическими данными?
- Зачем еще могут пригодиться нерекурсивные и рекурсивные табличные выражения?
- Каким именно образом в MySQL реализована поддержка табличных выражений, и что стоит иметь в виду при их использовании.

Кроме того, мы поговорим об оконных функциях:
- Что это такое и зачем они нужны?
- Какие именно оконные функции поддерживаются в MySQL 8.0?
- Как в MySQL реализованы оконные функции, и что это значит для пользователя.

В данном докладе я разберу основные ошибки в приложениях, которые возникают на этапе проектирования и написания кода приложения. И возьму только те ошибки, которые ведут к bloat в Postgresql. Как правило, это начало конца производительности вашей системы в целом, хотя изначально никаких предпосылок к этому не было видно.

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

Этот доклад не будет наполнен внутренней технической информацией, интересной только для DBA, он целиком ориентирован на разработчиков backend-систем, так как они самые главные пользователи баз данных. И именно им придется иметь дело с DBA и DevOps, чтобы устранить возникшие проблемы в связке БД - приложение.

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

В докладе расскажем об особенностях lambda-архитектур, платформе микросервисов Amazon Lambda, а также подводных камнях и победах с Node.JS и многопоточной Java. Затронем тему эффективной разработки и тестирования надежного и устойчивого многопоточного кода. Поделимся опытом организации промежуточного дифференциального хранилища и непростым выбором между LMDB (lightning memory-mapped database), LevelDB (используется в Bitcoin blockchain), Apache Derby и Berkeley DB. Подробно расскажем о тонкостях использования инфраструктуры очередей на базе Amazon SQS, NoSQL в DynamoDB и мониторинге системы для предотвращения потерь данных клиентов и минимизации рисков последствий отказов и аварий дата-центров.

Несмотря на то, что данных сейчас много почти везде, аналитические БД все еще довольно экзотичны. Их плохо знают и еще хуже умеют эффективно использовать. Многие продолжают "есть кактус" с MySQL или PostgreSQL, которые спроектированы под другие сценарии, мучиться с NoSQL или переплачивать за коммерческие решения. ClickHouse меняет правила игры и значительно снижает порог вхождения в мир аналитических DBMS.

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

Конкурентный доступ к данным является одним из основных преимуществ современных реляционных СУБД. С точки зрения пользователя всё происходит легко и просто. Очевидно, что внутри всё становится несколько сложнее и СУБД проделывает существенный объем работы для обеспечения удобства.

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

Эта тема будет, безусловно, полезна всем, кто администрирует базы данных. Разработчики также смогут почерпнуть для себя много полезной информации, т.к. я постараюсь объяснить почему ДБА “хотят странного” от разработчиков.

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

Расскажу про базовые канонические подходы к снаряду, про ряд опробованных за 15+ лет регулярного написания хэшей вручную ловких трюков, возможно, успеем немного поговорить про связанные штуки типа блокчейна (trollface) или там какого DHT.

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

Я расскажу, что такое корутины, и в чем отличие stackful и stackless.
Далее мы опустимся в недра исходного кода различных библиотек (libcoro, libtask и protothreads), чтобы понять, какими способами можно создать корутины на низком уровне.

Интернет, к которому мы привыкли, обречён.

На том, что принято называть Internet protocol suite, не осталось живого места. Протокол IP уже вовсе не тот, что раньше, HTTP тоже сменил версию, замена TCP активно готовится, а SSL вообще больше не существует. Эту ползучую революцию в сообществе принято встречать с энтузиазмом, в крайнем случае - со сдержанным оптимизмом.

Автор общается с идеологами этой революции и, как обычно, придерживается мнения, что у всего без исключения есть как достоинства, так и недостатки. В докладе предлагается перемыть косточки IPv6, QUIC, DNS-over-HTTPS, TLS v1.3 и HTTP/2, включая их историю, особенности дизайна и известные нюансы внедрения; политические моменты разработки протоколов нового поколения и психологию толпы инженеров.

Конечная цель - определить, куда мы все идём и как будем чувствовать себя, когда там окажемся.

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

Я расскажу, почему нельзя просто написать бесконечный цикл и обработать бесконечные данные. Расскажу о pull- и push-моделях, о ленивых вычислениях и обработке ошибок, об эквивалентности бесконечных программ.

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

Распознаванием лиц сейчас никого не удивишь, если у вас не:
- 330 миллионов пользовательских аккаунтов;
- ежедневно заливается 20 млн пользовательских фотографий;
- максимальное время на обработку одного фото не должно превышать 0.2 сек (забегая вперед, скажу, что нам удалось сделать это быстрее);
- ограниченные объемы оборудования для решения задачи.

В докладе будут рассмотрены:
- pipeline для: построения векторов пользователей и поиска пользователя на загруженном фото;
- обучение нейросети: построение dataset'а > обучение нейросети > построение датасета > варить до готовности;
- детектор лиц на каскаде нейросетей и его оптимизация;
- построение нормализованного вектора пользователя на GPU;
- железо и оптимизации, запуск в облаке, отказоустойчивость.

Многие компании, как и Lamoda, уже перешли на микросервисную архитектуру и рассказывают о положительном эффекте. Мы уже в начале перехода видели ряд опасностей от возможной связности сервисов. Некоторых рисков удалось избежать, другие напрыгнули из-за угла, и с ними пришлось сражаться на месте. Тем не менее, time to market удалось сократить в 2 раза и сохранить контроль над микросервисами, несмотря на постоянно увеличивающееся их число.

В докладе я поделюсь накопленным за последний год опытом и отвечу на следующие вопросы:
* В какой момент микросервисы становятся тем же монолитом и наносят ответный удар?
* Где найти ответственных, когда у тебя 30+ сервисов в ecom-платформе “общаются” с 60+ другими внутренними системами?
* Что ни в коем случае не стоит делить на микросервисы?

В Badoo так сложилось, что разработчик несет ответственность за те фичи, которые он "приручил".

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

- Не спамом единым или ситуация с рассылкой почты в 2018 году. Сколько можно терпеть "современные" MTA?
- Гарантия доставки, прелести SMTP, обход ограничений почтовых служб, жонглирование IP-адресами и прогрев серверов – поговорим об архитектуре.
- Почему мы выбрали Elixir, как нам это помогло, и где мы наступили на грабли.
- ТТХ полученного решения и сравнение с другими подходами.

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

Популярный веб-сервер nginx вы уже наверняка знаете. В этом докладе мы расскажем про другие проекты, которые мы разрабатываем в России, США, Англии и Ирландии. Вместе эти проекты составляют платформу для запуска, масштабирования и доставки приложений.

По порядку:

* Crossplane (5 минут). Часто случается необходимость понимать и разбирать конфигурацию NGINX. Эта библиотека занимается парсингом конфига и составлением из него JSON-объекта. Она специально разработана как отдельный продукт и используется внутри Amplify и Controller. Разрабатывается в Сан-Франциско.

* Amplify (5 минут). Система мониторинга для различных инсталляций NGINX и сопутствующего ПО. Умеет работать с любыми конфигурациями, разбирается в настройках NGINX и, кроме красивых графиков и аналитики, умеет подсказывать, как улучшить ваш конфиг. Разрабатывается в Москве и Сан-Франциско.

* njs (10 минут). Проект по внедрению JavaScript в конфигурацию веб-сервера nginx. Изначально разработан Игорем Сысоевым, сейчас поддерживается командой в Москве. Сделан как отдельный модуль и используется для создания сложной логики запроса и ответа. Мы покажем примеры использования и преимущества njs перед известными скриптовыми альтернативами - Lua, Perl.

* Unit (10 минут). Динамический сервер нового поколения, поддерживающий запуск приложений на разных языках и управление ими через удобный REST API. Unit разрабатывает непосредственно Игорь Сысоев в Москве.

* Kubernetes Ingress Controller (5 минут). Плагин, позволяющий использовать NGINX в качестве прокси и балансировщика нагрузки в Kubernetes. Существует два разных проекта с похожими задачами, но с несколько разным функционалом. Мы рассмотрим Ingress Controller, который делает сообщество kubernetes, и нашу собственную разработку. Наш Ingress Controller разрабатывается в Кембридже, Великобритания.

* nginMesh (10 минут). Проект по использованию NGINX в качестве сервисного прокси в Istio Service Mesh. Данный подход - Service Mesh - это новый баззворд 2017-2018 года. Istio, Service Mesh от Google, занимается управлением трафиком между большим количеством сервисов и поддерживает широкий набор плагинов и модулей. Проект nginMesh разрабатывается нашими инженерами в городе Саннивейл, Калифорния.

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

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

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

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

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

Будет произведен разбор самого подхода и основных паттернов. Поговорим о практических кейсах, ошибках, которые допускали и к чему пришли.

Казалось бы, кто только не делал tagging search, и при его разработке невозможно ошибиться... Да и вообще, а надо ли его разрабатывать, если он уже разработан? На эти и многие другие вопросы я попытаюсь ответить в данном докладе.

Мы рассмотрим типовые структуры базы данных для tagging search и проведем оценку достоинств и недостатков каждой структуры, далее проведем сравнение со специализированным функционалом на базе серверов полнотекстового поиска на примере Apache Solr. Замеры производительности будут производиться на основе базы данных тегов из StackOverflow за 5 лет.

Мы посмотрим как решения для tagging search можно использовать для faceted navigation и какие могут возникнуть подводные камни.

Наконец, будет рассмотрена текущая архитектура решения tagging search в крупном enterprise-проекте с 10000 тысячами запросов в секунду и 1000 пользователей, работающих одновременно, проблемы данного решения, и как мы собираемся решать их в будущем.

IPIP.net is the first and only Geo-IP database company based on real time BGP/ASN data computing. We'll share how we make Geo-IP data accurate and use cases in different industries.

The untold truth is there is no standard of Geo-IP location. Enterprises, carriers and data centers are more centralized, and end/mobile users are widely distributed and moving frequently which significantly increase the complexity of Geo-IP accuracy.

IPIP.net will introduce the way how we make our Geo-IP DB accurate including:
1. Global monitoring platform and how it works;
2. Data inaccuracy triggering and fixing;
3. Global WHOIS / BGP / ASN / RADB reference;
4. Global Internet Exchange DB;
5. IPIP.net rDNS and backbone IP db;
6. Cooperation between ISPs, clients, partners and community.

За последний год с небольшим, поиск Avito получил значительное развитие. Пришла пора поделиться текущими результатами. В докладе изложен как продуктовый, так и технический взгляд на поиск Авито, а также взаимосвязь этих аспектов.

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