Šį pavasarį atsidūrėme labai linksmomis sąlygomis. Dėl pandemijos tapo aišku, kad mūsų vasaros konferencijas reikia perkelti į internetą. O norint juos efektyviai vykdyti internete, mums netiko paruošti programinės įrangos sprendimai, reikėjo rašyti savo. Ir mes turėjome tris mėnesius tai padaryti.
Akivaizdu, kad tai buvo įdomūs trys mėnesiai. Tačiau iš išorės tai nėra visiškai akivaizdu: kas yra internetinių konferencijų platforma? Iš kokių dalių jis susideda? Todėl paskutinėje vasaros DevOops konferencijoje paklausiau tų, kurie buvo atsakingi už šią užduotį:
- Nikolajus Molčanovas - JUG Ru Group techninis direktorius;
- Vladimiras Krasilščikas yra pragmatiškas Java programuotojas, dirbantis su backend (jo pranešimus taip pat galite pamatyti mūsų Java konferencijose);
- Artyomas Nikonovas yra atsakingas už visą mūsų vaizdo transliaciją.
Beje, rudens-žiemos konferencijose naudosime patobulintą tos pačios platformos versiją – tiek daug habra skaitytojų vis tiek bus jos vartotojais.
Didelė nuotrauka
– Kokia buvo komandos sudėtis?
Nikolajus Molchanovas: Turime analitiką, dizainerį, testuotoją, tris priekinius įrenginius ir užpakalinę dalį. Ir, žinoma, T formos specialistas!
– Kaip apskritai atrodė procesas?
Nikolajus: Iki kovo vidurio mes neturėjome nieko pasiruošę internete. O kovo 15 dieną pradėjo suktis visa internetinė karuselė. Įrengėme kelias saugyklas, planavome, aptarėme pagrindinę architektūrą ir viską padarėme per tris mėnesius.
Tai, žinoma, praėjo klasikinius planavimo etapus, architektūrą, funkcijų parinkimą, balsavimą už tas savybes, tų savybių politiką, jų projektavimą, kūrimą, testavimą. Dėl to birželio 6 dieną viską išleidome į gamybą. . Viskam buvo skirta 90 dienų.
– Ar mums pavyko įvykdyti tai, ką įsipareigojome?
Nikolajus: Kadangi dabar dalyvaujame DevOops konferencijoje internete, tai reiškia, kad ji veikė. Aš asmeniškai įsipareigojau pagrindiniam dalykui: klientams pateiksiu įrankį, su kuriuo jie galės surengti internetinę konferenciją.
Iššūkis buvo toks: suteikite mums įrankį, kuriuo galėtume transliuoti savo konferencijas bilietų turėtojams.
Visas planavimas buvo suskirstytas į kelis etapus, o visos funkcijos (apie 30 pasaulinių) buvo suskirstytos į 4 kategorijas:
- kurį tikrai darysime (be jų negalime gyventi),
- ką padarysime antra,
- ko mes niekada nedarysime,
- ir ko mes niekada, niekada nedarysime.
Visas funkcijas sukūrėme iš pirmųjų dviejų kategorijų.
— Žinau, kad iš viso buvo sukurta 600 JIRA leidimų. Per tris mėnesius padarėte 13 mikropaslaugų ir įtariu, kad jos parašytos ne tik Java. Naudojote skirtingas technologijas, turite dvi „Kubernetes“ grupes trijose pasiekiamumo zonose ir 5 RTMP srautus „Amazon“.
Dabar pažvelkime į kiekvieną sistemos komponentą atskirai.
Srautinis perdavimas
— Pradėkime nuo to, kai jau turime vaizdo vaizdą, ir jis perduodamas kai kurioms tarnyboms. Artyomai, papasakok, kaip vyksta šis srautas?
Artiomas Nikonovas: Mūsų bendra schema atrodo taip: vaizdas iš fotoaparato -> mūsų valdymo kambarys -> vietinis RTMP serveris -> Amazon -> vaizdo grotuvas. Daugiau informacijos birželio mėn., Habré.
Apskritai tai galima padaryti dviem visuotiniais būdais: naudojant aparatinę įrangą arba programinės įrangos sprendimus. Mes pasirinkome programinės įrangos maršrutą, nes nuotolinių garsiakalbių atveju jis yra lengvesnis. Ne visada įmanoma pristatyti aparatinę įrangą į garsiakalbį kitoje šalyje, tačiau programinės įrangos pristatymas garsiakalbiui atrodo lengviau ir patikimiau.
Žiūrint iš techninės pusės, turime tam tikrą skaičių kamerų (studijose ir prie nuotolinių garsiakalbių), studijoje tam tikrą skaičių pultelių, kuriuos kartais tenka taisyti tiesiog po stalu transliacijos metu.
Signalai iš šių įrenginių patenka į kompiuterius su fiksavimo kortelėmis, įvesties / išvesties kortelėmis ir garso plokštėmis. Čia signalai sumaišomi ir surenkami į maketus:
4 garsiakalbių išdėstymo pavyzdys
4 garsiakalbių išdėstymo pavyzdys
Be to, nenutrūkstamas transliavimas užtikrinamas trijų kompiuterių pagalba: yra viena pagrindinė mašina ir pora veikiančių paeiliui. Pirmas kompiuteris renka pirmąją ataskaitą, antrasis – pertrauką, pirmas – kitą ataskaitą, antrasis – kitą pertrauką ir t.t. Ir pagrindinė mašina maišo pirmąją su antrąja.
Taip susidaro savotiškas trikampis, o jei kuris nors iš šių mazgų sugenda, galime greitai ir neprarandant kokybės toliau teikti turinį klientams. Pas mus buvo tokia situacija. Pirmą konferencijų savaitę sutvarkėme vieną aparatą, įjungėme/išjungėme. Atrodo, kad žmonės džiaugiasi mūsų atsparumu.
Tada srautai iš kompiuterių patenka į vietinį serverį, kuris turi dvi užduotis: nukreipti RTMP srautus ir įrašyti atsargines kopijas. Taigi turime kelis įrašymo taškus. Tada vaizdo įrašų srautai siunčiami į mūsų sistemos dalį, sukurtą naudojant „Amazon SaaS“ paslaugas. Mes naudojame ,S3,CloudFront.
Nikolajus: Kas ten nutinka, kol vaizdo įrašas pasiekia auditoriją? Jūs turite jį kažkaip sumažinti, tiesa?
Artiomas: Iš savo pusės vaizdo įrašą suspaudžiame ir siunčiame į MediaLive. Ten paleidžiame transkoderius. Jie realiu laiku perkoduoja vaizdo įrašus į kelias skiriamąsias gebas, kad žmonės galėtų žiūrėti juos savo telefonuose, per prastą internetą šalyje ir pan. Tada šie srautai supjaustomi , taip veikia protokolas . Į sąsają siunčiame grojaraštį, kuriame yra nuorodų į šiuos gabalus.
– Ar naudojame 1080p raišką?
Artiomas: Mūsų vaizdo įrašo plotis yra toks pat kaip 1080p - 1920 pikselių, o aukštis yra šiek tiek mažesnis, vaizdas yra pailgesnis - tam yra priežasčių.
Žaidėjas
— Artyomas papasakojo, kaip vaizdo įrašas patenka į srautus, kaip jis paskirstomas į skirtingus grojaraščius skirtingoms ekrano skyroms, supjaustomas į gabalus ir patenka į grotuvą. Kolya, dabar pasakyk man, koks tai žaidėjas, kaip jis naudoja srautą, kodėl HLS?
Nikolajus: Turime grotuvą, kurį gali žiūrėti visi konferencijos žiūrovai.
Iš esmės tai yra biblioteka , ant kurio parašyta daug kitų žaidėjų. Bet mums reikėjo labai specifinio funkcionalumo: atsukti ir pažymėti vietą, kur yra žmogus, kokį reportažą jis šiuo metu žiūri. Reikėjo ir savo maketų, visokių logotipų ir viso kito, kas buvo įmontuota pas mus. Todėl nusprendėme sukurti savo biblioteką (įvynioklis virš HLS) ir įterpti ją į svetainę.
Tai yra šakninė funkcija, todėl ji buvo įdiegta beveik pirmiausia. Ir tada viskas aplinkui išaugo.
Tiesą sakant, gavęs leidimą, grotuvas iš užpakalinės programos gauna grojaraštį su nuorodomis į gabalus, susijusius su laiku ir kokybe, atsisiunčia reikiamus ir parodo juos vartotojui, atlikdamas tam tikrą „stebuklingumą“.
Laiko juostos pavyzdys
— Į grotuvą įtaisytas mygtukas, rodantis visų ataskaitų laiko juostą...
Nikolajus: Taip, iš karto išsprendėme vartotojo navigacijos problemą. Balandžio viduryje nusprendėme, kad kiekvienos savo konferencijos netransliuosime atskirame tinklalapyje, o viską derinsime viename. Kad „Full Pass“ bilietų vartotojai galėtų laisvai persijungti tarp skirtingų konferencijų: tiek tiesioginių transliacijų, tiek praėjusių įrašų.
Kad naudotojams būtų lengviau naršyti dabartinį srautą ir perjungti takelius, nusprendėme sukurti mygtuką „Visa transliacija“ ir horizontalias ataskaitų korteles, kad būtų galima perjungti takelius ir ataskaitas. Yra klaviatūros valdymas.
– Ar dėl to kilo kokių nors techninių sunkumų?
Nikolajus: Jie turėjo slinkties juostą, kurioje buvo pažymėtos skirtingų ataskaitų pradžios taškai.
– Galų gale, ar įdiegėte šiuos ženklus slinkties juostoje, kol „YouTube“ padarė ką nors panašaus?
Artiomas: Tada jie turėjo jį beta versijoje. Atrodo, kad tai gana sudėtinga funkcija, nes per pastaruosius metus jie iš dalies ją išbandė su vartotojais. Ir dabar jis pasiekė pardavimą.
Nikolajus: Bet iš tikrųjų mes jį pardavėme greičiau. Sąžiningai, už šios paprastos funkcijos grotuvo viduje slypi didžiulis backend, frontend, skaičiavimų ir matematikos kiekis.
Frontend
— Išsiaiškinkime, kaip šis mūsų rodomas turinys (kalbos kortelė, garsiakalbiai, svetainė, tvarkaraštis) patenka į pradžią?
Vladimiras Krasilščikas: Turime keletą vidinių IT sistemų. Yra sistema, kurioje įvedami visi pranešimai ir visi pranešėjai. Yra procesas, kurio metu pranešėjas dalyvauja konferencijoje. Pranešėjas pateikia paraišką, sistema ją užfiksuoja, tada yra tam tikras vamzdynas, pagal kurį kuriama ataskaita.
Taip kalbėtojas mato dujotiekį
Ši sistema yra mūsų vidinė plėtra.
Tada turite sudaryti tvarkaraštį iš atskirų ataskaitų. Kaip žinote, tai NP sudėtinga problema, bet mes kažkaip ją išsprendžiame. Norėdami tai padaryti, paleidžiame kitą komponentą, kuris sukuria tvarkaraštį ir įkelia jį į trečiosios šalies debesies paslaugą „Contentful“. Ten jau viskas atrodo kaip lentelė, kurioje – konferencijos dienos, dienomis – laiko tarpsniai, o tarpuose – pranešimai, pertraukos ar rėmimo veikla. Taigi turinys, kurį matome, yra trečiosios šalies paslaugoje. O užduotis yra perteikti tai svetainei.
Atrodytų, kad svetainė yra tik puslapis su grotuvu, ir čia nėra nieko sudėtingo. Išskyrus tai, kad tai nėra. Už šio puslapio esanti galinė dalis patenka į „Contentful“, iš ten gauna tvarkaraštį, sugeneruoja kai kuriuos objektus ir siunčia jį į sąsają. Naudodami žiniatinklio lizdo ryšį, kurį atlieka kiekvienas mūsų platformos klientas, siunčiame jam grafiko atnaujinimą iš užpakalinės sistemos į priekinę dalį.
Tikras atvejis: pranešėjas konferencijos metu pakeitė darbą. Turime pakeisti jo darbdavio įmonės ženklelį. Kaip tai vyksta iš užpakalinės dalies? Atnaujinimas siunčiamas visiems klientams per žiniatinklio lizdą, o tada pati sąsaja perbraižo laiko juostą. Visa tai vyksta sklandžiai. Debesijos paslaugos ir kelių mūsų komponentų derinys suteikia mums galimybę generuoti visą šį turinį ir pateikti jį į priekį.
Nikolajus: Čia svarbu paaiškinti, kad mūsų svetainė nėra klasikinė SPA programa. Tai yra ir maketu pagrįsta, atvaizduota svetainė, ir SPA. „Google“ iš tikrųjų mato šią svetainę kaip pateiktą HTML. Tai naudinga SEO ir turinio pateikimui vartotojui. Jis nelaukia, kol bus įkeltas 1,5 megabaitų „JavaScript“, kol pamatys puslapį, iš karto mato jau pateiktą puslapį ir tai pajusite kiekvieną kartą, kai perjungiate ataskaitą. Viskas vyksta per pusę sekundės, nes turinys jau paruoštas ir paskelbtas reikiamoje vietoje.
— Nubrėžkime brūkšnį visoms aukščiau išvardintoms technologijoms. Tyoma sakė, kad turime 5 „Amazon“ srautus ir ten pristatome vaizdą ir garsą. Ten turime bash scenarijus, juos naudojame paleisti ir konfigūruoti...
Artiomas: Tai vyksta per AWS API, ten yra daug daugiau techninių šalutinių paslaugų. Mes pasiskirstėme savo pareigas taip, kad aš pristatysiu , o priekinės ir galinės dalies kūrėjai tai perima iš ten. Turime keletą savo įrišimų, kad supaprastintume turinio išdėstymą, kurį vėliau sukuriame 4K formatu ir kt. Kadangi terminai buvo labai trumpi, beveik visiškai tai padarėme naudodami AWS.
— Tada visa tai patenka į grotuvą naudojant backend sistemą. Savo grotuve turime TypeScript, React, Next.JS. Be to, mes turime keletą paslaugų C#, Java, Spring Boot ir Node.js. Visa tai įdiegta naudojant Kubernetes naudojant Yandex.Cloud infrastruktūrą.
Taip pat noriu pastebėti, kad kai reikėjo susipažinti su platforma, tai pasirodė nesunku: visos saugyklos yra GitLab, viskas gerai pavadinta, testai parašyti, dokumentacija yra. Tai yra, net avariniu režimu jie pasirūpino tokiais dalykais.
Verslo apribojimai ir analizė
— Atsižvelgdami į verslo reikalavimus, taikėme 10 000 vartotojų. Atėjo laikas pakalbėti apie verslo apribojimus, kuriuos turėjome. Turėjome užtikrinti didelį darbo krūvį, užtikrinti asmens duomenų saugojimo įstatymo laikymąsi. Ir kas dar?
Nikolajus: Iš pradžių pradėjome nuo vaizdo įrašų reikalavimų. Svarbiausia yra paskirstyta vaizdo įrašų saugykla visame pasaulyje, kad būtų galima greitai pristatyti klientui. Kiti apima 1080p raišką, taip pat atsukimą atgal, ko daugelis kitų neįgyvendina tiesioginiu režimu. Vėliau pridėjome galimybę įjungti 2x greitį, jos pagalba galite „pasivyti“ tiesioginį eterį ir toliau stebėti konferenciją realiu laiku. Ir pakeliui atsirado laiko juostos žymėjimo funkcija. Be to, turėjome būti atsparūs gedimams ir atlaikyti 10 000 jungčių apkrovą. Užpakalinės sistemos požiūriu tai yra maždaug 10 000 prisijungimų, padaugintų iš 8 užklausų kiekvienam puslapio atnaujinimui. Ir tai jau 80 000 RPS/sek. Gana šiek tiek.
— Ar „virtualiai parodai“ su partnerių internetiniais stendais buvo taikomi kiti reikalavimai?
Nikolajus: Taip, tai turėjo būti padaryta gana greitai ir visuotinai. Kiekvienai konferencijai turėjome iki 10 įmonių partnerių ir visos turėjo būti baigtos per savaitę ar dvi. Tačiau jų turinys šiek tiek skiriasi formatu. Tačiau buvo sukurtas tam tikras šablonų variklis, kuris surenka šiuos puslapius skrydžio metu, praktiškai nedalyvaujant tolesniam kūrimui.
— Taip pat buvo keliami reikalavimai realaus laiko rodinių ir statistikos analizei. Žinau, kad tam naudojame Prometėją, bet papasakokite plačiau: kokius analitikos reikalavimus atitinkame ir kaip tai įgyvendinama?
Nikolajus: Iš pradžių mes keliame rinkodaros reikalavimus rinkti A/B testavimui ir rinkti informaciją, kad suprastume, kaip tinkamai pateikti geriausią turinį klientui ateityje. Taip pat yra reikalavimai tam tikrai partnerių veiklos analizei ir jūsų matomai analizei (apsilankymų skaitiklis). Visa informacija renkama realiu laiku.
Šią informaciją galime pateikti apibendrinta forma net pranešėjams: kiek žmonių tam tikru metu jus stebėjo. Tuo pačiu metu, siekiant laikytis federalinio įstatymo 152, jūsų asmeninė paskyra ir asmens duomenys jokiu būdu nėra stebimi.
Platforma jau turi rinkodaros įrankius ir mūsų metriką, skirtą vartotojų veiklai realiuoju laiku matuoti (kas žiūrėjo kurią ataskaitos sekundę), kad būtų galima sudaryti ataskaitų lankomumo grafikus. Remiantis šiais duomenimis, atliekami tyrimai, kurių dėka kitos konferencijos bus geresnės.
Frodas
— Ar turime kovos su sukčiavimu mechanizmus?
Nikolajus: Dėl verslo požiūriu trumpo laiko tarpo iš pradžių nebuvo nustatyta užduotis nedelsiant blokuoti nereikalingus ryšius. Jei du vartotojai prisijungė prie tos pačios paskyros, jie galėjo peržiūrėti turinį. Tačiau žinome, kiek peržiūrų vienu metu buvo iš vienos paskyros. Ir uždraudėme kelis ypač piktybiškus pažeidėjus.
Vladimiras: Vienas iš uždraustų vartotojų suprato, kodėl taip atsitiko. Atėjo, atsiprašė ir pažadėjo nusipirkti bilietą.
— Kad visa tai įvyktų, turite visiškai atsekti visus vartotojus nuo įėjimo iki išėjimo, visada žinoti, ką jie daro. Kaip ši sistema veikia?
Vladimiras: Norėčiau pakalbėti apie analitiką ir statistiką, kurią analizuojame, kad būtų sėkminga ataskaita, arba galime pateikti partneriams. Visi klientai per žiniatinklio lizdą yra prijungti prie konkretaus užpakalinės sistemos klasterio. Ten stovi . Kiekvienas klientas kiekvienu laikotarpiu siunčia, ką jis veikia ir kokį takelį žiūri. Tada ši informacija kaupiama naudojant greitas Hazelcast užduotis ir siunčiama atgal visiems, kurie žiūri šiuos takelius. Matome kampe, kiek žmonių dabar yra su mumis.
Ta pati informacija saugoma ir eina į mūsų duomenų ežerą, iš kurio turime galimybę sukurti įdomesnį grafiką. Kyla klausimas: kiek unikalių vartotojų peržiūrėjo šią ataskaitą? Mes einame į , yra visų žmonių, kurie atėjo pagal šio pranešimo ID. Surinkome, agregavome unikalius ir dabar galime suprasti.
Nikolajus: Tačiau tuo pat metu mes taip pat gauname duomenis iš „Prometheus“ realiuoju laiku. Jis nukreiptas prieš visas Kubernetes paslaugas, prieš patį Kubernetes. Jis renka absoliučiai viską, o su Grafana galime sukurti bet kokius grafikus realiu laiku.
Vladimiras: Viena vertus, atsisiunčiame tai tolesniam OLAP apdorojimui. O OLTP atveju programa viską atsisiunčia į Prometheus, Grafana ir diagramos netgi susilieja!
– Taip būna, kai grafikai susilieja.
Dinaminiai pokyčiai
— Papasakokite, kaip vykdomi dinamiški pakeitimai: jei pranešimas buvo atšauktas likus 6 minutėms iki starto, kokia veiksmų grandinė? Kuris vamzdynas veikia?
Vladimiras: Dujotiekis yra labai sąlyginis. Yra keletas galimybių. Pirma, grafiko generavimo programa veikė ir pakeitė tvarkaraštį. Pakeistas tvarkaraštis įkeliamas į turinį. Po to užpakalinė programa supranta, kad yra pakeitimų šioje konferencijoje „Contentful“, paima ją ir atkuria. Viskas surenkama ir siunčiama per websocket.
Antra galimybė, kai viskas vyksta beprotišku tempu: redaktorius rankiniu būdu pakeičia informaciją Contentful (nuoroda į Telegramą, kalbėtojo pristatymas ir pan.) ir veikia ta pati logika kaip ir pirmą kartą.
Nikolajus: Viskas vyksta neatnaujinus puslapio. Visi pakeitimai klientui įvyksta visiškai sklandžiai. Tas pats pasakytina ir apie ataskaitų keitimą. Kai ateina laikas, ataskaita ir sąsaja pasikeičia.
Vladimiras: Be to, laiko juostoje yra ataskaitų pradžios laikas. Pačioje pradžioje nieko nėra. Ir jei užvessite pelės žymeklį ant raudonos juostelės, tam tikru momentu, transliacijos režisieriaus dėka, atsiras ribos. Režisierius nustato teisingą transliacijos pradžią, backend pasiima šį pakeitimą, pagal konferencijos tvarkaraštį apskaičiuoja viso takelio pristatymų pradžios ir pabaigos laikus, išsiunčia jį mūsų klientams, o žaidėjas ištraukia atkarpas. Dabar vartotojas gali lengvai pereiti prie ataskaitos pradžios ir pabaigos. Tai buvo griežtas verslo reikalavimas, labai patogu ir naudinga. Negaiškite laiko ieškant tikrojo ataskaitos pradžios laiko. Ir kai padarysime peržiūrą, ji bus be galo nuostabi.
Diegimas
– Norėčiau paklausti apie dislokavimą. Kolya ir komanda iš pradžių praleido daug laiko, kad sukurtų visą infrastruktūrą, kurioje mums viskas klostytųsi. Pasakyk man, iš ko visa tai padaryta?
Nikolajus: Žvelgiant iš techninės pusės, iš pradžių turėjome reikalavimą, kad produktas būtų kuo abstraktesnis iš bet kurio pardavėjo. Apsilankykite AWS, kad sukurtumėte „Terraform“ scenarijus specialiai iš AWS, „Yandex“, „Azure“ ir kt. nelabai tiko. Kažkada turėjome kažkur persikelti.
Pirmąsias tris savaites nuolat ieškojome būdo, kaip tai padaryti geriau. Dėl to priėjome prie išvados, kad Kubernetes šiuo atveju yra mūsų viskas, nes leidžia kurti automatinio mastelio keitimo paslaugas, automatinį išleidimą ir beveik visas paslaugas gauti iš dėžutės. Natūralu, kad visos tarnybos turėjo būti apmokytos dirbti su Kubernetes, Docker, o komanda taip pat turėjo mokytis.
Turime dvi grupes. Bandymas ir gamyba. Jie yra visiškai identiški techninės įrangos ir nustatymų požiūriu. Infrastruktūrą diegiame kaip kodą. Visos paslaugos automatiškai iškeliamos į tris aplinkas iš funkcijų šakų, pagrindinių šakų, bandomųjų šakų ir „GitLab“, naudojant automatinį dujotiekį. Tai maksimaliai integruota į GitLab, maksimaliai integruota su Elastic, Prometheus.
Mes gauname galimybę greitai (galinėje sistemoje per 10 minučių, priekinėje sistemoje per 5 minutes) įdiegti pakeitimus bet kurioje aplinkoje, atliekant visus testus, integracijas, vykdomus funkcinius testus, aplinkos integravimo testus, taip pat išbandyti naudojant apkrovos testus. bandomoji aplinka yra maždaug ta pati, kurią norime gauti gamyboje.
Apie testus
— Beveik viską išbandai, sunku patikėti, kaip viską parašei. Ar galite papasakoti apie backend testus: kiek viskas apima, kokie testai?
Vladimiras: Buvo parašyti dviejų tipų testai. Pirmieji yra komponentų testai. Viso spyruoklės taikymo ir pagrindo pakėlimo lygio bandymai . Tai aukščiausio lygio verslo scenarijų išbandymas. Netestuoju funkcijų. Mes išbandome tik kai kuriuos didelius dalykus. Pavyzdžiui, bandymo metu imituojamas prisijungimo prie vartotojo procesas, vartotojo užklausa dėl bilietų, kur jis gali nuvykti, ir prašymas leisti žiūrėti srautą. Labai aiškūs vartotojo scenarijai.
Maždaug tas pats įgyvendinamas vadinamuosiuose integracijos testuose, kurie iš tikrųjų veikia aplinkoje. Tiesą sakant, kai išleidžiamas kitas gamybos diegimas, gamyboje taip pat veikia tikri pagrindiniai scenarijai. Tas pats prisijungimas, prašymas bilietų, prašymas patekti į CloudFront, tikrinimas, ar srautas tikrai jungiasi su mano leidimais, tikrinamas režisieriaus sąsaja.
Šiuo metu turiu apie 70 komponentų testų ir apie 40 integravimo testų. Aprėptis yra labai artima 95%. Tai skirta komponentams, mažiau integraciniams, tiesiog nereikia tiek daug. Atsižvelgiant į tai, kad projektas apima visų rūšių kodų generavimą, tai yra labai geras rodiklis. Nebuvo kito būdo padaryti tai, ką padarėme per tris mėnesius. Nes jei testuotume rankiniu būdu, suteikdami funkcijas savo testuotojai, o ji surastų klaidas ir grąžintų mums pataisyti, tai ši kelionė pirmyn ir atgal derinti kodą būtų labai ilga ir nesilaikytume jokių terminų.
Nikolajus: Paprastai, norint atlikti regresiją visoje platformoje keičiant kokią nors funkciją, reikia dvi dienas visur sėdėti ir kištis.
Vladimiras: Todėl labai pasiseka, kad įvertindamas funkciją sakau, kad man reikia 4 dienų dviems paprastiems rašikliui ir 1 interneto lizdui, Kolya tai leidžia. Jis jau pripratęs, kad į šias 4 dienas įeina 2 rūšių tyrimai, ir tada, greičiausiai, pavyks.
Nikolajus: Taip pat turiu parašytų 140 testų: komponentas + funkcinis, kurie atlieka tą patį. Visi tie patys scenarijai yra išbandomi gamyboje, bandyme ir gamyboje. Taip pat neseniai pridėjome funkcinių pagrindinių vartotojo sąsajos testų. Tokiu būdu aprėpiame pagrindines funkcijas, kurios gali subyrėti.
Vladimiras: Žinoma, verta kalbėti apie apkrovos testus. Reikėjo išbandyti platformą esant apkrovai, artimai tikrajai, kad suprastume, kaip viskas yra, kas vyksta su Rabbit, kas vyksta su JVM, kiek iš tikrųjų reikia atminties.
– Tiksliai nežinau, ar ką nors testuojame srauto pusėje, bet prisimenu, kad rengiant susitikimus buvo problemų su transkoderiais. Ar išbandėme srautus?
Artiomas: Išbandyta iteratyviai. Susitikimų organizavimas. Organizuojant susitikimus buvo apie 2300 JIRA bilietų. Tai tik bendri dalykai, kuriuos žmonės darė susitikdami. Dalis platformos perkėlėme į atskirą susitikimų puslapį, kuriam vadovavo Kirilas Tolkačiovas ().
Tiesą sakant, didelių problemų nebuvo. Žodžiu, porą kartų užfiksavome „CloudFront“ talpyklos klaidas, gana greitai ją išsprendėme – tiesiog perkonfigūravome politiką. Svetainės srautinio perdavimo sistemose buvo žymiai daugiau klaidų.
Konferencijų metu turėjau parašyti dar kelis eksportuotojus, kad apimčiau daugiau įrangos ir paslaugų. Kai kuriose vietose dviračius teko pasidaryti pačiam vien dėl metrikos. AV (garso ir vaizdo) aparatinės įrangos pasaulis nėra labai rožinis - jūs turite tam tikrą įrangos „API“, kurios tiesiog negalite paveikti. Ir toli gražu ne faktas, kad galėsite gauti reikiamą informaciją. Techninės įrangos pardavėjai yra tikrai lėti, ir beveik neįmanoma iš jų gauti tai, ko norite. Iš viso yra daugiau nei 100 aparatūros dalių, jie negrąžina to, ko jums reikia, o jūs rašote keistus ir perteklinius eksportuotojus, kurių dėka galite bent kažkaip derinti sistemą.
įranga
— Prisimenu, kaip prieš konferencijų pradžią iš dalies įsigijome papildomos įrangos.
Artiomas: Įsigijome kompiuterius, nešiojamus kompiuterius ir baterijas. Šiuo metu be elektros galime gyventi 40 minučių. Birželio mėnesį Sankt Peterburge buvo smarki perkūnija – todėl turėjome tokį elektros energijos tiekimą. Tuo pačiu metu keli tiekėjai ateina pas mus su optinėmis nuorodomis iš skirtingų taškų. Tai tikrai 40 minučių pastato prastovos, per kurias įjungsime šviesas, veiks garsas, kameros ir t.t.
– Su internetu turime panašią istoriją. Biure, kuriame yra mūsų studijos, tarp aukštų tempėme nuožmų tinklą.
Artiomas: Tarp aukštų turime 20 Gbit šviesolaidžio. Toliau per aukštus kai kur yra optikos, kai kur nėra, bet vis tiek yra mažiau kanalų nei gigabitinių - juose paleidžiame vaizdo įrašą tarp konferencijos takelių. Apskritai labai patogu dirbti su savo infrastruktūra, retai tai galite padaryti neprisijungus vykstančiose konferencijose svetainėse.
– Prieš dirbdamas JUG Ru Group, mačiau, kaip per naktį buvo įrengiamos aparatinės įrangos patalpos neprisijungus vykstančiose konferencijose, kuriose buvo didelis monitorius su visa metrika, kurią kuriate Grafana. Dabar taip pat yra būstinės kambarys, kuriame sėdi kūrėjų komanda, kuri konferencijos metu ištaiso kai kurias klaidas ir kuria funkcijas. Tuo pačiu metu yra stebėjimo sistema, kuri rodoma dideliame ekrane. Artiomas, Kolia ir kiti vaikinai sėdi ir žiūri, kad viskas nenukristų ir veiktų gražiai.
Įdomybės ir problemos
– Gerai kalbėjote apie tai, kad mes turime transliaciją su „Amazon“, yra grotuvas su žiniatinkliu, viskas parašyta skirtingomis programavimo kalbomis, suteikiama gedimų tolerancija ir kiti verslo reikalavimai, įskaitant asmeninę paskyrą, kuri palaikoma juridiniams asmenims ir asmenys, ir mes galime integruotis su kuo nors naudojant OAuth 2.0, yra kovos su sukčiavimu, vartotojų blokavimas. Galime dinamiškai įdiegti pakeitimus, nes tai padarėme gerai ir viskas patikrinta.
Man įdomu sužinoti, kokios keistenybės buvo susijusios su pradėjimu. Ar buvo kokių nors keistų situacijų, kai kūrėte backendą, frontendą, išėjo kažkas beprotiško ir nesupratote, ką su tuo daryti?
Vladimiras: Man atrodo, kad taip nutiko tik pastaruosius tris mėnesius. Kiekvieną dieną. Kaip matote, visi mano plaukai buvo išraityti.
Vladimiras Krasilščikas po 3 mėnesių, kai pasirodė kažkoks žaidimas ir niekas nesuprato, ką su juo daryti
Kasdien būdavo kažkas tokio, kai būdavo toks momentas, kai imi ir nusiplėši plaukus, arba supranti, kad kito nėra, o tik tu gali tai padaryti. Pirmasis didelis mūsų renginys buvo „TechTrain“. Birželio 6 d., 2 val., Mes dar nebuvome išleidę gamybinės aplinkos, Kolya ją išleido. O asmeninė paskyra neveikė kaip autorizacijos serveris naudojant OAuth2.0. Mes pavertėme jį OAuth2.0 teikėju, kad prijungtume prie jo platformą. Dirbau turbūt 18 valandų iš eilės, žiūrėjau į kompiuterį ir nieko nematau, nesupratau kodėl neveikia, o Kolya nuotoliniu būdu pažiūrėjo į mano kodą, ieškojo klaidos Spring konfigūracijoje , jį rado, ir LC veikė, ir gamyboje.
Nikolajus: Likus valandai iki „TechTrain“ įvyko išleidimas.
Čia buvo išsirikiavusi daug žvaigždžių. Mums be galo pasisekė, nes turėjome super komandą ir visus įkvėpė idėja tai padaryti internetu. Visus šiuos tris mėnesius mus paskatino tai, kad „sukūrėme YouTube“. Neleidau sau išsiplėšti plaukų, bet visiems sakiau, kad viskas susitvarkys, nes iš tikrųjų viskas jau seniai paskaičiuota.
Apie pasirodymą
– Ar galite pasakyti, kiek žmonių buvo svetainėje viename takelyje? Ar buvo kokių nors veiklos problemų?
Nikolajus: Veikimo problemų, kaip jau minėjome, nebuvo. Didžiausias žmonių, kurie dalyvavo viename pranešime, skaičius buvo 1300 žmonių, tai yra Heisenbug.
– Ar buvo problemų su vietiniu žiūrėjimu? Ir ar galima turėti techninį aprašymą su schemomis kaip visa tai veikia?
Nikolajus: Apie tai vėliau parašysime straipsnį.
Jūs netgi galite derinti srautus vietoje. Prasidėjus konferencijoms tapo dar lengviau, nes atsirado produkcijos srautai, kuriuos galime žiūrėti visą laiką.
Vladimiras: Kaip suprantu, priekinės dalies kūrėjai dirbo lokaliai su pavyzdžiais, o tada, kadangi laikas, per kurį reikia pristatyti priekyje esančius kūrėjus, taip pat yra trumpas (5 minutės), nėra problemų tikrinant, kas vyksta su sertifikatais.
— Viskas išbandoma ir derinama, net vietoje. Tai reiškia, kad parašysime straipsnį su visomis techninėmis savybėmis, parodysime, papasakosime viską su diagramomis, kaip buvo.
Vladimiras: Galite paimti ir pakartoti.
- Per 3 mėnesius.
Visas
— Viskas, kas aprašyta kartu, skamba šauniai, turint galvoje, kad tai padarė nedidelė komanda per tris mėnesius.
Nikolajus: Didelė komanda to nepadarytų. Tačiau nedidelė grupė žmonių, kurie gana artimai ir gerai bendrauja tarpusavyje ir gali susitarti, galėtų. Jie neturi jokių prieštaravimų, architektūra buvo sugalvota per dvi dienas, buvo baigta ir faktiškai nepasikeitė. Yra labai griežtai palengvinami gaunami verslo reikalavimai, susiję su funkcijų užklausų ir pakeitimų kaupimu.
— Kas buvo jūsų tolesnių užduočių sąraše, kai jau buvo įvykusios vasaros konferencijos?
Nikolajus: Pavyzdžiui, kreditai. Vaizdo įraše šliaužiančios linijos, kai kuriose vaizdo įrašo vietose iššokantys langai, priklausomai nuo rodomo turinio. Pavyzdžiui, kalbėtojas nori užduoti klausimą auditorijai, o ekrane pasirodo balsavimas, kuris, remiantis balsavimo rezultatais, grįžta pačiam pranešėjui. Kažkokia socialinė veikla simpatijų, širdelių, reportažo įvertinimų pavidalu per patį pristatymą, kad reikiamu momentu galėtumėte užpildyti atsiliepimus, vėliau nesiblaškydami nuo atsiliepimų formų. Iš pradžių taip.
Taip pat pridedant visą platformą, išskyrus srautinį perdavimą ir konferenciją, būsena po konferencijos. Tai yra grojaraščiai (įskaitant vartotojų sudarytus), galbūt turinys iš kitų praėjusių konferencijų, integruotas, pažymėtas etiketėmis, pasiekiamas vartotojui, taip pat galima peržiūrėti mūsų svetainėje ().
– Vaikinai, labai ačiū už atsakymus!
Jei tarp skaitytojų yra tokių, kurie dalyvavo mūsų vasaros konferencijose, pasidalykite įspūdžiais apie grotuvą ir transliaciją. Kas buvo patogu, kas erzino, ką norėtum pamatyti ateityje?
Jei jus domina platforma ir norite ją pamatyti „mūšyje“, mes vėl ją naudojame savo svetainėje . Jų yra daugybė, todėl beveik neabejotinai yra vienas, kuris jums tinka.
Šaltinis: www.habr.com
