Banki.ru portal's Operations Director Andrey Nikolsky spoke at last year's conference about orphan services: how to identify orphans in the infrastructure, what problems orphan services cause, what to do with them, and how to act if nothing helps.
Below is the text version of the report.
Hello, colleagues! My name is Andrey, and I oversee operations at Banki.ru.
We have large services, such as monolithic services, some that are more classically understood, and very small ones. In my working-class terminology, I say that if a service is simple and small, it’s micro, and if it’s not very simple and not small, then it’s just a service.
Advantages of services
Let me quickly run through the advantages of services.
First — scalability. You can quickly set something up on a service and go live. Traffic comes in, you clone the service. More traffic arrives, you clone it again and manage with that. This is a great bonus, and when we started, it was considered our most important reason for doing all this.
Secondly, isolated development, where you have several development teams, several different developers in each team, and each team is working on its own service.
There are nuances with teams. Developers can be quite diverse. For example, there are . I first saw this concept from Maxim Dorofeev. Sometimes, snowflake people exist in some teams and not in others. This results in the services used within the company being somewhat uneven.
Look at the picture: this is a good developer, with big hands, he can do a lot. The main problem is where these hands are coming from.
Services allow using different programming languages that are better suited for different tasks. Some services in Go, some in Erlang, some in Ruby, some in PHP, some in Python. Overall, there is a wide array of options. There are also nuances here.
Service-oriented architecture is primarily about devops. That is, if you don't have automation, no deployment process, and if you're setting things up manually, your configurations might change from one service instance to another, and you have to go in and make adjustments, then you're in hell.
Məsələn, əgər sizin 20 xidmətiniz varsa və onları əl ilə tətbiq etməlisinizsə, 20 konsolunuz var və eyni anda "enter" düyməsinə basırsınız, bu, o qədər də yaxşı deyil.
Əgər xidmətiniz testdən keçdisə (əgər test varsa, əlbəttə), və onu istehsalata daldırmaq üçün hələ də düzəlişlər etməlisinizsə, sizin üçün də pis xəbərlərim var.
Əgər siz Amazonun spesifik xidmətlərinə bel bağlayırsınızsa və bunu Rusiyada edirsinizsə, iki ay öncə sizin də "Hər şey alovlanır, mən yaxşıyam, hər şey superdir" deməyiniz mümkün idi.
Biz Ansible-dan dağıtımın avtomatlaşdırılması üçün, Puppet-dən konvergensiya üçün, Bamboo-dan tətbiqatın avtomatlaşdırılması üçün, Confluence-dən isə bunları bir şəkildə təsvir etmək üçün istifadə edirik.
Buna daha ətraflı toxunmayacam, çünki təqdimat daha çox qarşılıqlı əlaqələr praktikası haqqında, texniki icraatı haqqında deyil.
Məsələn, bir dəfə bizdə problem oldu ki, Puppet serverdə Ruby 2 ilə işləyir, amma bir tətbiq Ruby 1.8 üçün yazılıb və onlar bir yerdə işləmirlər. Orada bir problem yaranır. Həmçinin, bir maşında bir neçə Ruby versiyasını saxlamağınız lazım olanda, adətən çətinliklər yaranır.
Məsələn, hər bir inkişaf etdiriciyə, inkişaf etdirə biləcəyi bütün xidmətləri, izolyasiya edilmiş mühitdə qırıb-yıxa biləcəyi bir platforma veririk.
Bəzən, xüsusi bir dəstək üçün xüsusi tərtib edilmiş paketə ehtiyac ola bilər. Bu, olduqca çətindir. Mən docker imici 45 GB olan bir təqdimata qulaq asdım. Linux-da əlbəttə ki, daha asandır, orada hər şey kiçikdir, amma yenə də, heç bir yer çatmayacaq.
Və bəzi ziddiyyətli asılılıqlar olur, bir layihə hissəsi bir versiyalı kitabxanadan asılıdır, digəri isə başqa versiyalı kitabxanadan asılıdır, amma kitabxanalar birlikdə quraşdıra bilmir.
Bizim PHP 5.6-da saytlarımız və xidmətlərimiz var, onlara görə utanırıq, amma nə eləyək. Bu, bizim bir platformadır. PHP 7-də daha çox saytlarımız və xidmətlərimiz var, onlara görə utanmırıq. Hər bir inkişaf etdiricinin öz mini verilənlər bazası var, orada sevinclə işləyir.
Əgər şirkətdə bir dildə yazırsınızsa, o zaman hər inkişaf etdirici üçün üç virtual maşın normaldır. Əgər sizdə müxtəlif proqramlaşdırma dilləri varsa, vəziyyət daha da ağırlaşır.
Sizin xidmətləriniz və saytlarınız var, daha sonra bir Go platforması, bir Ruby platforması, və yan tərəfdə başqa bir Redis. Nəticədə, bunlar hamısı böyük bir dəstək sahəsinə çevrilir, və daima bunlardan biri qırılma riski daşıyır.
Buna görə də biz proqramlaşdırma dili üstünlüklərini müxtəlif çərçivələrin istifadəsi ilə əvəz etdik, çünki PHP çərçivələri kifayət qədər fərqlidir, onların müxtəlif imkanları, müxtəlif icmaları və müxtəlif dəstəkləri var. Beləliklə, xidmətinizi yazmaq mümkündür ki, artıq ona uyğun bir şeyiniz olsun.
Hər xidmətin öz komandası var.
Bizim ildə altıraşan ən böyük üstünlüyümüz — hər xidmətin öz komandası olmasındadır. Bu, böyük layihə üçün rahatdır, sənədləşdirməyə vaxt qazana bilərsiniz, menecerlər layihələrini yaxşı başa düşürlər.
Dəstək məsələləri asanlıqla həll olunur. Məsələn, sığorta xidməti qırıldı. Və dərhal, sığorta ilə məşğul olan komanda onu düzəltməyə gedir.
Yeni xüsusiyyətlər tez bir zamanda hazırlanır, çünki bir atomar xidmətiniz olduqda, içərisinə operativ olaraq bir şey qura bilərsiniz.
Və xidmətinizi qırdığınızda, bu qaçınılmazdır, başqa xidmətləri təsirləndirmirsiniz, və sizə digər komandaların proqramçıları gəlmirlər və demirlər: «Ay-ay, belə etməyin».
Hər zaman incəliklər vardır. Bizim stabillik qruplarımız var, menecerlər komandaya yığılmışdır. Aydın sənədlər var, menecerlər buna diqqətlə nəzarət edirlər. Hər komandada menecerlə bir neçə xidmət var və konkret bir kompetensiya nöqtəsi var.
Əgər komandalar dəyişkəndirsə (bu da bəzən istifadə olunur), yaxşı bir üsul var ki, ona «ulduzlu xəritə» deyilir.
Sizdə xidmətlərin və insanların siyahısı var. Ulduz simvolu bir şəxsin bu xidmətdə ekspert olduğunu bildirir, kitab simvolu isə bir şəxsin bu xidməti öyrəndiyini göstərir. Şəxsin vəzifəsi kitabı ulduzla dəyişdirməkdir. Əgər xidmətin qarşısında heç nə yazılmayıbsa, o zaman problemlər başlayır, bunları daha sonra izah edəcəyəm.
Xidmətlər necə yetim olur?
İlk problem, infrastrukturunuzda bir yetim servis elde etmenin ilk yolu - insanların işten çıkarılmasıdır. İş dünyasında işler değerlendirilmeden son tarihler geldi mi? Bazen zamanlar çok sıkı olur ve belgeler için yeterli zaman kalmaz. "Servisi üretime vermek zorundayız, sonra yazacağız."
Eğer takım küçükse, genellikle içinde her şeyi yazan bir geliştirici olur, diğerleri destekleyici konumundadır. "Ben ana mimariyi yazdım, sen de arayüzleri oluştur." Sonra bir noktada, örneğin, yönetici işten ayrılır. Yönetici gittiğinde ve yenisi henüz atanmadığında, geliştiriciler servisin nereye gideceğine, ne olduğunu kendileri karar verirler. Bildiğimiz gibi (birkaç slayt önce dönelim), bazı takımlarda "kar taneleri" var, bazen de kar tanesi takım lideri. Sonra o da işten ayrılır ve biz yetim servisi elde ederiz.
Bu arada, destekten ve işten gelen talepler kaybolmaz, onlar geri planda birikir. Eğer servis geliştirilirken bazı mimari hatalar olduysa, onlar da geri planda birikir. Servis yavaş yavaş kötüleşir.
Yetimi nasıl tanırız?
Bu liste durumu iyi bir şekilde özetliyor. Altyapınızda kendinizi tanıyan biri var mı?
Belgelendirilmiş geçici çözümler hakkında: bir servis var ve genel olarak çalışıyor, iki sayfalık bir kılavuzu var, ama içindeki işleyişi kimse bilmiyor.
Ya da örneğin, bir URL kısaltıcı var. Şu anda, farklı amaçlar için farklı servislere sahip üç URL kısaltıcı kullanıyoruz. İşte bunlar sonuçlar.
Şimdi bariz bir gerçeklik olarak konuşacağım. Ne yapmalıyız? İlk olarak, servisi başka bir yöneticinin, başka bir takımın devralması gerekiyor. Eğer takım lideriniz henüz işten çıkmamışsa, bu başka takıma eğer servis yetim görünüyorsa anlamışsanız, onu anlayan birini dahil etmelisiniz.
En önemli şey: sizde yazılı prosedürler olmalıdır. Bizim durumda, bunu çoğunlukla ben takip ediyorum, çünkü bunun çalışmasını sağlamak istiyorum. Yöneticilerin, bunun hızlı bir şekilde tamamlanmasını istemesi gerekiyor, sonrasında bununla ne olacağı onlara o kadar önemli değil.
Sirotu bir şəkildə yaratmağın digər bir yolu - "Çölə verəcəyik, beləliklə daha sürətli olacaq, sonra komandaya təhvil verəcəyik". Aydındır ki, hər kəsin komandada bir planı var, tələbat var. Tez-tez iş müştərisi düşünür ki, çöl mütəxəssisləri şirkətdəki texniki şöbə kimi işləyəcəklər. Halbuki onların motivasiyaları fərqlidir. Çöldə qəribə texnoloji və alqoritmik həllər olur.
Məsələn, bizimdə bir xidmət var idi, burada Sphinx-nin gözlənilməz yerlərdə olduğu. Sonradan bunu necə etdiyimizi izah edəcəyəm.
Çöl mütəxəssislərinin öz yaza bildikləri çərçivələri olur. Bu, sadəcə olaraq, əvvəlki projeden kopyalanmış çiy PHP-dir, burada hər cür şey tapa bilərsiniz. Yayım skriptlərində böyük saxlamalar olur, sizə bir neçə sətiri dəyişdirmək üçün mürəkkəb Bash skriptləri lazımdır, bu yayım skriptləri bir üçüncü skript tərəfindən çağırılır. Nəticədə siz yönləndirmə sistemini dəyişirsiniz, başqasını seçirsiniz, və hop, xidmətiniz işləmir. Çünki burada müxtəlif qovluqlar arasında 8 bağlantı daha qoymalısınız. Ya da ola bilər ki, min qeyd işləyir, amma yüz min artıq işləməyəcək.
Kapitanlıq etməyə davam edəcəyəm. Xidan gələn xidmətin qəbul prosesi mütləqdir. Kimin başına gəlib ki, çöldən gələn xidmət qəbul edilmir? Bu, əlbəttə ki, servici-balonla müqayisədə o qədər populyar deyil, amma yenə də.
Servisi yoxlamaq lazımdır, servisi reviziyadan keçirmək lazımdır, şifrələri dəyişmək lazımdır. Bizim belə bir vəziyyətimiz olub, bizə bir xidmət təqdim edildikdə, orda admin panelində "if login == ‘admin’ && password == ‘admin’..." düz kodda yazılmışdı. Oturub düşünürük, bu insanları 2018-ci ildə yazıblar?
Saxlama həcminin test edilməsi də zəruri bir şeydir. Siz yüz min qeyd olduğunda nə olacağına baxmalısınız, hələ xidmətinizi istehsala buraxmazdan əvvəl.
Servisi dəyişdirməyə göndərməkdən utanmamalısınız. Siz dediyinizdə: "Bu xidməti qəbul etməyəcəyik, bizim 20 vəzifəmiz var, bunları edəcəyiniz zaman qəbul edəcəyik", bu normaldır. Vicdanınız meneceri qurban verməkdən və ya biznesin pul xərcləyəcəyindən narahat olmamalıdır. Biznes daha çox pul xərcləyəcək.
Bizim belə bir vəziyyətimiz olub ki, çöl mütəxəssisləri ilə pilot layihə həyata keçirməyə qərar verdik.
O, vaxtında təqdim edildi və bu, keyfiyyətin yeganə meyası idi. Buna görə də, tamamilə pilot layihədən də daha irəlidə olan birini həyata keçirdilər. Bu xidmətlər qəbul edildi, inzibati yollarla dedilər ki, budur sizin kod, budur komanda, budur sizin meneceriniz. Xidmətlər həqiqətən artıq gəlir gətirməyə başladı. Eyni zamanda, faktiki olaraq, hələ də yetim qaldılar, heç kim onların necə işlədiyini başa düşmür, və menecerlər onların tapşırıqlarından hər cür qaçmağa çalışırlar.
Başqa bir əla anlayış var - partizan inkişafı. Hər hansı bir şöbə, adətən, marketinq şöbəsi, bir hipotezi sınaqdan keçirmək istəyir və bir xidməti tamamilə xarici xidmətə sifariş edir. Trafik onun üzərinə axmağa başlayır, sənədləri bağlayırlar, podratçı ilə aktları imzalayırlar, istismara girirlər və deyirlər: «Dostlar, burada bir xidmətimiz var, artıq trafik var, bizə pul gətirir, gəlin onu qəbul edək». Biz isə belə deyirik: «Ayda, necə ola bilər».
Və yetim xidmətlər əldə etməyin başqa bir yolu: bir komanda birdən çox yüklənəndə rəhbərlik deyir: «Gəlin bu xidmətin yükünü bu komandanın digər komandasına verək, onun yükü azdır». Və sonra onu üçüncü komandaya veririk, meneceri dəyişirik. Nəticədə, yenidən yetimimiz olur.
Yetimlərdə problem nədir?
Kim bilmir, bu, İsveçdə qaldırılan Wasa zirehli gəmidir, 5 dəqiqə suya batdığı ilə məşhurdur. Və İsveç kralı, bu səbəbdən heç kimi edam etmədi. Bu, iki nəsil mühəndis tərəfindən inşa edilirdi ki, buna bənzər gəmiləri necə inşa edəcəklərini bilmir. Təqdirəlayiq bir nəticə.
Bu gəmi, yeri gəlmişkən, daha pis, məsələn, bununla bir kralın bir şiddətli fırtınada bir yerə hərəkət etdiyini düşünün. Beləliklə, dərhal batdı, əcəba, bu, agil metodologiyası baxımından yaxşıdır - erkən uğursuzluq.
Əgər biz erkən uğursuz olduqsa, adətən problem olmur. Məsələn, qəbul zamanı düzəlişə göndərdik. Ancaq əgər artıq istehsalda uğursuz olduq, pul sərf ediləndə, o zaman problemlər ola bilər. Biznesdə buna nəticələr deyilir.
Yetim xidmətlərin təhlükələri:
- Xidmət birdən dayana bilər.
- Xidmət uzun müddət təmir olunur və ya ümumiyyətlə təmir edilmir.
- Təhlükəsizlik problemləri.
- Düzəliş və yeniləmələrdə problemlər.
- Əgər vacib bir xidmət qırılırsa, şirkətin reputasiyası zərər görür.
Yetim xidmətlərlə nə etmək lazımdır?
Bir daha deyə bilərəm ki, nə etmək lazımdır. İlk növbədə, sənədləşmə olmalıdır. Banki.ru-da 7 il çalışmaq mənə öyrətdi ki, testçilər proqramçılara inanmalı deyil və istismar hamıya etibar etməməlidir. Yoxlama aparmaq lazımdır.
İkinci növbədə, qarşılıqlı əlaqələrin sxemlərini yazmaq lazımdır, çünki bəzən, yaxşı qəbul edilməyən xidmətlər heç kimin demədiyi asılılıqların içərisində olur. Məsələn, proqramçılar bir xidmətə Yandex.Xəritələri və ya Dadata üzərindən qoşulmuşdular. Pulsuz limitiniz bitdi, hər şey pozuldu və nə baş verdiyini bilmirsiniz. Belə əngəllər tamamilə təsvir edilməlidir: xidmət Dadata, Sms və daha nələri istifadə edir.
Üçüncü növbədə, texniki borc ilə işləmə. Nə vaxtsa qarmaqarışıq yollar edəndə və ya bir xidməti qəbul edib nəsə etməyi desəniz, buna diqqət etmək lazımdır. Çünki daha sonralar kiçik bir çuxur bu qədər kiçik olmaya bilər və içində batarsınız.
Arxitektura məsələləri ilə Sphinx haqqında bir hadisəmiz olub. Sphinx, bir xidmətin siyahıları daxil edilməsi üçün istifadə olunmuşdu. Yalnız bir səhifələmə ilə siyahı, lakin o, hər gecə yenidən indekslənirdi. O, iki indeksdən ibarət idi: biri hər gecə böyük ölçüdə indekslənirdi, digəri isə kiçik indeks ona birləşdirilirdi. Hər gün, 50% ehtimalla ya patlaya bilər, ya da yox, yerləşdirilmə zamanı indeks pozulur və xəbərlərimiz ana səhifədə yenilənməyə dayanırdı. Əvvəllər bu 5 dəqiqə idi, indeks yenidən indekslənənə qədər, sonra indeks böyüdü və bir müddət sonra yenidən indekslənmə 40 dəqiqəyə qədər uzandı. Bunu kənara qoyduqda, rahat nəfəs aldıq, çünki aydın idi ki, bir müddət sonra indeks tam iş günü yenidən indekslənəcək. Bu, portalımız üçün bir fiyask olacaq, səkkiz saat xəbərlər olmayacaq - iş qəzaya uğrayacaq.
Dövlət xidmətinin planı
Həqiqətən, bunu etmək çox çətindir, çünki devops ünsiyyətdir. Öz həmkarlarınızla yaxşı münasibət qurmaq istəyirsiniz, lakin siz həmkarlarınızı və menecerləri qaydalarla başlarına vursanız, onlar belə edən insanlara qarşı qarışıq hisslər keçirə bilərlər.
Bütün bu maddələrin yanında, hələ bir mühüm şey var: hər bir konkret xidmət, hər bir konkret yerləşdirmə prosesi üçün konkret insanlar məsuliyyət daşımalıdır. İnsanlar olmadıqda və başqa insanları cəlb etmək lazım gəldikdə, bunun öyrənilməsi çətin olur.
Əgər bunların hamısı kömək etmirsə, və hizmet yetimləriniz hələ də yetim qalıb, heç kim onu götürmək istəmir, sənədləşmə yazılmır, bu xidmətə cəlb edilən komanda nəsə etməyi rədd edirsə, sadə bir yol var — hər şeyi yenidən qurmaq.
Yəni, siz xidmətin tələblərini yenidən ələ alırsınız və daha yaxşı, daha yaxşı platformada yeni bir xidmət yazırsınız, qəribə texnologiya qərarları olmadan. Və döyüşdə ona köçürürsünüz.
Bizim bir vəziyyətimiz vardı, biz Yii 1 istifadə edərək bir xidməti aldıq və bunun daha da inkişaf etdirilməsi mümkün olmadığını anladıq, çünki Yii 1-də yaxşı yazan proqramçılarımız sona çatdı. Bütün proqramçılar Symfony 3-də yaxşı yazır. Nə etmək lazım? Vaxt ayırdıq, komanda ayırdıq, menecer ayırdıq, layihəni yenidən yazdıq və tədricən ora trafik keçirdik.
Bundan sonra köhnə xidməti silmək olar. Bu, mənim sevdiyim prosedurdur, konfiqurasiya idarəetmə sistemindən bir xidməti götürüb təmizləmək və sonra bütün istehsaldakı maşınların söndüyündən əmin olmaq üçün gəzinti etməkdir ki, proqramçılara heç bir iz qalmasın. Git depozitində isə qalır.
Bu, mənim danışmaq istədiyim hər şeydir, mübahisə etməyə hazıram, bu mövzu mübahisəlidir, bir çoxu bunun içində üzmüşdür.
Slaydlarda dillərin standartlaşdırılması haqqında danışılırdı. Məsələn, şəkillərin ölçüsünün dəyişdirilməsi. Amma həqiqətən də bir dilə sərt keçmək lazımdırmı? Çünki şəkilin PHP-də ölçüsünü dəyişmək, əslində, Golang ilə də edə bilərdim.
Əslində, bu, zəruri deyil, eyni zamanda bütün praktikalar üçün. Bəzi hallarda, hətta arzuolunmazdır. Lakin başa düşmək lazımdır ki, əgər şirkətinizdə 50 nəfər texniki hissədə çalışırsa, onlardan 45-i PHP mütəxəssisidirsə, 3-ü isə Python, Ansible, Puppet ilə işləyən devopsdur və yalnız bir nəfər şəkillərin ölçüsünü dəyişmək üçün Go-da proqram yazırsa, o zaman o, şirkətdən gedəndə, biliklər də onunla birlikdə gedəcək. Bu zaman siz bazarda spesifik, bu dili bilən bir proqramçı axtarmalısınız, xüsusilə də bu nadir bir dildirsə. Yəni, təşkilati baxımdan, bu problem yaradır. Devops perspektivindən, siz yalnız istifadə etdiyiniz hazır playbook dəstini klonlamaqla kifayətlənməyəcəksiniz, onu yenidən yazmalısınız.
İndiyə qədər Node.js-də bir xidmət üzərində çalışırıq və bu, hər bir proqramçı üçün ayrı bir dillə yan-yana olan bir platforma olacaq. Amma biz oturub düşündük ki, bu oyunun qiymətinə dəyər. Yəni burada məsələ oturub düşünməkdir.
Sizin xidmətlərinizi necə monitorinq edirsiniz? Logger-ları necə toplayıb izləyirsiniz?
Logger-ları Elasticsearch-də toplayırıq və Kibana-da saxlayırıq, istehsal (prod) və test mühitləri arasında fərqli toplayıcılar istifadə olunur. Bəziləri üçün Lumberjack, bəziləri üçün başqa bir şey, artıq yaddan çıxıb. Həm də müəyyən xidmətlərdə Telegraf quraşdırıb onu ayrı bir yerə göndərdiyimiz bəzi yerlər var.
Puppet və Ansible-i bir mühitdə necə birləşdirmək olar?
Əslində, hazırda iki mühitimiz var, biri Puppet, digəri Ansible. Onları hibridləşdirmək üzərində çalışırıq. Ansible ilkin konfiqurasiya üçün yaxşı mühitdir, Puppet isə ilkin konfiqurasiya üçün pisdir, çünki mühitlə birbaşa əl işləri ilə məşğul olmağı tələb edir. Puppet konfiqurasiyanın uyğunluğunu təmin edir. Bu, mühitin özünü aktual saxladığı deməkdir, ancaq ansibilləşdirilmiş maşın daima playbook-larla mütəmadi olaraq müşayiət olunmalıdır. Bax, belə bir fərq var.
Siz necə uyğunluğu saxlayırsınız? Sizin Ansible və Puppet-də konfiqurasiya fayllarınız var?
Bu bizim böyük problemimizdir, əl ilə uyğunluğu dəstəkləyirik və bununla bağlı necə köçəcəyimiz barədə düşünürük. Görürük ki, Puppet paketləri yükləyir və orada bəzi bağlantıları dəstəkləyir, Ansible isə, məsələn, kodu yükləyir və tətbiqlərin yeni konfiqurasiyalarını uyğunlaşdırır.
Təqdimatda Ruby-nin müxtəlif versiyaları haqqında oldu. Hangi həll var?
Biz bir yerdə bununla qarşılaşdıq və bunu daim ağlımızda saxlamağa məcburuq. Biz sadəcə olaraq, uyğun olmayan Ruby-də işləyən o hissəni bağladıq və onu ayrı saxladıq.
Bu il konfrans 7 dekabrda "Texnopolis"-də baş tutacaq. 11 noyabr tarixinə qədər çıxışlar üçün müraciətlər qəbul edirik. bizə, əgər çıxış etmək istəyirsinizsə.
İştirakçılar üçün qeydiyyat açıqdır, qoşulun!
Mənbə: habr.com
