2019-cu ildə bir İT şirkətinin uğur qazanması üçün nə lazımdır? Konfranslarda və görüşlərdə mühazirəçilər normal insanlar üçün heç də həmişə başa düşülməyən çoxlu səsli sözlər deyirlər. Yerləşdirmə vaxtı, mikroservislər, monolitdən imtina, DevOps transformasiyası və daha çox şey uğrunda mübarizə. Əgər şifahi gözəlliyi rədd etsək və birbaşa və rus dilində danışırıqsa, onda hər şey sadə bir tezisə gəlir: yüksək keyfiyyətli məhsul hazırlayın və bunu komanda üçün rahatlıqla edin.
Sonuncu kritik əhəmiyyətə çevrildi. Biznes nəhayət belə bir qənaətə gəldi ki, rahat inkişaf prosesi məhsuldarlığı artırır və hər şey düzəldilib saat kimi işləyirsə, o, həm də kritik vəziyyətlərdə manevr etmək üçün bir az yer verir. Bir vaxtlar, bu manevr üçün müəyyən bir ağıllı şəxs ehtiyat nüsxələri ilə gəldi, lakin sənaye inkişaf edir və biz DevOps mühəndislərinə gəldik - inkişaf və xarici infrastruktur arasındakı qarşılıqlı əlaqə prosesini adekvat və lazımlı bir şeyə çevirən insanlar. şamanizmlə əlaqəsi yoxdur.
Bütün bu “modul” hekayə gözəldir, amma... Elə oldu ki, bəzi adminlər qəfildən DevOps adlandırıldı və DevOps mühəndislərindən ən azı telepatiya və kəşfiyyat bacarıqlarına malik olmaları tələb olunmağa başladı.
İnfrastrukturun təmin edilməsinin müasir problemlərindən danışmazdan əvvəl bu terminlə nəyi nəzərdə tutduğumuzu müəyyən edək. İndiki məqamda vəziyyət elə inkişaf edib ki, biz bu konsepsiyanın ikililiyinə çatmışıq: infrastruktur şərti olaraq xarici və şərti olaraq daxili ola bilər.
Xarici infrastruktur dedikdə komandanın inkişaf etdirdiyi xidmət və ya məhsulun funksionallığını təmin edən hər şeyi nəzərdə tuturuq. Bunlar proqram və ya vebsayt serverləri, hostinq və məhsulun funksionallığını təmin edən digər xidmətlərdir.
Daxili infrastruktura inkişaf qrupunun özü və adətən çox olan digər işçilər tərəfindən istifadə edilən xidmətlər və avadanlıqlar daxildir. Bunlar kod saxlama sistemlərinin daxili serverləri, yerli olaraq yerləşdirilmiş tapşırıq meneceri və korporativ intranetdə mövcud olan hər şey, hər şey, hər şeydir.
Sistem administratoru şirkətdə nə edir? Bu çox korporativ intranetin idarə edilməsi işinə əlavə olaraq, tez-tez ofis avadanlığının işləkliyini təmin etmək üçün iqtisadi narahatlıqlar yükünü daşıyır. Admin, arxa otaqdan tez bir zamanda yeni sistem blokunu və ya istifadəyə hazır ehtiyat noutbuku sürükləyəcək, təzə klaviatura verəcək və Ethernet kabelini uzataraq ofislərdə dörd ayaq üstə sürünəcək eyni adamdır. Administrator təkcə daxili və xarici serverlərin deyil, həm də biznes icraçısının yerli sahibi və idarəçisidir. Bəli, bəzi administratorlar yalnız sistem müstəvisində, hardware olmadan işləyə bilər. Onlar ayrıca “infrastruktur sistem inzibatçıları” alt sinfinə ayrılmalıdırlar. Bəziləri isə yalnız ofis avadanlığına xidmət göstərmək üzrə ixtisaslaşırlar; xoşbəxtlikdən, şirkətdə yüzdən çox insan varsa, iş heç vaxt bitmir. Lakin onların heç biri devop deyil.
DevOps kimdir? Devops proqram təminatının inkişafının xarici infrastrukturla qarşılıqlı əlaqəsi haqqında danışan uşaqlardır. Daha doğrusu, müasir devoplar inkişaf və yerləşdirmə proseslərində əvvəllər ftp-yə yeniləmələri yükləyən adminlərdən daha dərindən iştirak edirlər. İndi DevOps mühəndisinin əsas vəzifələrindən biri inkişaf qrupları və məhsul infrastrukturu arasında rahat və effektiv strukturlaşdırılmış qarşılıqlı əlaqə prosesini təmin etməkdir. Məhz bu insanlar geri qaytarma və yerləşdirmə sistemlərinin tətbiqinə cavabdehdirlər; məhz bu insanlar yükün bir hissəsini tərtibatçılardan götürür və mümkün qədər çox vacib işlərinə cəmləşirlər. Eyni zamanda, devops heç vaxt yeni kabel çəkməyəcək və ya arxa otaqdan yeni noutbuk buraxmayacaq (c) KO
Tutmaq nədir?
“DevOps kimdir?” sualına sahədə çalışanların yarısı "Yaxşı, bir sözlə, bu admindir ..." və daha sonra mətndə cavab verməyə başlayır. Bəli, bir vaxtlar, DevOps mühəndisinin peşəsi xidmətə texniki xidmət baxımından ən istedadlı idarəçilər arasından yenicə yaranarkən, aralarındakı fərqlər hər kəs üçün açıq deyildi. Amma indi, komandada devop və admin funksiyaları köklü şəkildə fərqlənəndə, onları bir-biri ilə qarışdırmaq, hətta eyniləşdirmək də qəbuledilməzdir.
Bəs bu biznes üçün nə deməkdir?
İşə götürmək, hər şey bununla bağlıdır.
Siz “Sistem Administratoru” üçün vakansiya açırsınız və orada sadalanan tələblər “inkişaf və müştərilərlə qarşılıqlı əlaqə”, “CI/CD çatdırılma sistemi”, “şirkətin server və avadanlıqlarına texniki qulluq”, “daxili sistemlərin idarə edilməsi” və s. on; başa düşürsən ki, işəgötürən boş-boş danışır. Məsələ ondadır ki, “Sistem Administratoru” əvəzinə vakansiya adı “DevOps Engineer” olmalıdır və bu başlıq dəyişdirilərsə, hər şey öz yerinə düşür.
Ancaq belə bir vakansiyanı oxuyanda hansı təəssürat yaranır? Şirkət həm versiyaya nəzarət, həm də monitorinq sistemini yerləşdirəcək və twisteri dişləri ilə sıxacaq bir çox maşın operatoru axtarır ...
Ancaq əmək bazarında narkomaniyanın dərəcəsini artırmamaq üçün vakansiyaları öz adları ilə çağırmaq və DevOps mühəndisi ilə sistem administratorunun iki fərqli qurum olduğunu aydın şəkildə başa düşmək kifayətdir. Lakin bəzi işəgötürənlərin namizədə mümkün olan ən geniş tələblər siyahısını təqdim etmək istəyi ona gətirib çıxarır ki, “klassik” sistem administratorları ətraflarında baş verənləri başa düşmürlər. Nə, peşə mutasiyaya uğrayır və onlar zamandan geri qalırlar?
Xeyr və bir daha yox. Şirkətin daxili serverlərini idarə edəcək və ya L2/L3 dəstək vəzifələrini tutacaq və digər işçilərə kömək edəcək infrastruktur administratorları getməyiblər və getməyəcəklər.
Bu mütəxəssislər DevOps mühəndisləri ola bilərmi? Əlbəttə bilər. Əslində, bu, sistem idarəetmə bacarıqlarını tələb edən əlaqəli bir mühitdir, lakin buna əlavə olaraq, monitorinq, çatdırılma sistemləri ilə işləmək və ümumiyyətlə, inkişaf və sınaq qrupu ilə sıx qarşılıqlı əlaqə əlavə olunur.
Başqa bir DevOps Problemi
Əslində, hər şey yalnız işə götürmə və adminlər və devoplar arasında daimi qarışıqlıq ilə məhdudlaşmır. Bir anda biznes yeniləmələrin çatdırılması və inkişaf qrupunun son infrastrukturla qarşılıqlı əlaqəsi problemi ilə üzləşdi.
Bəlkə də elə həmin vaxt idi ki, gözləri parıldayan bir əmi hansısa konfransın səhnəsində ayağa qalxdı və dedi: “Biz bunu edirik və buna DevOps deyirik. Bu uşaqlar bütün problemlərinizi həll edəcək” - və DevOps təcrübələrini tətbiq etdikdən sonra şirkətdə həyatın necə yaxşı olduğunu söyləməyə başladı.
Bununla belə, hər şeyin lazım olduğu kimi işləməsi üçün DevOps mühəndisini işə götürmək kifayət deyil. Şirkət tam DevOps transformasiyasından keçməlidir, yəni DevOps-un rolu və imkanları məhsulun inkişafı və sınaq komandası tərəfindən də aydın şəkildə başa düşülməlidir. Bu mövzuda bəzi yerlərdə baş verən bütün vəhşiliyi tam əks etdirən “gözəl” hekayəmiz var.
Vəziyyət. DevOps, onun necə işləyəcəyinə dərindən baxmadan bir versiya geri qaytarma sistemini yerləşdirmək üçün tələb olunur. Tutaq ki, İstifadəçilər sistemində ad, soyad və parol üçün ayrıca sahələr var. Məhsulun yeni versiyası çıxır, lakin tərtibatçılar üçün "geri qaytarma" sadəcə hər şeyi düzəldəcək sehrli bir çubuqdur və onlar bunun necə işlədiyini belə bilmirlər. Beləliklə, məsələn, növbəti yamaqda tərtibatçılar ad və soyad sahələrini birləşdirdilər, onu istehsala təqdim etdilər, lakin versiya nədənsə yavaşdır. Nə baş verir? Rəhbərlik devoplara gəlir və “Keçiri çəkin!” deyir, yəni ondan əvvəlki versiyaya qayıtmasını xahiş edir. Devops nə edir? Əvvəlki versiyaya qayıdır, lakin tərtibatçılar bu geri çəkilmənin necə edildiyini anlamaq istəmədiklərinə görə, heç kim devops komandasına verilənlər bazasının da geri qaytarılması lazım olduğunu söyləmədi. Nəticədə, hər şey bizim üçün çökür və yavaş veb sayt əvəzinə istifadəçilər "500" xətası görürlər, çünki köhnə versiya yeni verilənlər bazası sahələri ilə işləmir. Devops bu barədə bilmir. Tərtibatçılar susur. Rəhbərlik əsəblərini və pullarını itirməyə başlayır və ehtiyat nüsxələri xatırlayır, onlardan geri çəkilməyi təklif edir ki, "heç olmasa bir şey işləsin". Nəticədə istifadəçilər müəyyən müddət ərzində bütün məlumatlarını itirirlər.
Qoz-fındıq, əlbəttə ki, "düzgün geri qaytarma sistemi yaratmayan" devoplara gedir və bu hekayədəki mooselərin tərtibatçı olması heç kimin vecinə deyil.
Nəticə sadədir: DevOps-a normal bir yanaşma olmadan, çox az faydası var.
Xatırlamaq lazım olan əsas şey: DevOps mühəndisi sehrbaz deyil və keyfiyyətli rabitə və inkişafla ikitərəfli qarşılıqlı əlaqə olmadan o, vəzifələrinin öhdəsindən gəlməyəcək. İnkişaf etdiriciləri "problemləri" ilə tək buraxmaq olmaz və ya "geliştiricilərə qarışmayın, onların işi kodlaşdırmaqdır" əmri verilə bilməz və sonra ümid edirik ki, kritik anda hər şey lazım olduğu kimi işləyəcək. Bu belə deyil.
Əsasən, DevOps idarəetmə və texnologiya arasındakı sərhəddə bir səriştədir. Üstəlik, bu kokteyldə idarəetmədən daha çox texnologiyanın olması lazım olduğu aydın deyil. Əgər həqiqətən daha sürətli və daha səmərəli inkişaf prosesləri qurmaq istəyirsinizsə, devops komandanıza etibar etməlisiniz. O, düzgün alətləri bilir, oxşar layihələr həyata keçirib, bunu necə edəcəyini bilir. Ona kömək edin, məsləhətlərinə qulaq asın, onu bir növ muxtar vahidə təcrid etməyə çalışmayın. Adminlər təkbaşına işləyə bilirlərsə, bu halda devoplar faydasızdır, əgər siz özünüz bu yardımı qəbul etmək istəmirsinizsə, onlar sizə daha yaxşı olmağa kömək edə bilməyəcəklər.
Və son bir şey: infrastruktur inzibatçılarını təhqir etməyi dayandırın. Onların öz işlərinin son dərəcə vacib cəbhəsi var. Bəli, bir idarəçi DevOps mühəndisi ola bilər, lakin bu, təzyiq altında deyil, şəxsin öz istəyi ilə baş verməlidir. Sistem administratorunun sistem administratoru olaraq qalmaq istəməsində isə heç bir qəbahət yoxdur - bu, onun ayrıca peşəsidir və hüququdur. Peşəkar bir transformasiyadan keçmək istəyirsinizsə, heç vaxt unutmamalısınız ki, yalnız texnoloji bacarıqları deyil, həm də idarəetmə bacarıqlarını inkişaf etdirməli olacaqsınız. Çox güman ki, bütün bu insanları bir araya gətirmək və onlara eyni dildə ünsiyyət qurmağı öyrətmək bir lider olaraq sizdən asılı olacaq.
Mənbə: www.habr.com