Обзор конференции Стачка 2019 в Иннополисе

Введение

Конференция “Стачка” уже 7 лет проводится в Ульяновске и сами себя они называют “крупнейшей регональной IT-конференцией. В этом году она впервые прошла не только в Ульяновске, но и в Иннополисе на территории местного университета.

Мне удалось побывать на этой конференции и она поразила меня количеством докладов (в течение двух дней доклады шли в тринадцать паралелльных треков), широтой тематики (тематика секций простиралась от обычных уже бэкенд разработки, QA и искусственного интеллекта до SEO, IT-сообществ и даже графического продакшена). Найти интересные доклады можно было без особых проблем, хотя нужно отметить, что многие из них читались ранее и на других конференциях. Пожалуй, единственным неприятным моментом было отсутствие видеозаписи.

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

Обзоры докладов

Как ускорить А/Б тесты в 10-100 раз (Валерий Бабушкин, X5 Retail Group / Яндекс)

Описание

Доклад состоял из двух частей: в первой Валерий рассказал, что такое A/B тестирование и зачем оно нужно, а во втором показал несколько приёмов, с помощью которых можно быстрее получить результаты теста с нужной степенью уверенности.

Всего было три приёма:

1. Линеаризация - тут мы делаем замену переменной и оцениваем не саму метрику теста (в качестве примера был CTR у какой-то ссылки), а её отличие от значения в контрольной группе. Это значение получается более чувствительным, что сокращает время на получение результата теста с нужной степенью уверенности.
2. Перевзвешивание (reweighting) - оно позволяет решить проблему наличия разных пользователей (с большой активностью и маленькой, “зевак” и реальных покупателей в магазине и т.д.). Основная идея тут в том, что пользователи учитыаются с разными коэффициентами. Про подбор коэффициентов Валерий не рассказал, сославшись на то, что его просили не раскрывать детали (видимо, это коммерческая тайна).
3. Использование теоремы Байеса - основная идея тут была в том, что мы переходим от сравнения с контрольной группой к сравнению с моделью поведения в контрольной группе, созданной с помощью машинного обучения. Детали я не записал и не смог восстановить по презентации, но кажется, что по смыслу это похоже на описанное в статье “Учёт данных о прошлом поведении пользователя в метриках A/B-тестирования”.

Как перестать бояться и начать разрабатывать специализированные структуры данных (Алексей Миловидов, Яндекс)

Описание, презентация

Алексей Миловидов - тимлид команды, занимающейся разработкой ClickHouse, и на его докладе был аншлаг. В докладе Алексей рассказал про задачу анализа фрода для Яндекс.Метрики и решении, которое он делал для хранения необходимой для этого информации. Он рассказал про набор оптимизаций, которые позволили не одном сервере хранить данные для 600К RPS. Мне запомнились эти:

• Cчётчики с вероятностным инкрементом старших байтов для хранения количества запросов к конкретным URL - это позволяет (с погрешностью) хранить счётчики с миллиардными значениями в одном байте:
  
• Hyperloglog для хранения уникального количества (кажется) IP адресов, запрашивающих URL - тут для меня стало откровением, что при снижении точности результата можно очень серьёзно сэкономить место для хранения счётчиков (с нескольких килобайт буквально до пары десятков байт).
• Counting bloom filters - разновидность фильтров Блума, считающие не факт наличия значения в потоке, а количество вхождений (до определённого предела). Они позволяли вообще не хранить информацию об URL, которые запрашиваются слишком редко.

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

“Как разрабатывается популярный OpenSource фреймворк” (Александр Макаров, Yii)

Описание

Александр Макаров рассказал про то, что стоит за разработкой популярного open source продукта. В целом было довольно интересно и я вынес оттуда две основные мысли:

1. Работа над популярным продуктом - это не столько про программирование, сколько про работу с сообществом, которое пользуется этим продуктом.
2. Работа над популярным продуктом требует множество усилий, поэтому стоит подумать, зачем оно автору и зарабатывает ли он на нём что-то. Если нет, то есть серьёзная вероятность, что в какой-то момент проект окажется заброшенным.

Тестирование больших кросс-командных проектов в дедлайн (Павел Сташевский, Lamoda)

Описание

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

