Direktur Operasi portal Banki.ru Andrey Nikolsky berbicara pada konferensi tahun lalu tentang layanan yatim piatu: bagaimana mengidentifikasi anak yatim berdasarkan prasarana, mengapa layanan yatim piatu buruk, apa yang harus dilakukan, dan apa yang harus dilakukan jika tidak ada yang membantu.
Di bawah potongan adalah versi teks dari laporan tersebut.
Halo rekan-rekan! Nama saya Andrey, saya kepala operasi di Banki.ru.
Kami memiliki layanan besar, ini adalah layanan monolitik, ada layanan dalam pengertian yang lebih klasik, dan ada juga yang sangat kecil. Dalam terminologi buruh-tani saya katakan, jika suatu pelayanan itu sederhana dan kecil, maka itu mikro, dan jika tidak terlalu sederhana dan kecil, maka itu hanyalah sebuah pelayanan.
Kelebihan layanan
Saya akan segera membahas keuntungan dari layanan ini.
Yang pertama adalah penskalaan. Anda dapat dengan cepat melakukan sesuatu pada layanan dan memulai produksi. Anda telah menerima lalu lintas, Anda telah mengkloning layanan. Anda memiliki lebih banyak lalu lintas, Anda telah mengkloningnya dan menjalaninya. Ini adalah bonus yang bagus, dan, pada prinsipnya, ketika kami memulai, hal terpenting bagi kami adalah alasan kami melakukan semua ini.
Kedua, pengembangan terisolasi, ketika Anda memiliki beberapa tim pengembangan, beberapa pengembang berbeda di setiap tim, dan setiap tim mengembangkan layanannya sendiri.
Dengan tim, ada perbedaannya. Pengembang berbeda. Dan ada, misalnya, . Saya pertama kali melihat ini dengan Maxim Dorofeev. Terkadang orang-orang kepingan salju ada di beberapa tim dan tidak di tim lain. Hal ini membuat berbagai layanan yang digunakan di seluruh perusahaan menjadi sedikit tidak merata.
Lihat gambarnya: ini adalah pengembang yang baik, dia punya andil besar, dia bisa melakukan banyak hal. Masalah utamanya adalah dari mana tangan ini berasal.
Layanan memungkinkan penggunaan bahasa pemrograman berbeda yang lebih sesuai untuk tugas berbeda. Beberapa layanan ada di Go, ada yang di Erlang, ada yang di Ruby, ada yang di PHP, ada yang di Python. Secara umum, Anda dapat memperluasnya secara luas. Ada nuansa di sini juga.
Arsitektur berorientasi layanan terutama tentang devops. Artinya, jika Anda tidak memiliki otomatisasi, tidak ada proses penerapan, jika Anda mengonfigurasinya secara manual, konfigurasi Anda dapat berubah dari satu instans layanan ke instans lainnya, dan Anda harus pergi ke sana untuk melakukan sesuatu, maka Anda berada di neraka.
Misalnya, Anda memiliki 20 layanan dan Anda perlu menerapkannya secara manual, Anda memiliki 20 konsol, dan Anda secara bersamaan menekan "enter" seperti seorang ninja. Itu tidak terlalu bagus.
Jika Anda memiliki layanan setelah pengujian (jika ada pengujian, tentu saja), dan Anda masih harus menyelesaikannya dengan sebuah file agar dapat berfungsi dalam produksi, saya juga punya kabar buruk untuk Anda.
Jika Anda mengandalkan layanan Amazon tertentu dan bekerja di Rusia, maka dua bulan lalu Anda juga mengalami βSegala sesuatu di sekitar terbakar, saya baik-baik saja, semuanya baik-baik saja.β
Kami menggunakan Ansible untuk mengotomatiskan penerapan, Wayang untuk konvergensi, Bamboo untuk mengotomatiskan penerapan, dan Confluence untuk menjelaskan semuanya.
Saya tidak akan membahasnya secara detail, karena laporan ini lebih banyak membahas praktik interaksi, bukan teknis implementasi.
Misalnya, kami mempunyai masalah ketika Wayang di server bekerja dengan Ruby 2, namun beberapa aplikasi ditulis untuk Ruby 1.8, dan keduanya tidak bekerja sama. Ada yang tidak beres di sana. Dan ketika Anda perlu menjalankan beberapa versi Ruby di satu mesin, biasanya Anda mulai mengalami masalah.
Misalnya, kami memberi setiap pengembang sebuah platform yang di dalamnya terdapat hampir semua yang kami miliki, semua layanan yang dapat dikembangkan, sehingga ia memiliki lingkungan yang terisolasi, ia dapat memecahkannya dan membangunnya sesuai keinginannya.
Kebetulan Anda memerlukan paket yang dikompilasi khusus dengan dukungan untuk sesuatu di sana. Ini cukup sulit. Saya mendengarkan laporan di mana gambar Docker berbobot 45 GB. Di Linux, tentu saja, lebih sederhana, semuanya lebih kecil di sana, tetapi tetap saja, tidak ada cukup ruang.
Ya, ada ketergantungan yang saling bertentangan, ketika satu bagian proyek bergantung pada perpustakaan satu versi, bagian lain dari proyek bergantung pada versi lain, dan perpustakaan tidak diinstal bersama sama sekali.
Kami memiliki situs dan layanan dalam PHP 5.6, kami malu karenanya, tapi apa yang bisa kami lakukan? Ini adalah satu-satunya situs kami. Ada situs dan layanan di PHP 7, masih banyak lagi, kami tidak malu karenanya. Dan setiap pengembang memiliki basisnya sendiri, tempat dia dengan senang hati melihat.
Jika Anda menulis di sebuah perusahaan dalam satu bahasa, maka tiga mesin virtual per pengembang terdengar normal. Jika Anda memiliki bahasa pemrograman yang berbeda, situasinya menjadi lebih buruk.
Anda memiliki situs dan layanan di sini, di sini, lalu situs lain untuk Go, satu situs untuk Ruby, dan beberapa Redis lainnya di sampingnya. Akibatnya, semua ini berubah menjadi ladang dukungan yang luas, dan sewaktu-waktu sebagian darinya bisa pecah.
Oleh karena itu, kami mengganti keunggulan bahasa pemrograman dengan penggunaan kerangka kerja yang berbeda, karena kerangka kerja PHP sangat berbeda, mereka memiliki kemampuan yang berbeda, komunitas yang berbeda, dan dukungan yang berbeda. Dan Anda dapat menulis sebuah layanan sehingga Anda sudah memiliki sesuatu yang siap untuk itu.
Setiap layanan memiliki timnya sendiri
Keuntungan utama kami, yang telah terkristalisasi selama beberapa tahun, adalah setiap layanan memiliki timnya sendiri. Ini nyaman untuk proyek besar, Anda dapat menghemat waktu dalam dokumentasi, manajer mengetahui proyek mereka dengan baik.
Anda dapat dengan mudah mengirimkan tugas dari dukungan. Misalnya, layanan asuransi mogok. Dan segera tim yang menangani asuransi berangkat untuk memperbaikinya.
Fitur-fitur baru dibuat dengan cepat, karena ketika Anda memiliki satu layanan atom, Anda dapat dengan cepat memasukkan sesuatu ke dalamnya.
Dan ketika Anda merusak layanan Anda, dan ini pasti terjadi, Anda tidak memengaruhi layanan orang lain, dan pengembang yang memiliki bagian dari tim lain tidak akan mendatangi Anda dan berkata: βOh, jangan lakukan itu.β
Seperti biasa, ada perbedaannya. Kami memiliki tim yang stabil, manajer terikat pada tim. Ada dokumen yang jelas, manajer memantau semuanya dengan cermat. Setiap tim dengan seorang manajer memiliki beberapa layanan, dan ada titik kompetensi tertentu.
Jika tim mengambang (terkadang kami juga menggunakan ini), ada metode bagus yang disebut βpeta bintangβ.
Anda memiliki daftar layanan dan orang. Tanda bintang berarti orang tersebut ahli dalam jasa tersebut, buku berarti orang tersebut sedang mempelajari jasa tersebut. Tugas orang tersebut adalah mengganti buklet menjadi tanda bintang. Dan jika tidak ada yang tertulis sebelum layanan, maka masalah dimulai, yang akan saya bicarakan lebih lanjut.
Bagaimana layanan anak yatim muncul?
Masalah pertama, cara pertama untuk mendapatkan layanan yatim piatu di infrastruktur Anda adalah dengan memecat orang. Adakah yang pernah memiliki bisnis yang memenuhi tenggat waktu sebelum tugas dinilai? Terkadang tenggat waktu sangat ketat dan waktu untuk dokumentasi tidak cukup. βKami perlu menyerahkan layanan ke produksi, lalu kami akan menambahkannya.β
Kalau timnya kecil, kebetulan ada satu pengembang yang menulis semuanya, sisanya ada di sayap. βSaya menulis arsitektur dasarnya, mari tambahkan antarmuka.β Kemudian pada suatu saat sang manajer, misalnya, pergi. Dan selama periode ini, ketika pengelola telah keluar dan yang baru belum ditunjuk, pengembang sendiri yang memutuskan ke mana arah layanan dan apa yang terjadi di sana. Dan seperti yang kita ketahui (mari kita kembali ke beberapa slide), di beberapa tim terdapat orang-orang kepingan salju, terkadang ada pemimpin tim kepingan salju. Kemudian dia berhenti, dan kami mendapatkan layanan yatim piatu.
Pada saat yang sama, tugas-tugas dari dukungan dan bisnis tidak hilang; malah berakhir di backlog. Jika ada kesalahan arsitektur selama pengembangan layanan, kesalahan tersebut juga akan berakhir di backlog. Layanan ini perlahan memburuk.
Bagaimana cara mengidentifikasi anak yatim piatu?
Daftar ini menggambarkan situasinya dengan baik. Siapa yang belajar sesuatu tentang infrastruktur mereka?
Tentang solusi yang terdokumentasi: ada layanan dan, secara umum, berfungsi, ada manual dua halaman tentang cara bekerja dengannya, tetapi tidak ada yang tahu cara kerjanya di dalam.
Atau misalnya ada semacam pemendek tautan. Misalnya, saat ini kami memiliki tiga penyingkat tautan yang digunakan untuk tujuan berbeda di layanan berbeda. Ini hanyalah konsekuensinya.
Sekarang saya akan menjadi kapten dari hal yang sudah jelas. Apa yang harus dilakukan? Pertama, kita perlu mentransfer layanan ke manajer lain, tim lain. Jika ketua tim Anda belum berhenti, maka di tim lain ini, ketika Anda memahami bahwa layanan itu seperti anak yatim piatu, Anda perlu menyertakan seseorang yang setidaknya memahami sesuatu tentangnya.
Hal utama: Anda harus memiliki prosedur transfer yang ditulis dengan darah. Dalam kasus kami, saya biasanya memantau ini, karena saya memerlukan semuanya agar berfungsi. Manajer memerlukannya untuk disampaikan dengan cepat, dan apa yang terjadi kemudian tidak lagi penting bagi mereka.
Cara membuat yatim piatu selanjutnya adalah βKita outsourcing, biar lebih cepat, nanti kita serahkan ke tim.β Jelas bahwa setiap orang memiliki rencana tertentu dalam tim, suatu giliran. Seringkali pelanggan bisnis berpikir bahwa agen outsourcing akan melakukan hal yang sama seperti departemen teknis yang dimiliki perusahaan. Meski motivasi mereka berbeda. Ada solusi teknologi yang aneh dan solusi algoritmik yang aneh dalam outsourcing.
Misalnya, kami memiliki layanan yang menampilkan Sphinx di berbagai tempat yang tidak terduga. Nanti aku akan memberitahumu apa yang harus kulakukan.
Agen outsourcing memiliki kerangka kerja yang ditulis sendiri. Ini hanyalah PHP dengan copy-paste dari proyek sebelumnya, di mana Anda dapat menemukan segala macam hal. Skrip penerapan adalah kelemahan besar ketika Anda perlu menggunakan beberapa skrip Bash yang rumit untuk mengubah beberapa baris di beberapa file, dan skrip penerapan ini dipanggil oleh skrip ketiga. Akibatnya, Anda mengubah sistem penerapan, memilih yang lain, melompat, tetapi layanan Anda tidak berfungsi. Karena disana perlu memasang 8 link lagi antar folder yang berbeda. Atau kebetulan seribu rekaman berfungsi, tetapi seratus ribu tidak lagi berfungsi.
Saya akan terus menjadi kapten. Menerima layanan outsourcing adalah prosedur wajib. Adakah yang pernah menerima layanan outsourcing dan tidak diterima di mana pun? Tentu saja, ini tidak sepopuler layanan anak yatim piatu, tapi tetap saja.
Layanan perlu diperiksa, layanan perlu ditinjau, kata sandi perlu diubah. Kami punya kasus ketika mereka memberi kami layanan, ada panel admin "if login == 'admin' && password == 'admin'...", itu tertulis tepat di kode. Kami duduk dan berpikir, dan orang-orang menulis ini pada tahun 2018?
Menguji kapasitas penyimpanan juga merupakan hal yang perlu. Anda perlu melihat apa yang akan terjadi pada seratus ribu rekaman, bahkan sebelum Anda memasukkan layanan ini ke dalam produksi di suatu tempat.
Tidak perlu malu mengirimkan layanan untuk perbaikan. Ketika Anda berkata: βKami tidak akan menerima layanan ini, kami memiliki 20 tugas, lakukanlah, maka kami akan menerimanya,β ini normal. Hati nurani Anda tidak boleh terluka oleh kenyataan bahwa Anda sedang mengangkat seorang manajer atau bahwa bisnis Anda membuang-buang uang. Bisnis kemudian akan menghabiskan lebih banyak uang.
Kami punya kasus ketika kami memutuskan untuk melakukan outsourcing proyek percontohan.
Pengirimannya tepat waktu, dan ini adalah satu-satunya kriteria kualitas. Itu sebabnya kami membuat proyek percontohan lain, yang sebenarnya bukan proyek percontohan lagi. Layanan ini diterima, dan melalui jalur administratif mereka berkata, ini kode Anda, ini tim, ini manajer Anda. Layanan tersebut sebenarnya sudah mulai menghasilkan keuntungan. Pada saat yang sama, pada kenyataannya, mereka masih yatim piatu, tidak ada yang mengerti cara mereka bekerja, dan para manajer melakukan yang terbaik untuk memungkiri tugas mereka.
Ada konsep hebat lainnya - pembangunan gerilya. Ketika beberapa departemen, biasanya departemen pemasaran, ingin menguji hipotesis dan memerintahkan seluruh layanan dialihdayakan. Lalu lintas mulai mengalir ke sana, mereka menutup dokumen, menandatangani dokumen dengan kontraktor, mulai beroperasi dan berkata: βBung, kami punya layanan di sini, sudah ada lalu lintas, ini memberi kami uang, mari kita terima.β Kami seperti, βOppa, bagaimana bisa.β
Dan cara lain untuk mendapatkan layanan yatim piatu: ketika sebuah tim tiba-tiba mendapati dirinya dimuat, manajemen berkata: "Mari kita alihkan layanan tim ini ke tim lain, bebannya lebih kecil." Dan kemudian kami akan mentransfernya ke tim ketiga dan mengganti manajer. Dan pada akhirnya kami mempunyai anak yatim piatu lagi.
Apa masalahnya dengan anak yatim piatu?
Siapa yang tak tahu, inilah kapal perang Wasa yang dibesarkan di Swedia yang terkenal tenggelam 5 menit setelah diluncurkan. Dan Raja Swedia, omong-omong, tidak mengeksekusi siapa pun karena ini. Kapal ini dibangun oleh dua generasi insinyur yang tidak tahu cara membuat kapal semacam itu. Efek alami.
Omong-omong, kapal itu bisa saja tenggelam dengan cara yang jauh lebih buruk, misalnya, ketika raja sudah menaikinya di suatu tempat di tengah badai. Makanya, dia langsung tenggelam, menurut Agile ada baiknya gagal lebih awal.
Jika kita gagal lebih awal, biasanya tidak ada masalah. Misalnya pada saat penerimaan dikirim untuk direvisi. Namun jika kita sudah gagal dalam produksi, ketika uang sudah diinvestasikan, maka mungkin akan timbul masalah. Konsekuensi, demikian sebutannya dalam bisnis.
Mengapa layanan anak yatim piatu berbahaya:
- Layanan mungkin tiba-tiba terputus.
- Pelayanannya lama sekali perbaikannya atau tidak diperbaiki sama sekali.
- Masalah keamanan.
- Masalah dengan perbaikan dan pembaruan.
- Jika suatu layanan penting rusak, reputasi perusahaan akan menurun.
Apa yang harus dilakukan dengan layanan anak yatim piatu?
Saya akan mengulangi apa yang harus saya lakukan lagi. Pertama, harus ada dokumentasi. 7 tahun di Banki.ru mengajari saya bahwa penguji tidak boleh mempercayai perkataan pengembang, dan operasi tidak boleh mempercayai perkataan semua orang. Kita perlu memeriksanya.
Kedua, perlu untuk menulis diagram interaksi, karena kebetulan layanan yang diterima dengan buruk mengandung ketergantungan yang tidak disebutkan oleh siapa pun. Misalnya, pengembang memasang layanan pada kunci mereka ke beberapa Yandex.Maps atau Dadata. Anda sudah kehabisan batas bebas, semuanya rusak, dan Anda tidak tahu apa yang terjadi sama sekali. Semua penggaruk tersebut harus dijelaskan: layanan menggunakan Dadata, SMS, dan lainnya.
Ketiga, bekerja dengan utang teknis. Ketika Anda melakukan semacam kruk atau menerima suatu layanan dan mengatakan bahwa sesuatu perlu dilakukan, Anda perlu memastikan bahwa hal itu telah dilakukan. Karena bisa jadi lubang kecil itu ternyata tidak terlalu kecil, dan Anda akan terjatuh ke dalamnya.
Dengan tugas arsitektur, kami punya cerita tentang Sphinx. Salah satu layanan menggunakan Sphinx untuk memasukkan daftar. Hanya daftar halaman, tetapi diindeks ulang setiap malam. Itu dirangkai dari dua indeks: satu indeks besar diindeks setiap malam, dan ada juga indeks kecil yang disekrup ke sana. Setiap hari, dengan kemungkinan 50% terjadi pengeboman atau tidak, indeks jatuh selama penghitungan, dan berita kami berhenti diperbarui di halaman utama. Mula-mula indeks memerlukan waktu 5 menit untuk diindeks ulang, kemudian indeks bertambah, dan pada titik tertentu mulai memerlukan waktu 40 menit untuk diindeks ulang. Ketika kami menghentikan hal ini, kami menarik napas lega, karena jelas bahwa sedikit waktu lagi akan berlalu dan indeks kami akan diindeks ulang secara penuh. Ini akan menjadi kegagalan bagi portal kami, tidak ada berita selama delapan jam - itu saja, bisnis terhenti.
Rencana untuk bekerja dengan layanan yatim piatu
Faktanya, hal ini sangat sulit dilakukan, karena devops adalah tentang komunikasi. Anda ingin menjalin hubungan baik dengan kolega Anda, dan ketika Anda menyerang kolega dan manajer Anda dengan peraturan, mereka mungkin memiliki perasaan yang bertentangan terhadap orang-orang yang melakukan hal ini.
Selain semua poin ini, ada hal penting lainnya: orang-orang tertentu harus bertanggung jawab atas setiap layanan tertentu, untuk setiap bagian tertentu dari prosedur penerapan. Ketika tidak ada orang dan Anda harus menarik beberapa orang lain untuk mempelajari seluruh masalah ini, itu menjadi sulit.
Jika semua ini tidak membantu, dan layanan yatim piatu Anda masih yatim piatu, tidak ada yang mau menerimanya, dokumentasi tidak ditulis, tim yang dipanggil ke layanan ini menolak melakukan apa pun, ada cara sederhana - untuk mengulang semuanya.
Artinya, Anda mengambil persyaratan layanan baru dan menulis layanan baru, lebih baik, pada platform yang lebih baik, tanpa solusi teknologi yang aneh. Dan Anda bermigrasi ke sana dalam pertempuran.
Kami mengalami situasi ketika kami mengambil layanan di Yii 1 dan menyadari bahwa kami tidak dapat mengembangkannya lebih jauh, karena kami kehabisan pengembang yang dapat menulis dengan baik di Yii 1. Semua pengembang menulis dengan baik di Symfony XNUMX. Apa yang harus dilakukan? Kami mengalokasikan waktu, mengalokasikan tim, mengalokasikan manajer, menulis ulang proyek, dan dengan lancar mengalihkan lalu lintas ke sana.
Setelah ini, layanan lama dapat dihapus. Ini adalah prosedur favorit saya, ketika Anda perlu mengambil dan membersihkan beberapa layanan dari sistem manajemen konfigurasi dan kemudian memeriksa dan melihat bahwa semua mobil dalam produksi telah dinonaktifkan, sehingga pengembang tidak memiliki jejak yang tersisa. Repositorinya tetap di Git.
Itu saja yang ingin saya bicarakan, saya siap berdiskusi, topiknya holivar, banyak yang berenang di dalamnya.
Slide tersebut mengatakan bahwa Anda menyatukan bahasa. Contohnya adalah mengubah ukuran gambar. Apakah benar-benar perlu membatasinya hanya pada satu bahasa? Karena pengubahan ukuran gambar di PHP sebenarnya bisa dilakukan di Golang.
Faktanya, ini opsional, seperti semua praktik lainnya. Mungkin, dalam beberapa kasus, hal ini bahkan tidak diinginkan. Namun perlu Anda pahami bahwa jika Anda memiliki departemen teknis di sebuah perusahaan yang terdiri dari 50 orang, 45 di antaranya adalah spesialis PHP, 3 lainnya adalah devops yang mengetahui Python, Ansible, Puppet dan sejenisnya, dan hanya satu dari mereka yang menulis di beberapa jenis bahasa.beberapa layanan pengubahan ukuran gambar Go, lalu ketika hilang, keahlian ikut serta. Dan pada saat yang sama, Anda perlu mencari pengembang khusus pasar yang mengetahui bahasa ini, terutama jika bahasa ini jarang ditemukan. Artinya, dari sudut pandang organisasi, hal ini bermasalah. Dari sudut pandang pengembang, Anda tidak hanya perlu mengkloning beberapa set pedoman siap pakai yang Anda gunakan untuk menerapkan layanan, tetapi Anda juga harus menulis semuanya dari awal lagi.
Kami sedang membangun layanan di Node.js, dan ini hanya akan menjadi platform terdekat untuk setiap pengembang dengan bahasa terpisah. Namun kami duduk dan berpikir bahwa permainan itu sepadan dengan usahanya. Artinya, ini adalah pertanyaan untuk Anda duduki dan pikirkan.
Bagaimana Anda memantau layanan Anda? Bagaimana Anda mengumpulkan dan memantau log?
Kami mengumpulkan log di Elasticsearch dan menaruhnya di Kibana, dan bergantung pada apakah itu lingkungan produksi atau pengujian, kolektor yang berbeda digunakan di sana. Di suatu tempat Lumberjack, di tempat lain, sesuatu yang lain, saya tidak ingat. Dan masih ada beberapa tempat di layanan tertentu di mana kami memasang Telegraf dan memotret di tempat lain secara terpisah.
Bagaimana cara hidup dengan Wayang dan Ansible di lingkungan yang sama?
Faktanya, kami sekarang memiliki dua lingkungan, yang satu adalah Wayang, yang lainnya adalah Ansible. Kami sedang berupaya untuk menghibridisasi mereka. Ansible adalah kerangka kerja yang baik untuk penyiapan awal, Puppet adalah kerangka kerja yang buruk untuk penyiapan awal karena memerlukan pekerjaan langsung langsung di platform, dan Puppet memastikan konvergensi konfigurasi. Ini berarti bahwa platform mempertahankan dirinya dalam keadaan terkini, dan agar mesin yang diaktifkan tetap mutakhir, Anda perlu menjalankan buku pedoman di dalamnya sepanjang waktu dengan frekuensi tertentu. Itulah perbedaannya.
Bagaimana cara menjaga kompatibilitas? Apakah Anda memiliki konfigurasi di Ansible dan Puppet?
Ini adalah penderitaan besar kami, kami menjaga kompatibilitas dengan tangan kami dan memikirkan bagaimana cara untuk melupakan semua ini sekarang. Ternyata Puppet meluncurkan paket dan memelihara beberapa tautan di sana, dan Ansible, misalnya, meluncurkan kode dan menyesuaikan konfigurasi aplikasi terbaru di sana.
Presentasinya tentang berbagai versi Ruby. Solusi apa?
Kami mengalami hal ini di satu tempat, dan kami harus selalu mengingatnya. Kami cukup mematikan bagian yang berjalan di Ruby yang tidak kompatibel dengan aplikasi dan memisahkannya.
Konferensi tahun ini akan berlangsung pada 7 Desember di Technopolis. Kami menerima permohonan laporan hingga 11 November. kami jika Anda ingin berbicara.
Pendaftaran peserta telah dibuka, bergabunglah bersama kami!
Sumber: www.habr.com