Hei! Nimeni on Vadim Madison, johdan Avito System Platformin kehitystä. Useammin kuin kerran on kerrottu, kuinka olemme yrityksessä siirtymässä monoliittisesta arkkitehtuurista mikropalveluarkkitehtuuriin. On aika kertoa, kuinka olemme muuttaneet infrastruktuuriamme saadakseen kaiken irti mikropalveluista ja estämään itseämme eksymästä niihin. Kuinka PaaS auttaa meitä tässä, kuinka yksinkertaistimme käyttöönottoa ja pienensimme mikropalvelun luomisen yhdellä napsautuksella - lue eteenpäin. Kaikki, mistä kirjoitan alla, ei ole täysin toteutettu Avitossa, osa siitä on se, miten kehitämme alustamme.

(Ja tämän artikkelin lopussa puhun mahdollisuudesta osallistua mikropalveluarkkitehtuurin asiantuntijan Chris Richardsonin kolmipäiväiseen seminaariin).

Miten pääsimme mikropalveluihin

Avito on yksi maailman suurimmista luokitelluista sivustoista, jossa julkaistaan ​​yli 15 miljoonaa uutta ilmoitusta päivässä. Taustajärjestelmämme hyväksyy yli 20 tuhatta pyyntöä sekunnissa. Meillä on tällä hetkellä useita satoja mikropalveluita.

Olemme rakentaneet mikropalveluarkkitehtuuria jo usean vuoden ajan. Kuinka tarkalleen - kollegamme yksityiskohtaisesti kertoi osastollamme RIT++ 2017. CodeFest 2017:ssä (katso. video), Sergey Orlov ja Mihail Prokopchuk selittivät yksityiskohtaisesti, miksi tarvitsimme siirtymistä mikropalveluihin ja mikä rooli Kubernetes oli tässä. No, nyt teemme kaikkemme minimoidaksemme tällaiselle arkkitehtuurille ominaiset skaalauskustannukset.

Aluksi emme luoneet ekosysteemiä, joka auttaisi meitä kokonaisvaltaisesti kehittämään ja käynnistämään mikropalveluita. He yksinkertaisesti keräsivät järkeviä avoimen lähdekoodin ratkaisuja, lanseerasivat ne kotona ja kutsuivat kehittäjän käsittelemään niitä. Tämän seurauksena hän meni tusinaan paikkaan (kojelaudat, sisäiset palvelut), minkä jälkeen hän vahvistui halussaan leikata koodia vanhalla tavalla, monoliitissa. Vihreä väri alla olevissa kaavioissa osoittaa, mitä kehittäjä tekee tavalla tai toisella omin käsin, ja keltainen väri tarkoittaa automaatiota.

Nyt PaaS CLI -apuohjelmassa luodaan uusi palvelu yhdellä komennolla ja uusi tietokanta lisätään kahdella komennolla ja otetaan käyttöön Stagessa.

Kuinka voittaa "mikropalvelujen pirstoutumisen" aikakausi

Monoliittinen arkkitehtuuri, tuotteen muutosten johdonmukaisuuden vuoksi, kehittäjät joutuivat selvittämään, mitä heidän naapureidensa kanssa tapahtui. Uuden arkkitehtuurin parissa työskennellessä palvelukontekstit eivät ole enää riippuvaisia ​​toisistaan.

Lisäksi, jotta mikropalveluarkkitehtuuri olisi tehokas, on perustettava monia prosesseja, nimittäin:

• puunkorjuu;
• pyytää jäljitystä (Jaeger);
• virheen aggregointi (Sentry);
• Kubernetesin tilat, viestit, tapahtumat (tapahtumavirran käsittely);
• kilpailuraja / katkaisija (voit käyttää Hystrixiä);
• palvelun liitettävyyden hallinta (käytämme Netrameshia);
• seuranta (Grafana);
• kokoonpano (TeamCity);
• viestintä ja tiedottaminen (Slack, sähköposti);
• tehtävien seuranta; (Jira)
• dokumentaation valmistelu.

Varmistaaksemme, että järjestelmä ei menetä eheyttään ja pysyy tehokkaana skaalautuessaan, ajattelimme mikropalveluiden organisoinnin uudelleen Avitossa.

Kuinka hallinnoimme mikropalveluita

Seuraavat auttavat toteuttamaan yhtenäisen "puoluepolitiikan" monien Avito-mikropalvelujen joukossa:

