hello! Nama saya Vadim Madison, saya mengetuai pembangunan Platform Sistem Avito. Telah dikatakan lebih daripada sekali bagaimana kami dalam syarikat itu beralih daripada seni bina monolitik kepada perkhidmatan mikro. Sudah tiba masanya untuk berkongsi cara kami telah mengubah infrastruktur kami untuk memanfaatkan perkhidmatan mikro sepenuhnya dan mengelakkan diri kami daripada tersesat di dalamnya. Bagaimana PaaS membantu kami di sini, cara kami memudahkan penggunaan dan mengurangkan penciptaan perkhidmatan mikro kepada satu klik - baca terus. Tidak semua yang saya tulis di bawah dilaksanakan sepenuhnya dalam Avito, sebahagian daripadanya adalah cara kami membangunkan platform kami.

(Dan pada akhir artikel ini, saya akan bercakap tentang peluang untuk menghadiri seminar tiga hari daripada pakar seni bina microservice Chris Richardson).

Bagaimana kami datang ke perkhidmatan mikro

Avito ialah salah satu tapak terperingkat terbesar di dunia; lebih daripada 15 juta iklan baharu diterbitkan padanya setiap hari. Bahagian belakang kami menerima lebih daripada 20 ribu permintaan sesaat. Pada masa ini kami mempunyai beberapa ratus perkhidmatan mikro.

Kami telah membina seni bina perkhidmatan mikro selama beberapa tahun sekarang. Bagaimana sebenarnya - rakan sekerja kami secara terperinci diberitahu di bahagian kami di RIT++ 2017. Di CodeFest 2017 (lihat. video), Sergey Orlov dan Mikhail Prokopchuk menerangkan secara terperinci mengapa kami memerlukan peralihan kepada perkhidmatan mikro dan peranan yang dimainkan Kubernetes di sini. Nah, kini kami melakukan segala-galanya untuk meminimumkan kos penskalaan yang wujud dalam seni bina sedemikian.

Pada mulanya, kami tidak mencipta ekosistem yang akan membantu kami membangunkan dan melancarkan perkhidmatan mikro secara menyeluruh. Mereka hanya mengumpulkan penyelesaian sumber terbuka yang wajar, melancarkannya di rumah dan menjemput pembangun untuk menanganinya. Akibatnya, dia pergi ke sedozen tempat (papan pemuka, perkhidmatan dalaman), selepas itu dia menjadi lebih kuat dalam keinginannya untuk memotong kod dengan cara lama, dalam monolit. Warna hijau dalam gambar rajah di bawah menunjukkan perkara yang dilakukan oleh pembangun dengan satu cara atau yang lain dengan tangannya sendiri, dan warna kuning menunjukkan automasi.

Kini dalam utiliti PaaS CLI, perkhidmatan baharu dicipta dengan satu arahan dan pangkalan data baharu ditambah dengan dua lagi dan digunakan ke Stage.

Bagaimana untuk mengatasi era "pemecahan perkhidmatan mikro"

Dengan seni bina monolitik, demi konsistensi perubahan dalam produk, pemaju terpaksa memikirkan apa yang berlaku dengan jiran mereka. Apabila mengusahakan seni bina baharu, konteks perkhidmatan tidak lagi bergantung antara satu sama lain.

Di samping itu, untuk seni bina perkhidmatan mikro menjadi berkesan, banyak proses perlu diwujudkan, iaitu:

• pembalakan;
• meminta pengesanan (Jaeger);
• pengagregatan ralat (Sentri);
• status, mesej, acara daripada Kubernetes (Pemprosesan Strim Acara);
• had perlumbaan / pemutus litar (anda boleh menggunakan Hystrix);
• kawalan ketersambungan perkhidmatan (kami menggunakan Netramesh);
• pemantauan (Grafana);
• perhimpunan (TeamCity);
• komunikasi dan pemberitahuan (Slack, e-mel);
• pengesanan tugas; (Jira)
• penyediaan dokumentasi.

Untuk memastikan sistem tidak kehilangan integritinya dan kekal berkesan semasa ia meningkat, kami memikirkan semula organisasi perkhidmatan mikro di Avito.

Cara kami mengurus perkhidmatan mikro

Bantuan berikut untuk melaksanakan "dasar parti" bersatu antara banyak perkhidmatan mikro Avito:

• membahagikan infrastruktur kepada lapisan;
• Konsep Platform sebagai Perkhidmatan (PaaS);
• memantau semua yang berlaku dengan perkhidmatan mikro.

