Kaixo! Nire izena Vadim Madison da, Avito System Plataformaren garapena zuzentzen dut. Behin baino gehiagotan esan da nola ari garen enpresan arkitektura monolitiko batetik mikrozerbitzuetara pasatzen. Gure azpiegitura nola eraldatu dugun partekatzeko garaia da mikrozerbitzuei etekinik handiena ateratzeko eta haietan gal ez gaitezen. PaaS-ek nola laguntzen digun hemen, nola inplementazioa sinplifikatu genuen eta mikrozerbitzu baten sorrera klik bakarrera murriztu genuen - irakurri. Jarraian idazten dudan guztia ez dago Aviton guztiz inplementatuta, horietako batzuk gure plataforma garatzen ditugunak dira.

(Eta artikulu honen amaieran, Chris Richardson mikrozerbitzuen arkitektura adituaren hiru eguneko mintegi batera joateko aukeraz hitz egingo dut).

Nola iritsi ginen mikrozerbitzuetara

Avito munduko sailkatutako gune handienetako bat da; egunean 15 milioi iragarki berri baino gehiago argitaratzen dira bertan. Gure backend-ak segundoko 20 mila eskaera baino gehiago onartzen ditu. Gaur egun ehunka mikrozerbitzu ditugu.

Hainbat urte daramatzagu mikrozerbitzuen arkitektura bat eraikitzen. Nola zehazki - gure lankideek xehetasunez kontatu RIT++ 2017ko gure atalean. CodeFest 2017-n (ikus. video), Sergey Orlovek eta Mikhail Prokopchuk-ek zehatz-mehatz azaldu zuten zergatik behar genuen mikrozerbitzuetarako trantsizioa eta zein rol jokatu zuen hemen Kubernetesek. Bada, orain dena egiten ari gara horrelako arkitektura batek berezko dituen eskalatze kostuak minimizatzeko.

Hasieran, ez genuen mikrozerbitzuak garatzen eta abiarazten lagunduko zigun ekosistemarik sortu. Kode irekiko irtenbide zentzuzkoak bildu, etxean jarri eta garatzailea gonbidatu zuten haiekin aurre egiteko. Ondorioz, dozena bat tokitara joan zen (agindu-panelak, barne-zerbitzuak), eta ondoren sendotu egin zen lehengo moduko kodea mozteko nahia, monolito batean. Beheko eskemetako kolore berdeak garatzaileak modu batean edo bestean bere eskuekin egiten duena adierazten du eta kolore horiak automatizazioa adierazten du.

Orain PaaS CLI erabilgarritasunean, zerbitzu berri bat sortzen da komando batekin, eta datu-base berri bat gehitzen da beste birekin eta Stage-n zabaltzen da.

Nola gainditu "mikrozerbitzuen zatiketaren" aroa

Arkitektura monolitiko batekin, produktuaren aldaketen koherentziaren mesedetan, garatzaileek beren bizilagunekin zer gertatzen zen asmatzera behartuta zeuden. Arkitektura berria lantzean, zerbitzu-testuinguruak jada ez dira elkarren menpekoak.

Gainera, mikrozerbitzuen arkitektura eraginkorra izan dadin, prozesu asko ezarri behar dira, hau da:

• erregistroa;
• eskatzeko trazadura (Jaeger);
• akatsen agregazioa (Sentry);
• Kubernetes-eko egoerak, mezuak, gertaerak (Event Stream Processing);
• lasterketa muga / etengailua (Hystrix erabil dezakezu);
• zerbitzu-konektibitatearen kontrola (Netramesh erabiltzen dugu);
• jarraipena (Grafana);
• muntaia (TeamCity);
• komunikazioa eta jakinarazpena (Slack, posta elektronikoa);
• zereginen jarraipena; (Jira)
• dokumentazioa prestatzea.

Sistemak osotasuna galtzen ez duela eta eskalatzen doan heinean eraginkorra izaten jarraitzen duela ziurtatzeko, Aviton mikrozerbitzuen antolaketa birplanteatu dugu.

Mikrozerbitzuak nola kudeatzen ditugun

Ondoko hauek Avito mikrozerbitzu askoren artean "alderdien politika" bateratua ezartzen laguntzen dute:

• azpiegiturak geruzatan banatzea;
• Platform as a Service (PaaS) kontzeptua;
• mikrozerbitzuekin gertatzen den guztia monitorizatzea.

