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

Ясно е, че бяха вълнуващи три месеца. Но отвън не е съвсем очевидно: какво е платформа за онлайн конференции? От какви части се състои? Затова на последната от летните DevOops конференции попитах тези, които бяха отговорни за тази задача:

• Николай Молчанов - технически директор на JUG Ru Group;
• Владимир Красилщик е прагматичен Java програмист, работещ върху бекенда (можете също да видите докладите му на нашите Java конференции);
• Артьом Никонов отговаря за цялото ни видео стрийминг.

Между другото, на есенно-зимните конференции ще използваме подобрена версия на същата платформа - толкова много читатели на habra ще продължат да бъдат нейни потребители.

Цялостна картина

– Какъв беше съставът на отбора?

Николай Молчанов: Имаме анализатор, дизайнер, тестер, три фронтендъра и бекенд. И, разбира се, Т-образен специалист!

– Как изглеждаше процесът като цяло?

Никола: До средата на март изобщо нямахме нищо готово за онлайн. И на 15 март цялата онлайн въртележка започна да се върти. Създадохме няколко хранилища, планирахме, обсъдихме основната архитектура и направихме всичко за три месеца.

Това, разбира се, премина през класическите етапи на планиране, архитектура, избор на функции, гласуване за тези функции, политика за тези функции, техния дизайн, разработка, тестване. В резултат на това на 6 юни пуснахме всичко в производство. Технически влак. Имаше 90 дни за всичко.

– Успяхме ли да изпълним това, с което се ангажирахме?

Никола: Тъй като сега участваме в конференцията DevOops онлайн, това означава, че работи. Аз лично се ангажирах с основното нещо: ще донеса на клиентите инструмент, с който да могат да правят онлайн конференция.

Предизвикателството беше следното: дайте ни инструмент, с който да излъчваме нашите конференции на притежателите на билети.

Цялото планиране беше разделено на няколко етапа и всички характеристики (около 30 глобални) бяха разделени в 4 категории:

• което определено ще направим (не можем да живеем без тях),
• което ще направим на второ място,
• което никога няма да направим,
• и което никога, никога няма да направим.

Направихме всички функции от първите две категории.

— Знам, че са създадени общо 600 броя на JIRA. За три месеца направихте 13 микроуслуги и подозирам, че не са написани само на Java. Използвали сте различни технологии, имате два клъстера Kubernetes в три зони на достъпност и 5 RTMP потока в Amazon.

Нека сега разгледаме всеки компонент на системата поотделно.

Поточно предаване

— Да започнем с това, когато вече имаме видео изображение и то се предава на някои услуги. Артьом, кажи ни как става това стрийминг?

Артьом Никонов: Нашата обща схема изглежда така: изображение от камерата -> нашата контролна зала -> локален RTMP сървър -> Amazon -> видео плейър. Повече информация писа за това на Хабре през юни.

Като цяло има два глобални начина да направите това: или на хардуер, или на базата на софтуерни решения. Избрахме софтуерния път, защото е по-лесен в случай на отдалечени високоговорители. Не винаги е възможно да донесете хардуер до високоговорител в друга държава, но доставянето на софтуер до високоговорителя изглежда по-лесно и по-надеждно.

От хардуерна гледна точка имаме определен брой камери (в нашите студия и на отдалечени високоговорители), определен брой дистанционни управления в студиото, които понякога трябва да бъдат ремонтирани точно под масата по време на предаване.

Сигналите от тези устройства влизат в компютри с карти за улавяне, входно/изходни карти и звукови карти. Там сигналите се смесват и сглобяват в оформления:

Примерно оформление за 4 високоговорителя

Примерно оформление за 4 високоговорителя

Освен това непрекъснатото излъчване се осигурява с помощта на три компютъра: има една основна машина и двойка работни на свой ред. Първият компютър събира първия отчет, вторият - паузата, първият - следващия отчет, вторият - следващата пауза и т.н. И основната машина смесва първото с второто.

Това създава нещо като триъгълник и ако някой от тези възли се повреди, можем бързо и без загуба на качество да продължим да доставяме съдържание на клиентите. Имахме такава ситуация. През първата седмица на конференциите поправихме една машина, включихме/изключихме я. Хората изглежда са доволни от нашата устойчивост.