• infrastruktuurin jakaminen kerroksiin;
• Platform as a Service (PaaS) -konsepti;
• seurata kaikkea mitä mikropalveluissa tapahtuu.

Infrastruktuurin abstraktiokerrokset sisältävät kolme kerrosta. Mennään ylhäältä alas.

A. Top - huoltoverkko. Aluksi kokeilimme Istiota, mutta kävi ilmi, että se kuluttaa liikaa resursseja, mikä on liian kallista volyymiimme. Siksi arkkitehtuuritiimin vanhempi insinööri Alexander Lukyanchenko kehitti oman ratkaisunsa - Netramesh (saatavana avoimena lähdekoodina), jota käytämme tällä hetkellä tuotannossa ja joka kuluttaa useita kertoja vähemmän resursseja kuin Istio (mutta ei tee kaikkea, mistä Istio voi ylpeillä).
B. Keskikokoinen - Kubernetes. Otamme käyttöön ja käytämme siihen mikropalveluita.
C. Pohja - paljas metalli. Emme käytä pilviä tai OpenStackin kaltaisia ​​asioita, vaan luotamme täysin paljaaseen metalliin.

PaaS yhdistää kaikki tasot. Ja tämä alusta puolestaan ​​koostuu kolmesta osasta.

I. Generaattorit, jota ohjataan CLI-apuohjelman kautta. Hän auttaa kehittäjää luomaan mikropalvelun oikealla tavalla ja mahdollisimman vähällä vaivalla.

II. Konsolidoitu keräilijä kaikkien työkalujen hallinta yhteisen kojelaudan kautta.

III. Varastointi. Yhdistää ajoittajiin, jotka asettavat automaattisesti liipaisimet merkittäville toimille. Tällaisen järjestelmän ansiosta yksikään tehtävä ei jää väliin vain siksi, että joku unohti määrittää tehtävän Jirassa. Käytämme tähän sisäistä työkalua nimeltä Atlas.

Myös mikropalvelujen käyttöönotto Avitossa tapahtuu yhden järjestelmän mukaan, mikä yksinkertaistaa niiden hallintaa jokaisessa kehitys- ja julkaisuvaiheessa.

Kuinka tavallinen mikropalvelukehitysputki toimii?

Yleisesti ottaen mikropalvelun luontiketju näyttää tältä:

CLI-push → Jatkuva integrointi → Paista → Käyttöönotto → Keinotekoiset testit → Kanarian testit → Puristustestaus → Tuotanto → Ylläpito.

Käydään se läpi tarkalleen tässä järjestyksessä.

CLI-push

• Mikropalvelun luominen.
Taistelimme pitkään opettaaksemme jokaiselle kehittäjälle mikropalveluiden tekemisen. Tämä sisälsi yksityiskohtaisten ohjeiden kirjoittamisen Confluenceen. Mutta suunnitelmat muuttuivat ja niitä täydennettiin. Tuloksena on, että matkan alussa ilmaantui pullonkaula: mikropalvelujen käynnistämiseen kului paljon enemmän aikaa, ja silti ongelmia ilmeni usein niiden luomisen aikana.

Lopulta rakensimme yksinkertaisen CLI-apuohjelman, joka automatisoi mikropalvelun luomisen perusvaiheet. Itse asiassa se korvaa ensimmäisen git-painauksen. Tässä on mitä hän tarkalleen tekee.

— Luo palvelun mallin mukaan — askel askeleelta, "velho"-tilassa. Meillä on malleja tärkeimmille ohjelmointikielille Avito-taustajärjestelmässä: PHP, Golang ja Python.

- Yksi komento kerrallaan ottaa käyttöön ympäristön paikallista kehitystä varten tietylle koneelle - Minikube käynnistetään, Helm-kaaviot luodaan ja käynnistetään automaattisesti paikallisissa kuberneteissä.

— Yhdistää tarvittavan tietokannan. Kehittäjän ei tarvitse tietää IP-osoitetta, käyttäjätunnusta ja salasanaa päästäkseen tarvitsemaansa tietokantaan - olipa se sitten paikallisesti, Stagessa tai tuotannossa. Lisäksi tietokanta otetaan käyttöön välittömästi vikasietoisessa kokoonpanossa ja tasapainotetulla tavalla.