Azpiegituren abstrakzio-geruzek hiru geruza dituzte. Goazen goitik behera.

A. Goiko - zerbitzu-sarea. Hasieran Istio probatu genuen, baina konturatu zen baliabide gehiegi erabiltzen dituela, eta hori garestiegia da gure bolumenetarako. Hori dela eta, Alexander Lukyanchenko arkitektura taldeko ingeniari seniorrak bere irtenbidea garatu zuen - Netramesh (Kode Irekian eskuragarri), gaur egun ekoizpenean erabiltzen duguna eta Istiok baino hainbat aldiz baliabide gutxiago kontsumitzen duena (baina ez du Istio harrotu daitekeen guztia egiten).
B. Ertaina - Kubernetes. Mikrozerbitzuak zabaltzen eta funtzionatzen ditugu bertan.
C. Behea - metal hutsa. Ez dugu hodeirik edo OpenStack bezalako gauzarik erabiltzen, baina guztiz metal hutsean oinarritzen gara.

Geruza guztiak PaaS bidez konbinatzen dira. Eta plataforma honek, berriz, hiru zati ditu.

I. Sorgailuak, CLI utilitate baten bidez kontrolatua. Bera da garatzaileari mikrozerbitzu bat modu egokian eta ahalegin minimo batekin sortzen laguntzen diona.

II. Kolektore finkatua tresna guztien kontrola panel komun baten bidez.

III. Biltegiratzea. Ekintza esanguratsuetarako abiarazleak automatikoki ezartzen dituzten programatzaileekin konektatzen da. Horrelako sistema bati esker, ez da zeregin bakar bat ere galduko norbait Jira-n zeregin bat konfiguratzea ahaztu delako. Atlas izeneko barne tresna erabiltzen dugu horretarako.

Avito-n mikrozerbitzuen ezarpena eskema bakar baten arabera egiten da, eta horrek sinplifikatzen du haien gaineko kontrola garatzeko eta kaleratzeko fase bakoitzean.

Nola funtzionatzen du mikrozerbitzuen garapen kanal estandarrak?

Oro har, mikrozerbitzuak sortzeko kateak itxura hau du:

CLI-push → Etengabeko integrazioa → Bake → Inplementatu → Proba artifizialak → Canary probak → Squeeze Testing → Produkzioa → Mantentzea.

Goazen zehatz-mehatz ordena honetan.

CLI-bultza

• Mikrozerbitzu bat sortzea.
Denbora luzez borrokatu genuen garatzaile guztiei mikrozerbitzuak nola egiten irakasteko. Honek Confluencen argibide zehatzak idaztea barne. Baina eskemak aldatu eta osatu egin ziren. Ondorioz, bidaiaren hasieran botila-lepo bat agertu zen: askoz denbora gehiago behar izan zen mikrozerbitzuak abiarazteko, eta oraindik ere arazoak sortzen ziren haiek sortzean.

Azkenean, mikrozerbitzu bat sortzean oinarrizko urratsak automatizatzen dituen CLI utilitate sinple bat eraiki dugu. Izan ere, lehen git push-a ordezkatzen du. Hona hemen zer egiten duen zehazki.

— Zerbitzu bat txantiloi baten arabera sortzen du — urratsez urrats, “morroi” moduan. Avito backend-en programazio-lengoaia nagusientzako txantiloiak ditugu: PHP, Golang eta Python.

- Komando batek aldi berean tokiko garapenerako ingurune bat zabaltzen du makina zehatz batean - Minikube abiarazten da, Helm diagramak automatikoki sortzen dira eta tokiko kubernetetan abiarazten dira.

— Beharrezko datu-basea konektatzen du. Garatzaileak ez du IP, saio-hasiera eta pasahitza jakin behar behar duen datu-basean sartzeko, izan lokalean, Stage-n edo ekoizpenean. Gainera, datu-basea berehala zabaltzen da akatsak jasan ditzakeen konfigurazio batean eta orekatuarekin.

— Zuzeneko muntaia bera egiten du. Demagun garatzaile batek mikrozerbitzu batean zerbait zuzendu duela bere IDEaren bidez. Utilitateak fitxategi-sisteman aldaketak ikusten ditu eta, horietan oinarrituta, aplikazioa berreraikitzen du (Golangentzat) eta berrabiarazi egiten du. PHPrako, kuboaren barruko direktorioa birbidaltzen dugu eta bertan zuzeneko birkarga "automatikoki" lortzen da.

