Разработать видеоплатформу за 90 дней
Этой весной мы оказались в очень весёлых условиях. Из-за пандемии стало ясно, что наши летние конференции необходимо переносить в онлайн. А чтобы провести их в онлайне качественно, нам не подходили готовые софтовые решения, требовалось написать собственное. И на это у нас было три месяца.
Понятно, что это были увлекательные три месяца. Но со стороны не вполне очевидно: что вообще представляет собой платформа для онлайн-конференций? Из каких частей она состоит? Поэтому на последней из летних конференций DevOops я расспросил тех, кто отвечал за эту задачу:
- Николай Молчанов — технический директор JUG Ru Group;
- Владимир Красильщик — прагматичный Java-программист, занимающийся бэкендом (вы также могли видеть его доклады на наших Java-конференциях);
- Артём Никонов — отвечает за весь наш видеостриминг.
Кстати, на осенне-зимних конференциях мы будем использовать улучшенную версию той же платформы — так что многие хабрачитатели ещё окажутся её пользователями.
— Каким был состав команды?
Николай Молчанов: У нас есть аналитик, дизайнер, тестировщик, три фронтендера, бэкендер. И, конечно, T-shaped специалист!
— Как в целом выглядел процесс?
Николай: До середины марта у нас к онлайну не было готово вообще ничего. А 15 марта завертелась вся карусель с онлайном. Мы завели несколько репозиториев, спланировали, обсудили базовую архитектуру и сделали всё за три месяца.
Это, конечно, прошло классические этапы планирования, архитектуры, выбора фич, голосование за эти фичи, политики этих фич, их дизайна, разработки, тестирования. В итоге 6 июня мы выкатили всё в прод на TechTrain. На всё про всё было 90 дней.
— Получилось ли успеть то, на что мы коммитились?
Николай: Раз мы сейчас участвуем в конференции DevOops в онлайне — значит, получилось. Я лично закоммитился на главную вещь: принесу заказчикам инструмент, при помощи которого можно будет сделать конференцию в онлайне.
Задача стояла так: дайте нам инструмент, с помощью которого мы сможем транслировать наши конференции обладателям билетов.
Все планирование было разбито на несколько этапов, и все фичи (около 30 глобальных), были поделены на 4 категории:
- которые мы сделаем обязательно (без них жить не можем),
- которые мы сделаем во вторую очередь,
- которые мы никогда не сделаем,
- и которые никогда-никогда не сделаем.
Все фичи из первых двух категорий мы сделали.
— Я знаю, что всего было заведено 600 JIRA-задач. За три месяца вы сделали 13 микросервисов, и подозреваю, что они написаны не только на Java. Вы использовали разные технологии, у вас поднято два Kubernetes-кластера в трех зонах доступности и 5 RTMP-стримов в Amazon.
Давайте теперь разберёмся с каждой составляющей системы по отдельности.
— Начнём с того, когда у нас уже есть видео-картинка, и она передаётся на какие-то сервисы. Артём, расскажи, как происходит этот стриминг?
Артём Никонов: Общая схема у нас выглядит так: изображение с камеры → наша пультовая → локальный RTMP-сервер → Amazon → видеоплеер. Подробнее писали об этом на Хабре в июне.
Вообще есть два глобальных пути, как это можно делать: либо на железе, либо на базе софтверных решений. Мы выбрали путь софта, потому что это проще в случае с удалёнными спикерами. Не всегда есть возможность привезти спикеру в другой стране железку, а поставить ПО спикеру кажется проще и надёжнее.
С точки зрения железа у нас есть некоторое количество камер (в наших студиях и у удалённых спикеров), некоторое количество пультов в студии, которые иногда приходится чинить прямо во время эфира под столом.
Сигналы от этих устройств попадают в компьютеры с платами захвата, ввода/вывода, звуковыми карточками. Там сигналы микшируются, собираются в лейауты:
Пример лейаута на 4-х спикеров
Пример лейаута на 4-х спикеров
Дальше беспрерывный эфир обеспечивается с помощью трёх компьютеров: есть одна главная машина и пара работающих по очереди. Первый компьютер собирает первый доклад, второй — перерыв, первый — следующий доклад, вторый — следующий перерыв и так далее. А главная машина микширует первую со второй.
Таким образом получается некий треугольник, и в случае падения любого из этих узлов мы можем быстро и без потери качества продолжить доставлять клиентам контент. Такая ситуация у нас была. На первой неделе конференций мы чинили одну машину, включали/выключали. Кажется, что люди довольны нашей отказоустойчивостью.
Далее потоки из компьютеров попадают на локальный сервер, у которого две задачи: роутить RTMP-потоки и записывать бэкап. Таким образом, у нас есть несколько точек записи. Затем потоки видео отправляются в часть нашей системы, построенную на амазоновских SaaS-сервисах. Используем MediaLive, S3, CloudFront.
Николай: А что там происходит до того, как видео попадёт к зрителям? Вы же должны его нарезать как-то?
Артём: Мы сжимаем со своей стороны видео, отправляем его в MediaLive. Там запускаем транскодеры. Они перекодируют видео в режиме реального времени в несколько разрешений для того, чтобы люди могли смотреть их на телефонах, через плохой интернет на даче и так далее. Потом эти стримы режутся на чанки, так работает протокол HLS. На фронтенд мы отдаем плейлист, в котором есть указатели на эти чанки.
— Мы используем разрешение 1080р?
Артём: По ширине у нас как 1080p видео — 1920 пикселей, а по высоте чуть меньше, картинка более вытянутая — на это есть свои причины.
— Артём описал, как видео попадает в стримы, как распределяется на разные плейлисты для разных разрешений экранов, режется на чанки и попадает в плеер. Коля, расскажи теперь, что это за плеер, как он потребляет стрим, почему HLS?
Николай: У нас есть плеер, который наблюдают все зрители конференции.
По сути, это обёртка над библиотекой hls.js, на которой написано много других плееров. Но нам была необходима очень специфическая функциональность: перемотка назад и отметка на месте, в котором находится человек, какой доклад он сейчас смотрит. Также нужны были собственные лейауты, всякие логотипы и все прочее, что встроилось у нас. Поэтому мы решили написать собственную библиотеку (обёртку над HLS) и встроить это на сайт.
Это корневая функциональность, так что её реализовали практически первой. А потом вокруг этого всё уже обрастало.
По факту плеер через авторизацию получает от бэкенда плейлист со ссылками на чанки, соотнесённые с временем и качеством, выкачивает нужные и показывает пользователю, проводя по ходу некоторую «магию».
Пример таймлайна
— Прямо в плеер встроена кнопка для выведения таймлайна всех докладов…
Николай: Да, мы сразу решали проблему навигации пользователя. В середине апреля решили, что не будем транслировать каждую из наших конференций на отдельном сайте, а объединим все на одном. Чтобы пользователи билетов Full Pass могли свободно переключаться между разными конференциями: и прямым эфиром, и записями прошедших.
А чтобы пользователям было проще передвигаться по текущему стриму и переключаться между треками, решили сделать кнопку «Весь эфир» и горизонтальные карточки докладов для переключения между треками и докладами. Там есть управление с клавиатуры.
— Были какие-то технические сложности с этим?
Николай: Были с полоской прокрутки, на которой отмечаются точки начала разных докладов.
— В итоге вы реализовали эти отметки на полосе прокрутки раньше, чем похожее сделал YouTube?
Артём: У них это тогда было в бете. Кажется, что это довольно сложная фича, потому что они частично тестировали ее на пользователях в течение последнего года. И вот теперь она дошла до прода.
Николай: Но мы действительно до прода донесли быстрее. Честно сказать, что за этой простой фичей стоит огромное количество и бэкенда, и фронтенда, и расчетов и матана внутри плеера.
— Давайте разберемся, как этот контент, который мы показываем (карточку доклада, спикеры, сайт, расписание), выходит на фронтенд?
Владимир Красильщик: У нас есть несколько внутренних айтишных систем. Есть система, в которой заведены все доклады и все спикеры. Есть процесс, по которому докладчик принимает участие в конференции. Спикер подает заявку, система её захватывает, дальше есть некий пайплайн, по которому создаётся доклад.
Так спикер видит пайплайн
Эта система — наша внутренняя разработка.
Дальше из отдельных докладов нужно построить расписание. Как известно, это NP-сложная задача, но мы её как-то решаем. Для этого запускаем другой компонент, который формирует расписание и засовывает его в сторонний облачный сервис Contentful. Там всё выглядит уже как таблица, в которой есть дни конференции, в днях — временные слоты, а в слотах — доклады, перерывы или спонсорские активности. Так что контент, который мы видим, располагается в стороннем сервисе. И стоит задача донести его до сайта.
Казалось бы, сайт — это просто страница с плеером, и ничего сложного тут нет. За исключением того, что это не так. Бэкенд, стоящий за этой страницей, идёт в Contentful, достает оттуда расписание, формирует некоторые объекты и отсылает на фронтенд. При помощи вебсокет-соединения, которое делает каждый клиент нашей платформы, мы с бэкенда на фронтенд закидываем ему обновление в расписании.
Реальный случай: спикер прямо во время конференции сменил работу. Надо поменять ему плашку компании-работодателя. Как это происходит с бэкенда? По вебсокету всем клиентам летит обновление, и дальше фронтенд уже сам перерисовывает таймлайн. Все это проходит бесшовно. Совокупность облачного сервиса и нескольких наших компонентов дают нам возможность сформировать весь этот контент и предоставить его фронту.
Николай: Здесь важно уточнить, что наш сайт не является классическим SPA-приложением. Это и свёрстанный, отрендеренный сайт, и SPA. На самом деле Google видит этот сайт как отрендеренный HTML. Это хорошо для SEO и для доставки пользователю контента. Он не ждет загрузки 1,5 мегабайт JavaScript, чтобы потом увидеть страницу, он сразу видит уже отрендеренную страницу, а вы это чувствуете каждый раз, когда переключаете доклад. Всё получается за полсекунды, так как контент уже готов и выложен в правильное место.
— Подведём черту под всем вышесказанным, перечислив технологии. Тёма рассказал, что у нас есть 5 Amazon-стримов, туда доставляем видео и звук. Там у нас bash-скрипты, с их помощью запускаем, конфигурим…
Артём: Это происходит через API AWS, там есть еще много побочных технических сервисов. Мы разделили свои обязанности так, что я доставляю на CloudFront, а фронтенд- и бэкенд-разработчики оттуда забирают. У нас некоторое количество своих обвязок для упрощения выкладки контента, который мы делаем потом в 4К и т.д. Поскольку сроки были очень сжатые, мы практически целиком сделали это на базе AWS.
— Дальше все это попадает в плеер, используя бэкенд системы. У нас в плеере TypeScript, React, Next.JS. И на бэкенде у нас есть несколько сервисов на С#, Java, Spring Boot и Node.js. Это все разворачивается с помощью Kubernetes, используя инфраструктуру Яндекс.Облака.
Ещё хочу заметить, что когда мне понадобилось познакомиться с платформой, это оказалось несложно: все репозитории находятся на GitLab, всё хорошо названо, написаны тесты, есть документация. То есть даже в авральном режиме заботились о таких вещах.
— Мы таргетировались по бизнес-требованиям на 10 000 пользователей. Самое время рассказать про бизнес-ограничения, которые у нас были. Мы должны были обеспечивать высокую нагрузку, обеспечивать выполнение закона о сохранении персональных данных. А что ещё?
Николай: Изначально мы отталкивались от требований к видео. Самое главное — распределённое хранение видео по миру для быстрой доставки клиенту. Из других — разрешение 1080р, а также перемотка назад, что у многих других в лайв-режиме не реализовано. Позже мы добавили возможность включить скорость 2x, с её помощью можно «догнать» лайв и дальше смотреть конференцию в реальном времени. И ещё по ходу появилась функциональность разметки таймлайна. Плюс к этому мы должны были быть отказоустойчивыми и выдерживать нагрузку 10 000 соединений. С точки зрения бэкенда это примерно 10 000 соединений умножить на 8 запросов на каждый рефреш страницы. А это уже 80 000 RPS/сек. Довольно много.
— Ещё были требования к «виртуальной выставке» с онлайн-стендами партнёров?
Николай: Да, это нужно было сделать довольно быстро и универсально. У нас было до 10 компаний-партнёров на каждую конференцию, и страницы их всех нужно было заверстать за неделю-две. При этом контент у них немного различается по формату. Но был сделан определённый шаблонизатор, собирающий эти страницы на лету, практически без дальнейшего участия по разработке.
— Было еще требования по аналитике просмотров в реал-тайме и статистике. Знаю, что мы используем для этого Prometheus, а расскажите подробнее: какие требования мы выполняем по аналитике, и как это реализуется?
Николай: Изначально у нас есть маркетологические требования по сбору для А/В-тестирования и по сбору информации для того, чтобы понять, как правильно клиенту доставлять лучший контент в дальнейшем. Еще есть требования по некой аналитике по партнерским активностям и аналитика, которую вы видите (счетчик посещений). Вся информация собирается в реал-тайме.
Эту информацию мы можем выдавать в агрегированном виде даже спикерам: сколько людей тебя смотрели в определенный момент времени. При этом для соблюдения 152 ФЗ личный кабинет и персональные данные не трекаются никак.
На платформе уже есть и маркетологические инструменты, и наши метрики для измерения пользовательской активности именно в реалтайме (кто смотрел какую секунду доклада), чтобы строить графики посещения докладов. На основе этих данных делаются исследования, которые позволят сделать следующие конференции лучше.
— У нас есть механизмы антифрода?
Николай: В связи с жёсткими временными рамками с точки зрения бизнеса изначально не ставилась задача сразу же блокировать лишние соединения. Если два пользователя заходили под одним и тем же аккаунтом, они могли посмотреть контент. Но мы знаем, сколько одновременных просмотров было с одного аккаунта. И нескольких особо злостных нарушителей мы забанили.
Владимир: Надо отдать должное, один из забаненных пользователей понял, почему это случилось. Пришёл, извинился и обещал купить билет.
— Чтобы это все происходило, вы должны полностью трассировать всех пользователей от входа до выхода, всегда знать что они делают. Как устроена эта система?
Владимир: Я бы хотел рассказать про аналитику и статистику, которую мы потом анализируем для успешности доклада или можем предоставить потом партнерам. Все клиенты присоединены по вебсокет-соединению к определенному кластеру бэкенда. Там стоит Hazelcast. Каждый клиент в каждый период времени отсылает, что он делает и какой трек он смотрит. Дальше эта информация быстрыми Hazelcast-джобами агрегируется и отсылается в обратку всем, кто смотрит эти треки. Мы видим в углу, сколько людей сейчас находятся вместе с нами.
Эта же информация складируется в Mongo и уезжает в наше озеро данных, по которому мы имеем возможность строить более интересный график. Приходит вопрос: сколько уникальных пользователей посмотрели данный доклад? Мы идем в Postgres, там пинги всех людей, которые пришли по id этого доклада. Собрали, агрегировали уникальных, и теперь можем понять.
Николай: Но при этом мы получаем ещё реалтайм-данные с Prometheus. Он натравлен на все Kubernetes-сервисы, на сам Kubernetes. Собирает абсолютно всё, и с Grafana мы можем строить любые графики в реальном времени.
Владимир: С одной стороны, мы это сгружаем для дальнейшей обработки типа OLAP. А для OLTP приложение сгружает все это дело в Prometheus, Grafana и графики даже сходятся!
— Тот самый случай, когда графики сходятся.
— Расскажите, как выкатываются динамические изменения: если доклад отменился за 6 минут до начала, какая цепочка действий? Какой пайплайн срабатывает?
Владимир: Пайплайн очень условный. Есть несколько возможностей. Первая — программа формирования расписания сработала и изменила это расписание. Изменённое расписание выгружается в Contentful. После чего бэкенд понимает, что есть изменения по данной конференции в Contentful, берёт и пересобирает. Всё собирается и отсылается по websocket.
Вторая возможность, когда всё происходит в бешеном темпе: редактор руками меняет в Contentful информацию (ссылку на Telegram, презентацию докладчика и т.д.) и срабатывает та же самая логика, что и в первый раз.
Николай: Все происходит без рефреша страницы. Все изменения происходят абсолютно бесшовно для клиента. Также и с переключением докладов. Когда подходит время, меняется доклад и интерфейс.
Владимир: Также и временные отсечки начала докладов в таймлайне. В самом начале ничего нет. А если навести мышку на красную полоску, то в какой-то момент, благодаря режиссеру трансляции, появятся отсечки. Режиссер ставит правильное начало трансляции, бэкенд это изменение схватывает, рассчитывает соответственно расписанию конференции время начала и окончания докладов всего трека, отправляет нашим клиентам, плеер рисует отсечки. Теперь пользователь может спокойно навигироваться в начало и конец доклада. Это было жесткое бизнес-требование, очень удобное и полезное. Ты не тратишь время, чтобы найти настоящее время начала доклада. А когда мы сделаем превью, будет вообще замечательно.
— Я бы хотел спросить про деплоймент. Коля и команда в начале убили много времени, чтобы настроить всю инфраструктуру, в которой у нас всё разворачивается. Расскажи, из чего это всё?
Николай: У нас изначально было требование с технической точки зрения к продукту максимально абстрагироваться от какого-либо вендора. Прийти в AWS делать Terraform-скрипты конкретно AWS-овские, или конкретно яндексовские, или Azure-овские и т.д. не очень подходило. Мы должны были в своё время куда-то съехать.
Первые недели три мы постоянно искали путь, как это лучше сделать. В итоге пришли к тому, что Kubernetes в данном случае — это наше всё, потому что позволяет делать автоматически-масштабируемые сервисы, автовыкатку и получить из коробки практически все сервисы. Естественно, надо было обучить все сервисы работе с Kubernetes, Docker, и команде тоже научиться.
У нас два кластера. Тестовый и продовский. Они абсолютно одинаковые с точки зрения железа, настроек. Имплементируем инфраструктуру как код. Все сервисы автоматическим пайплайном раскатываются в три среды из фичи-веток, из мастер-веток, из тестовых, из GitLab. Это максимально интегрировано в GitLab, максимально интегрировано с Elastic, Prometheus.
Мы получаем возможность быстро (для бэкенда в течение 10 минут, для фронтенда в течение 5 минут) выкатить изменения в любую среду со всеми тестами, интеграциями, запуском функциональных тестов, интеграционных тестов на среде, и еще и протестировать нагрузочными тестами на тестовой среде примерно то же самое, что мы хотим получить в продакшене.
— Вы почти всё тестируете, тяжело поверить, как вы всё написали. Можете рассказать как по бэкенду по тестам: насколько все покрыто, какие тесты?
Владимир: Написано два типа тестов. Первые — компонентные тесты. Тесты уровня подъема всего спрингового приложения и базы в Testcontainers. Это проверка самых высокоуровневых бизнес-сценариев. Я не тестирую функции. Мы тестируем только какие-то крупные штуки. Например, прямо в тесте эмулируется процесс логина пользователя, запрос этим пользователем билетов, куда он может сходить, запрос доступа на просмотр стрима. Очень понятные пользовательские сценарии.
Примерно то же самое реализовано в так называемых интеграционных тестах, которые реально бегут на среде. Фактически, когда очередной деплоймент в прод раскатывается, на проде также бегут настоящие базовые сценарии. Тот же самый логин, запрос билетов, запрос доступа до CloudFront, проверка того, что стрим действительно цепляется с моими разрешениями, проверка режиссерского интерфейса.
На данный момент у меня на борту примерно 70 компонентных тестов и около 40 интеграционных. Покрытие очень близко к 95%. Это по компонентным, по интеграционным поменьше, там столько просто не надо. Учитывая то, что в проекте всякие кодогенерации, это очень хороший показатель. Никакого другого способа сделать то, что мы сделали за три месяца, не было. Потому что если бы мы тестировали ручным образом, отдавая фичи нашей тестировщице, а она бы находила баги и возвращала нам на фиксы, то этот round trip по отлаживанию кода был бы очень долгий, и мы бы не влезли ни в какие сроки.
Николай: Условно, чтобы провести регресс на всей платформе при изменении какой-то функции, нужно два дня сидеть и тыкать везде.
Владимир: Поэтому большой успех, что, когда я эстимирую фичу, говорю, что мне нужно 4 дня на две простые ручки и 1 websocket, Коля разрешает. Он уже привык, что в эти 4 дня заложены 2 типа тестов, и потом, скорее всего, это будет работать.
Николай: У меня тоже написано 140 тестов: компонентных + функциональных, которые делают то же самое. Все те же самые сценарии тестируются и на продакшене, на тесте и на деве. Также недавно у нас появились функциональные базовые UI-ные тесты. Так мы покрываем самые базовые функциональности, которые могут развалиться.
Владимир: Конечно же, стоит рассказать про нагрузочные тесты. Нужно было проверить платформу под нагрузкой, приближенной к реальной, чтобы понять, как оно все, что происходит с Rabbit, что происходит с JVM-ками, сколько реально надо памяти.
— Я не знаю точно, тестируем ли мы что-нибудь на стороне стримов, но я помню, что были проблемы с транскодерами, когда мы делали митапы. Тестировали ли мы стримы?
Артём: Тестили итеративно. Организовывая митапы. В процессе организации митапов было примерно 2300 JIRA-тикетов. Это просто шаблонные вещи, которые люди делали, чтобы сделать митапы. Мы брали части платформы на отдельную страницу для митапов, которой занимался Кирилл Толкачев (tolkkv).
Честно говоря, больших проблем не было. Буквально пару раз ловили баги по кэшированию на CloudFront, решили довольно быстро — просто перенастроили политики. Багов было значительно больше в людях, в системах стриминга на площадке.
Во время конференций пришлось писать еще несколько экспортёров для того чтобы покрыть больше оборудования и сервисов. Местами приходилось делать свои велосипеды только ради метрик. Мир AV (аудио-видео) железа не очень радужный — у тебя есть какое-то «API» оборудования, на которое ты просто не можешь повлиять. И далеко не факт, что получится забрать ту информацию, которая тебе нужна. Вендоры железа реально медленные, и от них почти невозможно добиться желаемого. Итого более 100 железок, отдают они не то, что нужно, а ты пишешь странные и избыточные экспортёры, благодаря которым можно хоть как-то дебажить систему.
— Я помню, как до начала конференций мы частично дозакупали оборудование.
Артём: Закупали компьютеры, ноутбуки, батарейные блоки. На данный момент мы можем жить без электричества 40 минут. В июне в Питере были сильные грозы — так что такое отключение у нас было. При этом к нам приходят несколько провайдеров оптическими линками из разных точек. Это действительно 40 минут даунтайма здания, при которых у нас будет гореть свет, работать звук, камеры и т.д.
— С интернетом у нас похожая история. В офисе, где находятся наши студии, мы между этажами протащили лютую сеть.
Артём: У нас 20 ГБит оптики между этажами. Дальше по этажам где-то оптика, где-то нет, но все-таки меньше, чем гигабитных, каналов нет — мы гоняем по ним между треками конференции видео. Вообще очень удобно работать на своей инфраструктуре, на офлайн-конференциях на площадках так редко получается делать.
— Еще не работая в JUG Ru Group, я видел, как за ночь разворачиваются аппаратные на офлайн-конференциях, где стоит большой монитор со всеми метриками, которые вы строите в Grafana. Сейчас также есть помещение-штаб, в котором сидит команда разработки, которая во время конференции чинит какие-то баги и разрабатывает фичи. При этом есть система мониторинга, которая выводится на большой экран. Артём, Коля и другие ребята сидят и смотрят, чтобы это все не падало и красиво работало.
— Вы хорошо рассказали о том, что у нас есть стриминг с Амазоном, есть плеер с вебом, все написано на разных языках программирования, обеспечивается отказоустойчивость и другие бизнес-требования, в том числе есть личный кабинет, который поддерживается для юридических и физических лиц, и мы можем интегрироваться с кем-то по OAuth 2.0, есть антифрод, блокировка пользователя. Мы можем динамически выкатывать изменения, потому что сделали это хорошо, и при этом это все тестируется.
Мне интересно узнать, какие были курьёзы с тем, чтобы что-то запустилось. Были ли странные ситуации, когда вы разрабатывали бэкенд, фронтенд, получалась какая-то дичь и вы не понимали, что с этим делать?
Владимир: Мне кажется, такое было только последние три месяца. Каждый день. Как вы можете увидеть, все мои волосы вырваны.
Владимир Красильщик после 3 месяцев, когда получалась какая-то дичь и никто не понимал, что с этим делать
Каждый день что-то такое было, когда был такой момент, когда ты берешь и рвёшь на себе волосы, либо понимаешь, что больше никого нет, и только ты можешь это сделать. Первым большим мероприятием у нас был TechTrain. 6 июня в 2 часа ночи у нас еще не было раскатано продакшен-окружение, его раскатывал Коля. И не работал личный кабинет, как сервер авторизации по OAuth2.0. Мы превратили его в провайдера OAuth2.0, чтобы к нему подключить платформу. Я работал, наверное, уже 18 час подряд, смотрел в компьютер и ничего не видел, не понимал, почему он не работает, и удалённо Коля смотрел в мой код, искал баг в конфигурации Spring, нашел, и ЛК заработал, и в продакшене тоже.
Николай: И за час до TechTrain релиз состоялся.
Здесь сложились очень многие звёзды. Нам крайне повезло, потому что у нас сложилась просто супер-команда, и все задрайвились идеей сделать онлайн. Все эти три месяца нас драйвило то, что мы «делали YouTube». Я не позволял себе рвать волосы, а говорил всем, что всё получится, потому что на самом деле всё давно просчитано.
— Можете ли рассказать, сколько было максимально людей на сайте на одном треке? Были ли проблемы с производительностью?
Николай: Проблем с производительностью, как мы уже говорили, не было. Максимальное количество людей, которые были на одном докладе, — 1300 человек, это на Heisenbug.
— Были ли проблемы с локальным просмотром? И возможно ли техническое описание со схемами того, как это все устроено?
Николай: Сделаем об этом позже статью.
Локально можно отдебажить даже стримы. Как только начались конференции, это стало даже проще, потому что появились продакшен-стримы, которые мы можем смотреть постоянно.
Владимир: Как я понимаю, фронтенд-девелоперы локально работали с моками, а потом, поскольку время выкатки на дев во фронте тоже небольшое (5 минут), посмотреть, что там с сертификатами, проблем никаких нет.
— Все тестируется, дебажится, даже локально. Значит, напишем статью со всеми техническими особенностями, покажем, расскажем все со схемами, как было.
Владимир: Сможете взять и повторить.
— За 3 месяца.
— Всё описанное вместе звучит круто с учётом того, что это сделано маленькой командой за три месяца.
Николай: Большая команда этого бы не сделала. А вот маленькая группа людей, которые довольно плотно и хорошо друг с другом общаются и могут договориться, могла бы. У них нет каких-то противоречий, архитектура была придумана за два дня, была финализирована и фактически не поменялась. Есть очень жесткая фасилитация поступающих бизнес-требований с точки зрения наваливания фич-реквестов и изменений.
— Что оказалось в вашем списке дальнейших задач, когда летние конференции уже состоялись?
Николай: Например, титры. Бегущие строки на видео, всплывашки в некоторых местах видео в зависимости от показа контента. Например, спикер хочет задать вопрос в аудиторию, и на экране всплывает голосовалка, которая обратно в бэк по результатам голосования уходит самому спикеру. Какая-то социальная активность в виде лайков, сердечек, оценок доклада во время самой презентации, чтобы можно было, не отвлекаясь потом на формы обратной связи, заполнить фидбэк в нужную секунду. Первоначально вот так.
А ещё добавление всей платформе, кроме стримингового и конференционного, также постконференционное состояние. Это плейлисты (в том числе составленные пользователями), возможно, контент с других прошедших конференций, интегрированные, промаркированные, доступные для пользователя, ну и доступные для просмотра на нашем сайте (live.jugru.org).
— Ребята, спасибо большое за ответы!
Если среди читателей есть те, кто был на наших летних конференциях — поделитесь вашими впечатлениями от плеера и трансляции. Что было удобно, что раздражало, что хочется увидеть в будущем?
Если платформа заинтересовала и захотелось увидеть её «в бою» — мы снова используем её на наших осенне-зимних конференциях. Их целый ряд, так что почти наверняка есть подходящая для вас.
