Myndbandssamskipti eru aðal samskiptaleiðin milli kennara og nemanda á Vimbox pallinum. Við hættum Skype fyrir löngu, prófuðum nokkrar þriðju aðila lausnir og sættum okkur á endanum við WebRTC - Janus-gátt samsetninguna. Í nokkurn tíma vorum við ánægð með allt, en samt héldu nokkrar neikvæðar hliðar áfram að koma fram. Fyrir vikið var búið til sérstaka myndbandsstefnu.
Ég bað Kirill Rogovoy, yfirmann nýju stefnunnar, að tala um þróun myndbandssamskipta hjá Skyeng, vandamálin sem fundust, lausnir og hækjur sem við notuðum að lokum. Við vonum að greinin nýtist fyrirtækjum sem búa líka til myndbönd á eigin spýtur í gegnum vefforrit.
Smá saga
Sumarið 2017 talaði yfirmaður Skyeng þróunar, Sergey Safonov, á Backend Conf með sögu um hvernig við „hættum við Skype og innleiddum WebRTC. Áhugasamir geta horft á upptöku af ræðunni kl (~45 mín), og hér mun ég gera stuttlega grein fyrir kjarna þess.
Fyrir Skyeng School hafa myndbandssamskipti alltaf verið forgangsleið í samskiptum kennara og nemenda. Í fyrstu var Skype notað, en það var ekki fullnægjandi af ýmsum ástæðum, fyrst og fremst vegna skorts á annálum og ómögulegt að sameina beint inn í vefforritið. Þess vegna gerðum við alls kyns tilraunir.
Reyndar voru kröfur okkar um myndbandssamskipti um það bil eftirfarandi:
— stöðugleiki;
— lágt verð á kennslustund;
— taka upp kennslustundir;
— fylgjast með hver talar hversu mikið (það er mikilvægt fyrir okkur að nemendur tali meira en kennarinn í kennslustundum);
— línuleg mælikvarði;
- getu til að nota bæði UDP og TCP.
Fyrstur til að reyna var að innleiða Tokbox árið 2013. Allt var gott, en það reyndist mjög dýrt - 113 rúblur á kennslustund - og át upp ágóðann.
Síðan árið 2015 var Voximplant samþætt. Hér var aðgerðin sem við þurftum til að fylgjast með hver talaði hversu mikið og á sama tíma var lausnin miklu ódýrari: ef aðeins hljóð var tekið upp kostaði það 20 rúblur á kennslustund. Hins vegar virkaði það aðeins í gegnum UDP og gat ekki skipt yfir í TCP. Hins vegar enduðu um 40% nemenda á því að nota það.
Ári síðar byrjuðum við að hafa fyrirtækjaviðskiptavini með sínar sérstakar kröfur. Til dæmis ætti allt að virka í gegnum vafra, fyrirtækið opnar aðeins http og https; e.a.s. ekkert Skype eða UDP. Fyrirtækjaviðskiptavinir = peningar, svo þeir sneru aftur til Tokbox, en verðvandamálið hvarf ekki.
Lausn - WebRTC og Janus
Ákveðið að nota . Það er ábyrgt fyrir að koma á tengingu, kóðun og afkóðun strauma, samstillingu brauta og gæðaeftirlit með meðhöndlun netgalla. Af okkar hálfu verðum við að tryggja að lesa strauma úr myndavélinni og hljóðnemanum, teikna myndband, stjórna tengingunni, koma á WebRTC tengingu og senda strauma á hana, auk þess að senda merkjaskilaboð milli viðskiptavina til að koma á tengingu (WebRTC sjálft lýsir aðeins gagnasnið, en ekki flutningskerfi þess). Ef viðskiptavinir eru á bak við NAT, tengir WebRTC STUN netþjóna; ef þetta hjálpar ekki, TURN netþjóna.
Venjulegt p2p samband er ekki nóg fyrir okkur, því við viljum taka upp kennslustundir til frekari greiningar ef kvartanir koma upp. Þess vegna sendum við WebRTC strauma í gegnum gengi . Þar af leiðandi vita viðskiptavinir ekki heimilisföng hvers annars, sjá aðeins Janus netfangið; það sinnir einnig aðgerðum merkjaþjóns. Janus hefur marga eiginleika sem við þurfum: skiptir sjálfkrafa yfir í TCP ef viðskiptavinurinn er með UDP læst; getur tekið upp bæði UDP og TCP strauma; stigstærð; Það er meira að segja innbyggt viðbót fyrir bergmálspróf. Ef nauðsyn krefur eru STUN og TURN netþjónar frá Twilio sjálfkrafa tengdir.
Sumarið 2017 vorum við með tvo Janus netþjóna í gangi, auk viðbótarþjóns til að vinna úr uppteknum hráum hljóð- og myndskrám, til að taka ekki upp örgjörva þeirra helstu. Við tengingu voru Janus netþjónar valdir á jöfnum grunni (tengingarnúmer). Á þeim tíma var þetta nóg, samkvæmt tilfinningum okkar gaf það um það bil fjórfalt öryggisbil, útfærsluprósentan var um 80. Á sama tíma var verðið lækkað í ~2 rúblur á kennslustund, auk þróunar og stuðnings.
Vend aftur að efni myndbandssamskipta
Við fylgjumst stöðugt með endurgjöf nemenda og kennara til að greina og leiðrétta vandamál tímanlega. Sumarið 2018 voru gæði símtala í fyrsta sæti meðal kvartana. Annars vegar þýddi þetta að okkur hefði tekist að sigrast á öðrum göllum. Á hinn bóginn var nauðsynlegt að gera eitthvað brýnt: Ef kennslustundin truflast eigum við á hættu að missa verðmæti hennar, stundum samhliða kostnaði við kaup á næsta pakka, og ef kynningarkennslunni truflast eigum við á hættu að missa hugsanlegan viðskiptavin. með öllu.
Á þeim tíma voru myndbandssamskipti okkar enn í MVP ham. Einfaldlega sett, þeir settu það af stað, það virkaði, þeir stækkuðu það einu sinni, þeir skildu hvernig á að gera það - jæja, frábært. Ef það virkar, ekki laga það. Enginn fjallaði vísvitandi um gæði samskipta. Í ágúst varð ljóst að þetta gæti ekki haldið áfram og við settum af stað sérstaka stefnu til að komast að því hvað væri að hjá WebRTC og Janus.
Við inntakið fékk þessi leið: MVP lausn, engin mælikvarði, engin markmið, engin ferli til umbóta, á meðan 7% kennara kvarta yfir gæðum samskipta (það voru heldur engin gögn um nemendur).
Ný stefna er í gangi
Skipunin lítur einhvern veginn svona út:
- Deildarstjóri, sem jafnframt er aðalverktaki.
- QA hjálpar til við að prófa breytingar, leitar að nýjum leiðum til að skapa óstöðugar samskiptaaðstæður og tilkynnir um vandamál frá fremstu víglínu.
- Sérfræðingur leitar stöðugt að ýmsum fylgni í tæknigögnum, bætir greiningu á endurgjöf notenda og athugar niðurstöður tilrauna.
- Vörustjórinn aðstoðar við heildarstefnu og úthlutun fjármagns til tilrauna.
- Annar verktaki hjálpar oft við forritun og tengd verkefni.
Til að byrja með settum við upp tiltölulega áreiðanlega mælikvarða sem rakti breytingar á samskiptagæðamati (meðaltali yfir daga, vikur, mánuði). Á þessum tíma voru þetta einkunnir frá kennurum, síðar bættust einkunnir nemenda við. Síðan fóru þeir að byggja upp tilgátur um hvað virkaði rangt, leiðrétta það og skoða breytingar á gangverki. Við fórum að lágt hangandi ávöxtum: til dæmis skiptum við vp8 merkjamálinu út fyrir vp9, afköstin batnaði. Við reyndum að leika okkur með Janus stillingarnar og gera aðrar tilraunir - í flestum tilfellum leiddu þær ekki til neins.
Á öðru stigi kom fram tilgáta: WebRTC er jafningjalausn og við notum miðlara í miðjunni. Kannski liggur vandamálið hér? Við byrjuðum að grafa og fundum mikilvægustu framförina hingað til.
Á því augnabliki var netþjónn úr sundlauginni valinn með því að nota frekar heimskulegt reiknirit: hver hafði sína „þyngd“, allt eftir rás og krafti, og við reyndum að senda notandann á þann sem hefur mest „þyngd“ án að fylgjast með hvar notandinn var landfræðilega staðsettur. Fyrir vikið gat kennari frá Sankti Pétursborg átt samskipti við nemanda frá Síberíu í gegnum Moskvu, en ekki í gegnum Janus netþjóninn okkar í Sankti Pétursborg.
Reikniritið hefur verið endurgert: núna, þegar notandi opnar pallinn okkar, söfnum við pingum frá honum á alla netþjóna sem nota Ajax. Þegar tenging er stofnuð veljum við par af pingum (kennara-þjónn og nemandi-þjónn) með minnstu upphæðinni. Minni ping þýðir minni netfjarlægð til netþjónsins; styttri fjarlægð þýðir minni líkur á að pakka tapist; Pakkatap er stærsti neikvæði þátturinn í myndbandssamskiptum. Hlutur neikvæðni minnkaði um helming á þremur mánuðum (til að vera sanngjarnt voru aðrar tilraunir gerðar á þessum tíma, en þessi hafði næstum örugglega mest áhrif).
Við uppgötvuðum nýlega annað sem ekki er augljóst, en virðist mikilvægt: í stað eins öflugs Janus netþjóns á þykkri rás er betra að hafa tvo einfaldari með þynnri bandbreidd. Þetta kom í ljós eftir að við keyptum öflugar vélar í von um að troða sem flestum herbergjum (samskiptalotum) inn í þær á sama tíma. Netþjónar hafa bandbreiddartakmörk, sem við getum þýtt nákvæmlega yfir í fjölda herbergja - við vitum hversu mörg er hægt að opna, til dæmis á 300 Mbit/s. Um leið og of mörg herbergi eru opin á netþjóni hættum við að velja hann fyrir nýja starfsemi þar til álagið minnkar. Hugmyndin var sú að eftir að hafa keypt öfluga vél myndum við hlaða rásinni í hana að hámarki, þannig að á endanum yrði hún takmörkuð af örgjörva og minni, en ekki af bandbreidd. En það kom í ljós að eftir ákveðinn fjölda opinna herbergja (420), þrátt fyrir að álag á örgjörva, minni og disk sé enn mjög langt frá takmörkunum, byrjar neikvæðni að berast tæknilega aðstoð. Það er greinilega eitthvað að versna innra með Janusi, kannski eru einhverjar takmarkanir þar líka. Við byrjuðum að gera tilraunir, lækkuðum bandbreiddarmörkin úr 300 í 200 Mbit/s og vandamálin hurfu. Nú keyptum við þrjá nýja netþjóna í einu með lágum mörkum og eiginleikum, við teljum að þetta muni leiða til stöðugrar framförar á gæðum samskipta. Auðvitað reyndum við ekki að átta okkur á hvað var að gerast þarna; hækjur okkar eru allt. Í vörn okkar skulum við segja að á þeirri stundu hafi verið nauðsynlegt að leysa brýnt vandamál eins fljótt og auðið var, en ekki að gera það fallega; að auki er Janus fyrir okkur svartur kassi skrifaður í C, það er mjög dýrt að fikta í honum.
Jæja, í því ferli:
- uppfærði allar ósjálfstæðir sem hægt var að uppfæra, bæði á þjóninum og á biðlaranum (þetta voru líka tilraunir, við fylgdumst með niðurstöðunum);
- lagað allar auðkenndar villur sem tengjast sérstökum tilvikum, til dæmis þegar tengingin rofnaði og var ekki endurheimt sjálfkrafa;
- Við héldum marga fundi með fyrirtækjum sem starfa á sviði myndbandssamskipta og þekkja vandamálin okkar: streyma leikjum, skipuleggja vefnámskeið; við reyndum allt sem okkur þótti gagnlegt;
- Gerði tæknilega úttekt á vélbúnaði og samskiptagæðum kennara, sem flestar kvartanir komu frá.
Tilraunirnar og breytingarnar í kjölfarið gerðu það að verkum að hægt var að draga úr óánægju með samskipti kennara úr 7,1% í janúar 2018 í 2,5% í janúar 2019.
Hvað er næst
Að koma á stöðugleika á Vimbox vettvanginn okkar er eitt af helstu verkefnum fyrirtækisins fyrir árið 2019. Við bindum miklar vonir við að við náum að halda skriðþunganum og sjáum ekki lengur myndbandssamskipti í efstu kvörtunum. Okkur skilst að verulegur hluti þessara kvartana tengist töfum í tölvum notenda og interneti, en við verðum að ákveða þennan hluta og leysa afganginn. Allt annað er tæknilegt vandamál, það virðist sem við ættum að geta tekist á við það.
Helsti erfiðleikinn er sá að við vitum ekki að hvaða marki það er í raun hægt að bæta gæði. Að finna út þetta þak er aðalverkefnið. Þess vegna voru tvær tilraunir fyrirhugaðar:
- bera saman myndband í gegnum Janus við venjulegan p2p í bardagaaðstæðum. Þessi tilraun hefur þegar verið framkvæmd, enginn tölfræðilega marktækur munur fannst á lausn okkar og p2p;
- Útvegum (dýra) þjónustu frá fyrirtækjum sem græða eingöngu á myndsamskiptalausnum og berum saman magn neikvæðni frá þeim við þá sem fyrir eru.
Þessar tvær tilraunir munu gera okkur kleift að bera kennsl á markmið sem hægt er að ná og einbeita okkur að því.
Að auki eru nokkur verkefni sem hægt er að leysa reglulega:
- Við búum til tæknilega mælikvarða um gæði samskipta í stað huglægra dóma;
- Við gerum ítarlegri lotuskrár til að greina nákvæmari bilanir sem eiga sér stað, skilja hvenær og hvar nákvæmlega þær áttu sér stað og hvaða atburðir að því er virðist óskyldir áttu sér stað á því augnabliki;
- Við undirbúum sjálfvirkt tengingargæðapróf fyrir kennslustundina og gefum viðskiptavininum einnig tækifæri til að prófa tenginguna handvirkt til að draga úr neikvæðni af völdum vélbúnaðar hans og rásar;
- við munum þróa og framkvæma fleiri álagsprófanir á myndbandssamskiptum við slæmar aðstæður, með breytilegu pakkatapi o.s.frv.;
- við breytum hegðun netþjóna ef upp koma vandamál til að auka bilanaþol;
- Við munum vara notandann við ef eitthvað er athugavert við tenginguna hans, eins og Skype gerir, svo að hann skilji að vandamálið sé hans megin.
Síðan í apríl hefur myndbandssamskiptastefnan orðið að fullu aðskildu verkefni innan Skyeng, sem fjallar um sína eigin vöru, ekki bara hluta af Vimbox. Þetta þýðir að við erum farin að leita að fólki á . Jæja, eins og alltaf .
Og auðvitað höldum við áfram að hafa virkan samskipti við fólk og fyrirtæki sem vinna með myndbandssamskipti. Ef þú vilt skiptast á reynslu við okkur munum við vera ánægð! Athugaðu, hafðu samband - við svörum öllum.
Heimild: www.habr.com