— Autotestak sortzen ditu. Hutsunen moduan, baina erabiltzeko nahiko egokia.

• Mikrozerbitzuen hedapena.

Mikrozerbitzu bat zabaltzea lan pixka bat izaten zen guretzat. Honako hauek behar ziren:

I. Dockerfile.

II. Konfig.
III. Helm diagrama, astuna dena eta barne hartzen du:

— taulak berak;
- txantiloiak;
— balio zehatzak ingurune desberdinak kontuan hartuta.

Kubernetes-eko manifestuak birlantzeari minari kendu diogu, beraz, orain automatikoki sortzen dira. Baina garrantzitsuena, hedapena mugaraino erraztu zuten. Hemendik aurrera Dockerfile bat dugu, eta garatzaileak konfigurazio osoa idazten du app.toml fitxategi labur bakarrean.

Bai, eta app.toml-en bertan ez dago minutu batez ezer egiterik. Zerbitzuaren non eta zenbat kopia atera behar diren zehazten dugu (garapeneko zerbitzarian, eszenaratzean, ekoizpenean) eta bere menpekotasunak adierazten ditugu. Kontuan izan lerroaren tamaina = "txikia" [motorra] blokean. Hau da Kubernetes bidez zerbitzuari esleituko zaion muga.

Ondoren, konfigurazioan oinarrituta, beharrezko Helm grafiko guztiak automatikoki sortzen dira eta datu-baseetarako konexioak sortzen dira.

• Oinarrizko balioztatzea. Egiaztapen horiek automatizatuta daude.
Jarraitu behar da:
— Ba al dago Dockerfile bat;
— ba al dago app.toml;
— Ba al dago dokumentazioa eskuragarri?
— menpekotasuna ondo dago?
— alerta-arauak ezarri diren ala ez.
Azken punturaino: zerbitzuaren jabeak berak zehazten du zein produkturen neurketa kontrolatu.

• Dokumentazioa prestatzea.
Oraindik arazo-eremu bat. Agerikoena dirudi, baina, aldi berean, «askotan ahazten den» diskoa ere bada, eta, beraz, katearen kate zaurgarria.
Beharrezkoa da mikrozerbitzu bakoitzaren dokumentazioa egotea. Honako bloke hauek biltzen ditu.

I. Zerbitzuaren deskribapen laburra. Literalki esaldi batzuk zer egiten duen eta zergatik behar den.

II. Arkitektura diagrama esteka. Garrantzitsua da begirada bizkor batekin erraz ulertzea, adibidez, Redis erabiltzen ari zaren cachean gordetzeko edo modu iraunkorrean datu biltegi nagusi gisa. Aviton oraingoz hau Confluencerako lotura da.

III. Runbook. Zerbitzua abiarazteko eta kudeatzeko zailtasunei buruzko gida labur bat.

IV. ohiko galderak, non ondo legoke zure lankideek zerbitzuarekin lan egitean izan ditzaketen arazoei aurrea hartzea.

V. APIaren amaierako puntuen deskribapena. Bat-batean helmugak zehaztu ez badituzu, zurearekin zerikusia duten mikrozerbitzuak dituzten lankideek ia ziur ordainduko dute. Orain Swagger eta gure irtenbide laburra deitzen dugu horretarako.

VI. Etiketak. Edo zerbitzua enpresaren zein produktu, funtzionalitate edo egitura-dibisiotakoa den erakusten duten markatzaileak. Azkar ulertzen lagunduko dizute, adibidez, zure lankideek duela astebete negozio-unitate berean zabaldutako funtzionaltasuna mozten ari zaren ala ez.

VII. Zerbitzuaren jabea edo titularrak. Kasu gehienetan, automatikoki zehaztu daiteke PaaS erabiliz, baina seguru egoteko, garatzaileari eskuz zehaztea eskatzen diogu.

Azkenik, praktika ona da dokumentazioa berrikustea, kodearen berrikuspenaren antzera.

Etengabeko integrazioa

