Merhaba! Adım Vadim Madison, Avito Sistem Platformunun geliştirilmesine liderlik ediyorum. Şirket olarak yekpare bir mimariden mikro hizmetlere nasıl geçtiğimiz defalarca söylendi. Mikro hizmetlerden en iyi şekilde yararlanmak ve bunların içinde kaybolmamak için altyapımızı nasıl dönüştürdüğümüzü paylaşmanın zamanı geldi. PaaS burada bize nasıl yardımcı oluyor, dağıtımı nasıl basitleştirdik ve mikro hizmet oluşturma işlemini tek tıklamaya nasıl indirdik - okumaya devam edin. Aşağıda yazdığım her şey Avito'da tam olarak uygulanmıyor; bunların bir kısmı platformumuzu nasıl geliştirdiğimizle ilgili.

(Ve bu yazının sonunda mikro hizmet mimarisi uzmanı Chris Richardson'ın üç günlük seminerine katılma fırsatından bahsedeceğim).

Mikro hizmetlere nasıl geldik?

Avito, dünyanın en büyük ilan sitelerinden biridir; günde 15 milyondan fazla yeni ilan yayınlanmaktadır. Arka uçumuz saniyede 20 binden fazla isteği kabul ediyor. Şu anda birkaç yüz mikro hizmetimiz var.

Birkaç yıldır bir mikro hizmet mimarisi inşa ediyoruz. Tam olarak nasıl - ayrıntılı olarak meslektaşlarımız söyledi RIT++ 2017'deki bölümümüzde. CodeFest 2017'de (bkz. video), Sergey Orlov ve Mikhail Prokopchuk mikro hizmetlere geçişe neden ihtiyacımız olduğunu ve Kubernetes'in burada nasıl bir rol oynadığını ayrıntılı olarak açıkladılar. Artık böyle bir mimarinin doğasında olan ölçeklendirme maliyetlerini en aza indirmek için her şeyi yapıyoruz.

Başlangıçta mikro hizmetleri geliştirmemize ve başlatmamıza kapsamlı bir şekilde yardımcı olacak bir ekosistem oluşturmadık. Basitçe mantıklı açık kaynak çözümleri topladılar, bunları evde başlattılar ve geliştiriciyi bunlarla ilgilenmeye davet ettiler. Sonuç olarak, bir düzine yere (gösterge panelleri, dahili hizmetler) gitti ve ardından kodu eski yöntemle tek parça halinde kesme arzusu güçlendi. Aşağıdaki diyagramlardaki yeşil renk, geliştiricinin şu veya bu şekilde kendi elleriyle ne yaptığını, sarı renk ise otomasyonu gösterir.

Artık PaaS CLI yardımcı programında tek komutla yeni bir hizmet oluşturulur ve iki tane daha içeren yeni bir veritabanı eklenir ve Stage'e dağıtılır.

"Mikro hizmet parçalanması" çağının üstesinden nasıl gelinir?

Yekpare bir mimariyle, üründeki değişikliklerin tutarlılığı adına geliştiriciler, komşularında neler olup bittiğini anlamaya zorlandı. Yeni mimari üzerinde çalışırken hizmet bağlamları artık birbirine bağlı değil.

Ayrıca bir mikro hizmet mimarisinin etkili olabilmesi için birçok sürecin kurulması gerekir:

• Kerestecilik;
• izleme isteği (Jaeger);
• hata toplama (Sentry);
• Kubernetes'ten gelen durumlar, mesajlar, olaylar (Olay Akışı İşleme);
• yarış sınırı / devre kesici (Hystrix'i kullanabilirsiniz);
• hizmet bağlantısının kontrolü (Netramesh kullanıyoruz);
• izleme (Grafana);
• montaj (TeamCity);
• iletişim ve bildirim (Slack, e-posta);
• görev takibi; (Jira)
• dokümantasyonun hazırlanması.

Sistemin bütünlüğünü kaybetmemesini ve ölçeklenirken etkili kalmasını sağlamak için Avito'daki mikro hizmetlerin organizasyonunu yeniden düşündük.

Mikro hizmetleri nasıl yönetiriz?

Aşağıdakiler birçok Avito mikro hizmeti arasında birleşik bir "parti politikası" uygulamaya yardımcı olur:

• altyapıyı katmanlara bölmek;
• Hizmet Olarak Platform (PaaS) konsepti;
• Mikro hizmetlerde olan her şeyi izliyoruz.

Altyapı soyutlama katmanları üç katman içerir. Yukarıdan aşağıya doğru gidelim.

A. Üst servis ağı. İlk başta Istio'yu denedik ama çok fazla kaynak kullandığı ortaya çıktı, bu da bizim hacimlerimiz için çok pahalı. Bu nedenle mimarlık ekibindeki kıdemli mühendis Alexander Lukyanchenko kendi çözümünü geliştirdi: Netrameş (Açık Kaynakta mevcut), şu anda üretimde kullandığımız ve Istio'dan birkaç kat daha az kaynak tüketen (ancak Istio'nun övünebileceği her şeyi yapmıyor).
B. Orta - Kubernetes. Üzerinde mikro hizmetler dağıtıyor ve çalıştırıyoruz.
C. Alt - çıplak metal. Bulutları veya OpenStack gibi şeyleri kullanmıyoruz, ancak tamamen çıplak metale güveniyoruz.

Tüm katmanlar PaaS ile birleştirilir. Ve bu platform da üç bölümden oluşuyor.

I. Jeneratörler, bir CLI yardımcı programı aracılığıyla kontrol edilir. Geliştiricinin doğru şekilde ve minimum çabayla bir mikro hizmet oluşturmasına yardımcı olan kişidir.

II. Konsolide toplayıcı Tüm araçların ortak bir kontrol paneli üzerinden kontrol edilmesi.

III. Depolamak. Önemli eylemler için tetikleyicileri otomatik olarak ayarlayan zamanlayıcılara bağlanır. Böyle bir sistem sayesinde Jira'da birisi görev ayarlamayı unuttu diye tek bir görev bile kaçırılmıyor. Bunun için Atlas adında dahili bir araç kullanıyoruz.

Avito'da mikro hizmetlerin uygulanması da tek bir şemaya göre gerçekleştirilir; bu, geliştirme ve sürümün her aşamasında bunlar üzerindeki kontrolü basitleştirir.

Standart bir mikro hizmet geliştirme hattı nasıl çalışır?

Genel olarak mikro hizmet oluşturma zinciri şuna benzer:

CLI-push → Sürekli Entegrasyon → Pişirme → Dağıtım → Yapay testler → Kanarya testleri → Sıkma Testi → Üretim → Bakım.

Tam olarak bu sırayla üzerinden geçelim.

CLI-itme

• Mikro hizmet oluşturma.
Her geliştiriciye mikro hizmetlerin nasıl yapılacağını öğretmek için uzun süre uğraştık. Buna Confluence'da ayrıntılı talimatlar yazmak da dahildi. Ancak şemalar değişti ve tamamlandı. Sonuç olarak, yolculuğun başında bir darboğaz ortaya çıktı: Mikro hizmetlerin başlatılması çok daha fazla zaman aldı ve yine de bunların oluşturulması sırasında sıklıkla sorunlar ortaya çıktı.

Sonunda, mikro hizmet oluştururken temel adımları otomatikleştiren basit bir CLI yardımcı programı geliştirdik. Aslında ilk git push'un yerini alır. İşte tam olarak ne yapıyor?

— Bir şablona göre bir hizmet oluşturur — "sihirbaz" modunda adım adım. Avito arka ucunda ana programlama dilleri için şablonlarımız var: PHP, Golang ve Python.

- Her seferinde bir komut, belirli bir makinede yerel gelişim için bir ortam dağıtır - Minikube başlatılır, Helm grafikleri otomatik olarak oluşturulur ve yerel kubernet'lerde başlatılır.

— Gerekli veritabanını bağlar. Geliştiricinin ihtiyaç duyduğu veritabanına (yerel olarak, Sahne Alanı'nda veya üretimde) erişim sağlamak için IP'yi, kullanıcı adını ve şifreyi bilmesine gerek yoktur. Ayrıca veritabanı, hataya dayanıklı bir konfigürasyonda ve dengelemeyle anında devreye alınır.

— Canlı montajı kendisi gerçekleştirir. Diyelim ki bir geliştirici, IDE'si aracılığıyla mikro hizmetteki bir şeyi düzeltti. Yardımcı program, dosya sistemindeki değişiklikleri görür ve bunlara dayanarak uygulamayı (Golang için) yeniden oluşturur ve yeniden başlatır. PHP için, dizini küpün içine iletiriz ve orada canlı yeniden yükleme "otomatik olarak" elde edilir.

— Otomatik testler oluşturur. Boşluk şeklinde ancak kullanıma oldukça uygundur.

• Mikro hizmet dağıtımı.

Bir mikro hizmetin konuşlandırılması bizim için biraz zahmetli bir işti. Aşağıdakiler gerekliydi:

I. Docker dosyası.

II. Yapılandırma
III. Kendisi hantal olan ve şunları içeren dümen haritası:

— çizelgelerin kendisi;
— şablonlar;
— farklı ortamları dikkate alan belirli değerler.

Kubernetes bildirimlerini yeniden çalışmanın sıkıntısını ortadan kaldırdık, böylece artık otomatik olarak oluşturuldular. Ancak en önemlisi, konuşlandırmayı sınıra kadar basitleştirdiler. Artık bir Dockerfile'ımız var ve geliştirici tüm yapılandırmayı tek bir kısa app.toml dosyasına yazıyor.

Evet ve app.toml'de bir dakika boyunca yapacak hiçbir şey yok. Hizmetin nerede ve kaç kopyasının oluşturulacağını (geliştirme sunucusunda, hazırlamada, üretimde) belirtiriz ve bağımlılıklarını belirtiriz. [engine] bloğundaki line size = "small" ifadesine dikkat edin. Bu, Kubernetes üzerinden hizmete tahsis edilecek limittir.

Daha sonra yapılandırmaya bağlı olarak gerekli tüm Helm grafikleri otomatik olarak oluşturulur ve veritabanlarına bağlantılar oluşturulur.

• Temel doğrulama. Bu tür kontroller de otomatiktir.
İzlemeniz gerekiyor:
— Docker dosyası var mı;
— app.toml var mı;
— Dokümantasyon mevcut mu?
— bağımlılık düzenli mi?
— uyarı kurallarının belirlenip belirlenmediği.
Son noktaya gelince: Hangi ürün metriklerinin izleneceğini hizmetin sahibi kendisi belirler.

• Dokümantasyonun hazırlanması.
Hala sorunlu bir alan. En bariz olanı gibi görünse de aynı zamanda “çoğunlukla unutulan” bir kayıttır ve dolayısıyla zincirin savunmasız bir halkasıdır.
Her mikro hizmet için belgelerin bulunması gerekir. Aşağıdaki blokları içerir.

I. Hizmetin kısa açıklaması. Kelimenin tam anlamıyla ne yaptığı ve neden gerekli olduğu hakkında birkaç cümle.

II. Mimari diyagram bağlantısı. Örneğin, Redis'i önbellekleme için mi yoksa kalıcı modda ana veri deposu olarak mı kullandığınızı hızlı bir bakışla anlamanın kolay olması önemlidir. Avito'da şimdilik bu Confluence'a bir bağlantıdır.

III. Runbook'u. Hizmeti başlatma ve hizmeti kullanmanın incelikleri hakkında kısa bir kılavuz.

IV. SSS, iş arkadaşlarınızın hizmetle çalışırken karşılaşabilecekleri sorunları önceden tahmin etmeniz iyi olacaktır.

V. API için uç noktaların açıklaması. Birdenbire varış noktalarını belirtmezseniz, mikro hizmetleri sizinkiyle ilgili olan meslektaşlarınız neredeyse kesinlikle bunun bedelini ödeyecektir. Şimdi bunun için Swagger'ı ve kısa isimli çözümümüzü kullanıyoruz.

VI. Etiketler. Veya hizmetin hangi ürüne, işlevselliğe veya şirketin yapısal bölümüne ait olduğunu gösteren işaretleyiciler. Örneğin, meslektaşlarınızın aynı iş birimi için bir hafta önce uygulamaya koyduğu işlevselliği kesip kesmediğinizi hızlı bir şekilde anlamanıza yardımcı olurlar.

VII. Hizmetin sahibi veya sahipleri. Çoğu durumda, bu veya bunlar PaaS kullanılarak otomatik olarak belirlenebilir, ancak güvenli tarafta olmak için geliştiricinin bunları manuel olarak belirtmesini istiyoruz.

Son olarak, kod incelemesine benzer şekilde belgeleri incelemek de iyi bir uygulamadır.

Sürekli Entegrasyon

• Depoların hazırlanması.
• TeamCity'de bir işlem hattı oluşturma.
• Hakların ayarlanması.
• Hizmet sahiplerini arayın. Burada hibrit bir şema var; manuel işaretleme ve PaaS'tan minimum otomasyon. Hizmetler destek için başka bir geliştirme ekibine aktarıldığında veya örneğin hizmet geliştiricisi istifa ettiğinde tam otomatik bir plan başarısız olur.
• Atlas'ta bir hizmetin kaydedilmesi (yukarıyı görmek). Tüm sahipleri ve bağımlılıklarıyla.
• Göçler kontrol ediliyor. Bunlardan herhangi birinin potansiyel olarak tehlikeli olup olmadığını kontrol ediyoruz. Örneğin, bunlardan birinde, hizmetin farklı sürümleri arasındaki veri şemasının uyumluluğunu bozabilecek bir değiştirme tablosu veya başka bir şey açılır. Daha sonra geçiş gerçekleştirilmez, ancak bir aboneliğe yerleştirilir; PaaS, hizmet sahibine kullanımının güvenli olduğu konusunda sinyal vermelidir.

fırında pişirmek

Bir sonraki aşama, dağıtımdan önce hizmetlerin paketlenmesidir.

• Uygulamayı oluşturma. Klasiklere göre - Docker görüntüsünde.
• Hizmetin kendisi ve ilgili kaynaklar için Helm grafiklerinin oluşturulması. Veritabanları ve önbellek için dahil. CLI-push aşamasında oluşturulan app.toml yapılandırmasına uygun olarak otomatik olarak oluşturulurlar.
• Yöneticilerin bağlantı noktalarını açması için bilet oluşturma (Gerektiği zaman).
• Birim testlerini çalıştırma ve kod kapsamını hesaplama. Kod kapsamı belirtilen eşiğin altındaysa, büyük olasılıkla hizmet daha ileri gitmeyecektir - dağıtıma. Kabul edilebilir eşiğindeyse, hizmete "kötüye giden" bir katsayı atanacaktır: daha sonra göstergede zaman içinde herhangi bir iyileşme olmazsa geliştirici, testler açısından ilerleme olmadığına dair bir bildirim alacaktır ( ve bu konuda bir şeyler yapılması gerekiyor).
• Bellek ve CPU sınırlamalarının hesaba katılması. Mikro hizmetleri çoğunlukla Golang'da yazıyoruz ve bunları Kubernetes'te çalıştırıyoruz. Dolayısıyla Golang dilinin özelliğiyle ilgili bir incelik: varsayılan olarak, başlatırken makinedeki tüm çekirdekler kullanılır, GOMAXPROCS değişkenini açıkça ayarlamazsanız ve aynı makinede bu tür birkaç hizmet başlatıldığında, başlarlar kaynaklar için rekabet etmek, birbirlerine müdahale etmek. Aşağıdaki grafikler, uygulamayı çekişme olmadan ve kaynaklar için yarış modunda çalıştırdığınızda yürütme süresinin nasıl değiştiğini gösterir. (Grafiklerin kaynakları burada).

Yürütme süresi, daha az daha iyidir. Maksimum: 643ms, minimum: 42ms. Fotoğraf tıklanabilir.

Ameliyat zamanı, ne kadar az olursa o kadar iyidir. Maksimum: 14091 ns, minimum: 151 ns. Fotoğraf tıklanabilir.

Montaj hazırlık aşamasında bu değişkeni açık olarak ayarlayabilir veya kütüphaneyi kullanabilirsiniz. automaxproc'lar Uber'deki adamlardan.

Dağıtmak

• Kuralların kontrol edilmesi. Hizmet montajlarını hedeflediğiniz ortamlara sunmaya başlamadan önce aşağıdakileri kontrol etmeniz gerekir:
- API uç noktaları.
— API uç noktaları yanıtlarının şemayla uyumluluğu.
— Günlük formatı.
— Hizmete yapılan istekler için başlıkların ayarlanması (şu anda bu netramesh tarafından yapılmaktadır)
— Olay veriyoluna mesaj gönderirken sahip belirtecinin ayarlanması. Bu, otobüsteki hizmetlerin bağlantısını izlemek için gereklidir. Hem hizmetlerin bağlantısını artırmayan (ki bu iyi) veri yoluna idempotent verileri hem de hizmetlerin bağlantısını güçlendiren (ki bu çok kötü!) iş verilerini gönderebilirsiniz. Ve bu bağlantının bir sorun haline geldiği noktada, otobüsü kimin yazıp okuduğunu anlamak, hizmetlerin doğru şekilde ayrılmasına yardımcı olur.

Avito'da henüz çok fazla kongre yok ama havuzları genişliyor. Bu tür anlaşmalar ekibin anlayabileceği ve anlayabileceği bir biçimde ne kadar çok mevcut olursa, mikro hizmetler arasında tutarlılığın sağlanması o kadar kolay olur.

Sentetik testler

• Kapalı döngü testi. Bunun için artık açık kaynak kullanıyoruz Hoverfly.io. İlk önce hizmetteki gerçek yükü kaydeder, ardından kapalı bir döngüde onu taklit eder.

• Stres testi. Tüm hizmetleri optimum performansa getirmeye çalışıyoruz. Ve her hizmetin tüm sürümleri yük testine tabi olmalıdır; bu şekilde hizmetin mevcut performansını ve aynı hizmetin önceki sürümleriyle arasındaki farkı anlayabiliriz. Bir hizmet güncellemesinden sonra performansı bir buçuk kat düşerse, bu, sahipleri için açık bir sinyaldir: kodu derinlemesine incelemeniz ve durumu düzeltmeniz gerekir.
Toplanan verileri örneğin otomatik ölçeklendirmeyi doğru bir şekilde uygulamak ve sonunda hizmetin ne kadar ölçeklenebilir olduğunu genel olarak anlamak için kullanırız.

Yük testi sırasında kaynak tüketiminin belirlenen sınırlara uyup uymadığını kontrol ediyoruz. Ve öncelikle aşırılıklara odaklanıyoruz.

a) Toplam yüke bakıyoruz.
- Çok küçük - yük aniden birkaç kez düşerse büyük olasılıkla hiçbir şey çalışmıyor.
- Çok büyük - optimizasyon gerekli.

b) RPS'ye göre kesime bakıyoruz.
Burada mevcut versiyon ile önceki versiyon arasındaki farka ve toplam miktara bakıyoruz. Örneğin, bir hizmet 100 rps üretiyorsa, ya kötü yazılmıştır ya da bu onun özgüllüğüdür, ancak her durumda bu, hizmete çok yakından bakmak için bir nedendir.
Aksine, çok fazla RPS varsa, o zaman belki bir tür hata vardır ve bazı uç noktalar yükü yürütmeyi durdurmuştur, ancak başka biri basitçe tetiklenmiştir. return true;

Kanarya testleri

Sentetik testleri geçtikten sonra mikro hizmeti az sayıda kullanıcı üzerinde test ediyoruz. Hizmetin hedef kitlesinin %0,1'den az küçük bir payı ile dikkatli bir şekilde başlıyoruz. Bu aşamada doğru teknik ve ürün metriklerinin izlemeye dahil edilmesi, servisteki sorunun en hızlı şekilde gösterilmesi açısından çok önemlidir. Kanarya testi için minimum süre 5 dakika, asıl test ise 2 saattir. Karmaşık hizmetler için saati manuel olarak ayarlıyoruz.
Analiz ediyoruz:
— dile özgü ölçümler, özellikle php-fpm çalışanları;
— Sentry'deki hatalar;
— yanıt durumları;
— Tepki süresi, kesin ve ortalama;
— gecikme;
— işlenmiş ve işlenmemiş istisnalar;
— ürün ölçümleri.

Sıkma Testi

Sıkma Testine “sıkma” testi de denir. Tekniğin adı Netflix'e tanıtıldı. Bunun özü, öncelikle bir örneği başarısızlık noktasına kadar gerçek trafikle doldurmamız ve böylece sınırını belirlememizdir. Sonra başka bir örnek ekliyoruz ve bu çifti tekrar maksimuma yüklüyoruz; ilk “sıkışma” ile tavanlarını ve deltalarını görüyoruz. Ve böylece her seferinde bir örneği birbirine bağlıyoruz ve değişikliklerin modelini hesaplıyoruz.
"Sıkıştırma" yoluyla test verileri aynı zamanda ortak bir metrik veri tabanına akar; burada ya yapay yük sonuçlarını onlarla zenginleştiririz, hatta "sentetikleri" onlarla değiştiririz.

Üretme

• Ölçeklendirme. Bir hizmeti üretime sunduğumuzda, bunun nasıl ölçeklendiğini izliyoruz. Deneyimlerimize göre yalnızca CPU göstergelerini izlemek etkisizdir. RPS karşılaştırmasıyla otomatik ölçeklendirme saf haliyle çalışır, ancak yalnızca çevrimiçi akış gibi belirli hizmetler için çalışır. Bu nedenle öncelikle uygulamaya özel ürün metriklerine bakıyoruz.

Sonuç olarak, ölçeklendirirken şunları analiz ederiz:
- CPU ve RAM göstergeleri,
- kuyruktaki isteklerin sayısı,
- Tepki Süresi,
— birikmiş geçmiş verilere dayalı tahmin.

Bir hizmeti ölçeklendirirken, zincirdeki ilk hizmeti ölçeklendirmememiz ve eriştikleri hizmetin yük altında başarısız olması için bağımlılıklarını izlemek de önemlidir. Hizmet havuzunun tamamı için kabul edilebilir bir yük oluşturmak amacıyla, "en yakın" bağımlı hizmetin geçmiş verilerine bakarız (uygulamaya özel ölçümlerle birlikte CPU ve RAM göstergelerinin birleşimine dayalı olarak) ve bunları geçmiş verilerle karşılaştırırız. başlatma hizmetinin ve "bağımlılık zinciri" boyunca yukarıdan aşağıya doğru devam eder.

Обслуживание

Mikroservis devreye alındıktan sonra ona tetikleyiciler ekleyebiliriz.

Tetikleyicilerin meydana geldiği tipik durumlar şunlardır.
— Potansiyel olarak tehlikeli geçişler tespit edildi.
— Güvenlik güncellemeleri yayınlandı.
— Hizmetin kendisi uzun süredir güncellenmedi.
— Hizmetin yükü gözle görülür biçimde azaldı veya ürün metriklerinden bazıları normal aralığın dışında.
— Hizmet artık yeni platform gereksinimlerini karşılamıyor.

Tetikleyicilerden bazıları işlemin istikrarından sorumludur, bazıları - sistem bakımının bir fonksiyonu olarak - örneğin, bazı hizmetler uzun süredir dağıtılmamıştır ve temel görüntüsü güvenlik kontrollerinden geçmeyi bırakmıştır.

Gösterge Paneli

Kısacası kontrol paneli tüm PaaS'ımızın kontrol panelidir.

• Test kapsamı, görsel sayısı, üretim kopya sayısı, sürümler vb. verilerle birlikte hizmet hakkında tek bir bilgi noktası.
• Verileri hizmetlere ve etiketlere (iş birimlerine ait işaretleyiciler, ürün işlevselliği vb.) göre filtrelemek için bir araç.
• İzleme, günlüğe kaydetme ve izleme için altyapı araçlarıyla entegrasyona yönelik bir araç.
• Tek noktadan hizmet belgeleri.
• Hizmetlerdeki tüm olaylara ilişkin tek bir bakış açısı.

Toplam

Yeni bir geliştirici, PaaS'ı tanıtmadan önce üretimde bir mikro hizmet başlatmak için gerekli tüm araçları anlamak için birkaç hafta harcayabilir: Kubernetes, Helm, dahili TeamCity özelliklerimiz, veritabanlarına ve önbelleklere hataya dayanıklı bir şekilde bağlantılar kurma vb. hızlı başlangıcı okumak ve hizmetin kendisini oluşturmak birkaç saat sürer.

HighLoad++ 2018 için bu konuyla ilgili bir rapor verdim, izleyebilirsiniz video и tanıtım.

Sonuna kadar okuyanlar için bonus parça

Avito olarak geliştiriciler için üç günlük dahili bir eğitim düzenliyoruz. Chris Richardson, mikro hizmet mimarisinde uzman. Bu yazının okuyucularından birine katılma fırsatını vermek istiyoruz. öyle Eğitim programı yayınlandı.

Eğitim 5-7 Ağustos tarihleri ​​arasında Moskova'da gerçekleşecek. Bunlar tamamen dolu olacak çalışma günleridir. Öğle yemeği ve eğitim ofisimizde olacak olup, seçilen katılımcı yol ve konaklama masraflarını kendisi ödeyecektir.

Katılım için başvurabilirsiniz bu Google formunda. Sizden - Eğitime neden katılmanız gerekiyor sorusunun cevabı ve sizinle nasıl iletişime geçeceğinize dair bilgiler. Cevaplarınızı İngilizce olarak verin, çünkü eğitime katılacak katılımcıyı Chris kendisi seçecektir.
Eğitim katılımcısının adını bu gönderiye yapılacak bir güncellemeyle ve geliştiriciler için Avito sosyal ağlarında (AvitoTech) duyuracağız. Фейсбуке, VKontakte, heyecan) en geç 19 Temmuz'a kadar.

Kaynak: habr.com