1. Выделить список заинтересованных лиц (стейкхолдеров проекта) и собрать из них проектную команду. В этой команде не обязательно должны быть все заинтересованные, но стоит добавить туда “тест лида” (обычно из команды функционала, который будет задет больше всего). Задача тест лида - следить за тестированием всего проекта (и знать проект лучше всех).
2. Разобраться в бизнес-требованиях проекта и разложить их на составляющие (не только с точки зрения IT-систем, но и с точки зрения данных в этих системах и операционных процессов, которые участвуют).
3. Собрать требования и подготовить тест-план, ориентируясь на реальность сценариев и их ценность с точки зрения бизнеса. Это позволяет сократить количество сценариев и “победить” комбинаторный взрыв.
4. После сбора стоит показать сценарии всем членам команды проекта.

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

Профессиональная убедительность для инженеров перед менеджерами (Алексей Пименов, RealResult)

Описание

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

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

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

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

Всё пошло по Кафке (Григорий Кошелев, СКБ Контур)

Описание

Доклад состоял из двух основных частей. В первой Григорий рассказал, как устроена Apache Kafka, а во второй части прошёлся по “граблям”, с которыми они сталкивались. Общий посыл был в том, что нужно очень аккуратно подходить к настройке и следить за изменениями в поведении параметров при обновлении версии. Пересказывать проблемы нет особого смысла - лучше посмотрите презентацию.

Главное, что вынес - что документация к Кафке написана не очень хорошо и если нужно больше информации по тому, как всё устроено и работает, то стоит читать KIP-ы (Kafka Improvement Proposals).

Григорий уже выступал в этом году с похожими докладами: * “А вы Кафку пробовали?” на CodeFest (есть видео и презентация) * “Когда всё пошло по Кафке” на JPoint (есть видео и презентация)

Продукто-ориентированный программист (Дмитрий Шестернин, flowwow.com)

Описание

Рассказ от небольшого онлайн-магазина цветов (как я понял, работающего по Uber модели) про то, как им удаётся работать над продуктом при небольших ресурсах. Основная идея - нанимать программистов, которым интересно думать о продукте, а не тех, кому интересны только технологии.

Из всего доклада запомнилось буквально пара мыслей:

• У них явно определены три основные бизнес-метрики (“трафик”, “конверсия в покупки”, “повторные покупки”) и одна техническая (“снижение стоимости поддержки”) и для любой задачи должна быть определена метрика, которую должна улучшить эта задача. Если её нет, то нужно предварительно разобраться, а стоит ли делать задачу.
• У всей компании внутри есть доступ к финансовым показателям, что позволяет видеть свой вклад от реализации задач. Кроме этого активно практикуется раздача бонусов “спасибо”, с помощью которых дают возможность почувствовать себя важным тем сотрудникам, которым тяжело увидеть свой вклад на графиках.
• Dogfooding - любой сотрудник может периодически получить купон на какую-то сумму и сделать заказ, но потом обязательно должен написать фидбек. Это помогает понять, с какими проблемами сталкиваются реальные клиенты, и побывать в их шкуре.

Забавный факт: идею важности “думания о продукте” Дмитрий подтвердил на деле тем, что за время проведения конференции подключил к flowwow единственный цветочный магазин в Иннополисе.

Rest API сервер от кода до деплоя (Борис Ершов, Nixys)

Описание

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

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

При проблемах в первую очередь откатывается на предыдущую версию сервис, а при необходимости уже потом “по кнопке” откатывается миграция схемы БД. Чтобы это работало нужно думать об обратной соместимости версии базы данных (т.е. не нужно добавлять новую колонку и сразу удалять неиспользуемую, а стоит разделить это на несколько отдельных миграций).

Эластик весом весом в петабайт (Владимир Лила, СКБ Контур)

Описание

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

• почему они используют Kafka для записи данных в Elastic;
• как организованы и как хранятся индексы;
• какие задачи по работе с индексами автоматизированны и почему именно они.

У меня нет практического опыта работы с “эластиком” и было интересно послушать про это. Если тема интересна, то рекомендую посмотреть видео (на “Стачке” видеозаписи не было, но Владимир в этом году выступал с этим же докладом на DUMP, записи откуда можно найти).

Полезные ссылки:

• сборка ElasticSearch с открытой лицензией от Амазон;
• curator - набор утилит для работы с индексами ElasticSearch.

Заключение

В целом конференция мне понравилась (за исключением некоторых организационных моментов) и я могу рекомендовать её к посещению.