Banki.ru portalının Operasyon Direktörü Andrey Nikolsky geçen yılki konferansta konuştu Yetim hizmetleri hakkında: Altyapıdaki bir yetimin nasıl tespit edileceği, yetim hizmetlerinin neden kötü olduğu, onlarla ne yapılacağı ve hiçbir şeyin işe yaramaması durumunda ne yapılacağı.
Kesimin altında raporun metin versiyonu bulunmaktadır.
Merhaba meslektaşlarım! Adım Andrey, Banki.ru'da operasyonları yönetiyorum.
Büyük hizmetlerimiz var, bunlar o kadar yekpare hizmetler ki, daha klasik anlamda hizmetler var, çok küçük hizmetler de var. İşçi-köylü terminolojime göre bir hizmet basit ve küçükse mikro, çok basit ve küçük değilse sadece bir hizmettir diyorum.
Hizmetlerin artıları
Hizmetlerin avantajlarından hızlıca geçeceğim.
Birincisi ölçeklendirmedir. Serviste hızlı bir şekilde bir şeyler yapabilir ve üretime başlayabilirsiniz. Trafik aldınız, hizmeti klonladınız. Daha fazla trafiğiniz var, onu klonladınız ve onunla yaşıyorsunuz. Bu iyi bir bonus ve prensip olarak başladığımızda bizim için en önemli şeyin tüm bunları neden yaptığımız olduğu düşünülüyordu.
İkincisi, izole geliştirme; birden fazla geliştirme ekibiniz olduğunda, her ekipte birkaç farklı geliştirici olduğunda ve her ekip kendi hizmetini geliştirdiğinde.
Takımlarda bir nüans var. Geliştiriciler farklıdır. Ve örneğin şunlar var: . Bunu ilk kez Maxim Dorofeev'de gördüm. Bazen kar tanesi insanları bazı takımlarda bulunurken diğerlerinde olmayabilir. Bu, şirket genelinde kullanılan farklı hizmetleri biraz dengesiz hale getiriyor.
Resme bakın: Bu iyi bir geliştirici, büyük elleri var, çok şey yapabilir. Asıl sorun bu ellerin nereden geldiğidir.
Hizmetler, farklı görevlere daha uygun olan farklı programlama dillerinin kullanılmasını mümkün kılar. Bazı hizmetler Go'da, bazıları Erlang'da, bazıları Ruby'de, bazıları PHP'de, bazıları Python'da. Genel olarak çok geniş bir alana genişletebilirsiniz. Burada da nüanslar var.
Hizmet odaklı mimari öncelikle geliştiricilerle ilgilidir. Yani otomasyonunuz yoksa, dağıtım süreciniz de yok, manuel olarak yapılandırırsanız, konfigürasyonlarınız hizmet örneğinden sunucuya değişebilir ve bir şeyler yapmak için oraya gitmeniz gerekir, o zaman cehennemdesiniz demektir.
Örneğin, 20 hizmetiniz var ve elle dağıtmanız gerekiyor, 20 konsolunuz var ve aynı anda bir ninja gibi "enter" tuşuna basıyorsunuz. Bu hiç iyi değil.
Test ettikten sonra bir hizmetiniz varsa (elbette test varsa) ve üretimde çalışması için yine de bir dosyayla bitirmeniz gerekiyorsa, size de kötü bir haberim var.
Belirli Amazon hizmetlerine güveniyorsanız ve Rusya'da çalışıyorsanız, iki ay önce şunu da yaşadınız: "Etrafımdaki her şey yanıyor, ben iyiyim, her şey yolunda."
Dağıtımı otomatikleştirmek için Ansible'ı, yakınsama için Puppet'i, dağıtımı otomatikleştirmek için Bamboo'u ve hepsini bir şekilde açıklamak için Confluence'ı kullanıyoruz.
Bunun üzerinde ayrıntılı olarak durmayacağım çünkü rapor teknik uygulamayla değil daha çok etkileşim uygulamalarıyla ilgili.
Örneğin, sunucudaki Puppet'ın Ruby 2 ile çalışmasıyla ilgili sorunlar yaşadık, ancak bazı uygulamalar Ruby 1.8 için yazılmış ve birlikte çalışmıyorlar. Orada bir şeyler ters gidiyor. Ruby'nin birden fazla sürümünü tek bir makinede çalıştırmanız gerektiğinde genellikle sorun yaşamaya başlarsınız.
Örneğin, her geliştiriciye, yaklaşık olarak sahip olduğumuz her şeyin, geliştirilebilecek tüm hizmetlerin bulunduğu bir platform veriyoruz, böylece izole bir ortama sahip olsun, onu kırabilir ve istediği gibi inşa edebilir.
Orada bir şeyi destekleyen özel olarak derlenmiş bir pakete ihtiyacınız var. Oldukça zor. Docker görüntüsünün 45 GB ağırlığında olduğuna dair bir rapor dinledim. Linux'ta elbette daha basit, orada her şey daha küçük, ama yine de yeterli alan olmayacak.
Projenin bir parçası bir versiyondaki kütüphaneye bağlı olduğunda, projenin başka bir parçası başka bir versiyona bağlı olduğunda ve kütüphaneler hiç birlikte kurulmadığında, çelişkili bağımlılıklar vardır.
PHP 5.6'da sitelerimiz ve hizmetlerimiz var, bunlardan utanıyoruz ama ne yapabiliriz? Bu bizim tek sitemiz. PHP 7'de siteler ve hizmetler var, daha fazlası var, onlardan utanmıyoruz. Ve her geliştiricinin mutlu bir şekilde gördüğü kendi tabanı vardır.
Bir şirkette tek dilde yazıyorsanız geliştirici başına üç sanal makine normal gibi görünür. Farklı programlama dilleriniz varsa durum daha da kötüleşir.
Bu konuda siteleriniz ve hizmetleriniz var, ardından Go için başka bir site, Ruby için bir site ve yanda başka Redis'ler var. Sonuç olarak, tüm bunlar geniş bir destek alanına dönüşür ve her zaman bir kısmı kırılabilir.
Bu nedenle programlama dilinin faydalarını farklı çerçevelerin kullanımıyla değiştirdik, çünkü PHP çerçeveleri oldukça farklıdır, farklı yeteneklere, farklı topluluklara ve farklı desteklere sahiptirler. Ve zaten hazır bir şeye sahip olmak için bir hizmet yazabilirsiniz.
Her servisin kendi ekibi vardır
Birkaç yıldır netleşen temel avantajımız, her hizmetin kendi ekibine sahip olmasıdır. Bu büyük bir proje için uygundur, dokümantasyonda zaman kazanabilirsiniz, yöneticiler projelerini iyi bilir.
Destekten görevleri kolayca gönderebilirsiniz. Örneğin sigorta hizmeti bozuldu. Ve hemen sigortayla ilgilenen ekip sorunu çözmeye gidiyor.
Yeni özellikler hızlı bir şekilde oluşturuluyor çünkü tek bir atomik hizmetiniz olduğunda, ona hızlı bir şekilde bir şeyler vidalayabilirsiniz.
Ve hizmetinizi bozduğunuzda ve bu kaçınılmaz olarak gerçekleştiğinde, diğer insanların hizmetlerini etkilemezsiniz ve diğer ekiplerden geliştiriciler size parçalarla gelip şöyle demezler: "Ay-ay, bunu yapma."
Her zaman olduğu gibi nüanslar var. İstikrarlı ekiplerimiz var, yöneticiler takıma çivilenmiş. Net belgeler var, yöneticiler her şeyi yakından takip ediyor. Yöneticisi olan her ekibin çeşitli hizmetleri vardır ve belirli bir yeterlilik noktası vardır.
Eğer takımlar yüzüyorsa (bazen bunu da kullanırız), “yıldız haritası” denilen güzel bir yöntem var.
Hizmetlerin ve kişilerin bir listesi var. Yıldız işareti kişinin bu hizmette uzman olduğu, kitap ise kişinin bu hizmette eğitim aldığı anlamına gelir. Kişinin görevi kitapçığı yıldız işaretiyle değiştirmektir. Ve eğer hizmetin önünde hiçbir şey yazılmazsa, o zaman daha sonra konuşacağım sorunlar başlar.
Yetim hizmetleri nasıl ortaya çıkıyor?
İlk sorun, altyapınızda yetim hizmeti almanın ilk yolu insanları kovmaktır. Görevler değerlendirilmeden önce bir işletmenin son teslim tarihlerini karşıladığı oldu mu? Bazen son teslim tarihlerinin kısıtlı olduğu ve dokümantasyon için yeterli zamanın olmadığı durumlar olabilir. “Hizmeti üretime aktarmamız lazım, sonra ekleyeceğiz.”
Ekip küçükse, her şeyi yazan bir geliştirici olur, geri kalanı kanatlarda olur. “Temel mimariyi yazdım, arayüzleri ekleyelim.” Sonra bir noktada örneğin yönetici ayrılır. Ve yöneticinin ayrıldığı ve henüz yenisinin atanmadığı bu dönemde, hizmetin nereye gideceğine ve orada neler olacağına geliştiriciler kendileri karar verir. Ve bildiğimiz gibi (birkaç slayt geriye gidelim), bazı takımlarda kar tanesi insanları var, bazen de bir kar tanesi takımının liderliğini yapıyor. Sonra işi bırakıyor ve biz de yetimhane hizmeti alıyoruz.
Aynı zamanda, destekten ve işten gelen görevler ortadan kaybolmaz; birikmiş iş yığınına düşerler. Hizmetin geliştirilmesi sırasında herhangi bir mimari hata varsa, bunlar da birikime eklenir. Hizmet yavaş yavaş kötüleşiyor.
Yetim nasıl anlaşılır?
Bu liste durumu çok iyi açıklıyor. Altyapıları hakkında kim bir şeyler öğrendi?
Belgelenmiş geçici çözümler hakkında: Bir hizmet var ve genel olarak çalışıyor, onunla nasıl çalışılacağına dair iki sayfalık bir kılavuz var, ancak içeride nasıl çalıştığını kimse bilmiyor.
Veya örneğin bir çeşit bağlantı kısaltıcı var. Örneğin, şu anda farklı hizmetlerde farklı amaçlarla kullanılan üç bağlantı kısaltıcımız var. Bunlar sadece sonuçlarıdır.
Artık bariz olanın kaptanı olacağım. Ne yapılmalı? Öncelikle hizmeti başka bir yöneticiye, başka bir ekibe aktarmamız gerekiyor. Eğer takım lideriniz henüz işi bırakmamışsa, bu diğer takıma, hizmetin yetim kaldığını anladığınızda, en azından bu konuda bir şeyler anlayan birini dahil etmeniz gerekir.
Önemli olan: Transfer prosedürlerinin kanla yazılmış olması gerekir. Bizim durumumuzda genellikle bunu izliyorum çünkü hepsinin çalışması gerekiyor. Yöneticiler bunun hızlı bir şekilde teslim edilmesine ihtiyaç duyuyor ve daha sonra ne olacağı onlar için artık o kadar önemli değil.
Yetim yapmanın bir sonraki yolu ise “Dış kaynakla yapacağız, daha hızlı olur, sonra ekibe teslim ederiz.” Takımda herkesin bir takım planları olduğu açık, bir sıra. Çoğu zaman bir ticari müşteri, dış kaynak sağlayıcısının şirketin sahip olduğu teknik departmanla aynı şeyi yapacağını düşünür. Her ne kadar motivasyonları farklı olsa da. Dış kaynak kullanımında tuhaf teknolojik çözümler ve tuhaf algoritmik çözümler var.
Örneğin, beklenmedik yerlerde Sfenks bulunan bir servisimiz vardı. Ne yapmam gerektiğini sana daha sonra anlatacağım.
Dış kaynak sağlayıcıların kendi yazdıkları çerçeveleri vardır. Bu, her türlü şeyi bulabileceğiniz önceki bir projeden kopyala-yapıştır ile sadece çıplak PHP'dir. Bazı dosyalardaki birkaç satırı değiştirmek için bazı karmaşık Bash komut dosyalarını kullanmanız gerektiğinde dağıtım komut dosyaları büyük bir dezavantajdır ve bu dağıtım komut dosyaları üçüncü bir komut dosyası tarafından çağrılır. Sonuç olarak, dağıtım sistemini değiştirirsiniz, başka bir şey seçersiniz, atlarsınız ancak hizmetiniz çalışmaz. Çünkü orada farklı klasörler arasına 8 bağlantı daha koymak gerekiyordu. Veya binlerce kayıt çalışıyor ancak yüz bin kayıt artık çalışmıyor.
Kaptanlığa devam edeceğim. Dışarıdan sağlanan hizmetin kabul edilmesi zorunlu bir prosedürdür. Dışarıdan hizmet alıp da hiçbir yere kabul edilmeyen var mı? Bu elbette yetim servisi kadar popüler değil ama yine de.
Hizmetin kontrol edilmesi gerekiyor, hizmetin gözden geçirilmesi gerekiyor, şifrelerin değiştirilmesi gerekiyor. Bize hizmet verdiklerinde şöyle bir durum yaşadık, admin paneli var “if giriş == ‘admin’ && şifre == ‘admin’...”, doğrudan kodun içinde yazıyor. Oturup düşünüyoruz ve insanlar bunu 2018'de mi yazıyor?
Depolama kapasitesinin test edilmesi de gerekli bir şeydir. Bu hizmeti bir yerde üretime sokmadan önce yüzbinlerce kayıt üzerinde ne olacağına bakmak gerekiyor.
İyileştirme için hizmet göndermede utanılacak bir şey olmamalıdır. “Bu hizmeti kabul etmeyeceğiz, 20 görevimiz var, onları yapın, sonra kabul ederiz” dediğinizde bu normaldir. Yönetici kuruyor olmanız ya da işin boşa para harcaması vicdanınızı incitmesin. İşletme daha sonra daha fazla harcayacak.
Bir pilot projeyi dışarıdan temin etmeye karar verdiğimiz bir durum vardı.
Zamanında teslim edildi ve tek kalite kriteri buydu. Bu yüzden artık pilot bile olmayan bir pilot proje daha yaptık. Bu hizmetler kabul edildi ve idari yollardan, işte kodunuz, işte ekibiniz, işte yöneticiniz dediler. Hizmetler aslında şimdiden kar elde etmeye başladı. Aynı zamanda aslında hala yetimler, nasıl çalıştıklarını kimse anlamıyor ve yöneticiler görevlerini reddetmek için ellerinden geleni yapıyorlar.
Başka bir harika kavram daha var - gerilla gelişimi. Bazı departmanlar, genellikle de pazarlama departmanı, bir hipotezi test etmek istediğinde ve tüm hizmetin dış kaynaklardan sağlanmasını istediğinde. İçine trafik akmaya başlıyor, evrakları kapatıyorlar, müteahhitle evrak imzalıyorlar, devreye girip diyorlar ki: “Arkadaşlar bizim burada bir servisimiz var, zaten trafiği var, bize para getiriyor, kabul edelim.” Biz de "Oppa, bu nasıl olabilir" dedik.
Ve yetim hizmeti almanın başka bir yolu da: Bir takım bir anda kendisini yüklü bulduğunda, yönetim şunu söylüyor: "Bu takımın hizmetini başka bir takıma aktaralım, yükü daha az." Daha sonra üçüncü bir takıma transfer edip teknik direktörü değiştireceğiz. Ve sonunda yine bir yetimimiz oldu.
Yetimlerin sorunu ne?
Kim bilmez ki bu İsveç'te yetiştirilen Wasa zırhlısı, fırlatıldıktan 5 dakika sonra batmasıyla meşhur. Ve bu arada İsveç Kralı bunun için kimseyi idam etmedi. Bu tür gemilerin nasıl inşa edileceğini bilmeyen iki nesil mühendis tarafından inşa edildi. Doğal etki.
Bu arada gemi çok daha kötü bir şekilde batabilirdi, örneğin kral zaten fırtınada bir yere binerken. Ve böylece hemen boğuldu; Agile'a göre erken başarısız olmak iyidir.
Erken başarısız olursak genellikle hiçbir sorun olmaz. Örneğin kabul sırasında revizyona gönderildi. Ancak üretimde başarısız olursak, para yatırıldıktan sonra sorunlar yaşanabilir. İş hayatında bunlara sonuçlar denir.
Yetim hizmetleri neden tehlikelidir:
- Hizmet aniden kesilebilir.
- Servisin tamiri uzun sürüyor veya hiç tamir edilmiyor.
- Güvenlik sorunları.
- İyileştirmeler ve güncellemelerle ilgili sorunlar.
- Önemli bir hizmet bozulursa şirketin itibarı zarar görür.
Yetim hizmetleriyle ilgili ne yapmalı?
Ne yapacağımı bir kez daha tekrarlayacağım. Öncelikle belgelerin olması gerekiyor. Banki.ru'da geçirdiğim 7 yıl bana test uzmanlarının geliştiricilerin sözüne kulak asmaması gerektiğini ve operasyonların da herkesin sözüne kulak vermemesi gerektiğini öğretti. Kontrol etmemiz gerekiyor.
İkinci olarak, etkileşim diyagramları yazmak gerekir, çünkü çok iyi karşılanmayan hizmetler, kimsenin bahsetmediği bağımlılıklar içerir. Örneğin, geliştiriciler hizmeti bazı Yandex.Haritalar veya Datata'ların anahtarlarına yüklediler. Serbest limitiniz doldu, her şey bozuldu ve ne olduğunu hiç bilmiyorsunuz. Bu tür komisyonların tümü açıklanmalıdır: hizmet Dadata, Sms ve başka bir şey kullanır.
Üçüncüsü, teknik borçla çalışmak. Bir çeşit koltuk değneği yaptığınızda ya da bir hizmeti kabul ettiğinizde ve bir şeyin yapılması gerektiğini söylediğinizde, o şeyin yapıldığından emin olmanız gerekir. Çünkü o zaman küçük deliğin o kadar da küçük olmadığı ortaya çıkabilir ve içinden düşebilirsiniz.
Mimari görevlerle birlikte Sfenks ile ilgili bir hikayemiz oldu. Hizmetlerden biri listelere girmek için Sphinx'i kullandı. Sadece sayfalara ayrılmış bir liste ama her gece yeniden indeksleniyordu. İki indeksten oluşuyordu: her gece büyük bir endeks indeksleniyordu ve ona vidalanan küçük bir indeks de vardı. Her gün bombalama ya da bombalamama ihtimali yüzde 50 olan endeks hesaplama sırasında çöktü ve haberlerimiz ana sayfada güncellenmeyi bıraktı. Başlangıçta endeksin yeniden indekslenmesi 5 dakika sürdü, daha sonra endeks büyüdü ve bir noktada yeniden indekslenmesi 40 dakikayı almaya başladı. Bunu kestiğimizde rahat bir nefes aldık çünkü biraz daha zaman geçeceği ve endeksimizin tam zamanlı olarak yeniden indeksleneceği açıktı. Bu, portalımız için bir başarısızlık olacak, sekiz saat boyunca haber yok - işte bu, işler durdu.
Bir yetim servisiyle çalışmayı planlayın
Aslında bunu yapmak çok zordur çünkü devops iletişimle ilgilidir. Meslektaşlarınızla iyi geçinmek istiyorsunuz ve mevzuatla meslektaşlarınızın ve yöneticilerinizin kafasına vurduğunuzda, bunu yapan kişilere karşı çelişkili duygular besleyebilirler.
Tüm bu noktalara ek olarak önemli bir şey daha var: Dağıtım prosedürünün her belirli bölümünden, her belirli hizmetten belirli kişilerin sorumlu olması gerekir. Hiç kimse olmadığında ve tüm bu konuyu incelemek için başka insanları çekmek zorunda kaldığınızda, bu zorlaşır.
Bütün bunlar işe yaramadıysa ve yetim servisiniz hala yetimse, kimse bunu üstlenmek istemiyor, belgeler yazılmamış, bu servise çağrılan ekip herhangi bir şey yapmayı reddediyor, basit bir yol var - yeniden yapmak her şey .
Yani, hizmetin gereksinimlerini yeniden alıyorsunuz ve tuhaf teknolojik çözümler olmadan, daha iyi, daha iyi bir platformda yeni bir hizmet yazıyorsunuz. Ve savaşta ona göç edersiniz.
Yii 1'de bir hizmet aldığımızda bir durum yaşadık ve onu daha fazla geliştiremeyeceğimizi fark ettik çünkü Yii 1'de iyi yazabilen geliştiricilerimiz kalmadı. Tüm geliştiriciler Symfony XNUMX'te iyi yazıyor. Ne yapalım? Zaman ayırdık, bir ekip ayırdık, bir yönetici tahsis ettik, projeyi yeniden yazdık ve sorunsuz bir şekilde trafiği ona aktardık.
Bundan sonra eski hizmet silinebilir. Bu, konfigürasyon yönetim sisteminden bazı hizmetleri alıp temizlemeniz ve ardından geliştiricilerin hiçbir izi kalmaması için üretimdeki tüm arabaların devre dışı bırakıldığını görmeniz gerektiğinde benim en sevdiğim prosedürdür. Depo Git'te kalır.
Konuşmak istediğim tek şey bu, tartışmaya hazırım, konu holivar, pek çok kişi bu konuda yüzdü.
Slaytlarda dilleri birleştirdiğiniz söyleniyordu. Bir örnek, resimlerin yeniden boyutlandırılmasıydı. Bunu kesinlikle tek bir dille sınırlamak gerçekten gerekli mi? Çünkü PHP'de resim yeniden boyutlandırma aslında Golang'da yapılabilir.
Aslında tüm uygulamalar gibi isteğe bağlıdır. Belki bazı durumlarda bu istenmeyen bir durum bile olabilir. Ancak şunu anlamalısınız ki, 50 kişilik bir şirkette teknik departmanınız varsa, bunların 45'i PHP uzmanı, diğer 3'ü ise Python, Ansible, Puppet ve buna benzer şeyleri bilen devops ve bunlardan sadece biri bazı dillerde yazıyor. bir çeşit dil. bazı Go resim yeniden boyutlandırma hizmeti, sonra ayrıldığında uzmanlık da onunla birlikte gelir. Aynı zamanda, özellikle nadir ise, bu dili bilen, pazara özgü bir geliştirici aramanız gerekecektir. Yani örgütsel açıdan bakıldığında bu sorunludur. Devops açısından bakıldığında, hizmetleri dağıtmak için kullandığınız bazı hazır oyun kitaplarını kopyalamanız gerekmeyecek, aynı zamanda bunları yeniden yazmanız gerekecek.
Şu anda Node.js üzerinde bir hizmet geliştiriyoruz ve bu, her geliştiricinin ayrı bir dile sahip olduğu yakın bir platform olacak. Ama oturduk ve oyunun muma değeceğini düşündük. Yani bu sizin oturup düşünmeniz gereken bir soru.
Hizmetlerinizi nasıl takip ediyorsunuz? Günlükleri nasıl topluyor ve izliyorsunuz?
Elasticsearch'te logları toplayıp Kibana'ya koyuyoruz ve üretim ya da test ortamı olmasına göre orada farklı toplayıcılar kullanılıyor. Bir yerde Oduncu, başka bir yerde başka bir şey hatırlamıyorum. Ve bazı servislerde hala Telegraf kurup ayrı ayrı çekim yaptığımız yerler var.
Puppet ve Ansible ile aynı ortamda nasıl yaşanır?
Aslında artık iki ortamımız var, biri Puppet, diğeri Ansible. Bunları hibritleştirmek için çalışıyoruz. Ansible ilk kurulum için iyi bir çerçevedir, Puppet ilk kurulum için kötü bir çerçevedir çünkü doğrudan platform üzerinde uygulamalı çalışma gerektirir ve Puppet yapılandırma yakınsamasını sağlar. Bu, platformun kendisini güncel bir durumda tuttuğu anlamına gelir ve etkisizleştirilmiş makinenin güncel tutulması için, oyun kitaplarını her zaman belirli bir sıklıkta çalıştırmanız gerekir. Fark bu.
Uyumluluğu nasıl koruyorsunuz? Hem Ansible hem de Puppet'ta yapılandırmalarınız var mı?
Bu bizim en büyük acımız, ellerimizle uyumu koruyoruz ve tüm bunları artık bir yerden nasıl devam ettireceğimizi düşünüyoruz. Puppet'ın paketleri dağıttığı ve orada bazı bağlantıları koruduğu ve örneğin Ansible'ın kodu dağıttığı ve en son uygulama yapılandırmalarını orada ayarladığı ortaya çıktı.
Sunum Ruby'nin farklı versiyonları hakkındaydı. Hangi çözüm?
Bununla bir yerde karşılaştık ve bunu sürekli aklımızda tutmamız gerekiyor. Ruby üzerinde çalışan uygulamalarla uyumsuz olan kısmı kapatıp ayrı tuttuk.
Bu yılın konferansı 7 Aralık'ta Teknokent'te gerçekleşecek. 11 Kasım'a kadar rapor başvurularını kabul ediyoruz. konuşmak istersen bize.
Katılımcılar için kayıtlar açıldı, bize katılın!
Kaynak: habr.com