• Biltegiak prestatzea.
• TeamCity-n kanalizazio bat sortzea.
• Eskubideak ezartzea.
• Bilatu zerbitzuen jabeak. Hemen eskema hibrido bat dago: eskuzko markaketa eta automatizazio minimoa PaaS-tik. Guztiz automatikoki eskema batek huts egiten du zerbitzuak beste garapen-talde bati laguntza eskatzeko transferitzen zaizkionean edo, adibidez, zerbitzu-garatzaileak irteten bada.
• Atlas-en zerbitzu bat erregistratzea (ikus goian). Bere jabe eta menpekotasun guztiekin.
• Migrazioak egiaztatzea. Horietakoren bat arriskutsua den ala ez egiaztatzen dugu. Adibidez, horietako batean aldaketa taula bat edo zerbitzuaren bertsio desberdinen arteko datu-eskemaren bateragarritasuna hautsi dezakeen beste zerbait agertzen da. Ondoren, migrazioa ez da egiten, harpidetza batean jartzen da; PaaS-k zerbitzuaren jabeari adierazi behar dio erabiltzea segurua denean.

Labean

Hurrengo fasea ontziratzeko zerbitzuak dira zabaldu aurretik.

• Aplikazioa eraikitzea. Klasikoen arabera - Docker irudi batean.
• Helm diagramen sorrera zerbitzurako bera eta erlazionatutako baliabideetarako. Datu-baseetarako eta cacherako barne. Automatikoki sortzen dira CLI-push fasean sortu zen app.toml konfigurazioaren arabera.
• Administratzaileek portuak irekitzeko txartelak sortzea (beharrezkoa denean).
• Unitate-probak egitea eta kodearen estaldura kalkulatzea. Kodearen estaldura zehaztutako atalasearen azpitik badago, ziurrenik zerbitzua ez da urrunago joango - inplementaziora. Onartzeko zorian badago, orduan zerbitzuari koefiziente "ezkorra" bat esleituko zaio: orduan, denboran zehar adierazlean hobekuntzarik ez badago, garatzaileak jakinarazpen bat jasoko du probei dagokienez ez dagoela aurrerapenik ( eta zerbait egin behar da).
• Memoria eta PUZaren mugak kontabilizatzea. Batez ere Golang-en mikrozerbitzuak idazten ditugu eta Kubernetesen exekutatzen ditugu. Horregatik, Golang hizkuntzaren berezitasunarekin lotutako sotiltasun bat: lehenespenez, abiaraztean, makinako nukleo guztiak erabiltzen dira, GOMAXPROCS aldagaia esplizituki ezartzen ez baduzu, eta horrelako hainbat zerbitzu makina berean abiarazten direnean, hasten dira. baliabideengatik lehiatzeko, elkarri oztopatzen. Beheko grafikoek exekuzio-denbora nola aldatzen den erakusten dute aplikazioa eztabaidarik gabe eta baliabideen lasterketa moduan exekutatzen baduzu. (Grafikoen iturriak dira Hemen).

Exekuzio denbora, gutxiago da hobea. Gehienez: 643 ms, gutxienez: 42 ms. Argazkia klikagarria da.

Ebakuntza egiteko garaia, gutxiago da hobea. Gehienez: 14091 ns, gutxienez: 151 ns. Argazkia klikagarria da.

Muntaia prestatzeko fasean, aldagai hau esplizituki ezar dezakezu edo liburutegia erabil dezakezu automaxprocs Uber-eko mutilen eskutik.

Zabaldu

• Konbentzioak egiaztatzea. Zerbitzu-muntaiak aurreikusitako inguruneetara ematen hasi aurretik, honako hau egiaztatu behar duzu:
- API amaierako puntuak.
— API amaierako puntuen erantzunak eskemarekin betetzea.
— Erregistro formatua.
— Zerbitzuari egindako eskaeren goiburuak ezartzea (gaur egun netramesh-ek egiten du)
— Jabearen tokena ezartzea gertaera-busera mezuak bidaltzean. Hau beharrezkoa da autobusean zehar zerbitzuen konektibitatearen jarraipena egiteko. Datu idempotenteak bidal ditzakezu autobusera, zerbitzuen konektibitatea handitzen ez dutenak (ona da), eta zerbitzuen konektibitatea indartzen duten negozio datuak (oso txarra!). Eta konektibitate hori arazo bihurtzen den unean, autobusa nork idatzi eta irakurtzen duen ulertzeak zerbitzuak behar bezala bereizten laguntzen du.

Aviton oraindik ez dago konbentzio asko, baina haien igerilekua zabaltzen ari da. Zenbat eta hitzarmen gehiago egon taldeak ulertzeko eta ulertzeko moduan, orduan eta errazagoa izango da mikrozerbitzuen arteko koherentzia mantentzea.