Lapisan abstraksi infrastruktur merangkumi tiga lapisan. Mari kita pergi dari atas ke bawah.

A. Atas - jaringan perkhidmatan. Pada mulanya kami mencuba Istio, tetapi ternyata ia menggunakan terlalu banyak sumber, yang terlalu mahal untuk jumlah kami. Oleh itu, jurutera kanan dalam pasukan seni bina Alexander Lukyanchenko membangunkan penyelesaiannya sendiri - Netramesh (tersedia dalam Sumber Terbuka), yang kini kami gunakan dalam pengeluaran dan yang menggunakan sumber beberapa kali lebih sedikit daripada Istio (tetapi tidak melakukan semua yang boleh dibanggakan oleh Istio).
B. Sederhana - Kubernetes. Kami menggunakan dan mengendalikan perkhidmatan mikro padanya.
C. Bawah - logam kosong. Kami tidak menggunakan awan atau perkara seperti OpenStack, tetapi bergantung sepenuhnya pada logam kosong.

Semua lapisan digabungkan oleh PaaS. Dan platform ini pula terdiri daripada tiga bahagian.

I. Penjana, dikawal melalui utiliti CLI. Dialah yang membantu pembangun mencipta perkhidmatan mikro dengan cara yang betul dan dengan usaha yang minimum.

II. Pengumpul disatukan dengan kawalan semua alatan melalui papan pemuka biasa.

III. Penyimpanan. Berhubung dengan penjadual yang menetapkan pencetus secara automatik untuk tindakan penting. Terima kasih kepada sistem sebegitu, tiada satu pun tugas yang terlepas hanya kerana seseorang terlupa untuk menyediakan tugasan di Jira. Kami menggunakan alat dalaman yang dipanggil Atlas untuk ini.

Pelaksanaan perkhidmatan mikro dalam Avito juga dijalankan mengikut skema tunggal, yang memudahkan kawalan ke atasnya pada setiap peringkat pembangunan dan pelepasan.

Bagaimanakah saluran paip pembangunan perkhidmatan mikro standard berfungsi?

Secara umum, rantaian penciptaan perkhidmatan mikro kelihatan seperti ini:

CLI-push → Integrasi Berterusan → Bakar → Deploy → Ujian buatan → Ujian kanari → Ujian Picit → Pengeluaran → Penyelenggaraan.

Mari kita lalui dengan tepat dalam susunan ini.

CLI-tolak

• Mencipta perkhidmatan mikro.
Kami bergelut untuk masa yang lama untuk mengajar setiap pembangun cara melakukan perkhidmatan mikro. Ini termasuk menulis arahan terperinci dalam Confluence. Tetapi skim itu berubah dan ditambah. Hasilnya ialah kesesakan muncul pada permulaan perjalanan: ia mengambil lebih banyak masa untuk melancarkan perkhidmatan mikro, dan masalah sering timbul semasa penciptaannya.

Pada akhirnya, kami membina utiliti CLI ringkas yang mengautomasikan langkah asas semasa membuat perkhidmatan mikro. Malah, ia menggantikan tolakan git pertama. Inilah sebenarnya yang dia lakukan.

— Mencipta perkhidmatan mengikut templat — langkah demi langkah, dalam mod “wizard”. Kami mempunyai templat untuk bahasa pengaturcaraan utama dalam bahagian belakang Avito: PHP, Golang dan Python.

- Satu arahan pada satu masa menggunakan persekitaran untuk pembangunan tempatan pada mesin tertentu - Minikube dilancarkan, Carta Helm dijana secara automatik dan dilancarkan dalam kubernet tempatan.

— Menyambung pangkalan data yang diperlukan. Pembangun tidak perlu mengetahui IP, log masuk dan kata laluan untuk mendapatkan akses kepada pangkalan data yang dia perlukan - sama ada secara tempatan, di Peringkat, atau dalam pengeluaran. Selain itu, pangkalan data digunakan serta-merta dalam konfigurasi toleran kesalahan dan dengan pengimbangan.

— Ia melakukan perhimpunan langsung itu sendiri. Katakan pembangun membetulkan sesuatu dalam perkhidmatan mikro melalui IDEnya. Utiliti melihat perubahan dalam sistem fail dan, berdasarkannya, membina semula aplikasi (untuk Golang) dan dimulakan semula. Untuk PHP, kami hanya memajukan direktori di dalam kiub dan di sana muat semula langsung diperolehi "secara automatik".