— Se suorittaa itse live-kokoonpanon. Oletetaan, että kehittäjä korjasi jotain mikropalvelussa IDE:n kautta. Apuohjelma näkee muutokset tiedostojärjestelmässä ja rakentaa niiden perusteella sovelluksen uudelleen (Golangille) ja käynnistää uudelleen. PHP:ssä yksinkertaisesti välitämme edelleen kuution sisällä olevan hakemiston ja siellä live-reload saadaan "automaattisesti".

- Luo automaattisia testejä. Aihioiden muodossa, mutta varsin sopiva käytettäväksi.

• Mikropalveluiden käyttöönotto.

Mikropalvelun käyttöön ottaminen oli meille ennen vähän työlästä. Seuraavat vaadittiin:

I. Dockerfile.

II. Konfig.
III. Ruorikaavio, joka itsessään on hankala ja sisältää:

— itse kaaviot;
— mallit;
— erityiset arvot, joissa otetaan huomioon erilaiset ympäristöt.

Olemme poistaneet Kubernetes-luetteloiden uudelleenkäsittelyn vaivan, joten ne luodaan nyt automaattisesti. Mutta mikä tärkeintä, he yksinkertaistivat käyttöönottoa äärirajoille. Tästä lähtien meillä on Dockerfile, ja kehittäjä kirjoittaa koko konfiguraation yhteen lyhyeen app.toml-tiedostoon.

Kyllä, ja itse app.tomlissa ei ole mitään tekemistä hetkeen. Määritämme, missä ja kuinka monta kopiota palvelusta nostetaan (kehittäjäpalvelimella, lavastuksessa, tuotannossa) ja ilmoitamme sen riippuvuudet. Huomaa rivin koko = "small" [moottori]-lohkossa. Tämä on raja, joka myönnetään palvelulle Kubernetesin kautta.

Sitten konfiguroinnin perusteella luodaan automaattisesti kaikki tarvittavat Helm-kaaviot ja luodaan yhteydet tietokantoihin.

• Perustarkistus. Tällaiset tarkastukset ovat myös automaattisia.
Pitää seurata:
- onko Docker-tiedostoa olemassa;
- onko app.toml;
- onko asiakirjoja saatavilla?
- onko riippuvuus kunnossa?
— onko varoitussääntöjä asetettu.
Viimeiseen kohtaan: palvelun omistaja päättää itse, mitä tuotemittareita seurataan.

• Dokumentaation valmistelu.
Edelleen ongelma-alue. Se näyttää ilmeisimmältä, mutta samalla se on myös "usein unohdettu" ennätys ja siksi haavoittuva lenkki ketjussa.
Jokaisesta mikropalvelusta on oltava dokumentaatio. Se sisältää seuraavat lohkot.

I. Palvelun lyhyt kuvaus. Kirjaimellisesti muutama lause siitä, mitä se tekee ja miksi sitä tarvitaan.

II. Linkki arkkitehtuurikaavioon. On tärkeää, että nopealla vilkaisulla on helppo ymmärtää esimerkiksi, käytätkö Redistä välimuistiin vai päätietovarastona pysyvässä tilassa. Avitossa toistaiseksi tämä on linkki Confluenceen.

III. Runbook. Lyhyt opas palvelun aloittamiseen ja sen käsittelyn monimutkaisuuteen.

IV. FAQ, jossa olisi hyvä ennakoida ongelmia, joita työkaverit saattavat kohdata työskennellessään palvelun kanssa.

V. API:n päätepisteiden kuvaus. Jos et yhtäkkiä määrittänyt kohteita, kollegat, joiden mikropalvelut liittyvät sinun palveluusi, maksavat siitä lähes varmasti. Nyt käytämme tähän Swaggeria ja lyhyttä ratkaisuamme.

VI. Tarrat. Tai merkkejä, jotka osoittavat mihin tuotteeseen, toiminnallisuuteen tai yrityksen rakenteelliseen divisioonaan palvelu kuuluu. Niiden avulla ymmärrät esimerkiksi nopeasti, oletko leikamassa toimintoja, jotka kollegasi ottivat käyttöön samassa liiketoimintayksikössä viikko sitten.

VII. Palvelun omistaja tai omistajat. Useimmissa tapauksissa se – tai ne – voidaan määrittää automaattisesti PaaS:n avulla, mutta varmuuden vuoksi vaadimme kehittäjää määrittämään ne manuaalisesti.

Lopuksi on hyvä käytäntö tarkistaa asiakirjoja koodin tarkistamisen tapaan.

Jatkuva integraatio