Proba sintetikoak

• Begizta itxiko probak. Horretarako orain kode irekia erabiltzen ari gara Hoverfly.io. Lehenik eta behin, zerbitzuan benetako karga erregistratzen du, gero -begizta itxi batean- emulatzen du.

• Estres-probak. Zerbitzu guztiak errendimendu hoberenera eramaten saiatzen gara. Eta zerbitzu bakoitzaren bertsio guztiek karga-probak egin behar dituzte; horrela, zerbitzuaren egungo errendimendua eta zerbitzu beraren aurreko bertsioekiko aldea uler dezakegu. Zerbitzuaren eguneratze baten ondoren, bere errendimendua bider eta erdi jaitsi bada, hau seinale argia da jabeentzat: kodean sakondu eta egoera zuzendu behar duzu.
Bildutako datuak, adibidez, eskalatze automatikoa behar bezala ezartzeko eta, azkenean, zerbitzua nola eskalagarria den ulertzeko erabiltzen ditugu.

Karga probetan, baliabideen kontsumoak ezarritako mugak betetzen dituen egiaztatzen dugu. Eta batez ere muturretan zentratzen gara.

a) Karga osoa aztertuko dugu.
- Txikiegia - ziurrenik zerbaitek ez du funtzionatuko karga bat-batean hainbat aldiz jaisten bada.
- Handiegia - optimizazioa behar da.

b) Ebakidurari erreparatuko diogu RPSren arabera.
Hemen uneko bertsioaren eta aurrekoaren arteko aldea eta kantitate osoa ikusiko dugu. Esaterako, zerbitzu batek 100 rps ekoizten baditu, gaizki idatzita dago, edo hori da bere berezitasuna, baina, nolanahi ere, hau zerbitzua oso gertutik aztertzeko arrazoia da.
Aitzitik, RPS gehiegi badaude, agian akatsen bat dago eta amaierako puntu batzuek karga exekutatzen utzi dute, eta beste bat besterik ez da abiarazi. return true;

Kanariar probak

Proba sintetikoak gainditu ondoren, mikrozerbitzua erabiltzaile kopuru txiki batean probatzen dugu. Kontu handiz hasten gara, zerbitzuaren xede den audientziaren zati txiki batekin -% 0,1 baino gutxiago. Fase honetan, oso garrantzitsua da monitorizazioan neurketa tekniko eta produktu zuzenak sartzea, zerbitzuan arazoa ahalik eta azkarren erakusteko. Kanariar proba egiteko gutxieneko denbora 5 minutukoa da, nagusia 2 ordukoa. Zerbitzu konplexuetarako, ordua eskuz ezartzen dugu.
Azter dezagun:
— hizkuntzaren neurri espezifikoak, bereziki, php-fpm langileak;
— Sentryn akatsak;
— erantzun-egoerak;
— erantzun denbora, zehatza eta batez bestekoa;
- latentzia;
— salbuespenak, prozesatu eta kudeatu gabe;
- Produktuen neurketak.

Squeeze probak

Squeeze Testari "estuketa" proba ere deitzen zaio. Teknikaren izena Netflixen sartu zen. Bere funtsa da lehenik instantzia bat benetako trafikoarekin betetzen dugula hutsegiteraino eta horrela bere muga ezartzen dugula. Ondoren, beste instantzia bat gehitzen dugu eta bikote hau kargatzen dugu - berriro gehienez; haien sabaia eta delta ikusten ditugu lehen “estuketarekin”. Beraz, instantzia bat aldi berean konektatzen dugu eta aldaketen eredua kalkulatzen dugu.
"Estutu" bidezko proba-datuak metrika datu-base batera iristen dira, non karga artifizialaren emaitzak haiekin aberasten ditugun edo "sintetikoak" haiekin ordezkatzen ditugun.

Ekoizpena

• Eskalatzea. Zerbitzu bat produkziora zabaltzen dugunean, nola eskalatzen den kontrolatzen dugu. Gure esperientziaren arabera, PUZaren adierazleak soilik kontrolatzea ez da eraginkorra. Eskalatze automatikoak RPS benchmarking-ekin bere forma hutsean funtzionatzen du, baina zerbitzu jakin batzuetarako soilik, hala nola lineako streaming-a adibidez. Beraz, lehenik eta behin aplikazioaren produktuen neurri espezifikoak aztertzen ditugu.