След това потоците от компютрите отиват към локален сървър, който има две задачи: маршрутизиране на RTMP потоци и архивиране на записи. Така че имаме множество точки за запис. След това видео потоците се изпращат до частта от нашата система, изградена на услуги на Amazon SaaS. Ние използваме MediaLive:,S3,CloudFront.

Никола: Какво се случва там, преди видеото да стигне до публиката? Трябва да го отрежеш по някакъв начин, нали?

Артьом: Ние компресираме видеото от наша страна и го изпращаме на MediaLive. Пускаме транскодери там. Те прекодират видеата в реално време в няколко резолюции, за да могат хората да ги гледат на телефоните си, през слаб интернет в страната и т.н. След това тези потоци се нарязват буци, така работи протоколът HLS. Изпращаме плейлист към интерфейса, който съдържа указатели към тези парчета.

— Използваме ли резолюция 1080p?

Артьом: Ширината на нашето видео е същата като 1080p - 1920 пиксела, а височината е малко по-малка, картината е по-издължена - има причини за това.

Играч

— Артьом описа как видеото попада в потоци, как се разпределя в различни плейлисти за различни резолюции на екрана, нарязва се на парчета и влиза в плейъра. Коля, сега ми кажи какъв играч е това, как консумира потока, защо HLS?

Никола: Имаме играч, който всички зрители на конференцията могат да гледат.

По същество това е обвивка около библиотеката hls.js, на който са написани много други играчи. Но ни трябваше много специфична функционалност: пренавиване и маркиране на мястото, където се намира човекът, какъв репортаж гледа в момента. Имахме нужда и от наши собствени оформления, всякакви лога и всичко останало, което беше вградено при нас. Затова решихме да напишем собствена библиотека (обвивка върху HLS) и да я вградим в сайта.

Това е основната функционалност, така че е внедрена почти първа. И тогава всичко се разрасна около него.

Всъщност, чрез оторизация, играчът получава от бекенда плейлист с връзки към парчета, свързани с времето и качеството, изтегля необходимите и ги показва на потребителя, като извършва някаква „магия“ по пътя.

Пример за времева линия

— В плейъра е вграден бутон за показване на времева линия на всички отчети...

Никола: Да, веднага решихме проблема с потребителската навигация. В средата на април решихме, че няма да излъчваме всяка наша конференция на отделен сайт, а ще обединим всичко на едно. Така че потребителите на билети за Full Pass могат свободно да превключват между различни конференции: както предавания на живо, така и записи на минали.

И за да улесним потребителите да навигират в текущия поток и да превключват между песни, решихме да направим бутон „Цяло излъчване“ и хоризонтални отчетни карти за превключване между песни и отчети. Има управление с клавиатура.

— Имаше ли технически затруднения с това?

Никола: Те имаха лента за превъртане, на която бяха отбелязани началните точки на различни доклади.

— В крайна сметка внедрихте ли тези знаци върху лентата за превъртане, преди YouTube да направи нещо подобно?

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

Никола: Но всъщност го продадохме по-бързо. Честно казано, зад тази проста функция има огромно количество бекенд, фронтенд, изчисления и математика в плейъра.

Frontend

— Нека да разберем как това съдържание, което показваме (карта за реч, високоговорители, уебсайт, график), стига до предния край?

Владимир Красилщик: Имаме няколко вътрешни ИТ системи. Има система, в която се въвеждат всички доклади и всички говорители. Има процес, чрез който говорител участва в конференция. Говорителят подава заявление, системата го улавя, след което има определен конвейер, според който се създава отчетът.

Ето как говорителят вижда тръбопровода

Тази система е нашето вътрешно развитие.

След това трябва да изградите график от отделни отчети. Както знаете, това е NP-труден проблем, но ние някак си го решаваме. За да направим това, стартираме друг компонент, който генерира график и го качва в облачната услуга Contentful на трета страна. Там всичко изглежда като таблица, в която има дни от конференцията, в дните има времеви интервали, а в слотовете има доклади, почивки или спонсорски дейности. Така че съдържанието, което виждаме, се намира в услуга на трета страна. И задачата е да го предаде на сайта.

