Ĉi-printempe ni trovis nin en tre gajaj kondiĉoj. Pro la pandemio evidentiĝis, ke niaj someraj konferencoj devas esti translokigitaj interrete. Kaj por efike konduki ilin interrete, pretaj programaj solvoj ne taŭgis por ni; ni bezonis skribi nian propran. Kaj ni havis tri monatojn por fari ĉi tion.
Estas klare, ke ĝi estis ekscita tri monatoj. Sed ekstere ĝi ne estas tute evidenta: kio estas reta konferenca platformo? El kiuj partoj ĝi konsistas? Tial, ĉe la lasta de la someraj DevOops-konferencoj, mi demandis tiujn, kiuj respondecis pri ĉi tiu tasko:
- Nikolay Molchanov - teknika direktoro de JUG Ru Group;
- Vladimir Krasilshchik estas pragmata Java-programisto laboranta pri la backend (vi povus ankaŭ vidi liajn raportojn ĉe niaj Java-konferencoj);
- Artyom Nikonov respondecas pri ĉiuj niaj filmetoj.
Cetere, ĉe la aŭtuno-vintraj konferencoj ni uzos plibonigitan version de la sama platformo - tiom da habra legantoj ankoraŭ estos ĝiaj uzantoj.
Ĝenerala bildo
— Kio estis la konsisto de la teamo?
Nikolaj Molĉanov: Ni havas analiziston, dezajniston, testilon, tri front-endistojn kaj back-end. Kaj, kompreneble, specialisto en T-forma!
— Kiel aspektis la procezo ĝenerale?
Nikolay: Ĝis meze de marto, ni havis nenion pretan por rete. Kaj la 15-an de marto, la tuta reta karuselo komencis turniĝi. Ni starigis plurajn deponejojn, planis, diskutis la bazan arkitekturon kaj faris ĉion en tri monatoj.
Ĉi tio kompreneble trapasis la klasikajn stadiojn de planado, arkitekturo, trajto-elekto, voĉdonado por tiuj funkcioj, politiko por tiuj trajtoj, ilia dezajno, evoluo, testado. Kiel rezulto, la 6-an de junio, ni lanĉis ĉion al produktado. . Estis 90 tagoj por ĉio.
— Ĉu ni sukcesis plenumi tion, al kio ni engaĝiĝis?
Nikolay: Ĉar ni nun partoprenas la DevOops-konferencon interrete, tio signifas, ke ĝi funkciis. Mi persone engaĝiĝis al la ĉefa afero: mi alportos al klientoj ilon per kiu ili povas fari interretan konferencon.
La defio estis jena: donu al ni ilon per kiu ni povas elsendi niajn konferencojn al biletposedantoj.
Ĉiu planado estis dividita en plurajn stadiojn, kaj ĉiuj trajtoj (ĉirkaŭ 30 tutmondaj) estis dividitaj en 4 kategoriojn:
- kion ni certe faros (ni ne povas vivi sen ili),
- kion ni faros due,
- kion ni neniam faros,
- kaj kion ni neniam, neniam faros.
Ni faris ĉiujn funkciojn de la unuaj du kategorioj.
— Mi scias, ke entute 600 JIRA-numoj estis kreitaj. En tri monatoj, vi faris 13 mikroservojn, kaj mi suspektas, ke ili estis skribitaj ne nur en Java. Vi uzis malsamajn teknologiojn, vi havas du Kubernetes-aretojn en tri haveblecaj zonoj kaj 5 RTMP-riveretoj en Amazon.
Ni nun rigardu ĉiun komponenton de la sistemo aparte.
Streaming
— Ni komencu per kiam ni jam havas videobildon, kaj ĝi estas transdonita al iuj servoj. Artyom, diru al ni kiel ĉi tiu streaming okazas?
Artjom Nikonov: Nia ĝenerala skemo aspektas tiel: bildo de la fotilo -> nia kontrolĉambro -> loka RTMP-servilo -> Amazon -> videoludilo. Pli da detaloj sur Habré en junio.
Ĝenerale, ekzistas du tutmondaj manieroj fari tion: aŭ sur aparataro aŭ surbaze de softvarsolvoj. Ni elektis la programaran vojon ĉar ĝi estas pli facila en la kazo de foraj laŭtparoliloj. Ne ĉiam eblas alporti aparataron al parolanto en alia lando, sed liveri programaron al la parolanto ŝajnas pli facila kaj pli fidinda.
El aparatara vidpunkto, ni havas certan nombron da fotiloj (en niaj studioj kaj ĉe foraj laŭtparoliloj), certan nombron da teleregiloj en la studio, kiuj foje devas esti riparitaj ĝuste sub la tablo dum la elsendo.
Signaloj de ĉi tiuj aparatoj eniras komputilojn kun kaptkartoj, enig/eligkartoj, kaj sonkartoj. Tie la signaloj estas miksitaj kaj kunvenitaj en aranĝojn:
Ekzemplo de aranĝo por 4 parolantoj
Ekzemplo de aranĝo por 4 parolantoj
Plue, kontinua elsendo estas provizita per la helpo de tri komputiloj: estas unu ĉefa maŝino kaj paro da laborantaj en victurno. La unua komputilo kolektas la unuan raporton, la dua - la paŭzo, la unua - la sekva raporto, la dua - la sekva paŭzo, ktp. Kaj la ĉefa maŝino miksas la unuan kun la dua.
Ĉi tio kreas specon de triangulo, kaj se iu el ĉi tiuj nodoj malsukcesas, ni povas rapide kaj sen perdo de kvalito daŭrigi liveri enhavon al klientoj. Ni havis tian situacion. Dum la unua semajno da konferencoj, ni riparis unu maŝinon, ŝaltis/malŝaltis ĝin. Homoj ŝajnas esti feliĉaj kun nia rezistemo.
Poste, la fluoj de la komputiloj iras al loka servilo, kiu havas du taskojn: direkti RTMP-riveretojn kaj registri sekurkopiojn. Do ni havas plurajn registradpunktojn. La videofluoj tiam estas senditaj al la parto de nia sistemo konstruita sur Amazon SaaS-servoj. Ni uzas ,S3,CloudFront.
Nikolay: Kio okazas tie antaŭ ol la video atingas la spektantaron? Vi devas tranĉi ĝin iel, ĉu ne?
Artjom: Ni kunpremas la videon nianflanke kaj sendas ĝin al MediaLive. Ni lanĉas transkodilojn tie. Ili transkodas filmetojn en reala tempo en plurajn rezoluciojn por ke homoj povu spekti ilin per siaj telefonoj, per malbona Interreto en la lando, ktp. Tiam ĉi tiuj riveretoj estas tranĉitaj en , jen kiel funkcias la protokolo . Ni sendas ludliston al la fasado kiu enhavas montrilojn al ĉi tiuj partoj.
— Ĉu ni uzas 1080p-rezolucion?
Artjom: La larĝo de nia video estas la sama kiel 1080p - 1920 pikseloj, kaj la alteco estas iom malpli, la bildo estas pli longforma - estas kialoj por tio.
Ludanto
— Artyom priskribis kiel la video eniras en riveretojn, kiel ĝi estas distribuita en malsamajn ludlistojn por malsamaj ekranrezolucioj, tranĉita en pecojn kaj eniras la ludanton. Kolya, nun diru al mi kia ludanto ĉi tio estas, kiel ĝi konsumas la fluon, kial HLS?
Nikolay: Ni havas ludanton, kiun ĉiuj konferencaj spektantoj povas spekti.
Esence, ĉi tio estas envolvaĵo ĉirkaŭ la biblioteko , sur kiu multaj aliaj ludantoj estas skribitaj. Sed ni bezonis tre specifan funkciecon: rebobeni kaj marki la lokon kie la persono estas, kian raporton li nun rigardas. Ni ankaŭ bezonis niajn proprajn aranĝojn, ĉiajn emblemojn kaj ĉion alian, kio estis enkonstruita ĉe ni. Tial ni decidis skribi nian propran bibliotekon (envolvaĵo super HLS) kaj enmeti ĝin en la retejon.
Ĉi tiu estas la radika funkcio, do ĝi estis efektivigita preskaŭ unue. Kaj tiam ĉio kreskis ĉirkaŭ ĝi.
Fakte, per rajtigo, la ludanto ricevas de la backend ludliston kun ligiloj al pecoj korelaciitaj kun tempo kaj kvalito, elŝutas la necesajn kaj montras ilin al la uzanto, farante iun "magion" laŭ la vojo.
Ekzemplo de templinio
— Butono estas konstruita ĝuste en la ludanto por montri templinion de ĉiuj raportoj...
Nikolay: Jes, ni tuj solvis la problemon de uzantnavigado. Meze de aprilo ni decidis, ke ni ne dissendos ĉiun niajn konferencojn en aparta retejo, sed kombinos ĉion sur unu. Por ke la uzantoj de Full Pass-biletoj povu libere ŝanĝi inter malsamaj konferencoj: kaj vivaj elsendoj kaj registradoj de pasintaj.
Kaj por faciligi al uzantoj navigi la nunan fluon kaj ŝanĝi inter trakoj, ni decidis fari butonon "Tuta elsendo" kaj horizontalajn raportkartojn por ŝanĝi inter trakoj kaj raportoj. Estas klavara kontrolo.
— Ĉu estis teknikaj malfacilaĵoj kun ĉi tio?
Nikolay: Ili havis rulstangon sur kiu la deirpunktoj de malsamaj raportoj estis markitaj.
— En la fino, ĉu vi efektivigis ĉi tiujn markojn sur la rulumbreto antaŭ ol Jutubo faris ion similan?
Artjom: Ili havis ĝin en beta tiam. Ŝajnas, ke ĉi tio estas sufiĉe kompleksa trajto ĉar ili parte provis ĝin kun uzantoj dum la pasinta jaro. Kaj nun ĝi atingis vendon.
Nikolay: Sed ni efektive vendis ĝin pli rapide. Sincere, malantaŭ ĉi tiu simpla funkcio estas grandega kvanto da backend, fasado, kalkuloj kaj matematiko ene de la ludanto.
Frontend
— Ni eltrovu kiel ĉi tiu enhavo, kiun ni montras (parolkarto, parolantoj, retejo, horaro) atingas la antaŭan finon?
Vladimir Krasilshchik: Ni havas plurajn internajn IT-sistemojn. Estas sistemo en kiu ĉiuj raportoj kaj ĉiuj parolantoj estas enmetitaj. Estas procezo per kiu parolanto partoprenas en konferenco. La parolanto sendas peton, la sistemo kaptas ĝin, tiam ekzistas certa dukto laŭ kiu la raporto estas kreita.
Jen kiel la parolanto vidas la dukton
Ĉi tiu sistemo estas nia interna evoluo.
Poste, vi devas konstrui horaron el individuaj raportoj. Kiel vi scias, ĉi tio estas NP-malmola problemo, sed ni iel solvas ĝin. Por fari tion, ni lanĉas alian komponenton, kiu generas horaron kaj alŝutas ĝin al la triaparta nuba servo Contentful. Tie ĉio aspektas kiel tablo, en kiu estas tagoj de la konferenco, en la tagoj estas tempoperiodoj, kaj en la fendoj estas raportoj, paŭzoj aŭ sponsoraj agadoj. Do la enhavo, kiun ni vidas, situas en triaparta servo. Kaj la tasko estas transdoni ĝin al la retejo.
Ŝajnus, ke la retejo estas nur paĝo kun ludanto, kaj ĉi tie estas nenio komplika. Krom ĝi ne estas. La backend malantaŭ ĉi tiu paĝo iras al Contentful, ricevas la horaron de tie, generas kelkajn objektojn kaj sendas ĝin al la fasado. Uzante websocket-konekton, kiun ĉiu kliento de nia platformo faras, ni sendas al li ĝisdatigon al la horaro de la backend ĝis la fasado.
Vera kazo: la preleganto ŝanĝis laboron ĝuste dum la konferenco. Ni devas ŝanĝi lian insignon de dunganto-firmao. Kiel tio okazas de la backend? Ĝisdatigo estas sendita al ĉiuj klientoj per la retsocket, kaj tiam la fasado mem redesegnis la templinion. Ĉio ĉi okazas perfekte. La kombinaĵo de la nuba servo kaj pluraj el niaj komponantoj donas al ni la ŝancon generi ĉi tiun tutan enhavon kaj provizi ĝin ĉe la fronto.
Nikolay: Gravas klarigi ĉi tie, ke nia retejo ne estas klasika SPA-apliko. Ĉi tio estas kaj aranĝo-bazita, prezentita retejo kaj SPA. Guglo efektive vidas ĉi tiun retejon kiel igita HTML. Ĉi tio estas bona por SEO kaj por liveri enhavon al la uzanto. Ĝi ne atendas ke 1,5 megabajtoj da JavaScript ŝargiĝu antaŭ ol vidi la paĝon, ĝi tuj vidas la jam bilditan paĝon, kaj vi sentas ĝin ĉiufoje kiam vi ŝanĝas la raporton. Ĉio okazas en duona sekundo, ĉar la enhavo jam estas preta kaj afiŝita en la ĝusta loko.
— Ni desegnu linion sub ĉio ĉi-supra listigante la teknologiojn. Tyoma diris, ke ni havas 5 Amazon-riveretojn, kaj ni liveras videon kaj sonon tie. Ni havas bash-skriptojn tie, ni uzas ilin por lanĉi kaj agordi...
Artjom: Ĉi tio okazas per la AWS API, ekzistas multaj pli teknikaj flankaj servoj tie. Ni dividis niajn respondecojn tiel ke mi liveras al , kaj antaŭfinaj kaj malantaŭaj programistoj prenas ĝin de tie. Ni havas kelkajn proprajn ligojn por simpligi la aranĝon de enhavo, kiun ni poste faras en 4K ktp. Ĉar la limdatoj estis tre striktaj, ni faris ĝin preskaŭ tute sur AWS.
— Tiam ĉio ĉi eniras la ludanton uzante la backend-sistemon. Ni havas TypeScript, React, Next.JS en nia ludanto. Kaj sur la backend ni havas plurajn servojn en C#, Java, Spring Boot kaj Node.js. Ĉio ĉi estas deplojita per Kubernetes per la Yandex.Cloud-infrastrukturo.
Mi ankaŭ volas rimarki, ke kiam mi bezonis konatiĝi kun la platformo, ĝi montriĝis facila: ĉiuj deponejoj estas sur GitLab, ĉio estas bone nomita, testoj estas skribitaj, estas dokumentaro. Tio estas, eĉ en kriz-reĝimo, ili zorgis pri tiaj aferoj.
Komercaj Limoj kaj Analitiko
— Ni celis 10 uzantojn laŭ komercaj postuloj. Estas tempo paroli pri la komercaj limigoj, kiujn ni havis. Ni devis certigi altan laborŝarĝon, certigi plenumon de la leĝo pri konservado de personaj datumoj. Kaj kio alia?
Nikolay: Komence, ni komencis de videopostuloj. La plej grava afero estas distribuita videostokado tra la mondo por rapida livero al la kliento. Aliaj inkluzivas 1080p-rezolucion, same kiel rebobenadon, kiun multaj aliaj ne efektivigas en viva reĝimo. Poste ni aldonis la kapablon ebligi 2x-rapidecon, kun ĝia helpo vi povas "kapti" kun la viva kaj daŭrigi spekti la konferencon en reala tempo. Kaj survoje, templinia markado funkcieco aperis. Krome, ni devis esti toleremaj al misfunkciadoj kaj elteni la ŝarĝon de 10 konektoj. De backend vidpunkto, ĉi tio estas proksimume 000 konektoj multobligitaj per 10 petoj por ĉiu paĝa refreŝiĝo. Kaj ĉi tio jam estas 000 RPS/sek. Sufiĉe da.
— Ĉu estis aliaj postuloj por "virtuala ekspozicio" kun interretaj standoj de partneroj?
Nikolay: Jes, ĉi tio devis esti farita sufiĉe rapide kaj universale. Ni havis ĝis 10 partnerajn kompaniojn por ĉiu konferenco, kaj ĉiuj ili devis esti kompletigitaj en unu aŭ du semajnoj. Tamen ilia enhavo iomete malsamas laŭ formato. Sed certa ŝablonmotoro estis farita kiu kunvenas ĉi tiujn paĝojn sur la flugo, kun preskaŭ neniu pluevoluiga partopreno.
— Estis ankaŭ postuloj por analizo de realtempaj vidoj kaj statistikoj. Mi scias, ke ni uzas Prometheus por tio, sed diru al ni pli detale: kiajn postulojn ni plenumas por analizo, kaj kiel ĉi tio efektiviĝas?
Nikolay: Komence, ni havas merkatajn postulojn por kolekti por A/B-testado kaj kolekti informojn por kompreni kiel ĝuste liveri la plej bonan enhavon al la kliento estonte. Estas ankaŭ postuloj por iuj analizoj pri partneraj agadoj kaj la analizoj, kiujn vi vidas (vizita nombrilo). Ĉiuj informoj estas kolektitaj en reala tempo.
Ni povas provizi ĉi tiujn informojn en agregita formo eĉ al parolantoj: kiom da homoj observis vin en certa momento. Samtempe, por plenumi la Federalan Leĝon 152, via persona konto kaj personaj datumoj neniel estas spuritaj.
La platformo jam havas merkatigajn ilojn kaj niajn metrikojn por mezuri uzantan agadon en reala tempo (kiu rigardis kian sekundon de la raporto) por konstrui grafikaĵojn de ĉeesto ĉe la raportoj. Surbaze de ĉi tiuj datumoj, esploroj estas faritaj, kiuj plibonigos la venontajn konferencojn.
Fraŭdo
— Ĉu ni havas kontraŭfraŭdajn mekanismojn?
Nikolay: Pro la streĉa tempokadro de komerca vidpunkto, la tasko ne estis komence fiksita por tuj bloki nenecesajn konektojn. Se du uzantoj ensalutis sub la sama konto, ili povus vidi la enhavon. Sed ni scias kiom da samtempaj vidoj estis de unu konto. Kaj ni malpermesis plurajn aparte malicajn malobservantojn.
Vladimiro: Al sia kredito, unu el la malpermesitaj uzantoj komprenis kial tio okazis. Li venis, pardonpetis kaj promesis aĉeti bileton.
— Por ke ĉio ĉi okazu, vi devas tute spuri ĉiujn uzantojn de eniro ĝis eliro, ĉiam scii kion ili faras. Kiel funkcias ĉi tiu sistemo?
Vladimiro: Mi ŝatus paroli pri analitiko kaj statistiko, kiujn ni tiam analizas por la sukceso de la raporto aŭ poste povas provizi al partneroj. Ĉiuj klientoj estas konektitaj per retkonekto al specifa backend-grupo. Ĝi staras tie . Ĉiu kliento je ĉiu tempoperiodo sendas tion, kion li faras kaj kian trakon li spektas. Tiam ĉi tiuj informoj estas kunigitaj uzante rapidajn laborojn de Hazelcast kaj resendataj al ĉiuj, kiuj spektas ĉi tiujn trakojn. Ni vidas en la angulo kiom da homoj nun estas kun ni.
La sama informo estas konservita en kaj iras al nia datuma lago, el kiu ni havas la ŝancon konstrui pli interesan grafeon. Estiĝas la demando: kiom da unikaj uzantoj rigardis ĉi tiun raporton? Ni iras al , estas pingoj de ĉiuj homoj, kiuj venis per la id de ĉi tiu raporto. Ni kolektis, kunigis unikajn, kaj nun ni povas kompreni.
Nikolay: Sed samtempe ni ankaŭ ricevas realtempajn datumojn de Prometeo. Ĝi estas metita kontraŭ ĉiuj Kubernetes-servoj, kontraŭ Kubernetes mem. Ĝi kolektas absolute ĉion, kaj kun Grafana ni povas konstrui ajnajn grafikaĵojn en reala tempo.
Vladimiro: Unuflanke, ni elŝutas ĉi tion por plia OLAP-prilaborado. Kaj por OLTP, la aplikaĵo elŝutas la tuton al Prometheus, Grafana kaj la grafikaĵoj eĉ konverĝas!
- Tiel okazas kiam la grafikaĵoj konverĝas.
Dinamikaj Ŝanĝoj
— Diru al ni kiel dinamikaj ŝanĝoj estas lanĉitaj: se la raporto estis nuligita 6 minutojn antaŭ la komenco, kio estas la ĉeno de agoj? Kiu dukto funkcias?
Vladimiro: La dukto estas tre kondiĉa. Estas pluraj eblecoj. La unua estas, ke la programo de generado de horaro funkciis kaj ŝanĝis la horaron. La modifita horaro estas alŝutita al Contentful. Post tio la backend komprenas, ke estas ŝanĝoj por ĉi tiu konferenco en Contentful, prenas ĝin kaj rekonstruas ĝin. Ĉio estas kolektita kaj sendita per websocket.
La dua ebleco, kiam ĉio okazas rapide: la redaktoro mane ŝanĝas la informojn en Contentful (ligilo al Telegramo, prezento de parolanto, ktp.) kaj la sama logiko funkcias kiel la unua fojo.
Nikolay: Ĉio okazas sen refreŝigado de la paĝo. Ĉiuj ŝanĝoj okazas absolute perfekte por la kliento. La sama validas por ŝanĝi raportojn. Kiam la tempo venas, la raporto kaj interfaco ŝanĝiĝas.
Vladimiro: Ankaŭ, estas tempolimoj por la komenco de raportoj en la templinio. Ĉe la komenco estas nenio. Kaj se vi ŝvebas vian muson super la ruĝa strio, tiam iam, dank' al la elsendodirektoro, aperos tranĉoj. La direktoro fiksas la ĝustan komencon de la elsendo, la malantaŭo prenas ĉi tiun ŝanĝon, kalkulas la komencon kaj fintempojn de la prezentoj de la tuta aŭtoveturejo konforme al la konferenca horaro, sendas ĝin al niaj klientoj, kaj la ludanto desegnas tranĉojn. Nun la uzanto povas facile navigi al la komenco kaj fino de la raporto. Ĝi estis strikta komerca postulo, tre oportuna kaj utila. Vi ne malŝparas tempon por trovi la realan komencan tempon por la raporto. Kaj kiam ni faros antaŭprezenton, ĝi estos absolute mirinda.
Deplojo
— Mi ŝatus demandi pri deplojo. Kolya kaj la teamo pasigis multe da tempo komence por starigi la tutan infrastrukturon, en kiu ĉio disvolviĝas por ni. Diru al mi, el kio ĉio estas farita?
Nikolay: De teknika vidpunkto, ni komence havis postulon, ke la produkto estu kiel eble plej abstrakta de iu ajn vendisto. Venu al AWS por fari Terraform-skriptojn specife de AWS, aŭ specife de Yandex, aŭ de Azure, ktp. ne vere taŭgis. Ni devis moviĝi ien iam.
Dum la unuaj tri semajnoj ni konstante serĉis manieron fari tion pli bone. Kiel rezulto, ni alvenis al la konkludo, ke Kubernetes ĉi-kaze estas nia ĉio, ĉar ĝi permesas al ni krei aŭtomate-skalajn servojn, aŭtomatan lanĉon kaj akiri preskaŭ ĉiujn servojn el la skatolo. Kompreneble, ĉiuj servoj devis esti trejnitaj por labori kun Kubernetes, Docker, kaj la teamo ankaŭ devis lerni.
Ni havas du aretojn. Testo kaj produktado. Ili estas absolute identaj laŭ aparataro kaj agordoj. Ni efektivigas infrastrukturon kiel kodon. Ĉiuj servoj aŭtomate estas lanĉitaj en tri mediojn de ĉefbranĉoj, majstraj branĉoj, testaj branĉoj kaj GitLab uzante aŭtomatan dukton. Ĉi tio estas maksimume integrita en GitLab, maksimume integrita kun Elastic, Prometheus.
Ni havas la ŝancon rapide (por la backend ene de 10 minutoj, por la fasado ene de 5 minutoj) efektivigi ŝanĝojn al iu ajn medio kun ĉiuj testoj, integriĝoj, funkciado de funkciaj testoj, integrigaj testoj en la medio, kaj ankaŭ testi kun ŝarĝaj testoj. prova medio proksimume la sama afero, kiun ni volas akiri en produktado.
Pri provoj
— Vi provas preskaŭ ĉion, estas malfacile kredi, kiel vi skribis ĉion. Ĉu vi povas rakonti al ni pri la backend-testoj: kiom ĉio estas kovrita, kiaj testoj?
Vladimiro: Du specoj de testoj estis skribitaj. La unuaj estas komponaj testoj. Levu niveltestojn de la tuta printempa aplikaĵo kaj bazu en . Ĉi tio estas testo de la plej altnivelaj komercaj scenaroj. Mi ne testas funkciojn. Ni nur provas kelkajn grandajn aferojn. Ekzemple, ĝuste en la testo, la procezo de ensaluto al uzanto estas kopiita, la peto de la uzanto por biletoj al kie li povas iri, kaj peto por aliro por spekti la rivereton. Tre klaraj uzantaj scenaroj.
Proksimume la sama afero estas efektivigita en la tiel nomataj integrigaj testoj, kiuj efektive funkcias sur la medio. Fakte, kiam la sekva deplojo en produktado estas lanĉita, realaj bazaj scenaroj ankaŭ funkcias en produktado. La sama ensaluto, petante biletojn, petante aliron al CloudFront, kontroli ke la rivereto vere konektas kun miaj permesoj, kontrolante la interfacon de la direktoro.
Nuntempe mi havas ĉirkaŭ 70 komponenttestojn kaj ĉirkaŭ 40 integriĝtestojn surŝipe. Kovrado estas tre proksima al 95%. Ĉi tio estas por komponantoj, malpli por integrigaj, simple ne tiom necesas. Konsiderante, ke la projekto implikas ĉiajn kodgeneradojn, ĉi tio estas tre bona indikilo. Ne estis alia maniero fari tion, kion ni faris en tri monatoj. Ĉar se ni provus permane, donante funkciojn al nia testilo, kaj ŝi trovus cimojn kaj resendus ilin al ni por korektoj, tiam ĉi tiu rondveturo por sencimigi la kodon estus tre longa, kaj ni ne plenumus iujn limdatojn.
Nikolay: Konvencie, por efektivigi regreson sur la tuta platformo kiam vi ŝanĝas iun funkcion, vi devas sidi kaj piki ĉie dum du tagoj.
Vladimiro: Sekve, estas granda sukceso, ke kiam mi taksas funkcion, mi diras, ke mi bezonas 4 tagojn por du simplaj plumoj kaj 1 retejo, Kolya permesas ĝin. Li jam kutimas, ke ĉi tiuj 4 tagoj inkluzivas 2 specojn de provoj, kaj tiam, plej verŝajne, ĝi funkcios.
Nikolay: Mi ankaŭ havas 140 testojn skribitajn: komponento + funkcia, kiuj faras la samon. Ĉiuj samaj scenaroj estas testitaj en produktado, en testo kaj en produktado. Ni ankaŭ lastatempe aldonis funkciajn bazajn UI-testojn. Tiel ni kovras la plej bazajn funkciojn, kiuj povas disiĝi.
Vladimiro: Kompreneble, indas paroli pri ŝarĝaj provoj. Necesis testi la platformon sub ŝarĝo proksima al la reala por kompreni kiel ĉio estas, kio okazas kun Rabbit, kio okazas kun la JVM-oj, kiom da memoro efektive necesas.
— Mi ne scias certe ĉu ni testas ion ajn ĉe la fluo, sed mi memoras, ke estis problemoj kun transkodiloj kiam ni faris renkontiĝojn. Ĉu ni provis la riveretojn?
Artjom: Provita ripete. Organizi renkontiĝojn. En la procezo de organizado de renkontiĝoj, ekzistis proksimume 2300 JIRA-biletoj. Ĉi tiuj estas nur ĝeneralaj aferoj, kiujn homoj faris por fari renkontiĝojn. Ni portis partojn de la platformo sur apartan paĝon por renkontiĝoj, kiun administris Kirill Tolkachev ().
Verdire, ne estis grandaj problemoj. Laŭvorte kelkfoje ni kaptis kaŝmemorajn cimojn ĉe CloudFront, ni solvis ĝin sufiĉe rapide - ni simple reagordis la politikojn. Estis signife pli da cimoj en homoj, en la fluaj sistemoj en la retejo.
Dum la konferencoj, mi devis skribi plurajn pliajn eksportantojn por kovri pli da ekipaĵoj kaj servoj. Kelkloke mi devis fari miajn proprajn biciklojn nur pro metriko. La mondo de AV (aŭdio-video) aparataro ne estas tre rozkolora - vi havas ian "API" de ekipaĵo, kiun vi simple ne povas influi. Kaj estas malproksime de fakto, ke vi povos akiri la informojn, kiujn vi bezonas. Aparataj vendistoj estas vere malrapidaj, kaj estas preskaŭ neeble akiri tion, kion vi volas de ili. Entute estas pli ol 100 pecoj da aparataro, ili ne redonas tion, kion vi bezonas, kaj vi skribas strangajn kaj superfluajn eksportantojn, dank' al kiuj vi povas almenaŭ iel elpurigi la sistemon.
Ekipaĵo
— Mi memoras, kiel antaŭ la komenco de la konferencoj ni parte aĉetis pliajn ekipaĵojn.
Artjom: Ni aĉetis komputilojn, tekkomputilojn kaj bateriojn. Nuntempe ni povas vivi sen elektro dum 40 minutoj. En junio estis severaj fulmotondroj en Peterburgo – do ni havis tian senkurentiĝon. Samtempe, pluraj provizantoj venas al ni kun optikaj ligiloj de malsamaj punktoj. Ĉi tio vere estas 40 minutoj da konstrua malfunkcio, dum kiuj ni havos lumojn ŝaltitajn, sonon, fotilojn, ktp.
— Ni havas similan historion kun Interreto. En la oficejo, kie troviĝas niaj studioj, ni trenis ferocan reton inter la etaĝojn.
Artjom: Ni havas 20 Gbit da fibro inter etaĝoj. Pli laŭ la etaĝoj, ie estas optiko, ie ne estas optiko, sed tamen estas malpli da kanaloj ol gigabit-oj - ni ruligas filmeton sur ili inter spuroj de la konferenco. Ĝenerale, estas tre oportune labori pri via propra infrastrukturo; vi malofte povas fari tion ĉe eksterretaj konferencoj en retejoj.
— Antaŭ ol mi laboris ĉe JUG Ru Group, mi vidis kiel aparataj ĉambroj ĉe eksterretaj konferencoj estis instalitaj dum la nokto, kie estis granda monitoro kun ĉiuj metrikoj kiujn vi konstruas en Grafana. Nun estas ankaŭ ĉefsidejo, en kiu sidas la evolua teamo, kiu dum la konferenco riparas kelkajn erarojn kaj disvolvas funkciojn. Samtempe, ekzistas monitora sistemo, kiu estas montrata sur granda ekrano. Artjom, Kolya kaj aliaj uloj sidas kaj certigas, ke ĉio ne falas kaj funkcias bele.
Kuriozaĵoj kaj problemoj
— Vi bone parolis pri la fakto, ke ni havas streaming kun Amazon, ekzistas ludanto kun la reto, ĉio estas skribita en malsamaj programlingvoj, mistoleremo kaj aliaj komercaj postuloj estas provizitaj, inkluzive de persona konto kiu estas subtenata por juraj personoj kaj individuoj, kaj ni povas integri kun iu uzante OAuth 2.0, ekzistas kontraŭ-fraŭdo, uzantblokado. Ni povas efektivigi ŝanĝojn dinamike ĉar ni faris ĝin bone, kaj ĉio estas provita.
Mi interesiĝas scii, kiaj strangaĵoj estis implikitaj en komenci ion. Ĉu okazis strangaj situacioj, kiam vi disvolvis backend, frontend, io freneza rezultis kaj vi ne komprenis kion fari kun ĝi?
Vladimiro: Ŝajnas al mi, ke tio okazis nur dum la lastaj tri monatoj. Ĉiutage. Kiel vi povas vidi, miaj ĉiuj haroj estas eltiritaj.
Vladimir Krasilshchik post 3 monatoj, kiam ia ludo rezultis kaj neniu komprenis kion fari kun ĝi
Ĉiutage estis io tia, kiam estis tia momento, kiam oni prenas ĝin kaj elŝiras viajn harojn, aŭ rimarkas, ke ekzistas neniu alia, kaj nur vi povas fari ĝin. Nia unua granda evento estis TechTrain. La 6-an de junio je la 2-a matene ni ankoraŭ ne lanĉis la produktan medion, Kolya estis ruliĝanta ĝin. Kaj la persona konto ne funkciis kiel rajtiga servilo uzante OAuth2.0. Ni transformis ĝin en OAuth2.0-provizanto por konekti la platformon al ĝi. Mi laboris verŝajne dum 18 horoj rekte, mi rigardis la komputilon kaj nenion vidis, mi ne komprenis kial ĝi ne funkcias, kaj Kolya rigardis mian kodon malproksime, serĉis cimon en la Spring-agordo. , trovis ĝin, kaj la LC funkciis, kaj ankaŭ en produktado.
Nikolay: Kaj unu horon antaŭ TechTrain la liberigo okazis.
Multaj steloj estis vicigitaj ĉi tie. Ni estis ege bonŝancaj ĉar ni havis bonegan teamon, kaj ĉiuj estis inspiritaj de la ideo fari ĝin interrete. Ĉiuj ĉi tiuj tri monatoj ni estis pelitaj de la fakto, ke ni "faris Jutubo". Mi ne permesis al mi elŝiri miajn harojn, sed diris al ĉiuj, ke ĉio funkcios, ĉar fakte, ĉio estis kalkulita antaŭ longe.
Pri agado
— Ĉu vi povas diri al mi kiom da homoj estis sur la retejo sur unu trako? Ĉu estis problemoj pri rendimento?
Nikolay: Ne estis problemoj de rendimento, kiel ni jam diris. La maksimuma nombro da homoj, kiuj ĉeestis unu raporton, estis 1300 homoj, ĉi tio estas ĉe Heisenbug.
— Ĉu estis problemoj kun loka spektado? Kaj ĉu eblas havi teknikan priskribon kun diagramoj pri kiel ĉio funkcias?
Nikolay: Ni faros artikolon pri tio poste.
Vi eĉ povas sencimigi fluojn loke. Post kiam la konferencoj komenciĝis, ĝi fariĝis eĉ pli facila, ĉar aperis produktadfluoj, kiujn ni povas spekti la tutan tempon.
Vladimiro: Kiel mi komprenas ĝin, antaŭfinaj programistoj laboris loke kun mokoj, kaj tiam, ĉar la tempo por ruliĝi al la devs en la fronto ankaŭ estas mallonga (5 minutoj), ne estas problemoj por kontroli kio okazas kun la atestiloj.
— Ĉio estas elprovita kaj sencimigita, eĉ loke. Ĉi tio signifas, ke ni skribos artikolon kun ĉiuj teknikaj trajtoj, montros al vi, rakontos al vi ĉion per diagramoj, kiel ĝi estis.
Vladimiro: Vi povas preni ĝin kaj ripeti ĝin.
- Post 3 monatoj.
La rezulto
— Ĉio priskribita kune sonas mojosa, konsiderante ke ĝi estis farita de malgranda teamo en tri monatoj.
Nikolay: Granda teamo ne farus ĉi tion. Sed grupeto de homoj, kiuj sufiĉe proksime kaj bone komunikas unu kun la alia kaj povas interkonsenti, povus. Ili ne havas kontraŭdirojn, la arkitekturo estis inventita en du tagoj, estis finpretigita kaj fakte ne ŝanĝiĝis. Estas tre strikta faciligo de envenantaj komercaj postuloj koncerne amasigado de funkcioj kaj ŝanĝoj.
— Kio estis en via listo de pliaj taskoj, kiam la someraj konferencoj jam okazis?
Nikolay: Ekzemple, kreditoj. Rampa linioj sur la video, pop-ups en iuj lokoj en la video depende de la enhavo montrita. Ekzemple, la parolanto volas demandi demandon al la spektantaro, kaj voĉdono aperas sur la ekrano, kiu iras reen al la malantaŭo surbaze de la voĉdonadrezultoj al la parolanto mem. Ia socia agado en formo de ŝatoj, koroj, taksoj de la raporto dum la prezento mem, por ke vi povu plenigi reagojn en la ĝusta momento sen esti distrita poste per reagoj formularoj. Komence tiel.
Kaj ankaŭ aldonante al la tuta platformo, krom streaming kaj konferenco, ankaŭ postkonferenca stato. Ĉi tiuj estas ludlistoj (inkluzive de tiuj kompilitaj de uzantoj), eble enhavo de aliaj pasintaj konferencoj, integritaj, etikeditaj, alireblaj por la uzanto, kaj ankaŭ disponeblaj por rigardado en nia retejo ().
— Knaboj, koran dankon pro viaj respondoj!
Se inter la legantoj estas tiuj, kiuj ĉeestis niajn somerajn konferencojn, bonvolu konigi viajn impresojn pri la ludanto kaj elsendo. Kio estis oportuna, kio incitis vin, kion vi ŝatus vidi estonte?
Se vi interesiĝas pri la platformo kaj volas vidi ĝin "en batalo", ni denove uzas ĝin ĉe nia . Estas tuta gamo da ili, do preskaŭ certe ekzistas unu, kiu taŭgas por vi.
fonto: www.habr.com