Idén tavasszal nagyon vidám körülmények között találtuk magunkat. A járvány miatt világossá vált, hogy nyári konferenciáinkat át kell helyezni az internetre. A hatékony online lebonyolításhoz pedig a kész szoftvermegoldások nem feleltek meg nekünk, meg kellett írnunk a magunkét. És három hónapunk volt erre.
Egyértelmű, hogy izgalmas három hónap volt. De kívülről nézve nem teljesen nyilvánvaló: mi az az online konferencia-platform? Milyen részekből áll? Ezért a nyári DevOops konferenciák utolsó alkalmával megkérdeztem azokat, akik ezt a feladatot ellátták:
- Nikolay Molchanov - a JUG Ru Group műszaki igazgatója;
- Vladimir Krasilshchik pragmatikus Java programozó, aki a háttérrendszeren dolgozik (jelentéseit a Java konferenciánkon is láthatta);
- Artyom Nikonov felelős az összes videó streamingünkért.
Az őszi-téli konferenciákon egyébként ugyanennek a platformnak a továbbfejlesztett változatát használjuk majd – így sok habra olvasó továbbra is a felhasználója lesz.
A nagy kép
– Milyen volt a csapat összetétele?
Nikolay Molchanov: Van egy elemzőnk, egy tervezőnk, egy tesztelőnk, három front-enderünk és egy back-endünk. És persze egy T alakú szakember!
– Hogyan nézett ki általában a folyamat?
Nikolay: Március közepéig semmi sem volt kész az online használatra. Március 15-én pedig pörögni kezdett az egész online körhinta. Három hónap alatt több adattárat hoztunk létre, terveztünk, megbeszéltük az alap architektúrát és mindent megtettünk.
Ez természetesen végigment a tervezés, az építészet, a funkciók kiválasztásának klasszikus szakaszain, az adott jellemzőkre való szavazáson, az adott funkciókra vonatkozó szabályzaton, a tervezésen, fejlesztésen, tesztelésön. Ennek eredményeként június 6-án mindent elindítottunk a gyártásba. . 90 nap volt mindenre.
– Sikerült megvalósítanunk, amit vállaltunk?
Nikolay: Mivel most online veszünk részt a DevOops konferencián, ez azt jelenti, hogy működött. Én személy szerint elköteleztem magam a lényeg mellett: hozok az ügyfeleknek egy olyan eszközt, amellyel online konferenciát rendezhetnek.
A kihívás a következő volt: adjunk nekünk egy eszközt, amellyel közvetíthetjük konferenciáinkat a jegytulajdonosoknak.
Az összes tervezést több szakaszra osztották, és az összes funkciót (körülbelül 30 globális) 4 kategóriába sorolták:
- amit biztosan meg fogunk tenni (nem tudunk nélkülük élni),
- amit másodszor meg fogunk tenni,
- amit soha nem fogunk megtenni,
- és amit soha, de soha nem fogunk megtenni.
Az összes funkciót az első két kategóriából készítettük el.
— Úgy tudom, hogy összesen 600 JIRA-kiadás született. Három hónap alatt 13 mikroszolgáltatást készítettél, és gyanítom, hogy ezeket nem csak Java nyelven írták. Különböző technológiákat használt, két Kubernetes-fürtje van három rendelkezésre állási zónában, és 5 RTMP adatfolyama van az Amazonban.
Nézzük most a rendszer minden egyes összetevőjét külön-külön.
Folyó
— Kezdjük azzal, amikor már van videoképünk, és azt egyes szolgáltatások felé továbbítják. Artyom, meséld el, hogyan történik ez a közvetítés?
Artyom Nikonov: Általános sémánk így néz ki: kép a kamerából -> a vezérlőszobánk -> helyi RTMP szerver -> Amazon -> videólejátszó. További részletek júniusban a Habrén.
Általánosságban elmondható, hogy ennek két globális módja van: vagy hardveren, vagy szoftveres megoldásokon alapuló. Azért választottuk a szoftveres utat, mert távoli hangszórók esetén ez egyszerűbb. Nem mindig lehet hardvert vinni egy másik országban lévő hangszóróhoz, de a szoftver eljuttatása a hangszóróhoz egyszerűbbnek és megbízhatóbbnak tűnik.
Hardveres szempontból bizonyos számú kameránk van (stúdióinkban és a távoli hangszóróknál), bizonyos számú távirányító a stúdióban, amelyeket időnként közvetlenül az asztal alatt kell megjavítani adás közben.
Az ezekről az eszközökről érkező jelek rögzítőkártyákkal, bemeneti/kimeneti kártyákkal és hangkártyákkal jutnak be a számítógépekbe. Ott a jeleket összekeverik és elrendezésekbe állítják össze:
Példa 4 hangszóró elrendezésére
Példa 4 hangszóró elrendezésére
Továbbá a folyamatos sugárzás három számítógép segítségével történik: van egy főgép és egy pár működő gép. Az első számítógép összegyűjti az első jelentést, a második a szünetet, az első a következő jelentést, a második a következő szünetet és így tovább. A főgép pedig keveri az elsőt a másodikkal.
Ez egyfajta háromszöget hoz létre, és ha bármelyik csomópont meghibásodik, gyorsan és minőségromlás nélkül tovább tudjuk szállítani a tartalmat az ügyfeleknek. Volt egy ilyen helyzetünk. A konferenciák első hetében egy gépet megjavítottunk, ki/be kapcsoltunk. Úgy tűnik, az emberek elégedettek a rugalmasságunkkal.
Ezután a számítógépekről érkező adatfolyamok egy helyi kiszolgálóra kerülnek, amelynek két feladata van: az RTMP adatfolyamok továbbítása és a rekordok biztonsági mentése. Tehát több rögzítési pontunk van. A videofolyamokat ezután rendszerünk Amazon SaaS szolgáltatásokra épülő részére küldjük. Használjuk ,S3,CloudFront.
Nikolay: Mi történik ott, mielőtt a videó eljut a közönséghez? Valahogy le kell vágni, nem?
Artyom: A videót a magunk részéről tömörítjük és elküldjük a MediaLive-nek. Ott elindítjuk a transzkódereket. Valós időben kódolják át a videókat több felbontásra, hogy az emberek megnézhessék őket telefonjukon, az ország gyenge internetén stb. Aztán ezeket a patakokat felvágják , így működik a protokoll . Lejátszási listát küldünk a frontendnek, amely mutatókat tartalmaz ezekre a darabokra.
– 1080p felbontást használunk?
Artyom: Videónk szélessége megegyezik az 1080p-vel - 1920 pixel, a magassága pedig valamivel kisebb, a kép elnyújtottabb - ennek megvan az oka.
Játékos
- Artyom leírta, hogyan kerül a videó streamekbe, hogyan kerül szét a különböző képernyőfelbontású lejátszási listákba, hogyan vágják darabokra és hogyan kerül be a lejátszóba. Kolya, most mondd meg, milyen játékos ez, hogyan fogyasztja a streamet, miért a HLS?
Nikolay: Van egy lejátszónk, amelyet minden konferencianéző megnézhet.
Lényegében ez egy csomag a könyvtár körül , amelyre sok más játékos is rá van írva. De nagyon konkrét funkcionalitásra volt szükségünk: visszatekerni és megjelölni azt a helyet, ahol az illető tartózkodik, milyen jelentést néz éppen. Szükségünk volt saját elrendezésekre is, mindenféle logóra és minden másra, ami velünk együtt beépült. Ezért úgy döntöttünk, hogy megírjuk a saját könyvtárunkat (a HLS feletti wrapper), és beágyazzuk az oldalra.
Ez a gyökér funkció, tehát szinte először valósították meg. Aztán minden nőtt körülötte.
Valójában az engedélyezés révén a lejátszó kap egy lejátszási listát a háttérből, amely linkeket tartalmaz az idővel és minőséggel korrelált darabokra, letölti a szükségeseket, és megmutatja a felhasználónak, miközben némi „varázslatot” hajt végre.
Idővonal példa
— Egy gomb közvetlenül a lejátszóba van beépítve, hogy megjelenítse az összes jelentés idővonalát...
Nikolay: Igen, azonnal megoldottuk a felhasználói navigáció problémáját. Április közepén úgy döntöttünk, hogy nem közvetítjük minden konferenciánkat külön weboldalon, hanem mindent egybe fogunk. Hogy a Full Pass jegyet használók szabadon válthassanak a különböző konferenciák között: élő adások és korábbiak felvételei között egyaránt.
Annak érdekében, hogy a felhasználók könnyebben navigálhassanak az aktuális adatfolyamon és válthassanak a műsorszámok között, úgy döntöttünk, hogy létrehozunk egy „Teljes adás” gombot és vízszintes jelentéskártyákat a műsorszámok és jelentések közötti váltáshoz. Van billentyűzet vezérlés.
– Volt-e ezzel valamilyen technikai probléma?
Nikolay: Volt rajtuk egy görgetősáv, amelyen a különböző jelentések kiindulási pontjait jelölték.
– Végül is alkalmaztad ezeket a jelöléseket a görgetősávon, mielőtt a YouTube valami hasonlót csinált volna?
Artyom: Akkor még béta állapotban volt. Úgy tűnik, hogy ez egy meglehetősen összetett funkció, mert az elmúlt évben részben tesztelték a felhasználókkal. És most értékesítésre került.
Nikolay: De valójában gyorsabban értékesítettük. Őszintén szólva, ez az egyszerű funkció mögött hatalmas mennyiségű háttér, frontend, számítások és matematika rejtőzik a lejátszón belül.
Frontend
— Találjuk ki, hogy ez a tartalom, amit megjelenítünk (beszédkártya, előadók, weboldal, ütemterv), hogyan kerül a kezelőfelületre?
Vladimir Krasilshchik: Számos belső informatikai rendszerünk van. Létezik egy rendszer, amelybe az összes jelentést és az összes felszólalót beviszik. Van egy folyamat, amelynek során az előadó részt vesz egy konferencián. Az előadó bead egy kérelmet, a rendszer rögzíti, majd van egy bizonyos pipeline, amely szerint a jelentés készül.
A hangszóró így látja a csővezetéket
Ez a rendszer a mi belső fejlesztésünk.
Ezután ütemezést kell készítenie az egyes jelentésekből. Mint tudod, ez egy NP-nehéz probléma, de valahogy megoldjuk. Ehhez elindítunk egy másik összetevőt, amely ütemezést generál, és feltölti a harmadik fél Contentful felhőszolgáltatásába. Ott minden úgy néz ki, mint egy táblázat, amelyben vannak a konferencia napjai, a napokban vannak idősávok, a résekben pedig jelentések, szünetek vagy szponzori tevékenységek. Tehát az általunk látott tartalom egy harmadik féltől származó szolgáltatásban található. A feladat pedig az, hogy közvetítse az oldalra.
Úgy tűnik, hogy a webhely csak egy oldal egy lejátszóval, és nincs itt semmi bonyolult. Kivéve, hogy nem. Az oldal mögötti háttérprogram a Contentful oldalra megy, onnan lekéri az ütemezést, generál néhány objektumot, és elküldi a frontendnek. Websocket kapcsolat segítségével, amelyet platformunk minden ügyfele készít, küldünk neki frissítést az ütemezésről a háttértől a frontend felé.
Valós eset: az előadó közvetlenül a konferencia alatt munkahelyet váltott. Meg kell változtatnunk a munkáltatói cég jelvényét. Hogyan történik ez a háttérből? A frissítést minden kliensnek elküldik a websocketen keresztül, majd maga a frontend újrarajzolja az idővonalat. Mindez zökkenőmentesen történik. A felhőszolgáltatás és több komponensünk kombinációja lehetőséget ad arra, hogy mindezt a tartalmat generáljuk és előtérbe hozzuk.
Nikolay: Itt fontos tisztázni, hogy oldalunk nem egy klasszikus SPA alkalmazás. Ez egyszerre egy elrendezés alapú, renderelt weboldal és egy SPA. A Google valójában megjelenített HTML-nek tekinti ezt a webhelyet. Ez jó a SEO-hoz és a tartalom eljuttatásához a felhasználóhoz. Nem várja meg 1,5 megabájt JavaScript betöltését, mielőtt meglátja az oldalt, hanem azonnal látja a már renderelt oldalt, és ezt minden jelentésváltáskor érzi. Minden fél másodperc alatt megtörténik, hiszen a tartalom már készen van és a megfelelő helyre került fel.
— Húzzunk egy vonalat a fentiek alá a technológiák felsorolásával. Tyoma azt mondta, hogy 5 Amazon streamünk van, és oda szállítjuk a videót és a hangot. Vannak bash szkriptjeink, amelyekkel indítjuk és konfiguráljuk...
Artyom: Ez az AWS API-n keresztül történik, ott sokkal több technikai mellékszolgáltatás található. Úgy osztottuk meg a feladatainkat, hogy teljesítsem , és a front-end és back-end fejlesztők onnan veszik át. Számos saját kötésünk van a tartalom elrendezésének egyszerűsítésére, amelyeket aztán 4K-ban stb. készítünk el. Mivel a határidők nagyon szorosak voltak, szinte teljes egészében AWS-en csináltuk.
— Aztán mindez a háttérrendszert használó lejátszóba kerül. A lejátszónkban van TypeScript, React, Next.JS. A háttérben pedig számos szolgáltatásunk van C#, Java, Spring Boot és Node.js nyelven. Mindez a Kubernetes használatával, a Yandex.Cloud infrastruktúrával van telepítve.
Azt is szeretném megjegyezni, hogy amikor meg kellett ismerkednem a platformmal, könnyűnek bizonyult: az összes adattár a GitLabon van, minden jól el van nevezve, tesztek meg vannak írva, dokumentáció van. Vagyis vészüzemmódban is intézték az ilyeneket.
Üzleti korlátok és elemzések
— Az üzleti követelmények alapján 10 000 felhasználót céloztunk meg. Itt az ideje, hogy beszéljünk az üzleti korlátozásainkról. Biztosítanunk kellett a nagy munkaterhelést, a személyes adatok megőrzéséről szóló törvény betartását. És mi más?
Nikolay: Kezdetben a videókövetelményekből indultunk ki. A legfontosabb dolog az elosztott videotárolás az egész világon, hogy gyorsan eljuttassuk az ügyfélhez. Mások közé tartozik az 1080p felbontás, valamint a visszatekerés, amit sokan mások nem valósítanak meg élő módban. Később hozzáadtuk a 2x-es sebesség engedélyezésének lehetőségét is, melynek segítségével "utolérheti" az élő adást és folytathatja a konferencia valós idejű követését. És közben megjelent az idővonal-jelölő funkció. Ráadásul hibatűrőnek kellett lennünk, és el kellett viselnünk a 10 000 csatlakozás terhelését. Háttérrendszer szempontjából ez körülbelül 10 000 kapcsolat megszorozva 8 kéréssel minden oldalfrissítésnél. Ez pedig már 80 000 RPS/mp. Elég kevés.
— Volt-e egyéb követelmény egy „virtuális kiállítás”-nál a partnerek online standjaival?
Nikolay: Igen, ezt elég gyorsan és általánosan kellett megtenni. Konferenciánként maximum 10 partnercégünk volt, és mindegyiket egy-két hét alatt kellett teljesíteni. Tartalmuk azonban formátumban kissé eltér. De készült egy bizonyos sablonmotor, amely menet közben szereli össze ezeket az oldalakat, gyakorlatilag további fejlesztési részvétel nélkül.
— Követelmények voltak a valós idejű nézetek és statisztikák elemzésére is. Tudom, hogy ehhez a Prometheust használjuk, de mondja el részletesebben: milyen követelményeknek kell megfelelnünk az elemzéssel szemben, és hogyan valósul meg ez?
Nikolay: Kezdetben marketingkövetelményeink vannak az A/B teszteléshez és az információgyűjtéshez annak érdekében, hogy megértsük, hogyan lehet megfelelően eljuttatni a legjobb tartalmat az ügyfélhez a jövőben. Követelmények vannak a partnertevékenységek elemzésére és a látható elemzésekre is (látogatásszámláló). Minden információ valós időben kerül összegyűjtésre.
Ezeket az információkat összesített formában is közölni tudjuk a felszólalóknak: hányan nézték Önt egy adott időpontban. Ugyanakkor a 152. szövetségi törvénynek való megfelelés érdekében az Ön személyes fiókját és személyes adatait semmilyen módon nem követik nyomon.
A platform már rendelkezik marketingeszközökkel és mérőszámainkkal a felhasználói aktivitás valós idejű mérésére (kik nézték meg a jelentés melyik másodpercét), hogy grafikonokat készítsünk a jelentések látogatottságáról. Ezen adatok alapján olyan kutatások zajlanak, amelyek jobbá teszik a következő konferenciákat.
Csalás
— Vannak csalás elleni mechanizmusaink?
Nikolay: Az üzleti szempontból szűkös időkeret miatt kezdetben nem a szükségtelen kapcsolatok azonnali blokkolása volt a feladat. Ha két felhasználó jelentkezett be ugyanazzal a fiókkal, megtekinthetik a tartalmat. De tudjuk, hogy egy fiókból hány egyidejű megtekintés volt. És több különösen rosszindulatú szabálysértőt kitiltottunk.
Vladimir: Becsületére legyen mondva, az egyik kitiltott felhasználó megértette, miért történt ez. Jött, bocsánatot kért és megígérte, hogy vesz egy jegyet.
— Ahhoz, hogy mindez megtörténjen, teljes mértékben nyomon kell követnie minden felhasználót a belépéstől a kilépésig, és mindig tudnia kell, mit csinál. Hogyan működik ez a rendszer?
Vladimir: Szeretnék beszélni az elemzésekről és a statisztikákról, amelyeket aztán elemezünk a jelentés sikere érdekében, vagy továbbíthatunk partnereinknek. Minden ügyfél websocket kapcsolaton keresztül csatlakozik egy adott háttérfürthöz. Ott áll . Minden ügyfél minden időintervallumban elküldi, hogy mit csinál, és milyen műsorszámot néz. Ezután ezeket az információkat a rendszer gyors Hazelcast-feladatok segítségével összesíti, és visszaküldi mindenkinek, aki nézi ezeket a számokat. A sarokban látjuk, mennyi ember van most velünk.
Ugyanezek az információk tárolódnak és elmegy az adattavunkhoz, amiből lehetőségünk nyílik egy érdekesebb grafikon felépítésére. Felmerül a kérdés: hány egyedi felhasználó tekintette meg ezt a jelentést? Megyünk , minden olyan ember pingjei között szerepel, aki a jelentés azonosítójával érkezett. Egyedieket gyűjtöttünk, összesítettünk, és most már érthető.
Nikolay: De ugyanakkor valós idejű adatokat is kapunk a Prometheustól. Minden Kubernetes szolgáltatással szemben áll, magával a Kubernetes-szel. Abszolút mindent összegyűjt, a Grafana segítségével pedig bármilyen grafikont készíthetünk valós időben.
Vladimir: Egyrészt letöltjük ezt a további OLAP-feldolgozáshoz. Az OLTP-nél pedig az alkalmazás letölti az egészet Prometheus-ra, Grafana-ra és a grafikonok még konvergálnak is!
- Ez az eset, amikor a grafikonok konvergálnak.
Dinamikus változások
— Mondja el, hogyan hajtják végre a dinamikus változtatásokat: ha a bejelentést 6 perccel a kezdés előtt törölték, mi a lépések láncolata? Melyik csővezeték működik?
Vladimir: A csővezeték nagyon feltételes. Több lehetőség is van. Az első az, hogy az ütemtervet létrehozó program működött, és megváltoztatta az ütemezést. A módosított ütemterv feltöltődik a Contentful oldalra. Ezt követően a háttérrendszer megérti, hogy változások történtek ezen a konferencián a Contentful alkalmazásban, átveszi és újraépíti. Mindent összegyűjtenek és elküldenek websocket-en keresztül.
A második lehetőség, amikor minden rohamtempóban történik: a szerkesztő manuálisan módosítja az információkat a Contentful-ban (hivatkozás a Telegramra, előadó prezentációja stb.), és ugyanaz a logika működik, mint az első alkalommal.
Nikolay: Minden az oldal frissítése nélkül történik. Minden változás zökkenőmentesen megy végbe az ügyfél számára. Ugyanez vonatkozik a jelentésváltásra is. Ha eljön az ideje, a jelentés és a felület megváltozik.
Vladimir: Ezenkívül az idővonalon a jelentések kezdetére vonatkozó határidők is vannak. A legelején nincs semmi. És ha az egeret a piros csík fölé viszi, akkor a közvetítés rendezőjének köszönhetően valamikor levágások jelennek meg. A rendező beállítja az adás helyes kezdetét, a backend felveszi ezt a változást, a konferencia ütemtervének megfelelően kiszámítja a teljes pálya bemutatóinak kezdési és befejezési időpontját, elküldi ügyfeleinknek, a játékos pedig cutoffokat húz. Mostantól a felhasználó könnyedén navigálhat a jelentés elejére és végére. Szigorú üzleti követelmény volt, nagyon kényelmes és hasznos. Nem vesztegeti az időt a jelentés tényleges kezdési időpontjának megkeresésére. És amikor elkészítjük az előzetest, az teljesen csodálatos lesz.
Telepítés
— A bevetésről szeretnék kérdezni. Kolya és a csapat kezdetben sok időt fordítottak arra, hogy felállítsák a teljes infrastruktúrát, amelyben minden kibontakozik számunkra. Mondd, miből van az egész?
Nikolay: Technikai szempontból kezdetben az volt a követelményünk, hogy a termék a lehető legelvontabb legyen bármely szállítótól. Lépjen be az AWS-be, és készítsen Terraform szkripteket kifejezetten az AWS-ből, vagy kifejezetten a Yandexből, vagy az Azure-ból stb. nem igazán jött be. Valamikor el kellett költöznünk valahova.
Az első három hétben folyamatosan kerestük a módját, hogy ezt jobbá tegyük. Ennek eredményeként arra a következtetésre jutottunk, hogy ebben az esetben a Kubernetes a mindenünk, mert lehetővé teszi számunkra, hogy automatikusan skálázódó szolgáltatásokat hozzunk létre, automatikusan kiterjesszük, és szinte minden szolgáltatást kivehetünk a dobozból. Természetesen minden szolgáltatást ki kellett képezni a Kubernetes és a Docker együttműködésére, és a csapatnak is tanulnia kellett.
Két klaszterünk van. Teszt és gyártás. Hardverben és beállításokban teljesen azonosak. Az infrastruktúrát kódként valósítjuk meg. Az összes szolgáltatás automatikusan három környezetbe kerül a szolgáltatási ágakból, a fő ágakból, a tesztágakból és a GitLabból egy automatikus folyamat segítségével. Ez maximálisan integrálva van a GitLab-ba, maximálisan integrálva az Elastic-hoz, a Prometheus-hoz.
Lehetőséget kapunk arra, hogy gyorsan (a háttérben 10 percen belül, a frontendben 5 percen belül) bármilyen környezetben végrehajtsuk a módosításokat az összes teszttel, integrációkkal, funkcionális tesztek futtatásával, integrációs tesztekkel a környezetben, valamint terhelési tesztekkel is. egy tesztkörnyezet körülbelül ugyanaz, mint amit élesben szeretnénk megszerezni.
A tesztekről
- Szinte mindent tesztelsz, nehéz elhinni, hogy mindent leírtál. Mesélne nekünk a háttértesztekről: mennyi mindenre vonatkozik, milyen tesztek?
Vladimir: Kétféle tesztet írtak. Az első a komponenstesztek. Emelési szint tesztek a teljes rugófelhordásnál és az alapozásnál . Ez a legmagasabb szintű üzleti forgatókönyvek tesztje. Nem tesztelem a funkciókat. Csak néhány nagy dolgot tesztelünk. Például közvetlenül a tesztben emulálódik a felhasználó bejelentkezésének folyamata, a felhasználó jegykérése, hogy hová mehet, és hozzáférési kérelmet kér a stream megtekintéséhez. Nagyon világos felhasználói forgatókönyvek.
Körülbelül ugyanezt implementálják az úgynevezett integrációs tesztek, amelyek valójában a környezetben futnak. Valójában a következő üzembe helyezéskor az éles környezetben valós alapforgatókönyvek is futnak. Ugyanaz a bejelentkezés, jegyek kérése, hozzáférés kérése a CloudFronthoz, ellenőrzés, hogy a stream valóban csatlakozik-e az engedélyeimhez, a rendezői felület ellenőrzése.
Jelenleg körülbelül 70 alkatrészteszt és körülbelül 40 integrációs teszt van a fedélzeten. A lefedettség nagyon közel van a 95%-hoz. Ez a komponensekhez való, az integrációsakhoz kevésbé, egyszerűen nincs olyan nagy szükség. Figyelembe véve, hogy a projekt mindenféle kódgenerálást tartalmaz, ez nagyon jó mutató. Nem volt más módja annak, amit három hónap alatt tettünk. Mert ha manuálisan tesztelnénk, funkciókat adva a tesztelőnknek, és ő megtalálná a hibákat és visszaküldené nekünk javításra, akkor ez a kód hibakeresési útja nagyon hosszú lenne, és nem tartanánk be a határidőket.
Nikolay: Hagyományosan ahhoz, hogy a teljes platformon regressziót hajtson végre valamilyen funkció megváltoztatásakor, két napig mindenhol le kell ülnie és piszkálnia kell.
Vladimir: Ezért nagy siker, hogy amikor megbecsülök egy funkciót, azt mondom, hogy 4 nap kell két egyszerű tollhoz és 1 websockethez, Kolya megengedi. Már megszokta, hogy ez a 4 nap 2 féle vizsgálatot tartalmaz, és akkor nagy valószínűséggel menni fog.
Nikolay: 140 tesztem is van írva: komponens + funkcionális, amik ugyanezt csinálják. Ugyanazokat a forgatókönyveket tesztelik a termelésben, a tesztben és a termelésben. Nemrég hozzáadtunk funkcionális alapvető felhasználói felület teszteket is. Így lefedjük a legalapvetőbb funkciókat, amelyek széteshetnek.
Vladimir: Természetesen érdemes beszélni a terhelési tesztekről. A platformot a valódihoz közeli terhelés alatt kellett tesztelni, hogy megértsük, hogyan is van minden, mi történik a Rabbittel, mi történik a JVM-ekkel, mennyi memória szükséges valójában.
- Nem tudom biztosan, hogy tesztelünk-e valamit a stream oldalon, de emlékszem, hogy voltak problémák a transzkóderekkel, amikor találkoztunk. Teszteltük a streameket?
Artyom: Iteratívan tesztelve. Találkozók szervezése. A találkozók szervezése során megközelítőleg 2300 JIRA jegy volt. Ezek csak általános dolgok, amelyeket az emberek azért tettek, hogy találkozókat szervezzenek. A platform egyes részeit külön oldalra vittük a találkozókhoz, amelyet Kirill Tolkachev ().
Őszintén szólva nem voltak nagy problémák. Szó szerint néhányszor elkaptuk a gyorsítótárazási hibákat a CloudFronton, és elég gyorsan megoldottuk – egyszerűen átkonfiguráltuk a házirendeket. Lényegesen több volt a hiba az emberekben, az oldal streaming rendszereiben.
A konferenciák során több exportőrt kellett írnom, hogy minél több felszerelést és szolgáltatást lefedjek. Egyes helyeken már csak a mérőszámok kedvéért is saját kerékpárt kellett készítenem. Az AV (audio-video) hardver világa nem túl rózsás – van valamiféle „API”-je a berendezésnek, amelyet egyszerűen nem tud befolyásolni. És távolról sem tény, hogy képes lesz megszerezni a szükséges információkat. A hardvergyártók nagyon lassúak, és szinte lehetetlen megszerezni tőlük, amit akarsz. Összesen több mint 100 hardver van, nem adják vissza azt, amire szükséged van, és furcsa és felesleges exportőröket írsz, amiknek köszönhetően legalább valahogyan debuggolni tudod a rendszert.
Оборудование
— Emlékszem, hogy a konferenciák kezdete előtt részben kiegészítő eszközöket vásároltunk.
Artyom: Vásároltunk számítógépeket, laptopokat, akkumulátorokat. Jelenleg 40 percig élhetünk áram nélkül. Júniusban heves zivatarok voltak Szentpéterváron – ezért volt ilyen áramszünet. Ugyanakkor több szolgáltató különböző pontokról érkezik hozzánk optikai kapcsolattal. Ez valóban 40 perc építési leállás, ami alatt világítanak, működnek a hangok, kamerák stb.
— Hasonló történetünk van az internettel is. Az irodában, ahol a stúdióink találhatók, heves hálót húztunk az emeletek közé.
Artyom: 20 Gbit szálunk van az emeletek között. Az emeletek mentén hol van, hol nincs optika, de így is kevesebb a csatorna, mint a gigabites - a konferencia műsorszámai között videózunk rajtuk. Általánosságban elmondható, hogy nagyon kényelmes a saját infrastruktúrán dolgozni; ezt ritkán teheti meg a webhelyeken tartott offline konferenciákon.
— Mielőtt a JUG Ru Groupnál dolgoztam, láttam, hogy az offline konferenciákon egyik napról a másikra hogyan állítottak fel hardvertermeket, ahol volt egy nagy monitor a Grafanában épített összes mérőszámmal. Most már van egy központ is, amelyben a fejlesztőcsapat ül, akik a konferencia során javítanak néhány hibát és fejlesztenek funkciókat. Ugyanakkor van egy felügyeleti rendszer, amely egy nagy képernyőn jelenik meg. Artyom, Kolya és más srácok ülnek, és ügyelnek arra, hogy minden ne essen és szépen működjön.
Érdekességek és problémák
— Jól beszélt arról, hogy van streamelésünk az Amazon-nal, van egy lejátszó a weben, minden különböző programozási nyelveken van megírva, hibatűrés és egyéb üzleti követelmények biztosítottak, beleértve a jogi személyek számára támogatott személyes fiókot, ill. magánszemélyek, és OAuth 2.0 használatával integrálhatunk valakivel, van csalás elleni védelem, felhasználóblokkolás. Dinamikusan tudjuk végrehajtani a változtatásokat, mert jól csináltuk, és minden tesztelve van.
Érdekelne, hogy milyen furcsaságok voltak abban, hogy valami elindult. Voltak olyan furcsa helyzetek, amikor egy backendet, frontendet fejlesztettél, valami őrültség alakult ki, és nem értettél, mit kezdj vele?
Vladimir: Számomra úgy tűnik, hogy ez csak az elmúlt három hónapban történt. Minden nap. Amint látja, az összes hajam ki lett húzva.
Vladimir Krasilshchik 3 hónap után, amikor kiderült valami játék, és senki sem értett, mit kezdjen vele
Minden nap volt ilyen, amikor volt egy olyan pillanat, amikor az ember előveszi és kitépi a haját, vagy rájön, hogy nincs más, és ezt csak te tudod megtenni. Az első nagy rendezvényünk a TechTrain volt. Június 6-án hajnali 2-kor még nem vezettük be a gyártási környezetet, a Kolya éppen elindította. A személyes fiók pedig nem működött engedélyezési szerverként az OAuth2.0 használatával. OAuth2.0-s szolgáltatóvá alakítottuk, hogy összekapcsoljuk vele a platformot. Valószínűleg 18 órája dolgoztam egyfolytában, a számítógépre néztem, és nem láttam semmit, nem értettem, miért nem működik, és Kolya távolról megnézte a kódomat, hibát keresett a tavaszi konfigurációban. , megtalálta, és az LC működött, és a gyártásban is .
Nikolay: Egy órával a TechTrain előtt pedig megtörtént a kiadás.
Sok sztár sorakozott itt. Rendkívül szerencsések voltunk, mert szuper csapatunk volt, és mindenkit megihletett az ötlet, hogy online csináljuk. Ez alatt a három hónap alatt az vezérelt bennünket, hogy „elkészítettük a YouTube-ot”. Nem engedtem meg magamnak, hogy kitépjem a hajam, hanem mindenkinek azt mondtam, hogy minden sikerülni fog, mert valójában már régen ki volt számítva minden.
A teljesítményről
— Meg tudná mondani, hányan voltak az oldalon egy pályán? Voltak teljesítménybeli problémák?
Nikolay: Nem volt teljesítményprobléma, ahogy már mondtuk. Egy riporton maximum 1300 ember vett részt, ez a Heisenbug-on van.
— Problémák voltak a helyi nézéssel? És lehet egy műszaki leírást diagramokkal, hogy mindez hogyan működik?
Nikolay: Erről később készítünk egy cikket.
Akár helyben is hibakeresheti a streameket. Miután elkezdődtek a konferenciák, még könnyebbé vált, mert megjelentek a produkciós streamek, amelyeket folyamatosan nézhetünk.
Vladimir: Ha jól értem, a front-end fejlesztők helyben dolgoztak gúnyolással, majd mivel az előlapi fejlesztőkhöz való kijutás ideje is rövid (5 perc), nincs gond a tanúsítványok állapotának ellenőrzésével.
— Mindent tesztelnek és hibakeresnek, még helyben is. Ez azt jelenti, hogy írunk egy cikket az összes műszaki jellemzővel, megmutatjuk, diagramokkal mindent elmondunk, hogyan is volt.
Vladimir: Elveheted és megismételheted.
- 3 hónap múlva.
Teljes
— Minden, amit leírtunk, jól hangzik, tekintve, hogy egy kis csapat három hónap alatt csinálta.
Nikolay: Egy nagy csapat ezt nem tenné meg. De az emberek egy kis csoportja, akik meglehetősen szorosan és jól kommunikálnak egymással, és képesek megegyezni. Nincsenek ellentmondások, az építészetet két nap alatt találták ki, véglegesítették és tulajdonképpen nem változott. Nagyon szigorúan könnyítik a beérkező üzleti követelményeket a szolgáltatáskérelmek és -módosítások halmozása tekintetében.
— Mi szerepelt a további feladatai között, amikor már lezajlottak a nyári konferenciák?
Nikolay: Például kreditek. Kúszó vonalak a videón, egyes helyeken felugró ablakok a videóban a megjelenített tartalomtól függően. Például a felszólaló kérdést akar feltenni a hallgatóságnak, és a képernyőn egy szavazat jelenik meg, amely a szavazás eredménye alapján hátrafelé megy vissza magához az előadóhoz. Valamiféle közösségi tevékenység lájkok, szívek, értékelések formájában a beszámolónak maga a prezentáció során, hogy a megfelelő pillanatban tölthesse ki a visszajelzést anélkül, hogy később a visszajelzési űrlapok megzavarnák. Kezdetben így.
És a teljes platformhoz a streaming és a konferencia kivételével egy konferencia utáni állapot is hozzáadódik. Ezek lejátszási listák (beleértve a felhasználók által összeállítottakat is), esetleg más korábbi konferenciákról származó tartalmak, integrált, címkézett, a felhasználó számára elérhető, és a weboldalunkon is megtekinthető ().
– Srácok, köszönöm szépen a válaszokat!
Ha az olvasók között van olyan, aki részt vett nyári konferenciáinkon, kérjük, ossza meg benyomásait a játékosról és a közvetítésről. Mi volt kényelmes, mi irritált, mit szeretnél látni a jövőben?
Ha érdekli a platform, és szeretné látni „csatában”, újra használjuk a mi platformunkon . Sokféle létezik belőlük, így szinte biztosan van olyan, amelyik megfelel az Ön számára.
Forrás: will.com