Tänä keväänä olimme erittäin iloisissa olosuhteissa. Pandemian vuoksi kävi selväksi, että kesäkonferenssimme oli siirrettävä verkkoon. Ja jotta ne voitaisiin tehdä verkossa tehokkaasti, valmiit ohjelmistoratkaisut eivät sopineet meille, vaan meidän piti kirjoittaa omat. Ja meillä oli kolme kuukautta aikaa tehdä tämä.
On selvää, että kolme kuukautta on ollut jännittäviä. Mutta ulkopuolelta se ei ole täysin selvää: mikä on online-konferenssialusta? Mistä osista se koostuu? Siksi viimeisessä kesän DevOops-konferenssissa kysyin tästä tehtävästä vastaavilta:
- Nikolay Molchanov - JUG Ru Groupin tekninen johtaja;
- Vladimir Krasilshchik on pragmaattinen Java-ohjelmoija, joka työskentelee taustalla (voit nähdä hänen raporttejaan myös Java-konferensseissamme);
- Artjom Nikonov vastaa kaikesta videon suoratoistosta.
Muuten, syksy-talvikonferensseissa käytämme samasta alustasta parannettua versiota - niin monet habra-lukijat ovat edelleen sen käyttäjiä.
Yleiskuva
– Mikä oli joukkueen kokoonpano?
Nikolai Molchanov: Meillä on analyytikko, suunnittelija, testaaja, kolme etuosaa ja taustaosa. Ja tietysti T-muotoinen asiantuntija!
– Miltä prosessi ylipäätään näytti?
Nikolai: Maaliskuun puoliväliin asti meillä ei ollut mitään valmiina verkkokäyttöön. Ja 15. maaliskuuta koko verkkokaruselli alkoi pyöriä. Perustimme useita arkistoja, suunnittelimme, keskustelimme perusarkkitehtuurista ja teimme kaiken kolmessa kuukaudessa.
Tämä tietysti kävi läpi klassiset suunnitteluvaiheet, arkkitehtuuri, ominaisuuksien valinta, noiden ominaisuuksien äänestäminen, noiden ominaisuuksien politiikka, niiden suunnittelu, kehitys ja testaus. Tämän seurauksena 6. kesäkuuta otimme kaiken tuotantoon. . Kaikessa oli 90 päivää.
– Saimmeko aikaan sen, mihin olimme sitoutuneet?
Nikolai: Koska osallistumme nyt DevOops-konferenssiin verkossa, se tarkoittaa, että se toimi. Sitouduin henkilökohtaisesti pääasiaan: tuon asiakkaille työkalun, jolla he voivat tehdä verkkoneuvottelun.
Haaste oli tämä: anna meille työkalu, jolla voimme lähettää konferenssejamme lipunhaltijoille.
Kaikki suunnittelu jaettiin useisiin vaiheisiin, ja kaikki ominaisuudet (noin 30 maailmanlaajuista) jaettiin 4 luokkaan:
- jonka me varmasti teemme (emme voi elää ilman niitä),
- jonka teemme toiseksi,
- jota emme koskaan tee,
- ja mitä emme koskaan, koskaan tee.
Teimme kaikki ominaisuudet kahdesta ensimmäisestä kategoriasta.
— Tiedän, että yhteensä 600 JIRA-numeroa luotiin. Kolmessa kuukaudessa teit 13 mikropalvelua, ja epäilen, että niitä ei ole kirjoitettu vain Javalla. Käytit erilaisia tekniikoita, sinulla on kaksi Kubernetes-klusteria kolmella saatavuusvyöhykkeellä ja viisi RTMP-virtaa Amazonissa.
Tarkastellaan nyt jokaista järjestelmän osaa erikseen.
suoratoisto
— Aloitetaan siitä, kun meillä on jo videokuva ja se välitetään joihinkin palveluihin. Artyom, kerro meille kuinka tämä suoratoisto tapahtuu?
Artjom Nikonov: Yleinen kaaviomme näyttää tältä: kuva kamerasta -> valvomomme -> paikallinen RTMP-palvelin -> Amazon -> videosoitin. Lisätietoja Habressa kesäkuussa.
Yleisesti ottaen tähän on kaksi maailmanlaajuista tapaa: joko laitteistolla tai ohjelmistoratkaisuilla. Valitsimme ohjelmistoreitin, koska se on helpompaa etäkaiuttimien tapauksessa. Aina ei ole mahdollista tuoda laitteistoa kaiuttimeen toisessa maassa, mutta ohjelmiston toimittaminen kaiuttimeen näyttää helpommalta ja luotettavammalta.
Laitteiston näkökulmasta meillä on tietty määrä kameroita (studioissamme ja kaukokaiuttimissa), studiossa tietty määrä kaukosäätimiä, jotka joutuu joskus korjaamaan lähetyksen aikana suoraan pöydän alle.
Näistä laitteista tulevat signaalit tulevat tietokoneisiin sieppauskorteilla, tulo-/lähtökorteilla ja äänikorteilla. Siellä signaalit sekoitetaan ja kootaan asetteluiksi:
Esimerkki 4 kaiuttimen asettelusta
Esimerkki 4 kaiuttimen asettelusta
Lisäksi jatkuva lähetys toteutetaan kolmen tietokoneen avulla: on yksi pääkone ja pari vuorollaan toimivaa. Ensimmäinen tietokone kerää ensimmäisen raportin, toinen - tauon, ensimmäinen - seuraavan raportin, toinen - seuraavan tauon ja niin edelleen. Ja pääkone sekoittaa ensimmäisen ja toisen.
Tämä luo eräänlaisen kolmion, ja jos jokin näistä solmuista epäonnistuu, voimme nopeasti ja ilman laadun heikkenemistä jatkaa sisällön toimittamista asiakkaille. Meillä oli tällainen tilanne. Ensimmäisen konferenssiviikon aikana korjasimme yhden koneen, laitoimme sen päälle/pois. Ihmiset näyttävät olevan tyytyväisiä kestävyyteemme.
Seuraavaksi tietokoneiden streamit menevät paikalliselle palvelimelle, jolla on kaksi tehtävää: reitittää RTMP-virrat ja tallentaa varmuuskopiot. Meillä on siis useita tallennuspisteitä. Videovirrat lähetetään sitten järjestelmämme Amazon SaaS -palveluihin rakennettuun osaan. Käytämme ,S3,CloudFront.
Nikolai: Mitä siellä tapahtuu ennen kuin video saavuttaa yleisön? Sinun täytyy leikata se jotenkin, eikö?
Artyom: Pakkaamme videon omalta osaltamme ja lähetämme sen MediaLiveen. Tuomme siellä transkooderit markkinoille. Ne muuntaa videoita reaaliajassa useisiin resoluutioihin, jotta ihmiset voivat katsella niitä puhelimillaan, maan huonon Internetin kautta ja niin edelleen. Sitten nämä virrat leikataan , näin protokolla toimii . Lähetämme käyttöliittymään soittolistan, joka sisältää osoittimia näihin osiin.
– Käytämmekö 1080p-resoluutiota?
Artyom: Videomme leveys on sama kuin 1080p - 1920 pikseliä, ja korkeus on hieman pienempi, kuva on pitkänomainen - tähän on syitä.
Pelaaja
— Artyom kuvaili, kuinka video päätyy streameihin, kuinka se jaetaan eri soittolistoille eri näytön resoluutioille, leikataan paloiksi ja pääsee soittimeen. Kolya, kerro nyt millainen pelaaja tämä on, miten se kuluttaa streamia, miksi HLS?
Nikolai: Meillä on soitin, jota kaikki konferenssin katsojat voivat katsella.
Pohjimmiltaan tämä on kääre kirjaston ympärillä , johon monet muut pelaajat on kirjoitettu. Mutta tarvitsimme hyvin erityisiä toimintoja: kelataan taaksepäin ja merkitään paikka, jossa henkilö on, mitä raporttia hän parhaillaan katselee. Tarvitsimme myös omia ulkoasuja, kaikenlaisia logoja ja kaikkea muuta, mitä meille rakennettiin. Siksi päätimme kirjoittaa oman kirjastomme (kääre HLS:n päällä) ja upottaa sen sivustolle.
Tämä on juuritoiminto, joten se otettiin käyttöön melkein ensimmäisenä. Ja sitten kaikki sen ympärille kasvoi.
Itse asiassa valtuutuksen kautta pelaaja saa taustajärjestelmästä soittolistan, jossa on linkkejä ajan ja laadun kanssa korreloiviin paloihin, lataa tarvittavat kappaleet ja näyttää ne käyttäjälle suorittaen "taikaa" matkan varrella.
Esimerkki aikajanasta
— Soittimeen on sisäänrakennettu painike kaikkien raporttien aikajanan näyttämiseksi...
Nikolai: Kyllä, ratkaisimme välittömästi käyttäjän navigointiongelman. Päätimme huhtikuun puolivälissä, että emme lähetä jokaista konferenssiamme erillisellä verkkosivulla, vaan yhdistämme kaiken yhdelle. Jotta Full Pass -lippujen käyttäjät voivat vapaasti vaihtaa eri konferenssien välillä: sekä suoria lähetyksiä että menneiden konferenssien tallenteita.
Jotta käyttäjien olisi helpompi navigoida nykyisessä streamissa ja vaihtaa kappaleiden välillä, päätimme tehdä "Koko lähetys" -painikkeen ja vaakasuuntaiset raporttikortit raitojen ja raporttien välillä vaihtamista varten. Näppäimistön ohjaus löytyy.
– Onko tässä ollut teknisiä ongelmia?
Nikolai: Niissä oli vierityspalkki, johon oli merkitty eri raporttien lähtökohdat.
— Laitoitko lopulta nämä merkit vierityspalkkiin ennen kuin YouTube teki jotain vastaavaa?
Artyom: Heillä oli se silloin beta-vaiheessa. Näyttää siltä, että tämä on melko monimutkainen ominaisuus, koska he ovat testanneet sitä osittain käyttäjien kanssa viimeisen vuoden aikana. Ja nyt se on tullut myyntiin.
Nikolai: Mutta itse asiassa saimme sen myyntiin nopeammin. Rehellisesti sanottuna tämän yksinkertaisen ominaisuuden takana on valtava määrä taustaa, käyttöliittymää, laskelmia ja matematiikkaa soittimen sisällä.
Käyttöliittymä
— Selvitetään, miten tämä näyttämämme sisältö (puhekortti, kaiuttimet, verkkosivusto, aikataulu) pääsee käyttöliittymään?
Vladimir Krasilshchik: Meillä on useita sisäisiä IT-järjestelmiä. On järjestelmä, johon kaikki raportit ja kaikki puhujat syötetään. On olemassa prosessi, jossa puhuja osallistuu konferenssiin. Puhuja lähettää hakemuksen, järjestelmä kaappaa sen, sitten on tietty putkisto, jonka mukaan raportti luodaan.
Näin puhuja näkee putken
Tämä järjestelmä on meidän sisäinen kehitystyömme.
Seuraavaksi sinun on rakennettava aikataulu yksittäisistä raporteista. Kuten tiedätte, tämä on NP-kova ongelma, mutta me ratkaisemme sen jotenkin. Tätä varten käynnistämme toisen komponentin, joka luo aikataulun ja lataa sen kolmannen osapuolen pilvipalveluun Contentful. Siellä kaikki näyttää jo taulukolta, jossa on konferenssipäiviä, päivinä aikavälit ja välissä raportteja, taukoja tai sponsorointitoimintaa. Joten näkemämme sisältö sijaitsee kolmannen osapuolen palvelussa. Ja tehtävänä on välittää se sivustolle.
Vaikuttaa siltä, että sivusto on vain sivu, jossa on soitin, eikä tässä ole mitään monimutkaista. Paitsi että ei ole. Tämän sivun takana oleva taustaohjelma siirtyy Contentfuliin, hakee sieltä aikataulun, luo joitakin objekteja ja lähettää sen käyttöliittymään. Käyttämällä websocket-yhteyttä, jonka jokainen alustamme asiakas tekee, lähetämme hänelle päivityksen aikatauluun taustasta käyttöliittymään.
Todellinen tapaus: puhuja vaihtoi työpaikkaa heti konferenssin aikana. Meidän on vaihdettava hänen työnantajayhtiönsä tunnus. Miten tämä tapahtuu taustapuolelta? Päivitys lähetetään kaikille asiakkaille websocketin kautta, ja sitten käyttöliittymä itse piirtää aikajanan uudelleen. Kaikki tämä tapahtuu saumattomasti. Pilvipalvelun ja useiden komponenttiemme yhdistelmä antaa meille mahdollisuuden tuottaa kaiken tämän sisällön ja toimittaa sen eteenpäin.
Nikolai: Tässä on tärkeää selventää, että sivustomme ei ole klassinen SPA-sovellus. Tämä on sekä ulkoasupohjainen, renderöity verkkosivusto että SPA. Google itse asiassa näkee tämän sivuston renderoituna HTML-muodossa. Tämä on hyvä hakukoneoptimoinnissa ja sisällön toimittamisessa käyttäjälle. Se ei odota 1,5 megatavun JavaScriptin latautumista ennen kuin näkee sivun, se näkee heti jo hahmonnetun sivun, ja tunnet sen aina, kun vaihdat raporttia. Kaikki tapahtuu puolessa sekunnissa, koska sisältö on jo valmis ja lähetetty oikeaan paikkaan.
— Vedetään viiva kaikkien edellä mainittujen alle listaamalla tekniikat. Tyoma sanoi, että meillä on 5 Amazon-streamia, ja toimitamme sinne videota ja ääntä. Meillä on siellä bash-skriptejä, käytämme niitä käynnistämään ja määrittämään...
Artyom: Tämä tapahtuu AWS API:n kautta, siellä on paljon enemmän teknisiä sivupalveluita. Jaoimme vastuumme niin, että toimitan , ja käyttöliittymä- ja taustakehittäjät ottavat sen sieltä. Meillä on useita omia sidoksia sisällön asettelun yksinkertaistamiseksi, minkä jälkeen teemme 4K-muodossa jne. Koska määräajat olivat erittäin tiukat, teimme sen lähes kokonaan AWS:llä.
— Sitten kaikki tämä menee soittimeen taustajärjestelmän avulla. Meillä on TypeScript, React, Next.JS soittimessamme. Ja taustalla meillä on useita palveluita C#-, Java-, Spring Boot- ja Node.js-kielillä. Tämä kaikki otetaan käyttöön Kubernetesin avulla Yandex.Cloud-infrastruktuurin avulla.
Haluan myös huomauttaa, että kun minun piti tutustua alustaan, se osoittautui helpoksi: kaikki arkistot ovat GitLabissa, kaikki on hyvin nimetty, testit on kirjoitettu, dokumentaatio on olemassa. Eli jopa hätätilassa he huolehtivat sellaisista asioista.
Liiketoiminnan rajoitukset ja analytiikka
— Kohdistimme 10 000 käyttäjää liiketoiminnan vaatimusten perusteella. On aika puhua bisneksen rajoituksista, joita meillä oli. Meidän piti varmistaa korkea työmäärä, varmistaa henkilötietojen säilyttämistä koskevan lain noudattaminen. Ja mitä muuta?
Nikolai: Aluksi aloitimme videovaatimuksista. Tärkeintä on hajautettu videotallennus ympäri maailmaa nopeaa toimitusta varten asiakkaalle. Toisiin kuuluu 1080p-resoluutio sekä kelaus taaksepäin, joita monet muut eivät toteuta live-tilassa. Myöhemmin lisäsimme mahdollisuuden ottaa käyttöön 2x nopeus, jonka avulla voit "kiinni" livenä ja jatkaa konferenssin seuraamista reaaliajassa. Ja matkan varrella ilmestyi aikajanan merkintätoiminto. Lisäksi meidän oli oltava vikasietoisia ja kestettävä 10 000 yhteyden kuormitus. Taustajärjestelmän näkökulmasta tämä on noin 10 000 yhteyttä kerrottuna 8 pyynnöstä jokaista sivun päivitystä kohden. Ja tämä on jo 80 000 RPS/s. Aika vähän.
— Oliko "virtuaalinäyttelylle" muita vaatimuksia kumppaneiden online-osastoilla?
Nikolai: Kyllä, tämä piti tehdä melko nopeasti ja yleismaailmallisesti. Meillä oli jokaiseen konferenssiin jopa 10 kumppaniyritystä, ja ne kaikki piti saada valmiiksi viikossa tai kahdessa. Niiden sisältö eroaa kuitenkin hieman muodoltaan. Mutta tehtiin tietty mallimoottori, joka kokoaa nämä sivut lennossa, käytännössä ilman jatkokehitykseen osallistumista.
— Vaatimuksia oli myös reaaliaikaisten näkymien ja tilastojen analysoinnille. Tiedän, että käytämme Prometheusta tähän, mutta kerro meille tarkemmin: mitä vaatimuksia täytämme analytiikan suhteen ja miten se toteutetaan?
Nikolai: Aluksi meillä on markkinointivaatimuksia kerätä A/B-testausta varten ja kerätä tietoa, jotta ymmärrämme, kuinka asiakkaalle voidaan jatkossa toimittaa oikein parasta sisältöä. Vaatimuksia on myös joillekin kumppanitoiminnan analyyseille ja näkemällesi analytiikalle (käyntilaskuri). Kaikki tiedot kerätään reaaliajassa.
Voimme toimittaa nämä tiedot koostetussa muodossa jopa puhujille: kuinka monta ihmistä katsoi sinua tiettynä ajankohtana. Samaan aikaan liittovaltion lain 152 noudattamiseksi henkilökohtaista tiliäsi ja henkilötietojasi ei seurata millään tavalla.
Alustalla on jo markkinointityökaluja ja mittarimme käyttäjien aktiivisuuden mittaamiseen reaaliajassa (kuka katsoi minkä sekunnin raportista) kaavioiden rakentamiseksi raporttien osallistumisesta. Näiden tietojen perusteella tehdään tutkimusta, joka tekee seuraavista konferensseista parempia.
Petos
— Onko meillä petostentorjuntamekanismeja?
Nikolai: Liiketoiminnallisesti tiukan aikataulun vuoksi tehtävää ei alunperin asetettu estämään turhat yhteydet välittömästi. Jos kaksi käyttäjää kirjautui sisään samalla tilillä, he voivat tarkastella sisältöä. Mutta tiedämme kuinka monta samanaikaista näyttökertaa oli yhdeltä tililtä. Ja kielsimme useita erityisen ilkeitä rikkojia.
Vladimir: Sen kunniaksi yksi kielletyistä käyttäjistä ymmärsi miksi näin tapahtui. Hän tuli, pyysi anteeksi ja lupasi ostaa lipun.
— Jotta kaikki tämä tapahtuisi, sinun on jäljitettävä kaikki käyttäjät täysin tulosta poistumiseen ja tiedettävä aina, mitä he tekevät. Miten tämä järjestelmä toimii?
Vladimir: Haluaisin puhua analytiikasta ja tilastoista, joita sitten analysoimme raportin onnistumisen kannalta tai voimme tarjota kumppaneille. Kaikki asiakkaat on liitetty websocket-yhteyden kautta tiettyyn taustaklusteriin. Se seisoo siellä . Jokainen asiakas lähettää kullakin ajanjaksolla, mitä hän tekee ja mitä raitaa hän katselee. Sitten nämä tiedot kootaan käyttämällä nopeita Hazelcast-töitä ja lähetetään takaisin kaikille, jotka katsovat näitä kappaleita. Näemme nurkassa kuinka monta ihmistä on nyt kanssamme.
Samat tiedot on tallennettu ja menee datajärveemme, josta meillä on mahdollisuus rakentaa kiinnostavampi kaavio. Herää kysymys: kuinka monta yksittäistä käyttäjää katseli tätä raporttia? Menemme , on kaikkien tämän raportin tunnuksen kautta saapuneiden ihmisten pingit. Keräsimme ja kokosimme ainutlaatuisia, ja nyt voimme ymmärtää.
Nikolai: Mutta samaan aikaan saamme myös reaaliaikaista dataa Prometheuksesta. Se on asetettu kaikkia Kubernetes-palveluita vastaan, itse Kubernetesia vastaan. Se kerää aivan kaiken, ja Grafanan avulla voimme rakentaa mitä tahansa kaavioita reaaliajassa.
Vladimir: Toisaalta lataamme tämän OLAP-käsittelyä varten. Ja OLTP:lle sovellus lataa kaiken Prometheukseen, Grafanaan ja kaaviot jopa lähentyvät!
- Tämä on tilanne, kun kuvaajat konvergoivat.
Dynaamiset muutokset
— Kerro meille, miten dynaamiset muutokset otetaan käyttöön: jos raportti peruttiin 6 minuuttia ennen alkua, mikä on toimenpideketju? Mikä putkisto toimii?
Vladimir: Putkilinja on hyvin ehdollinen. Mahdollisuuksia on useita. Ensimmäinen on, että aikataulun luontiohjelma toimi ja muutti aikataulua. Muokattu aikataulu ladataan Contentfuliin. Tämän jälkeen taustaohjelma ymmärtää, että Contentfulissa on muutoksia tähän konferenssiin, ottaa sen ja rakentaa sen uudelleen. Kaikki kerätään ja lähetetään websocketin kautta.
Toinen mahdollisuus, kun kaikki tapahtuu huimaa vauhtia: editori muuttaa manuaalisesti Contentfulin tietoja (linkki Telegramiin, puhujan esitys jne.) ja sama logiikka toimii kuin ensimmäisellä kerralla.
Nikolai: Kaikki tapahtuu ilman sivun päivittämistä. Kaikki muutokset tapahtuvat asiakkaan kannalta täysin saumattomasti. Sama koskee raporttien vaihtamista. Kun aika koittaa, raportti ja käyttöliittymä muuttuvat.
Vladimir: Myös aikajanalla on aikakatkoja raporttien alkamiselle. Alussa ei ole mitään. Ja jos viet hiiren punaisen raidan päälle, jossain vaiheessa lähetyksen ohjaajan ansiosta katkaisuja tulee näkyviin. Ohjaaja asettaa lähetyksen oikean alun, backend poimii tämän muutoksen, laskee koko kappaleen esitysten alkamis- ja päättymisajat konferenssiaikataulun mukaisesti, lähettää sen asiakkaillemme ja pelaaja arvostaa cutoffit. Nyt käyttäjä voi helposti navigoida raportin alkuun ja loppuun. Se oli tiukka liiketoiminnan vaatimus, erittäin kätevä ja hyödyllinen. Et tuhlaa aikaa raportin todellisen alkamisajan etsimiseen. Ja kun teemme esikatselun, se on aivan upea.
Käyttöönotto
– Haluaisin kysyä käyttöönotosta. Kolya ja tiimi käyttivät alussa paljon aikaa koko infrastruktuurin rakentamiseen, jossa kaikki tapahtuu meille. Kerro minulle, mistä se kaikki on tehty?
Nikolai: Tekniseltä kannalta katsottuna meillä oli alun perin vaatimus, että tuotteen oli oltava mahdollisimman abstrakti mistä tahansa myyjästä. Tule AWS:ään tekemään Terraform-skriptejä erityisesti AWS:stä tai erityisesti Yandexistä tai Azuresta jne. ei oikein sopinut. Meidän piti muuttaa jossain vaiheessa jonnekin.
Ensimmäiset kolme viikkoa etsimme jatkuvasti tapaa tehdä tämä paremmin. Tuloksena tulimme siihen tulokseen, että Kubernetes on tässä tapauksessa kaikkemme, koska sen avulla voimme luoda automaattisesti skaalautuvia palveluita, ottaa käyttöön automaattisen käyttöönoton ja saada lähes kaikki palvelut pois pakkauksesta. Luonnollisesti kaikki palvelut piti kouluttaa toimimaan Kubernetesin, Dockerin kanssa, ja myös tiimin piti oppia.
Meillä on kaksi klusteria. Testaus ja tuotanto. Ne ovat täysin identtisiä laitteiston ja asetusten suhteen. Toteutamme infrastruktuurin koodina. Kaikki palvelut levitetään automaattisesti kolmeen ympäristöön ominaisuushaaroista, päähaaroista, testihaaroista ja GitLabista automaattisen putkilinjan avulla. Tämä on integroitu maksimaalisesti GitLabiin, maksimaalisesti integroitu Elasticiin, Prometheukseen.
Saamme mahdollisuuden nopeasti (taustajärjestelmälle 10 minuutissa, käyttöliittymälle 5 minuutissa) ottaa käyttöön muutokset mihin tahansa ympäristöön kaikilla testeillä, integroinneilla, toimintatesteillä, ympäristön integrointitesteillä ja myös kuormitustesteillä. testiympäristö suunnilleen sama asia, jonka haluamme saada tuotantoon.
Tietoja testeistä
- Testaat melkein kaikkea, on vaikea uskoa, kuinka kirjoitit kaiken. Voitko kertoa taustatesteistä: kuinka paljon kaikkea on katettu, mitkä testit?
Vladimir: Kahdenlaisia testejä on kirjoitettu. Ensimmäiset ovat komponenttitestejä. Koko jousisovelluksen ja pohjan nostotason testit . Tämä on korkeimman tason liiketoimintaskenaarioiden testi. En testaa toimintoja. Testaamme vain joitain suuria asioita. Esimerkiksi heti testissä emuloidaan käyttäjälle kirjautumisprosessia, käyttäjän pyyntöä lippujen saamiseksi minne hän voi mennä ja pyyntöä päästä katsomaan suoratoistoa. Erittäin selkeät käyttäjäskenaariot.
Suunnilleen sama asia toteutetaan niin sanotuissa integraatiotesteissä, jotka itse asiassa ajetaan ympäristössä. Itse asiassa, kun seuraava tuotantokäyttöönotto otetaan käyttöön, myös todelliset perusskenaariot ovat käynnissä tuotannossa. Sama kirjautuminen, lippujen pyytäminen, pääsyn pyytäminen CloudFrontiin, tarkistaminen, että stream todella yhdistää käyttöoikeuksiani, tarkistaa ohjaajan käyttöliittymä.
Tällä hetkellä minulla on noin 70 komponenttitestiä ja noin 40 integrointitestiä. Kattavuus on hyvin lähellä 95 %. Tämä on tarkoitettu komponenteille, vähemmän integraatioille, sitä ei yksinkertaisesti tarvita niin paljon. Ottaen huomioon, että projekti sisältää kaikenlaista koodintuotantoa, tämä on erittäin hyvä indikaattori. Ei ollut muuta tapaa tehdä sitä mitä teimme kolmessa kuukaudessa. Koska jos testaamme manuaalisesti, antaen ominaisuuksia testaajallemme, ja hän löytäisi virheitä ja palauttaisi ne meille korjausta varten, niin tämä koodin virheenkorjausmatka olisi hyvin pitkä, emmekä noudattaisi mitään määräaikoja.
Nikolai: Perinteisesti, jotta voit suorittaa regression koko alustalla, kun muutat jotakin toimintoa, sinun on istuttava ja tönäistävä kaikkialla kaksi päivää.
Vladimir: Siksi on suuri menestys, että kun arvioin ominaisuutta, sanon, että tarvitsen 4 päivää kahdelle yksinkertaiselle kynälle ja 1 verkkopistorasialle, Kolya sallii sen. Hän on jo tottunut siihen, että nämä 4 päivää sisältävät 2 tyyppisiä testejä, ja sitten se todennäköisesti toimii.
Nikolai: Minulla on myös kirjoitettu 140 testiä: komponentti + toiminnallinen, jotka tekevät saman asian. Kaikki samat skenaariot testataan tuotannossa, testissä ja tuotannossa. Lisäsimme äskettäin myös toiminnallisia peruskäyttöliittymätestejä. Tällä tavalla katamme perustoiminnot, jotka voivat hajota.
Vladimir: Tietysti kannattaa puhua kuormitustesteistä. Alustaa piti testata kuormituksen alaisena lähellä todellista, jotta ymmärrettäisiin, miten kaikki on, mitä tapahtuu Rabbitille, mitä tapahtuu JVM: ille, kuinka paljon muistia todella tarvitaan.
– En tiedä varmasti testaammeko mitään streamin puolella, mutta muistan, että transkoodereissa oli ongelmia tapaamisten aikana. Olemmeko testanneet streameja?
Artyom: Testattu iteratiivisesti. Tapaamisten järjestäminen. Tapaamisten järjestämisen aikana JIRA-lippuja oli noin 2300 XNUMX kappaletta. Nämä ovat vain yleisiä asioita, joita ihmiset tekivät tapaamista varten. Otimme osa alustasta erilliselle tapaamissivulle, jota johti Kirill Tolkachev ().
Rehellisesti sanottuna ei ollut suuria ongelmia. Kirjaimellisesti pari kertaa havaitsimme välimuistivirheitä CloudFrontissa, ratkaisimme sen melko nopeasti - konfiguroimme käytännöt uudelleen. Ihmisissä, sivuston suoratoistojärjestelmissä, oli huomattavasti enemmän bugeja.
Konferenssien aikana minun piti kirjoittaa useita viejiä, jotta voisin kattaa enemmän laitteita ja palveluita. Joissain paikoissa jouduin tekemään omia polkupyöriä vain mittareiden vuoksi. AV (audio-video) -laitteiston maailma ei ole kovin ruusuinen - sinulla on jonkinlainen laitteiden "API", johon et yksinkertaisesti voi vaikuttaa. Ja se on kaukana tosiasiasta, että pystyt saamaan tarvitsemasi tiedot. Laitteistotoimittajat ovat todella hitaita, ja on lähes mahdotonta saada heiltä haluamaasi. Laitteita on yhteensä yli 100 kappaletta, ne eivät anna takaisin mitä tarvitset, ja kirjoitat outoja ja tarpeettomia viejiä, joiden ansiosta voit ainakin jotenkin korjata järjestelmän virheitä.
Оборудование
— Muistan, kuinka ennen konferenssien alkua ostimme osittain lisälaitteita.
Artyom: Ostimme tietokoneita, kannettavia tietokoneita ja akkuja. Tällä hetkellä voimme elää ilman sähköä 40 minuuttia. Kesäkuussa Pietarissa oli kovia ukkosmyrskyjä - joten meillä oli sellainen sähkökatkos. Samaan aikaan useat palveluntarjoajat tulevat meille optisilla linkeillä eri kohdista. Tämä on todellakin 40 minuuttia rakennuksen seisonta-aikaa, jonka aikana meillä on valot päällä, ääni, kamerat jne.
– Meillä on samanlainen tarina Internetin kanssa. Toimistossa, jossa studiomme sijaitsevat, vetimme rajua verkkoa kerrosten väliin.
Artyom: Meillä on 20 Gbit kuitua kerrosten välissä. Edelleen kerroksissa jossain on optiikkaa, jossain ei ole optiikkaa, mutta silti kanavia on vähemmän kuin gigabittisiä - näytämme niillä videota konferenssin raitojen välissä. Yleensä on erittäin kätevää työskennellä omalla infrastruktuurilla; voit harvoin tehdä tämän offline-konferensseissa sivustoilla.
— Ennen kuin työskentelin JUG Ru Groupissa, näin, kuinka offline-konferensseissa rakennettiin laitteistohuoneita yhdessä yössä, ja siellä oli suuri näyttö kaikilla Grafanassa rakentamillasi mittareilla. Nyt siellä on myös pääkonttorihuone, jossa istuu kehitystiimi, joka konferenssin aikana korjaa joitain bugeja ja kehittää ominaisuuksia. Samaan aikaan on olemassa valvontajärjestelmä, joka näytetään suurella näytöllä. Artjom, Kolya ja muut kaverit istuvat ja varmistavat, että kaikki ei putoa ja toimii kauniisti.
Uteliaisuutta ja ongelmia
— Puhuit hyvin siitä, että meillä on suoratoisto Amazonin kanssa, siellä on nettisoitin, kaikki on kirjoitettu eri ohjelmointikielillä, tarjotaan vikasietoisuus ja muut liiketoiminnan vaatimukset, mukaan lukien henkilökohtainen tili, jota tuetaan juridisille henkilöille ja yksilöitä, ja voimme integroida jonkun kanssa OAuth 2.0:aa käyttävän kanssa, on petostentorjunta, käyttäjien esto. Voimme toteuttaa muutoksia dynaamisesti, koska teimme sen hyvin, ja kaikki on testattu.
Minua kiinnostaa tietää, mitkä oudot asiat liittyivät jonkin alkuun. Onko ollut outoja tilanteita, kun kehitit taustaa, frontendia, jotain hullua on tapahtunut, etkä ymmärtänyt mitä tehdä sen kanssa?
Vladimir: Minusta näyttää siltä, että tätä on tapahtunut vasta viimeisen kolmen kuukauden aikana. Joka päivä. Kuten näette, kaikki hiukseni on revitty pois.
Vladimir Krasilshchik 3 kuukauden jälkeen, kun jonkinlainen peli osoittautui ja kukaan ei ymmärtänyt mitä tehdä sen kanssa
Joka päivä oli jotain tällaista, kun oli sellainen hetki, kun otat sen ja revit hiukset irti, tai tajuat, ettei ole ketään muuta, ja vain sinä voit tehdä sen. Ensimmäinen iso tapahtumamme oli TechTrain. Kesäkuun 6. päivänä klo 2:2.0 emme olleet vielä ottaneet tuotantoympäristöä käyttöön, Kolya otti sitä käyttöön. Ja henkilökohtainen tili ei toiminut valtuutuspalvelimena OAuth2.0:lla. Teimme siitä OAuth18-palveluntarjoajan yhdistääksemme alustan siihen. Olin työskennellyt luultavasti XNUMX tuntia putkeen, katsoin tietokonetta enkä nähnyt mitään, en ymmärtänyt miksi se ei toiminut, ja Kolya katsoi koodiani etänä, etsi vikaa Spring-kokoonpanosta. , löysi sen, ja LC toimi, ja myös tuotannossa .
Nikolai: Ja tuntia ennen TechTrainia julkaisu tapahtui.
Monet tähdet asettuivat tänne. Olimme erittäin onnekkaita, koska meillä oli supertiimi, ja kaikki inspiroituivat ajatuksesta tehdä se verkossa. Kaikki nämä kolme kuukautta ohjasivat meitä se tosiasia, että teimme YouTuben. En antanut itseni repiä hiuksiani irti, vaan sanoin kaikille, että kaikki järjestyy, koska itse asiassa kaikki oli laskettu kauan sitten.
Tietoja suorituskyvystä
– Voitko kertoa kuinka monta ihmistä oli sivustolla yhdellä kappaleella? Oliko suorituskykyongelmia?
Nikolai: Suorituskykyongelmia ei ollut, kuten jo sanoimme. Yhdelle raportille osallistui enintään 1300 henkilöä, tämä on Heisenbugissa.
– Oliko paikallisessa katselussa ongelmia? Ja onko mahdollista saada tekninen kuvaus kaavioineen kuinka se kaikki toimii?
Nikolai: Teemme tästä artikkelin myöhemmin.
Voit jopa korjata streameja paikallisesti. Kun konferenssit alkoivat, se helpotti entisestään, koska ilmestyi tuotantovirtoja, joita voimme seurata koko ajan.
Vladimir: Ymmärtääkseni käyttöliittymäkehittäjät työskentelivät paikallisesti pilkkujen avulla, ja koska myös aika julkaisun kehittäjille edessä on lyhyt (5 minuuttia), ei ole ongelmia tarkistaa, mitä varmenteiden kanssa tapahtuu.
— Kaikki testataan ja vianetsintään, jopa paikallisesti. Tämä tarkoittaa, että kirjoitamme artikkelin, jossa on kaikki tekniset ominaisuudet, näytämme sinulle, kerromme sinulle kaiken kaavioiden avulla, kuinka se oli.
Vladimir: Voit ottaa sen ja toistaa sen.
- 3 kuukaudessa.
Koko
— Kaikki kuvattu yhdessä kuulostaa siistiltä, kun ottaa huomioon, että pieni tiimi teki sen kolmessa kuukaudessa.
Nikolai: Suuri joukkue ei tekisi tätä. Mutta pieni joukko ihmisiä, jotka kommunikoivat melko läheisesti ja hyvin keskenään ja voivat päästä sopimukseen, voisivat. Niissä ei ole mitään ristiriitaa, arkkitehtuuri keksittiin kahdessa päivässä, valmistui eikä ole varsinaisesti muuttunut. Saapuvia liiketoimintavaatimuksia helpotetaan erittäin tiukasti ominaisuuspyyntöjen ja muutosten kasaamisen suhteen.
— Mitä oli jatkotehtävissäsi, kun kesäkonferenssit olivat jo pidetty?
Nikolai: Esimerkiksi krediittejä. Hiipiviä viivoja videossa, ponnahdusikkunoita joissain paikoissa videossa näytettävän sisällön mukaan. Esimerkiksi puhuja haluaa esittää kysymyksen yleisölle, ja ruudulle ilmestyy äänestys, joka palaa äänestystulosten perusteella takaisin puhujalle itselleen. Jonkinlainen sosiaalinen aktiviteetti tykkäysten, sydämien, raportin arvioiden muodossa itse esityksen aikana, jotta voit täyttää palautteen oikealla hetkellä ilman, että palautelomakkeet häiritsevät myöhemmin. Aluksi näin.
Ja myös lisäämällä koko alustalle suoratoistoa ja konferenssia lukuun ottamatta myös konferenssin jälkeinen tila. Nämä ovat soittolistoja (mukaan lukien käyttäjien kokoamat), mahdollisesti sisältöä muista menneistä konferensseista, integroituja, merkittyjä, käyttäjän saatavilla ja myös katseltavissa verkkosivuillamme ().
– Kaverit, kiitos paljon vastauksistanne!
Jos lukijoiden joukossa on kesäkonferensseihimme osallistuneita, kerro mielipiteistäsi pelaajasta ja lähetyksestä. Mikä oli kätevää, mikä ärsytti sinua, mitä haluaisit nähdä tulevaisuudessa?
Jos olet kiinnostunut alustasta ja haluat nähdä sen "taistelussa", käytämme sitä uudelleen . Niitä on laaja valikoima, joten niistä on lähes varmasti yksi, joka sopii sinulle.
Lähde: will.com