• Varastojen valmistelu.
• Putkilinjan luominen TeamCityssä.
• Oikeuksien asettaminen.
• Etsi palvelun omistajia. Täällä on hybridimalli - manuaalinen merkintä ja minimaalinen automaatio PaaS:ltä. Täysautomaattinen järjestelmä epäonnistuu, kun palvelut siirretään tueksi toiselle kehitystiimille tai esimerkiksi jos palvelun kehittäjä lopettaa.
• Palvelun rekisteröinti Atlasissa (Katso edellä). Kaikkineen omistajineen ja riippuvuuksineen.
• Tarkastetaan siirtoja. Tarkistamme, onko jokin niistä mahdollisesti vaarallinen. Esimerkiksi yhdessä niistä ponnahtaa esiin alter-taulukko tai jotain muuta, joka voi rikkoa tietoskeeman yhteensopivuuden palvelun eri versioiden välillä. Tällöin siirtoa ei suoriteta, vaan se asetetaan liittymään - PaaS:n on ilmoitettava palvelun omistajalle, kun sen käyttö on turvallista.

Leipoa

Seuraava vaihe on pakkauspalvelut ennen käyttöönottoa.

• Sovelluksen rakentaminen. Klassikoiden mukaan - Docker-kuvassa.
• Helm-kaavioiden luominen itse palvelulle ja siihen liittyville resursseille. Mukaan lukien tietokannat ja välimuisti. Ne luodaan automaattisesti CLI-push-vaiheessa luodun app.toml-konfiguraation mukaisesti.
• Lippujen luominen järjestelmänvalvojille porttien avaamiseen (tarvittaessa).
• Yksikkötestien suorittaminen ja koodin peiton laskeminen. Jos koodin kattavuus on alle määritetyn kynnyksen, palvelu ei todennäköisesti mene pidemmälle - käyttöönottoon. Jos se on hyväksyttävän partaalla, palvelulle annetaan "pessimoiva" kerroin: sitten, jos indikaattori ei parane ajan myötä, kehittäjä saa ilmoituksen, että testien suhteen ei ole edistytty ( ja asialle on tehtävä jotain).
• Muistin ja suorittimen rajoitusten huomioiminen. Kirjoitamme pääasiassa mikropalveluita Golangissa ja suoritamme niitä Kubernetesissa. Tästä johtuu yksi Golang-kielen erikoisuuteen liittyvä hienous: oletusarvoisesti käynnistettäessä käytetään kaikkia koneen ytimiä, jos et nimenomaisesti aseta GOMAXPROCS-muuttujaa ja kun samassa koneessa käynnistetään useita tällaisia ​​palveluita, ne alkavat. kilpailemaan resursseista häiriten toisiaan. Alla olevat kaaviot osoittavat, kuinka suoritusaika muuttuu, jos käytät sovellusta ilman kilpailua ja kilpa resursseista -tilassa. (Kaavioiden lähteet ovat täällä).

Toteutusaika, vähemmän on parempi. Maksimi: 643 ms, minimi: 42 ms. Valokuva on klikattava.

Leikkauksen aika, vähemmän on parempi. Suurin: 14091 ns, minimi: 151 ns. Valokuva on klikattava.

Kokoonpanon valmisteluvaiheessa voit asettaa tämän muuttujan eksplisiittisesti tai voit käyttää kirjastoa automaxprocs Uberin kavereilta.

Ota käyttöön

• Konventojen tarkistus. Ennen kuin aloitat huoltokokoonpanojen toimittamisen aiottuun ympäristöön, sinun on tarkistettava seuraavat asiat:
- API-päätepisteet.
— API-päätepisteiden vastausten yhteensopivuus skeeman kanssa.
— Lokin muoto.
- Otsikoiden asettaminen palvelupyyntöille (tällä hetkellä tämän tekee netramesh)
— Omistajan tunnuksen asettaminen lähetettäessä viestejä tapahtumaväylään. Tätä tarvitaan palvelujen yhteyksien seuraamiseen bussissa. Väylään voi lähettää sekä idempotenttia dataa, joka ei lisää palveluiden yhteyksiä (mikä on hyvä), että palveluiden yhteyksiä vahvistavaa yritysdataa (mikä on erittäin huonoa!). Ja silloin, kun tästä liitettävyydestä tulee ongelma, sen ymmärtäminen, kuka kirjoittaa ja lukee väylää, auttaa erottamaan palvelut oikein.

