Цієї весни ми опинилися в дуже веселих умовах. Через пандемію стало зрозуміло, що наші літні конференції необхідно переносити до онлайн. А щоб провести їх в онлайні якісно, нам не підходили готові софтові рішення, потрібно написати власне. І на це ми мали три місяці.
Зрозуміло, що це були три місяці. Але з боку не зовсім очевидно: що взагалі є платформою для онлайн-конференцій? З яких частин вона складається? Тому на останній з літніх конференцій DevOops я розпитав тих, хто відповідав за це завдання:
- Микола Молчанов – технічний директор JUG Ru Group;
- Володимир Красильник - прагматичний Java-програміст, який займається бекендом (ви також могли бачити його доповіді на наших Java-конференціях);
- Артем Ніконов відповідає за весь наш відеострімінг.
До речі, на осінньо-зимових конференціях ми будемо використовувати покращену версію тієї ж платформи - так що багато хабрачитачів ще виявляться її користувачами.
Загальна картина
- Яким був склад команди?
Микола Молчанов: У нас є аналітик, дизайнер, тестувальник, три фронтендери, бекендер. І, звичайно, T-shaped фахівець!
— Як загалом виглядав процес?
Миколай: До середини березня у нас до онлайн не було готово взагалі нічого. А 15 березня закрутилася вся карусель із онлайном. Ми завели кілька репозиторіїв, спланували, обговорили базову архітектуру та зробили за три місяці.
Це, звичайно, пройшло класичні етапи планування, архітектури, вибору фічі, голосування за ці фічі, політики цих фіч, їх дизайну, розробки, тестування. У підсумку 6 червня ми викотили все в прод на . На все про все було 90 днів.
— Чи встигло встигнути те, на що ми комітувалися?
Миколай: Якщо ми зараз беремо участь у конференції DevOops в онлайні — значить, вийшло. Я особисто закомітівся на головну річ: принесу замовникам інструмент, за допомогою якого можна буде зробити конференцію в онлайні.
Завдання стояло так: дайте нам інструмент, за допомогою якого ми зможемо транслювати наші конференції власникам квитків.
Все планування було розбито на кілька етапів, і всі фічі (близько 30 глобальних) були поділені на 4 категорії:
- які ми зробимо обов'язково (без них жити не можемо),
- які ми зробимо у другу чергу,
- які ми ніколи не зробимо,
- і які ніколи-ніколи не зробимо.
Усі фічі з перших двох категорій ми зробили.
— Я знаю, що всього було заведено 600 JIRA-завдань. За три місяці ви зробили 13 мікросервісів і підозрюю, що вони написані не тільки на Java. Ви використовували різні технології, у вас піднято два Kubernetes-кластери в трьох зонах доступності та 5 RTMP-стримів у Amazon.
Давайте тепер розберемося з кожною складовою системи окремо.
Стрімінг
— Почнемо з того, коли ми вже маємо відео-картинку, і вона передається на якісь сервіси. Артеме, розкажи, як відбувається цей стрімінг?
Артем Ніконов: Загальна схема у нас виглядає так: зображення з камери -> наша пультова -> локальний RTMP-сервер -> Amazon -> відеоплеєр. Детальніше на Хабре у червні.
Загалом є два глобальні шляхи, як це можна робити: або на залозі, або на базі софтверних рішень. Ми вибрали шлях софту, тому що це простіше у випадку з віддаленими спікерами. Не завжди є можливість привезти спікеру в іншій країні залізницю, а поставити програмне забезпечення спікеру здається простіше і надійніше.
З точки зору заліза у нас є кілька камер (у наших студіях і у віддалених спікерів), кілька пультів у студії, які іноді доводиться лагодити прямо під час ефіру під столом.
Сигнали від цих пристроїв потрапляють до комп'ютерів з платами захоплення, введення/виводу, звуковими картками. Там сигнали мікшуються, збираються до лейаутів:
Приклад лейауту на 4 спікери
Приклад лейауту на 4 спікери
Далі безперервний ефір забезпечується за допомогою трьох комп'ютерів: є одна головна машина та пара працюючих по черзі. Перший комп'ютер збирає першу доповідь, другий — перерву, першу — наступну доповідь, другу — наступну перерву тощо. А головна машина мікшує першу з другою.
Таким чином, виходить якийсь трикутник, і в разі падіння будь-якого з цих вузлів ми можемо швидко і без втрати якості продовжити доставляти клієнтам контент. Така ситуація у нас була. На першому тижні конференцій ми лагодили одну машину, включали/вимикали. Здається, що люди задоволені нашою стійкістю до відмови.
Далі потоки з комп'ютерів потрапляють на локальний сервер, у якого дві задачі: роутіть RTMP-потоки і записувати бекап. Таким чином, у нас є кілька точок запису. Потім потоки відео вирушають до частини нашої системи, побудованої на амазонівських SaaS-сервісах. Використовуємо , S3, CloudFront.
Миколай: А що там відбувається до того, як відео потрапить до глядачів? Ви ж маєте його нарізати якось?
Артем: Ми стискуємо зі свого боку відео, відправляємо його до MediaLive. Там запускаємо транскодери. Вони перекодують відео в режимі реального часу в кілька дозволів для того, щоб люди могли дивитися їх на телефонах через поганий інтернет на дачі і так далі. Потім ці стрими ріжуться на , так працює протокол . На фронтенд ми віддаємо плейлист, у якому є вказівники на ці чанки.
— Ми використовуємо роздільну здатність 1080р?
Артем: По ширині у нас як 1080p відео - 1920 пікселів, а по висоті трохи менше, картинка витягнутіша - на це є свої причини.
плеєр
— Артем описав, як відео потрапляє у стрими, як розподіляється на різні плейлисти для різних дозволів екранів, ріжеться на чанки та потрапляє у плеєр. Коля, розкажи тепер, що це за плеєр, як він споживає стриму, чому HLS?
Миколай: У нас є плеєр, який спостерігають усі глядачі конференції.
По суті, це обгортка над бібліотекою , де написано багато інших плеєрів. Але нам була потрібна дуже специфічна функціональність: перемотування назад і позначка на місці, в якому знаходиться людина, яку доповідь вона зараз дивиться. Також були потрібні власні лейаути, всякі логотипи та все інше, що вбудувалося у нас. Тому ми вирішили написати власну бібліотеку (обгортку над HLS) та вбудувати це на сайт.
Це коренева функціональність, отже її реалізували майже першою. А потім довкола цього все вже обростало.
За фактом плеєр через авторизацію отримує від бекенда плейлист з посиланнями на чанки, співвіднесені з часом і якістю, викачує потрібні та показує користувачеві, проводячи по ходу деяку магію.
Приклад таймлайну
— Прямо в плеєр вбудовано кнопку для виведення таймлайну всіх доповідей…
Миколай: Так, ми одразу вирішували проблему навігації користувача. У середині квітня вирішили, що не транслюватимемо кожну з наших конференцій на окремому сайті, а об'єднаємо все на одному. Щоб користувачі квитків Full Pass могли вільно перемикатися між різними конференціями: і прямим ефіром, і минулими записами.
А щоб користувачам було простіше пересуватися по поточному стриму та перемикатися між треками, вирішили зробити кнопку «Весь ефір» та горизонтальні картки доповідей для перемикання між треками та доповідями. Там є керування з клавіатури.
— Чи були якісь технічні складнощі із цим?
Миколай: Були зі смужкою прокручування, на якій відзначаються точки початку різних доповідей.
— У результаті ви реалізували ці позначки на смузі прокручування раніше, ніж подібне зробив YouTube?
Артем: У них тоді це було в беті. Здається, це досить складна фіча, тому що вони частково тестували її на користувачах протягом останнього року. І тепер вона дійшла до прода.
Миколай: Але ми справді до прода донесли швидше. Чесно сказати, що за цією простою фічею стоїть величезна кількість і бекенда, і фронтенда, і розрахунків і матана всередині плеєра.
Фронтенд
— Давайте розберемося, як цей контент, який ми показуємо (картку доповіді, спікери, сайт, розклад) виходить на фронтенд?
Володимир Красильник: У нас є кілька внутрішніх айтішних систем. Є система, в якій заведено всі доповіді та всі спікери. Є процес, за яким доповідач бере участь у конференції. Спікер подає заявку, система її захоплює, далі є якийсь пайплайн, яким створюється доповідь.
Так спікер бачить пайплайн
Ця система – наша внутрішня розробка.
Далі з окремих доповідей слід побудувати розклад. Як відомо, це NP-складне завдання, але ми його вирішуємо. Для цього запускаємо інший компонент, який формує розклад та засовує його у сторонній хмарний сервіс Contentful. Там все виглядає вже як таблиця, де є дні конференції, днями — тимчасові слоти, а в слотах — доповіді, перерви чи спонсорські активності. Отже, контент, який ми бачимо, розташовується в сторонньому сервісі. І постає завдання донести його до сайту.
Здавалося б, сайт це просто сторінка з плеєром, і нічого складного тут немає. Крім того, що це не так. Бекенд, що стоїть за цією сторінкою, йде в Contentful, дістає звідти розклад, формує деякі об'єкти та відсилає на фронтенд. За допомогою вебсокет-з'єднання, яке робить кожен клієнт нашої платформи, ми з бекенда на фронтенд закидаємо оновлення в розкладі.
Реальний випадок: спікер під час конференції змінив роботу. Потрібно поміняти йому плашку компанії-роботодавця. Як це відбувається з бекенда? За вебсокетом усім клієнтам летить оновлення, і далі фронтенд вже сам перемальовує таймлайн. Все це відбувається безшовно. Сукупність хмарного сервісу та кількох наших компонентів дають нам можливість сформувати весь цей контент та надати його фронту.
Миколай: Тут важливо уточнити, що наш сайт не є класичним додатком SPA. Це і згорблений, відрендерений сайт, і SPA. Насправді Google бачить цей сайт як відрендерований HTML. Це добре для SEO та для доставки користувачеві контенту. Він не чекає на завантаження 1,5 мегабайт JavaScript, щоб потім побачити сторінку, він відразу бачить вже відрендеровану сторінку, а ви це відчуваєте щоразу, коли перемикаєте доповідь. Все виходить за півсекунди, оскільки контент готовий і викладений у правильне місце.
— Підіб'ємо межу під усім вищесказаним, перерахувавши технології. Тема розповів, що у нас є 5 Amazon-стримів, туди доставляємо відео та звук. Там у нас bash-скрипти, за їх допомогою запускаємо, конфігуруємо…
Артем: Це відбувається через API AWS, є ще багато побічних технічних сервісів. Ми поділили свої обов'язки так, що я доставляю на , а фронтенд- та бекенд-розробники звідти забирають. У нас кілька своїх обв'язок для спрощення викладення контенту, який ми робимо потім в 4К і т.д. Оскільки терміни були дуже стислі, ми практично повністю зробили це на базі AWS.
— Далі все це потрапляє до плеєра, використовуючи бекенд системи. У нас у плеєрі TypeScript, React, Next.JS. І на бекенді у нас є кілька сервісів на С#, Java, Spring Boot та Node.js. Це все розгортається за допомогою Kubernetes, використовуючи інфраструктуру Яндекс.Хмари.
Ще хочу помітити, що коли мені знадобилося познайомитися з платформою, це виявилося нескладно: усі репозиторії знаходяться на GitLab, все добре названо, написані тести, документація. Тобто навіть в авральному режимі дбали про такі речі.
Бізнес-обмеження та аналітика
— Ми таргетувалися на бізнес-вимоги на 10 000 користувачів. Саме час розповісти про бізнес-обмеження, які ми мали. Ми мали забезпечувати високе навантаження, забезпечувати виконання закону про збереження персональних даних. А що ще?
Миколай: Спочатку ми відштовхувалися від вимог до відео. Найголовніше – розподілене зберігання відео по світу для швидкої доставки клієнту. З інших – дозвіл 1080р, а також перемотування назад, що у багатьох інших у лайв-режимі не реалізовано. Пізніше ми додали можливість увімкнути швидкість 2x, з її допомогою можна «наздогнати» лайв і далі дивитися конференцію в реальному часі. І ще по ходу виникла функціональність розмітки таймлайну. Плюс до цього ми повинні були бути стійкими до відмов і витримувати навантаження 10 000 з'єднань. З точки зору бекенд це приблизно 10 000 з'єднань помножити на 8 запитів на кожен рефреш сторінки. А це вже 80 RPS/сек. Доволі багато.
— Ще були вимоги до «віртуальної виставки» із онлайн-стендами партнерів?
Миколай: Так, це потрібно було зробити досить швидко та універсально. У нас було до 10 компаній-партнерів на кожну конференцію, і сторінки їх усіх треба було загорнути за тиждень-два. При цьому контент вони трохи різняться за форматом. Але був зроблений певний шаблонізатор, який збирає ці сторінки на льоту, практично без подальшої участі в розробці.
— Були ще вимоги щодо аналітики переглядів у реал-таймі та статистиці. Знаю, що ми використовуємо для цього Prometheus, а розкажіть докладніше: які вимоги ми виконуємо з аналітики та як це реалізується?
Миколай: Спочатку у нас є маркетологічні вимоги щодо збору для А/В-тестування та збору інформації для того, щоб зрозуміти, як правильно клієнту доставляти кращий контент надалі. Ще є вимоги щодо певної аналітики з партнерських активностей та аналітика, яку ви бачите (лічильник відвідувань). Вся інформація збирається у реал-таймі.
Цю інформацію ми можемо видавати в агрегованому вигляді навіть спікерам: скільки людей тебе дивилися у певний час. При цьому для дотримання 152 ФЗ особистий кабінет та персональні дані не трекаються ніяк.
На платформі вже є і маркетологічні інструменти, і наші метрики для вимірювання активності користувача саме в реалтаймі (хто дивився якусь секунду доповіді), щоб будувати графіки відвідування доповідей. На основі цих даних робляться дослідження, які дозволять зробити наступні конференції кращими.
Фрід
— Чи маємо механізми антифроду?
Миколай: У зв'язку з жорсткими часовими рамками з погляду бізнесу спочатку не ставилося завдання відразу блокувати зайві з'єднання. Якщо два користувачі заходили під тим самим акаунтом, вони могли переглянути контент. Але ми знаємо, скільки одночасних переглядів було з одного облікового запису. І кількох особливо злісних порушників ми забанили.
Володимир: Треба віддати належне, один із забанених користувачів зрозумів, чому це сталося. Прийшов, вибачився та обіцяв купити квиток.
— Щоб це все відбувалося, ви повинні повністю трасувати всіх користувачів від входу до виходу, завжди знати, що вони роблять. Як улаштована ця система?
Володимир: Я хотів би розповісти про аналітику та статистику, яку ми потім аналізуємо для успішності доповіді або можемо надати потім партнерам. Всі клієнти приєднані по веб-з'єднанню до певного кластеру бекенда. Там стоїть . Кожен клієнт у кожний період часу посилає, що він робить і який трек він дивиться. Далі ця інформація швидкими Hazelcast-джобами агрегується і надсилається в зворотному напрямку всім, хто дивиться ці треки. Ми бачимо у кутку, скільки людей зараз перебувають разом із нами.
Ця ж інформація складується в і їде в наше озеро даних, яким ми маємо можливість будувати більш цікавий графік. Постає питання: скільки унікальних користувачів переглянули цю доповідь? Ми йдемо в , там пінги всіх людей, які прийшли по 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 хвилин) викотити зміни в будь-яке середовище з усіма тестами, інтеграціями, запуском функціональних тестів, інтеграційних тестів на середовищі, та ще й протестувати навантажувальними тестами на тестовому середовищі. те саме, що ми хочемо отримати в продакшені.
Про тести
— Ви майже все тестуєте, важко повірити, як ви написали. Можете розповісти як по бекенду з тестів: наскільки все покрито, які тести?
Володимир: Написано два типи тестів. Перші – компонентні тести. Тести рівня підйому всього спрингового застосування та бази в . Це перевірка найбільш високорівневих бізнес-сценаріїв. Я не тестую функції. Ми тестуємо лише якісь великі штуки. Наприклад, прямо в тесті емулює процес логіна користувача, запит цим користувачем квитків, куди він може сходити, запит доступу на перегляд стриму. Дуже зрозумілі користувальницькі сценарії.
Приблизно те саме реалізовано в так званих інтеграційних тестах, які реально біжать на середовищі. Фактично, коли черговий деплоймент у прод розкочується, на проді також біжать справжні базові сценарії. Той самий логін, запит квитків, запит доступу до CloudFront, перевірка того, що стрім справді чіпляється з моїми дозволами, перевірка режисерського інтерфейсу.
На даний момент у мене на борту приблизно 70 компонентних тестів та близько 40 інтеграційних. Покриття дуже близько до 95%. Це по компонентним, по менших інтеграційних, там стільки просто не треба. Враховуючи те, що у проекті будь-які кодогенерації, це дуже добрий показник. Жодного іншого способу зробити те, що ми зробили за три місяці, не було. Тому що якби ми тестували ручним чином, віддаючи фічі нашій тестувальникці, а вона знаходила б баги і повертала нам на фікси, то цей round trip по налагодженню коду був би дуже довгий, і ми б не влізли ні в які терміни.
Миколай: Умовно, щоб провести регрес на всій платформі при зміні якоїсь функції, потрібно два дні сидіти та тикати скрізь.
Володимир: Тому великий успіх, що коли я естимую фічу, кажу, що мені потрібно 4 дні на дві прості ручки і 1 websocket, Коля дозволяє. Він уже звик, що у ці 4 дні закладено 2 типи тестів, і потім, швидше за все, це працюватиме.
Миколай: У мене теж написано 140 тестів: компонентних + функціональних, які роблять те саме. Ті самі сценарії тестуються і на продакшені, на тесті і на діві. Також нещодавно у нас з'явилися функціональні базові UI тести. Так ми покриваємо найбільш базові функціональності, які можуть розвалитися.
Володимир: Звичайно ж, варто розповісти про тести навантаження. Потрібно було перевірити платформу під навантаженням, наближеним до реальної, щоб зрозуміти, як воно все, що відбувається з Rabbit, що відбувається з JVM-ками, скільки реально треба пам'яті.
— Я не знаю точно, чи ми тестуємо щось на боці стриму, але я пам'ятаю, що були проблеми з транскодерами, коли ми робили мітапи. Чи тестували ми стримувані?
Артем: Тестилі ітеративно. Організовуючи мітапи. У процесі організації мітапів було приблизно 2300 JIRA-тикетів. Це просто шаблонні речі, які люди робили зробити мітапи. Ми брали частини платформи на окрему сторінку для мітапів, якою займався Кирило Толкачов ().
Щиро кажучи, великих проблем не було. Буквально кілька разів ловили баги з кешування на 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 місяці.
Підсумок
— Все описане разом звучить круто з огляду на те, що це зроблено маленькою командою за три місяці.
Миколай: Велика команда цього не зробила б. А ось маленька група людей, які досить щільно та добре один з одним спілкуються та можуть домовитися, могла б. У них немає якихось протиріч, архітектура була вигадана за два дні, була фіналізована і практично не змінилася. Є дуже жорстка фасилітація бізнес-вимог, що надходять, з погляду навалювання фіч-реквестів та змін.
— Що виявилось у вашому списку подальших завдань, коли літні конференції вже відбулися?
Миколай: Наприклад, титри. Рядки, що біжать на відео, спливають в деяких місцях відео в залежності від показу контенту. Наприклад, спікер хоче задати питання в аудиторію, і на екрані спливає голосування, яке назад у бек за результатами голосування йде самому спікеру. Якась соціальна активність у вигляді лайків, сердець, оцінок доповіді під час самої презентації, щоб можна було, не відволікаючись потім на форми зворотного зв'язку, заповнити фідбек у потрібну секунду. Спочатку ось так.
А ще додавання всій платформі, крім стрімінгового та конференційного, також постконференційний стан. Це плейлисти (у тому числі складені користувачами), можливо, контент з інших минулих конференцій, інтегровані, промарковані, доступні для користувача, та доступні для перегляду на нашому сайті ().
— Хлопці, дякую за відповіді!
Якщо серед читачів є ті, хто був на наших літніх конференціях, поділіться вашими враженнями від плеєра та трансляції. Що було зручно, що дратувало, що хочеться побачити у майбутньому?
Якщо платформа зацікавила і захотілося побачити її «в бою» - ми знову використовуємо її на наших . Їх ціла низка, так що майже напевно є підходяща для вас.
Джерело: habr.com