Изглежда, че сайтът е просто страница с играч и тук няма нищо сложно. Само дето не е. Бекендът зад тази страница отива до Contentful, получава графика от там, генерира някои обекти и го изпраща до предния край. Използвайки websocket връзка, която всеки клиент на нашата платформа прави, ние му изпращаме актуализация на графика от бекенда към фронтенда.

Истински случай: говорителят смени работата си точно по време на конференцията. Трябва да сменим значката на фирмата му работодател. Как става това от бекенда? Актуализация се изпраща до всички клиенти чрез websocket и след това самият интерфейс преначертава времевата линия. Всичко това се случва безпроблемно. Комбинацията от облачната услуга и няколко от нашите компоненти ни дава възможност да генерираме цялото това съдържание и да го предоставим на преден план.

Никола: Тук е важно да уточним, че нашият сайт не е класическо СПА приложение. Това е както базиран на оформление, изобразен уебсайт, така и SPA. Google всъщност вижда този сайт като изобразен HTML. Това е добре за SEO и за предоставяне на съдържание на потребителя. Той не чака 1,5 мегабайта JavaScript да се зареди, преди да види страницата, той веднага вижда вече изобразената страница и вие го усещате всеки път, когато превключвате отчета. Всичко се случва за половин секунда, тъй като съдържанието вече е готово и публикувано на правилното място.

— Нека теглим черта под всичко по-горе, като изброим технологиите. Tyoma каза, че имаме 5 потока на Amazon и доставяме видео и звук там. Имаме bash скриптове там, използваме ги за стартиране и конфигуриране...

Артьом: Това се случва чрез AWS API, там има много повече технически странични услуги. Разделихме отговорностите си така, че да доставям на CloudFront, а разработчиците от предния и задния край го вземат оттам. Имаме редица наши собствени обвързвания за опростяване на оформлението на съдържанието, което след това правим в 4K и т.н. Тъй като сроковете бяха много кратки, го направихме почти изцяло на AWS.

— След това всичко това влиза в плейъра с помощта на бекенд системата. Имаме TypeScript, React, Next.JS в нашия плейър. И в бекенда имаме няколко услуги в C#, Java, Spring Boot и Node.js. Всичко това се внедрява с помощта на Kubernetes, използвайки инфраструктурата Yandex.Cloud.

Също така искам да отбележа, че когато трябваше да се запозная с платформата, се оказа лесно: всички хранилища са в GitLab, всичко е добре наименувано, тестовете са написани, има документация. Тоест дори в авариен режим са се погрижили за такива неща.

Бизнес ограничения и анализи

— Насочихме се към 10 000 потребители въз основа на бизнес изискванията. Време е да поговорим за бизнес ограниченията, които имахме. Трябваше да осигурим висока натовареност, да осигурим спазването на закона за защита на личните данни. И какво друго?

Никола: Първоначално започнахме от изискванията за видео. Най-важното нещо е разпределеното видео съхранение по целия свят за бърза доставка до клиента. Други включват 1080p резолюция, както и превъртане назад, което много други не прилагат в режим на живо. По-късно добавихме възможността за активиране на 2x скорост, с нейна помощ можете да „наваксате“ на живо и да продължите да гледате конференцията в реално време. И по пътя се появи функционалност за маркиране на времевата линия. Освен това трябваше да сме устойчиви на грешки и да издържим натоварването от 10 000 връзки. От гледна точка на бекенда, това са приблизително 10 000 връзки, умножени по 8 заявки за всяко опресняване на страница. А това вече е 80 000 RPS/сек. Доста малко.

— Имаше ли други изисквания за „виртуална изложба“ с онлайн щандове на партньори?

Никола: Да, това трябваше да стане доста бързо и универсално. Имахме до 10 партньорски компании за всяка конференция и всички трябваше да бъдат завършени за седмица или две. Съдържанието им обаче се различава малко по формат. Но беше създадена определена машина за шаблони, която сглобява тези страници в движение, без практически никакво допълнително участие в разработката.

— Имаше и изисквания за анализ на изгледи и статистики в реално време. Знам, че използваме Prometheus за това, но ни кажете по-подробно: на какви изисквания отговаряме за анализи и как се прилага това?