Avitossa ei ole vielä kovin montaa kokousta, mutta niiden allas laajenee. Mitä enemmän tällaisia ​​sopimuksia on saatavilla tiimin ymmärtämässä ja ymmärrettävässä muodossa, sitä helpompi on ylläpitää mikropalveluiden välistä johdonmukaisuutta.

Synteettiset testit

• Suljetun silmukan testaus. Tätä varten käytämme nyt avointa lähdekoodia Hoverfly.io. Ensin se tallentaa palvelun todellisen kuormituksen, sitten - vain suljetussa silmukassa - emuloi sitä.

• Stressitestaus. Pyrimme saamaan kaikki palvelut parhaalla mahdollisella tavalla. Ja jokaisen palvelun kaikille versioille on tehtävä kuormitustestaus - näin voimme ymmärtää palvelun tämänhetkisen suorituskyvyn ja eron saman palvelun aikaisempiin versioihin. Jos sen suorituskyky putosi palvelun päivityksen jälkeen puolitoista kertaa, tämä on selvä signaali sen omistajille: sinun on kaivettava koodia ja korjattava tilanne.
Käytämme kerättyä dataa esimerkiksi automaattisen skaalauksen oikein toteuttamiseen ja loppujen lopuksi palvelun skaalautuvuuden ymmärtämiseen.

Kuormitustestauksen aikana tarkistamme, täyttääkö resurssien kulutus asetetut rajat. Ja keskitymme ensisijaisesti äärimmäisyyksiin.

a) Tarkastellaan kokonaiskuormaa.
- Liian pieni - todennäköisesti jokin ei toimi ollenkaan, jos kuorma putoaa yhtäkkiä useita kertoja.
- Liian suuri - optimointi vaaditaan.

b) Katsomme rajaa RPS:n mukaan.
Tässä tarkastellaan eroa nykyisen ja edellisen version välillä sekä kokonaismäärää. Esimerkiksi, jos palvelu tuottaa 100 rps, se on joko huonosti kirjoitettu tai tämä on sen erityispiirre, mutta joka tapauksessa tämä on syy tarkastella palvelua erittäin tarkasti.
Jos päinvastoin RPS:itä on liikaa, saattaa olla jonkinlainen bugi ja jotkut päätepisteet ovat lopettaneet hyötykuorman suorittamisen, ja jokin muu on yksinkertaisesti lauennut return true;

Kanarian kokeet

Kun olemme läpäisseet synteettiset testit, testaamme mikropalvelua pienellä määrällä käyttäjiä. Aloitamme varovasti, pienellä osuudella palvelun kohdeyleisöstä - alle 0,1 %. Tässä vaiheessa on erittäin tärkeää, että oikeat tekniset ja tuotemittarit otetaan mukaan seurantaan, jotta ne näyttäisivät ongelman palvelussa mahdollisimman nopeasti. Kanariankokeen vähimmäisaika on 5 minuuttia, pääasiallinen 2 tuntia. Monimutkaisille palveluille asetamme ajan manuaalisesti.
Analysoimme:
— kielikohtaiset mittarit, erityisesti php-fpm-työntekijät;
- virheet Sentryssä;
— vastaustilat;
— vasteaika, tarkka ja keskimääräinen;
- viive;
— käsitellyt ja käsittelemättömät poikkeukset;
- tuotetiedot.

Puristustestaus

Puristustestausta kutsutaan myös "puristustestaukseksi". Tekniikan nimi esiteltiin Netflixissä. Sen ydin on, että ensin täytämme yhden ilmentymän todellisella liikenteellä epäonnistumispisteeseen asti ja asetamme siten sen rajan. Sitten lisäämme toisen esiintymän ja lataamme tämän parin - jälleen maksimiin; näemme niiden katon ja suiston ensimmäisellä "puristuksella". Ja niin yhdistämme yhden esiintymän kerrallaan ja laskemme muutoskuvion.
Testitiedot "puristamalla" virtaavat myös yhteiseen metriikkatietokantaan, jossa joko rikastamme keinotekoisia kuormitustuloksia niillä tai jopa korvaamme "synteettiset tuotteet".

Tuotanto

• Skaalaus. Kun otamme palvelun käyttöön tuotantoon, seuraamme sen skaalaamista. Kokemuksemme mukaan vain CPU-indikaattoreiden seuranta on tehotonta. Automaattinen skaalaus RPS-vertailulla puhtaassa muodossaan toimii, mutta vain tietyissä palveluissa, kuten online-suoratoistossa. Joten tarkastelemme ensin sovelluskohtaisia ​​tuotemittareita.