— Menghasilkan autotest. Dalam bentuk kosong, tetapi agak sesuai untuk digunakan.

• Penggunaan perkhidmatan mikro.

Menggunakan perkhidmatan mikro dahulunya agak menyusahkan kami. Perkara berikut diperlukan:

I. Dockerfile.

II. Konfigurasi.
III. Carta helm, yang itu sendiri menyusahkan dan termasuk:

— carta itu sendiri;
— templat;
— nilai khusus dengan mengambil kira persekitaran yang berbeza.

Kami telah menghilangkan rasa sakit daripada mengolah semula manifes Kubernetes supaya ia kini dijana secara automatik. Tetapi yang paling penting, mereka memudahkan penggunaan sehingga had. Mulai sekarang kami mempunyai Dockerfile, dan pembangun menulis keseluruhan konfigurasi dalam satu fail app.toml pendek.

Ya, dan dalam app.toml sendiri tiada apa-apa yang perlu dilakukan selama satu minit. Kami menentukan di mana dan berapa banyak salinan perkhidmatan untuk dibangkitkan (pada pelayan pembangun, pada pementasan, dalam pengeluaran), dan menunjukkan kebergantungannya. Perhatikan saiz garisan = "kecil" dalam blok [enjin]. Ini adalah had yang akan diperuntukkan kepada perkhidmatan melalui Kubernetes.

Kemudian, berdasarkan konfigurasi, semua carta Helm yang diperlukan dijana secara automatik dan sambungan ke pangkalan data dibuat.

• Pengesahan asas. Pemeriksaan sedemikian juga automatik.
Perlu menjejaki:
— adakah terdapat Dockerfile;
— adakah terdapat app.toml;
— adakah dokumentasi tersedia?
— adakah pergantungan itu teratur?
— sama ada peraturan amaran telah ditetapkan.
Hingga ke titik terakhir: pemilik perkhidmatan itu sendiri menentukan metrik produk yang hendak dipantau.

• Penyediaan dokumentasi.
Masih kawasan masalah. Nampaknya ia adalah yang paling jelas, tetapi pada masa yang sama ia juga merupakan rekod "sering dilupakan", dan oleh itu pautan yang terdedah dalam rantaian.
Perlu ada dokumentasi untuk setiap perkhidmatan mikro. Ia termasuk blok berikut.

I. Penerangan ringkas tentang perkhidmatan. Secara harfiah beberapa ayat tentang apa yang dilakukannya dan mengapa ia diperlukan.

II. Pautan gambar rajah seni bina. Adalah penting bahawa dengan sepintas lalu ia mudah difahami, contohnya, sama ada anda menggunakan Redis untuk caching atau sebagai stor data utama dalam mod berterusan. Di Avito buat masa ini, ini adalah pautan ke Confluence.

III. Buku larian. Panduan ringkas untuk memulakan perkhidmatan dan kerumitan pengendaliannya.

IV. Soalan Lazim, adalah baik untuk menjangkakan masalah yang mungkin dihadapi oleh rakan sekerja anda semasa bekerja dengan perkhidmatan tersebut.

V. Penerangan tentang titik akhir untuk API. Jika tiba-tiba anda tidak menyatakan destinasi, rakan sekerja yang perkhidmatan mikronya berkaitan dengan anda hampir pasti akan membayarnya. Sekarang kami menggunakan Swagger dan penyelesaian kami dipanggil ringkas untuk ini.

VI. Label. Atau penanda yang menunjukkan produk, fungsi atau bahagian struktur syarikat milik perkhidmatan itu. Mereka membantu anda memahami dengan cepat, sebagai contoh, sama ada anda memotong fungsi yang dilancarkan oleh rakan sekerja anda untuk unit perniagaan yang sama seminggu yang lalu.

VII. Pemilik atau pemilik perkhidmatan. Dalam kebanyakan kes, ia — atau mereka — boleh ditentukan secara automatik menggunakan PaaS, tetapi untuk berada di bahagian yang selamat, kami memerlukan pembangun untuk menentukannya secara manual.

Akhir sekali, adalah amalan yang baik untuk menyemak dokumentasi, sama seperti semakan kod.

Integrasi Berterusan