Ondorioz, eskalatzerakoan:
- CPU eta RAM adierazleak,
— ilaran dauden eskaera kopurua,
- erantzun denbora,
— metatutako datu historikoetan oinarritutako aurreikuspena.

Zerbitzu bat eskalatzerakoan, bere mendekotasunak kontrolatzea ere garrantzitsua da, kateko lehen zerbitzua eskalatu ez dezagun, eta sartzen direnek kargapean huts egin dezaten. Zerbitzu multzo osorako karga onargarria ezartzeko, menpeko zerbitzu "hurbilen"aren datu historikoak aztertuko ditugu (PUZaren eta RAM adierazleen konbinazioan oinarrituta, aplikazioaren neurri espezifikoekin batera) eta datu historikoekin alderatzen ditugu. hasierako zerbitzuaren, eta abar "mendekotasun-katean" osoan ", goitik behera.

zerbitzu

Mikrozerbitzua martxan jarri ondoren, abiarazleak erantsi ditzakegu.

Hona hemen abiarazleak gertatzen diren egoera tipikoak.
— Arriskutsuak izan daitezkeen migrazioak detektatu dira.
— Segurtasun-eguneratzeak kaleratu dira.
— Zerbitzua bera ez da denbora luzez eguneratu.
— Zerbitzuaren karga nabarmen gutxitu da edo produktuaren neurketa batzuk normaltasunetik kanpo daude.
— Zerbitzuak jada ez ditu plataformaren eskakizun berriak betetzen.

Abiarazleetako batzuk funtzionamenduaren egonkortasunaren erantzule dira, beste batzuk -sistemaren mantentzearen arabera-, adibidez, zerbitzu batzuk denbora luzez zabaldu gabe egon dira eta bere oinarrizko irudiak segurtasun-kontrolak gainditzeari utzi dio.

Aginte-panela

Laburbilduz, aginte-panela gure PaaS osoaren kontrol-panela da.

• Zerbitzuari buruzko informazio puntu bakarra, bere proba-estaldurari buruzko datuekin, bere irudien kopurua, ekoizpen-kopia kopurua, bertsioa, etab.
• Datuak zerbitzuen eta etiketen arabera iragazteko tresna (negozio-unitateetako pertenentzia-markak, produktuaren funtzionaltasuna, etab.)
• Trazadura, erregistroa eta jarraipena egiteko azpiegitura tresnekin integratzeko tresna.
• Zerbitzu-puntu bakarreko dokumentazioa.
• Zerbitzuen arteko ekitaldi guztien ikuspuntu bakarra.

Guztira

PaaS aurkeztu aurretik, garatzaile berri batek zenbait aste eman ditzake ekoizpenean mikrozerbitzu bat abiarazteko beharrezko tresna guztiak ulertzen: Kubernetes, Helm, gure TeamCity barneko funtzioak, datu-baseetarako eta cacheetarako konexioak akatsekiko tolerantzian konfiguratzeko, etab. ordu pare bat behar da abiarazte azkarra irakurtzeko eta zerbitzua bera sortzeko.

HighLoad++ 2018rako gai honi buruzko txosten bat eman nuen, ikus dezakezu video и aurkezpena.

Bukaera arte irakurtzen dutenentzako bonus track

Avitotik garatzaileentzako hiru eguneko barne prestakuntza bat antolatzen ari gara Chris Richardson, mikrozerbitzuen arkitekturan aditua. Bertan parte hartzeko aukera eman nahi diogu mezu honen irakurleetako bati. Hemen Prestakuntza programa argitaratu da.

Prestakuntza abuztuaren 5etik 7ra izango da Moskun. Guztiz okupatuko diren lanegunak dira. Bazkaria eta prestakuntza gure bulegoan izango dira, eta aukeratutako parte-hartzaileak berak ordainduko ditu bidaia eta ostatua.

Parte hartzeko eskaera egin dezakezu google formulario honetan. Zuregandik - prestakuntzara zergatik joan behar duzun galderari erantzuna eta zurekin harremanetan jartzeko informazioa. Erantzun ingelesez, Chrisek berak aukeratuko baitu prestakuntzara joango den parte-hartzailea.
Prestakuntzako parte-hartzailearen izena argitalpen honen eguneraketa batean eta garatzaileentzako Avito sare sozialetan jakinaraziko dugu (AvitoTech-en Фейсбуке, Vkontakte, Twitter) uztailaren 19a baino lehen.

Iturria: www.habr.com