Никола: Първоначално имаме маркетингови изисквания за събиране за A/B тестване и събиране на информация, за да разберем как правилно да доставяме най-доброто съдържание на клиента в бъдеще. Има и изисквания за някои анализи на дейностите на партньорите и анализите, които виждате (брояч на посещения). Цялата информация се събира в реално време.

Можем да предоставим тази информация в обобщен вид дори на говорещи: колко души са ви гледали в определен момент от време. В същото време, за спазване на Федерален закон 152, вашият личен акаунт и лични данни не се проследяват по никакъв начин.

Платформата вече разполага с маркетингови инструменти и нашите показатели за измерване на активността на потребителите в реално време (кой коя секунда от отчета е гледал), за да се изграждат графики на посещаемостта на отчетите. Въз основа на тези данни се правят изследвания, които ще направят следващите конференции по-добри.

Измама

— Имаме ли механизми за борба с измамите?

Никола: Поради кратката времева рамка от бизнес гледна точка първоначално не беше поставена задачата незабавно да блокира ненужните връзки. Ако двама потребители влязат с един и същи акаунт, те могат да видят съдържанието. Но знаем колко едновременни гледания е имало от един акаунт. И забранихме няколко особено злонамерени нарушители.

Владимир: За негова чест, един от забранените потребители разбра защо се е случило това. Той дойде, извини се и обеща да си купи билет.

— За да се случи всичко това, трябва напълно да проследите всички потребители от входа до изхода, винаги да знаете какво правят. Как работи тази система?

Владимир: Бих искал да говоря за анализи и статистики, които след това анализираме за успеха на доклада или можем да предоставим на партньорите. Всички клиенти са свързани чрез websocket връзка към конкретен бекенд клъстер. Стои там леска. Всеки клиент във всеки период от време изпраща какво прави и каква песен гледа. След това тази информация се събира с помощта на бързи задания на Hazelcast и се изпраща обратно на всеки, който гледа тези песни. Виждаме в ъгъла колко хора са сега с нас.

Същата информация се съхранява в Монго и отива в нашето езеро от данни, от което имаме възможност да изградим по-интересна графика. Възниква въпросът: колко уникални потребители са прегледали този отчет? Отиваме на Postgres, има пингове на всички хора, дошли с id от този доклад. Събрахме, обобщихме уникални и сега можем да разберем.

Никола: Но в същото време ние също получаваме данни в реално време от Prometheus. Настроен е срещу всички услуги на Kubernetes, срещу самия Kubernetes. Събира абсолютно всичко, а с Grafana можем да изграждаме всякакви графики в реално време.

Владимир: От една страна, ние изтегляме това за по-нататъшна OLAP обработка. А за OLTP приложението изтегля всичко в Prometheus, Grafana и графиките дори се събират!

- Това е случаят, когато графиките се събират.

Динамични промени

— Кажете ни как се въвеждат динамичните промени: ако докладът е бил отменен 6 минути преди началото, каква е веригата от действия? Кой тръбопровод работи?

Владимир: Тръбопроводът е много условен. Има няколко възможности. Първият е, че програмата за генериране на график работи и промени графика. Модифицираният график се качва в Contentful. След което бекендът разбира, че има промени за тази конференция в Contentful, взема я и я възстановява. Всичко се събира и изпраща чрез websocket.

Втората възможност, когато всичко се случва с главоломна скорост: редакторът ръчно променя информацията в Contentful (връзка към Telegram, презентация на лектора и т.н.) и същата логика работи като първия път.

Никола: Всичко се случва без опресняване на страницата. Всички промени се случват абсолютно безпроблемно за клиента. Същото важи и за превключването на отчетите. Когато дойде времето, отчетът и интерфейсът се променят.

Владимир: Освен това има времеви прекъсвания за началото на отчетите във времевата линия. В самото начало няма нищо. И ако задържите курсора на мишката върху червената ивица, тогава в даден момент, благодарение на режисьора на излъчването, ще се появят прекъсвания. Режисьорът задава правилното начало на излъчването, бекендът улавя тази промяна, изчислява началното и крайното време на презентациите на цялата песен в съответствие с графика на конференцията, изпраща го на нашите клиенти и играчът рисува прекъсвания. Сега потребителят може лесно да навигира до началото и края на отчета. Това беше строго бизнес изискване, много удобно и полезно. Не губите време в намиране на действителния начален час за отчета. И когато направим визуализация, ще бъде абсолютно прекрасно.