• Menyediakan repositori.
• Mencipta saluran paip dalam TeamCity.
• Menetapkan hak.
• Cari pemilik perkhidmatan. Terdapat skema hibrid di sini - penandaan manual dan automasi minimum daripada PaaS. Skim automatik sepenuhnya gagal apabila perkhidmatan dipindahkan untuk sokongan kepada pasukan pembangunan lain atau, sebagai contoh, jika pemaju perkhidmatan berhenti.
• Mendaftarkan perkhidmatan di Atlas (lihat di atas). Dengan semua pemilik dan tanggungannya.
• Menyemak migrasi. Kami menyemak sama ada mana-mana daripadanya berpotensi berbahaya. Sebagai contoh, dalam salah satu daripadanya jadual alter atau sesuatu yang lain muncul yang boleh memecahkan keserasian skema data antara versi perkhidmatan yang berbeza. Kemudian migrasi tidak dilakukan, tetapi diletakkan dalam langganan - PaaS mesti memberi isyarat kepada pemilik perkhidmatan apabila selamat untuk menggunakannya.

Bakar

Peringkat seterusnya ialah perkhidmatan pembungkusan sebelum penggunaan.

• Membina aplikasi. Menurut klasik - dalam imej Docker.
• Penjanaan carta Helm untuk perkhidmatan itu sendiri dan sumber berkaitan. Termasuk untuk pangkalan data dan cache. Ia dibuat secara automatik mengikut konfigurasi app.toml yang dijana pada peringkat CLI-push.
• Mencipta tiket untuk pentadbir membuka port (apabila diperlukan).
• Menjalankan ujian unit dan mengira liputan kod. Jika liputan kod berada di bawah ambang yang ditentukan, kemungkinan besar perkhidmatan itu tidak akan pergi lebih jauh - ke penggunaan. Sekiranya ia berada di ambang boleh diterima, maka perkhidmatan itu akan diberikan pekali "pesimisme": kemudian, jika tiada peningkatan dalam penunjuk dari masa ke masa, pemaju akan menerima pemberitahuan bahawa tidak ada kemajuan dari segi ujian ( dan sesuatu perlu dilakukan mengenainya).
• Perakaunan untuk had memori dan CPU. Kami terutamanya menulis perkhidmatan mikro di Golang dan menjalankannya dalam Kubernetes. Oleh itu satu kehalusan yang dikaitkan dengan keanehan bahasa Golang: secara lalai, apabila dimulakan, semua teras pada mesin digunakan, jika anda tidak menetapkan pembolehubah GOMAXPROCS secara eksplisit, dan apabila beberapa perkhidmatan sedemikian dilancarkan pada mesin yang sama, ia akan bermula untuk bersaing untuk mendapatkan sumber, campur tangan antara satu sama lain. Graf di bawah menunjukkan cara masa pelaksanaan berubah jika anda menjalankan aplikasi tanpa pertikaian dan dalam perlumbaan untuk mod sumber. (Sumber graf ialah di sini).

Masa pelaksanaan, kurang adalah lebih baik. Maksimum: 643ms, minimum: 42ms. Foto boleh diklik.

Masa untuk pembedahan, kurang adalah lebih baik. Maksimum: 14091 ns, minimum: 151 ns. Foto boleh diklik.

Pada peringkat penyediaan pemasangan, anda boleh menetapkan pembolehubah ini secara eksplisit atau anda boleh menggunakan perpustakaan automaxprocs daripada lelaki dari Uber.

Sebarkan

• Menyemak konvensyen. Sebelum anda mula menghantar pemasangan perkhidmatan ke persekitaran yang anda inginkan, anda perlu menyemak perkara berikut:
- Titik akhir API.
— Pematuhan respons titik akhir API dengan skema.
— Format log.
— Menetapkan pengepala untuk permintaan kepada perkhidmatan (pada masa ini ini dilakukan oleh netramesh)
— Menetapkan token pemilik semasa menghantar mesej ke bas acara. Ini diperlukan untuk menjejaki ketersambungan perkhidmatan di seluruh bas. Anda boleh menghantar kedua-dua data idempoten ke bas, yang tidak meningkatkan ketersambungan perkhidmatan (yang bagus), dan data perniagaan yang mengukuhkan ketersambungan perkhidmatan (yang sangat buruk!). Dan apabila ketersambungan ini menjadi isu, memahami siapa yang menulis dan membaca bas membantu memisahkan perkhidmatan dengan betul.

Belum ada banyak konvensyen di Avito, tetapi kumpulan mereka semakin berkembang. Lebih banyak perjanjian sedemikian tersedia dalam bentuk yang boleh difahami dan difahami oleh pasukan, lebih mudah untuk mengekalkan konsistensi antara perkhidmatan mikro.