Tämän seurauksena skaalattaessa analysoimme:
- CPU- ja RAM-ilmaisimet,
— jonossa olevien pyyntöjen määrä,
- vasteaika,
— ennuste, joka perustuu kertyneisiin historiallisiin tietoihin.

Palvelua skaalattaessa on myös tärkeää seurata sen riippuvuuksia, jotta emme skaalaa ketjun ensimmäistä palvelua ja sen käyttämät epäonnistuvat kuormituksen alaisena. Hyväksyttävän kuormituksen määrittämiseksi koko palvelujoukolle tarkastelemme "lähimmän" riippuvaisen palvelun historiallisia tietoja (perustuu CPU- ja RAM-indikaattoreiden yhdistelmään yhdistettynä sovelluskohtaisiin mittareihin) ja vertaamme niitä historiallisiin tietoihin. alustuspalvelusta ja niin edelleen koko "riippuvuusketjussa" ", ylhäältä alas.

palvelu

Kun mikropalvelu on otettu käyttöön, voimme liittää siihen liipaisimet.

Tässä on tyypillisiä tilanteita, joissa laukaisee.
— Mahdollisesti vaarallisia siirtymiä havaittu.
— Tietoturvapäivitykset on julkaistu.
– Itse palvelua ei ole päivitetty pitkään aikaan.
— Palvelun kuormitus on laskenut tuntuvasti tai osa sen tuotemittareista on normaalialueen ulkopuolella.
— Palvelu ei enää täytä uusia alustavaatimuksia.

Osa triggereistä on vastuussa toiminnan vakaudesta, osa - järjestelmän ylläpidon funktiona - esimerkiksi osa palvelusta on ollut käyttämättä pitkään aikaan ja sen peruskuva on lakannut läpäisemään turvatarkastuksia.

Kojelauta

Lyhyesti sanottuna kojelauta on koko PaaS:n ohjauspaneeli.

• Yksittäinen tietopiste palvelusta, jossa on tiedot sen testikattavuudesta, sen kuvien määrästä, tuotantokopioiden määrästä, versioista jne.
• Työkalu tietojen suodattamiseen palveluiden ja tunnisteiden mukaan (liiketoimintayksiköihin kuulumisen merkit, tuotteen toiminnallisuus jne.)
• Työkalu integroitavaksi infrastruktuurityökaluihin jäljittämiseen, kirjaamiseen ja seurantaan.
• Yhden huoltopisteen dokumentaatio.
• Yksi näkökulma kaikista palveluiden tapahtumista.

Yhteensä

Ennen PaaS:n käyttöönottoa uusi kehittäjä voi viettää useita viikkoja ymmärtääkseen kaikki työkalut, joita tarvitaan mikropalvelun käynnistämiseen tuotannossa: Kubernetes, Helm, sisäiset TeamCity-ominaisuudet, yhteyksien luominen tietokantoihin ja välimuistiin vikasietoisella tavalla jne. Pikaoppaan lukeminen ja itse palvelun luominen vie pari tuntia.

Annoin raportin tästä aiheesta HighLoad++ 2018:lle, voit katsoa sen video и esittely.

Bonusraita niille, jotka lukevat loppuun

Me Avitolla järjestämme kehittäjille sisäisen kolmipäiväisen koulutuksen alkaen Chris Richardson, mikropalveluarkkitehtuurin asiantuntija. Haluamme antaa mahdollisuuden osallistua siihen yhdelle tämän postauksen lukijoista. Täällä Koulutusohjelma on julkaistu.

Koulutus järjestetään 5.-7. elokuuta Moskovassa. Nämä ovat työpäiviä, jotka ovat täynnä. Lounas ja koulutus ovat toimistollamme ja valittu osallistuja maksaa itse matkat ja majoituksen.

Voit hakea osallistumista tässä google-lomakkeessa. Sinulta - vastaus kysymykseen, miksi sinun on osallistuttava koulutukseen ja tietoa yhteydenottotavoista. Vastaa englanniksi, koska Chris valitsee itse koulutukseen osallistuvan osallistujan.
Ilmoitamme koulutuksen osallistujan nimen tämän postauksen päivityksessä ja sosiaalisessa mediassa Avito kehittäjille (AvitoTech in Facebook, Vkontakte, viserrys) viimeistään 19. heinäkuuta.

Lähde: will.com