Разгръщане

— Бих искал да попитам относно разгръщането. Коля и екипът отделиха много време в началото, за да настроят цялата инфраструктура, в която всичко се развива за нас. Кажете ми от какво е направено всичко?

Никола: От техническа гледна точка първоначално имахме изискване продуктът да бъде възможно най-абстрактен от всеки доставчик. Елате в AWS, за да направите скриптове Terraform специално от AWS, или конкретно от Yandex, или от Azure и т.н. наистина не пасваше. В един момент трябваше да се преместим някъде.

През първите три седмици непрекъснато търсихме начин да направим това по-добре. В резултат на това стигнахме до извода, че Kubernetes в този случай е нашето всичко, защото ни позволява да създаваме услуги с автоматично мащабиране, автоматично разгръщане и да извличаме почти всички услуги от кутията. Естествено, всички услуги трябваше да бъдат обучени да работят с Kubernetes, Docker и екипът също трябваше да се научи.

Имаме два клъстера. Тест и производство. Те са абсолютно идентични като хардуер и настройки. Ние внедряваме инфраструктура като код. Всички услуги се внедряват автоматично в три среди от клонове на функции, главни клонове, тестови клонове и GitLab с помощта на автоматичен конвейер. Това е максимално интегрирано в GitLab, максимално интегрирано с Elastic, Prometheus.

Получаваме възможност бързо (за бекенда в рамките на 10 минути, за фронтенда в рамките на 5 минути) да внедрим промени във всяка среда с всички тестове, интеграции, изпълняващи функционални тестове, интеграционни тестове в средата, а също и да тестваме с тестове за натоварване на тестова среда, приблизително същото, което искаме да получим в производството.

Относно тестовете

— Тествате почти всичко, трудно е да повярвате как сте написали всичко. Можете ли да ни кажете за бекенд тестовете: колко всичко е покрито, какви тестове?

Владимир: Написани са два вида тестове. Първите са компонентни тестове. Тестове за ниво на повдигане на цялото пружинно приложение и основата в Тестови контейнери. Това е тест за бизнес сценарии от най-високо ниво. Не тествам функции. Тестваме само някои големи неща. Например, точно в теста се емулира процесът на влизане на потребител, искането на потребителя за билети до мястото, където може да отиде, и искането за достъп за гледане на потока. Много ясни потребителски сценарии.

Приблизително същото нещо се прилага в така наречените интеграционни тестове, които всъщност се изпълняват в средата. Всъщност, когато бъде пуснато следващото внедряване в производството, реални основни сценарии също се изпълняват в производството. Същото влизане, искане на билети, искане на достъп до CloudFront, проверка дали потокът наистина се свързва с моите разрешения, проверка на интерфейса на директора.

В момента имам около 70 компонентни теста и около 40 интеграционни теста на борда. Покритието е много близо до 95%. Това е за компонентни, по-малко за интеграционни, просто не е толкова необходимо. Като се има предвид, че проектът включва всякакъв вид генериране на код, това е много добър показател. Нямаше друг начин да направим това, което направихме за три месеца. Защото, ако тествахме ръчно, предоставяйки функции на нашия тестер, и тя щеше да намери грешки и да ни ги върне за корекции, тогава това двупосочно пътуване за отстраняване на грешки в кода щеше да бъде много дълго и нямаше да спазим никакви крайни срокове.

Никола: Обикновено, за да извършите регресия на цялата платформа, когато промените някаква функция, трябва да седите и да бъркате навсякъде в продължение на два дни.

Владимир: Затова е голям успех, когато оценявам функция, казвам, че ми трябват 4 дни за две прости химикалки и 1 websocket, Коля го позволява. Той вече е свикнал с факта, че тези 4 дни включват 2 вида тестове и тогава най-вероятно ще работи.