Ujian sintetik

• Ujian gelung tertutup. Untuk ini kami kini menggunakan sumber terbuka Hoverfly.io. Pertama, ia merekodkan beban sebenar pada perkhidmatan, kemudian - hanya dalam gelung tertutup - ia menirunya.

• Ujian Tekanan. Kami cuba membawa semua perkhidmatan ke prestasi optimum. Dan semua versi setiap perkhidmatan mesti tertakluk kepada ujian beban - dengan cara ini kita boleh memahami prestasi semasa perkhidmatan dan perbezaan dengan versi perkhidmatan yang sama sebelumnya. Jika, selepas kemas kini perkhidmatan, prestasinya menurun sebanyak satu setengah kali, ini adalah isyarat yang jelas untuk pemiliknya: anda perlu menggali kod dan membetulkan keadaan.
Kami menggunakan data yang dikumpul, sebagai contoh, untuk melaksanakan penskalaan automatik dengan betul dan, pada akhirnya, secara amnya memahami betapa berskala perkhidmatan itu.

Semasa ujian beban, kami menyemak sama ada penggunaan sumber memenuhi had yang ditetapkan. Dan kami memberi tumpuan terutamanya kepada keterlaluan.

a) Kami melihat jumlah beban.
- Terlalu kecil - kemungkinan besar sesuatu tidak berfungsi sama sekali jika beban tiba-tiba turun beberapa kali.
- Terlalu besar - pengoptimuman diperlukan.

b) Kami melihat potongan mengikut RPS.
Di sini kita melihat perbezaan antara versi semasa dan yang sebelumnya dan jumlah kuantiti. Sebagai contoh, jika perkhidmatan menghasilkan 100 rps, maka ia sama ada ditulis dengan buruk, atau ini adalah kekhususannya, tetapi dalam apa jua keadaan, ini adalah sebab untuk melihat perkhidmatan dengan teliti.
Jika, sebaliknya, terdapat terlalu banyak RPS, maka mungkin terdapat beberapa jenis pepijat dan beberapa titik akhir telah berhenti melaksanakan muatan, tetapi beberapa yang lain hanya dicetuskan return true;

Ujian kanari

Selepas kami lulus ujian sintetik, kami menguji perkhidmatan mikro pada sebilangan kecil pengguna. Kami bermula dengan berhati-hati, dengan sebahagian kecil daripada khalayak sasaran perkhidmatan - kurang daripada 0,1%. Pada peringkat ini, adalah sangat penting bahawa metrik teknikal dan produk yang betul dimasukkan dalam pemantauan supaya ia menunjukkan masalah dalam perkhidmatan secepat mungkin. Masa minimum untuk ujian kenari ialah 5 minit, yang utama ialah 2 jam. Untuk perkhidmatan yang kompleks, kami menetapkan masa secara manual.
Mari analisa:
— metrik khusus bahasa, khususnya, pekerja php-fpm;
— ralat dalam Sentry;
- status tindak balas;
— masa tindak balas, tepat dan purata;
- kependaman;
— pengecualian, diproses dan tidak dikendalikan;
- metrik produk.

Ujian Picit

Ujian Squeeze juga dipanggil ujian "squeezing". Nama teknik itu diperkenalkan ke Netflix. Intipatinya ialah mula-mula kita mengisi satu kejadian dengan trafik sebenar hingga ke tahap kegagalan dan dengan itu menetapkan hadnya. Kemudian kami menambah contoh lain dan memuatkan pasangan ini - sekali lagi kepada maksimum; kita melihat siling dan delta mereka dengan "squeeze" pertama. Oleh itu, kami menyambungkan satu kejadian pada satu masa dan mengira corak perubahan.
Data ujian melalui "memerah" juga mengalir ke pangkalan data metrik biasa, di mana kami sama ada memperkayakan hasil beban buatan dengannya, atau malah menggantikan "sintetik" dengannya.

Pengeluaran

• Penskalaan. Apabila kami melancarkan perkhidmatan kepada pengeluaran, kami memantau cara ia berskala. Dalam pengalaman kami, pemantauan hanya penunjuk CPU tidak berkesan. Penskalaan automatik dengan penanda aras RPS dalam bentuk tulen berfungsi, tetapi hanya untuk perkhidmatan tertentu, seperti penstriman dalam talian. Jadi kita melihat dahulu pada metrik produk khusus aplikasi.