Никола: Имам и написани 140 теста: компонент + функционален, които правят едно и също нещо. Всички същите сценарии се тестват в производството, в теста и в производството. Наскоро добавихме и функционални базови тестове на потребителския интерфейс. По този начин покриваме най-основната функционалност, която може да се разпадне.

Владимир: Разбира се, струва си да говорим за тестове за натоварване. Беше необходимо да се тества платформата под натоварване, близко до реалното, за да се разбере как е всичко, какво се случва с Rabbit, какво се случва с JVM, колко памет всъщност е необходима.

— Не знам със сигурност дали тестваме нещо от страната на потока, но си спомням, че имаше проблеми с транскодери, когато правехме срещи. Тествахме ли стриймовете?

Артьом: Тествано итеративно. Организиране на срещи. В процеса на организиране на срещи имаше приблизително 2300 билета за JIRA. Това са просто общи неща, които хората правят, за да правят срещи. Взехме части от платформата на отделна страница за срещи, която се управлява от Кирил Толкачев (talkkv).

Честно казано, нямаше големи проблеми. Буквално няколко пъти хванахме грешки в кеширането на CloudFront, решихме го доста бързо - просто преконфигурирахме правилата. Имаше значително повече грешки в хората, в стрийминг системите на сайта.

По време на конференциите трябваше да напиша още няколко износителя, за да покрия повече оборудване и услуги. На някои места трябваше да правя собствени велосипеди само заради показателите. Светът на AV (аудио-видео) хардуера не е много розов - имате някакъв вид "API" на оборудване, на което просто не можете да повлияете. И далеч не е факт, че ще можете да получите информацията, от която се нуждаете. Доставчиците на хардуер са наистина бавни и е почти невъзможно да получите това, което искате от тях. Общо има повече от 100 хардуера, те не връщат това, от което се нуждаете, и пишете странни и излишни износители, благодарение на които можете поне по някакъв начин да дебъгвате системата.

Оборудование

— Спомням си как преди началото на конференциите частично закупихме допълнително оборудване.

Артьом: Закупихме компютри, лаптопи и батерии. В момента можем да живеем без ток 40 минути. През юни имаше силни гръмотевични бури в Санкт Петербург - така че имахме такова затъмнение. В същото време няколко доставчика идват при нас с оптични връзки от различни точки. Това наистина са 40 минути престой на сградата, през които ще имаме включени светлини, звук, камери и т.н.

— Имаме подобна история с интернет. В офиса, където се намират ателиетата ни, провлякохме жестока мрежа между етажите.

Артьом: Имаме 20 Gbit влакна между етажите. По-нататък по етажите, някъде има оптика, някъде няма оптика, но все пак има по-малко канали от гигабитовите - пускаме видео по тях между песните на конференцията. Като цяло е много удобно да работите върху собствената си инфраструктура; рядко можете да направите това на офлайн конференции на сайтове.

— Преди да работя в JUG Ru Group, видях как хардуерните стаи на офлайн конференции се настройват за една нощ, където имаше голям монитор с всички показатели, които изграждате в Grafana. Сега има и стая на централата, в която седи екипът за разработка, който по време на конференцията коригира някои грешки и разработва функции. В същото време има система за наблюдение, която се показва на голям екран. Артьом, Коля и други момчета седят и се уверяват, че всичко това не пада и работи красиво.

Любопитни неща и проблеми

— Говорихте добре за факта, че имаме стрийминг с Amazon, има плейър с мрежата, всичко е написано на различни езици за програмиране, предоставени са толерантност към грешки и други бизнес изисквания, включително личен акаунт, който се поддържа за юридически лица и физически лица и можем да се интегрираме с някой, използващ OAuth 2.0, има защита срещу измами, блокиране на потребители. Можем да внедряваме промени динамично, защото го направихме добре и всичко е тествано.

Интересно ми е да разбера какви странности са включени в започването на нещо. Имало ли е някакви странни ситуации, когато сте разработвали бекенд, фронтенд, нещо лудо се е оказало и не сте разбирали какво да правите с него?

Владимир: Струва ми се, че това се случи само през последните три месеца. Всеки ден. Както виждате, цялата ми коса е изскубана.

Владимир Красилщик след 3 месеца, когато се получи някаква игра и никой не разбра какво да прави с нея

Всеки ден имаше нещо подобно, когато имаше такъв момент, когато го вземеш и разкъсаш косата си или осъзнаеш, че няма кой друг и само ти можеш да го направиш. Първото ни голямо събитие беше TechTrain. На 6 юни в 2 часа през нощта още не бяхме пуснали производствената среда, Коля я пускаше. И личният акаунт не работи като сървър за оторизация с помощта на OAuth2.0. Превърнахме го в доставчик на OAuth2.0, за да свържем платформата с него. Работех сигурно 18 часа без прекъсване, погледнах компютъра и не видях нищо, не разбрах защо не работи, а Коля погледна кода ми от разстояние, потърси бъг в конфигурацията на Spring , намери го и LC работи, и в производството също.

Никола: И един час преди TechTrain се състоя освобождаването.

Тук бяха подредени много звезди. Имахме изключителен късмет, защото имахме супер екип и всички бяха вдъхновени от идеята да го направим онлайн. През всичките тези три месеца бяхме водени от факта, че „направихме YouTube“. Не си позволих да си скубя косата, но казах на всички, че всичко ще се получи, защото всъщност всичко беше изчислено отдавна.

Относно изпълнението

— Можете ли да ми кажете колко души бяха на сайта на една писта? Имаше ли проблеми с производителността?

Никола: Нямаше проблеми с производителността, както вече казахме. Максималният брой хора, присъствали на един доклад, беше 1300 души, това е на Heisenbug.

— Имаше ли проблеми с местното гледане? И може ли да има техническо описание със схеми как работи всичко?

Никола: Ще направим статия за това по-късно.

Можете дори да отстранявате грешки в потоци локално. След като започнаха конференциите, стана още по-лесно, защото се появиха производствени потоци, които можем да гледаме през цялото време.

Владимир: Доколкото разбирам, предните разработчици са работили локално с фалшиви версии и след това, тъй като времето за пускане на разработчиците отпред също е кратко (5 минути), няма проблеми с проверката какво се случва със сертификатите.

— Всичко се тества и се отстраняват грешки, дори локално. Това означава, че ще напишем статия с всички технически характеристики, ще ви покажем, ще ви разкажем всичко с диаграми, как е било.

Владимир: Можете да го вземете и да го повторите.

- След 3 месеца.

Общо

— Всичко описано заедно звучи готино, като се има предвид, че е направено от малък екип за три месеца.

Никола: Голям екип не би направил това. Но малка група от хора, които общуват доста тясно и добре помежду си и могат да постигнат споразумение, биха могли. Те нямат никакви противоречия, архитектурата е измислена за два дни, финализирана е и всъщност не се е променила. Има много стриктно улесняване на входящите бизнес изисквания по отношение на натрупването на заявки за функции и промени.

— Какво беше в списъка ви с по-нататъшни задачи, когато летните конференции вече бяха проведени?

Никола: Например кредити. Пълзящи линии във видеото, изскачащи прозорци на някои места във видеото в зависимост от показваното съдържание. Например, ораторът иска да зададе въпрос на публиката и на екрана се появява гласуване, което се връща назад въз основа на резултатите от гласуването до самия оратор. Някакъв вид социална активност под формата на харесвания, сърца, оценки на доклада по време на самата презентация, така че да можете да попълните обратна връзка в точния момент, без да се разсейвате по-късно от формуляри за обратна връзка. Първоначално така.

И също така добавяне към цялата платформа, с изключение на стрийминг и конференция, също състояние след конференцията. Това са плейлисти (включително съставени от потребители), евентуално съдържание от други минали конференции, интегрирани, етикетирани, достъпни за потребителя и също достъпни за гледане на нашия уебсайт (live.jugru.org).

— Момчета, много ви благодаря за отговорите!

Ако сред читателите има такива, които са присъствали на нашите летни конференции, моля, споделете впечатленията си от плейъра и предаването. Какво беше удобно, какво ви подразни, какво бихте искали да видите в бъдеще?

Ако се интересувате от платформата и искате да я видите „в битка“, ние я използваме отново на нашия есенно-зимни конференции. Има цяла гама от тях, така че почти сигурно има един, който е подходящ за вас.

Източник: www.habr.com