Akibatnya, apabila penskalaan kami menganalisis:
- Penunjuk CPU dan RAM,
— bilangan permintaan dalam baris gilir,
- masa tindak balas,
— ramalan berdasarkan data sejarah terkumpul.

Semasa menskala perkhidmatan, adalah penting juga untuk memantau kebergantungannya supaya kami tidak menskalakan perkhidmatan pertama dalam rantaian, dan perkhidmatan yang diakses gagal di bawah beban. Untuk mewujudkan beban yang boleh diterima bagi keseluruhan kumpulan perkhidmatan, kami melihat data sejarah perkhidmatan bergantung "terdekat" (berdasarkan gabungan penunjuk CPU dan RAM, ditambah dengan metrik khusus apl) dan membandingkannya dengan data sejarah perkhidmatan permulaan, dan seterusnya sepanjang “rantaian pergantungan” ", dari atas ke bawah.

Perkhidmatan

Selepas perkhidmatan mikro digunakan, kami boleh melampirkan pencetus padanya.

Berikut ialah situasi biasa di mana pencetus berlaku.
— Penghijrahan yang berpotensi berbahaya dikesan.
— Kemas kini keselamatan telah dikeluarkan.
— Perkhidmatan itu sendiri tidak dikemas kini untuk masa yang lama.
— Beban pada perkhidmatan telah berkurangan dengan ketara atau beberapa metrik produknya berada di luar julat biasa.
— Perkhidmatan tidak lagi memenuhi keperluan platform baharu.

Beberapa pencetus bertanggungjawab untuk kestabilan operasi, sesetengahnya - sebagai fungsi penyelenggaraan sistem - contohnya, sesetengah perkhidmatan tidak digunakan untuk masa yang lama dan imej asasnya telah berhenti lulus pemeriksaan keselamatan.

Papan pemuka

Ringkasnya, papan pemuka ialah panel kawalan keseluruhan PaaS kami.

• Satu titik maklumat tentang perkhidmatan, dengan data tentang liputan ujiannya, bilangan imejnya, bilangan salinan pengeluaran, versi, dsb.
• Alat untuk menapis data mengikut perkhidmatan dan label (penanda kepunyaan unit perniagaan, fungsi produk, dsb.)
• Alat untuk penyepaduan dengan alat infrastruktur untuk mengesan, mengelog dan memantau.
• Satu titik dokumentasi perkhidmatan.
• Satu sudut pandangan bagi semua acara merentas perkhidmatan.

Dalam jumlah

Sebelum memperkenalkan PaaS, pembangun baharu boleh menghabiskan masa beberapa minggu untuk memahami semua alatan yang diperlukan untuk melancarkan perkhidmatan mikro dalam pengeluaran: Kubernetes, Helm, ciri TeamCity dalaman kami, menyediakan sambungan ke pangkalan data dan cache dengan cara yang tahan terhadap kesalahan, dsb. Kini ia mengambil masa beberapa jam untuk membaca permulaan pantas dan mencipta perkhidmatan itu sendiri.

Saya memberikan laporan mengenai topik ini untuk HighLoad++ 2018, anda boleh menontonnya video и pembentangan.

Lagu bonus untuk mereka yang membaca hingga habis

Kami di Avito menganjurkan latihan dalaman selama tiga hari untuk pembangun dari Chris Richardson, pakar dalam seni bina perkhidmatan mikro. Kami ingin memberi peluang untuk menyertainya kepada salah seorang pembaca siaran ini. ia adalah Program latihan telah disiarkan.

Latihan itu akan berlangsung dari 5 hingga 7 Ogos di Moscow. Ini adalah hari bekerja yang akan diduduki sepenuhnya. Makan tengah hari dan latihan akan berada di pejabat kami, dan peserta yang dipilih akan membayar sendiri perjalanan dan penginapan.

Anda boleh memohon penyertaan dalam google form ini. Daripada anda - jawapan kepada soalan mengapa anda perlu menghadiri latihan dan maklumat tentang cara menghubungi anda. Jawab dalam bahasa Inggeris, kerana Chris akan memilih peserta yang akan menghadiri latihan itu sendiri.
Kami akan mengumumkan nama peserta latihan dalam kemas kini siaran ini dan pada rangkaian sosial Avito untuk pembangun (AvitoTech dalam Фейсбуке, Vkontakte, Twitter) selewat-lewatnya pada 19 Julai.

Sumber: www.habr.com