Hazırda bu, demək olar ki, bazarda ən bahalı mövqedir. "DevOps" mühəndisləri ətrafında təlaş bütün təsəvvür edilən hədləri aşır və daha da pis DevOps mühəndisləri ilə bağlıdır.
Mən inteqrasiya və avtomatlaşdırma şöbəsinin müdiri kimi işləyirəm, İngilis dilinin dekodlanmasını təxmin edin - DevOps Manager. Çətin ki, ingilis dilində transkript bizim gündəlik fəaliyyətimizi əks etdirir, lakin bu halda rus versiyası daha dəqiqdir. Fəaliyyətimin xarakterinə görə komandamın gələcək üzvlərindən müsahibə götürməyim təbiidir və son bir ildə 50-yə yaxın insan məndən keçdi və eyni sayda işçilərimlə əvvəlcədən ekranda kəsildi.
Biz hələ də həmkarlar axtarırıq, çünki DevOps etiketinin arxasında gizlənən müxtəlif növ mühəndislərin çox böyük təbəqəsi var.
Aşağıda yazılanların hamısı mənim şəxsi fikrimdir, onunla razılaşmaq lazım deyil, amma etiraf edirəm ki, mövzuya münasibətinizə müəyyən rəng qatacaq. Gözdən düşmə riskinə baxmayaraq, fikrimi dərc edirəm, çünki onun yeri olduğuna inanıram.
Şirkətlər DevOps mühəndislərinin kim olduqlarına dair fərqli anlayışlara malikdirlər və tez bir resurs işə götürmək üçün bu etiketi hər kəsə asırlar. Vəziyyət olduqca qəribədir, çünki şirkətlər bu insanlara qeyri-real mükafatlar ödəməyə hazırdırlar, əksər hallarda onlar üçün bir vasitə administratoru alırlar.
Beləliklə, DevOps mühəndisləri kimlərdir?
Görünüşünün tarixindən başlayaq - İnkişaf Əməliyyatları gözlənilən nəticə olaraq məhsul istehsalının sürətini artırmaq üçün kiçik komandalarda qarşılıqlı əlaqəni optimallaşdırmaq üçün daha bir addım kimi ortaya çıxdı. İdeya məhsul mühitinin idarə edilməsində prosedurlar və yanaşmalar haqqında biliklərlə inkişaf qrupunu gücləndirmək idi. Başqa sözlə, tərtibatçı müəyyən şərtlərdə məhsulunun necə işlədiyini başa düşməli və bilməlidir, məhsulunu necə yerləşdirməyi, performansı yaxşılaşdırmaq üçün ətraf mühitin hansı xüsusiyyətlərini tənzimləmək olar. Beləliklə, bir müddət DevOps yanaşması olan tərtibatçılar meydana çıxdı. DevOps tərtibatçıları fəaliyyətlərini və istehsal mühitinin işini asanlaşdırmaq üçün quraşdırma və qablaşdırma skriptləri yazdılar. Bununla birlikdə, həll arxitekturasının mürəkkəbliyi və infrastruktur komponentlərinin qarşılıqlı təsiri zaman keçdikcə mühitlərin işini pisləşdirməyə başladı; hər bir iterasiya ilə müəyyən komponentlərin getdikcə daha dərindən başa düşülməsi tələb olunurdu, bu da əlavələr səbəbindən inkişaf etdiricinin məhsuldarlığını azaldır. müəyyən bir tapşırıq üçün komponentləri və tənzimləmə sistemlərini başa düşmək xərcləri. Tərtibatçının öz dəyəri artdı, onunla birlikdə məhsulun dəyəri, komandadakı yeni tərtibatçılara olan tələblər kəskin şəkildə artdı, çünki onlar da inkişaf "ulduzunun" məsuliyyətlərini ödəməli idilər və təbii olaraq, "ulduzlar" daha az oldu. və daha az mövcuddur. Onu da qeyd etmək yerinə düşər ki, mənim təcrübəmə görə, bir neçə tərtibatçı əməliyyat sisteminin nüvəsi tərəfindən paketlərin işlənməsinin xüsusiyyətləri, paketlərin marşrutlaşdırma qaydaları və hostun təhlükəsizlik aspektləri ilə maraqlanır. Məntiqi addım bununla tanış olan bir idarəçini cəlb etmək və ona oxşar vəzifələr vermək idi ki, bu da öz təcrübəsi sayəsində eyni göstəricilərə "ulduz" inkişafının dəyəri ilə müqayisədə daha aşağı qiymətə nail olmağa imkan verdi. Bu cür idarəçilər bir komandaya yerləşdirildi və onun əsas vəzifəsi bu xüsusi komandaya ayrılan resurslarla müəyyən bir komandanın qaydalarına uyğun olaraq sınaq və istehsal mühitlərini idarə etmək idi. Əslində, DevOps əksəriyyətin ağlında belə göründü.
Qismən və ya tamamilə, zaman keçdikcə, bu sistem administratorları bu xüsusi komandanın inkişaf sahəsindəki ehtiyaclarını, tərtibatçılar və testçilər üçün həyatı necə asanlaşdırmağı, yeniləməni necə yaymağı və cümə günü gecələmək məcburiyyətində qalmamağı başa düşməyə başladılar. ofis, yerləşdirmə səhvlərinin düzəldilməsi. Vaxt keçdi və indi "ulduzlar" tərtibatçıların nə istədiyini başa düşən sistem administratorları idi. Təsiri minimuma endirmək üçün idarəetmə proqramları ortaya çıxmağa başladı; hamı OS səviyyəsini təcrid etməyin köhnə və etibarlı üsullarını xatırladı ki, bu da təhlükəsizlik, şəbəkə hissəsinin idarə edilməsi və host konfiqurasiyası kimi tələbləri minimuma endirməyə imkan verdi. bütövlükdə və nəticədə yeni "ulduzlar" üçün tələbləri azaldır.
"Gözəl" bir şey ortaya çıxdı - doker. Niyə möhtəşəm? Bəli, yalnız bir chroot və ya həbsxanada, eləcə də OpenVZ-də təcrid yaratmaq üçün OS haqqında qeyri-trivial bilik tələb olunduğu üçün, bunun əksinə olaraq, yardım proqramı içəridə və əlinizdə lazım olan hər şeylə müəyyən bir hostda sadəcə təcrid olunmuş tətbiq mühiti yaratmağa imkan verir. yenidən inkişaf cilovu üzərində və sistem administratoru yalnız bir host ilə idarə edə bilər, onun təhlükəsizliyini və yüksək əlçatanlığını təmin edir - məntiqi sadələşdirmə. Ancaq tərəqqi hələ də dayanmır və sistemlər yenidən getdikcə mürəkkəbləşir, getdikcə daha çox komponent var, bir host artıq sistemin ehtiyaclarını ödəmir və klasterlər qurmaq lazımdır, biz yenidən sistem administratorlarına qayıdırıq. bu sistemləri qura bilir.
Döngədən sonra, inkişafı və/və ya idarəetməni asanlaşdıran müxtəlif sistemlər peyda olur, standart prosesdən kənara çıxmağa ehtiyac duyana qədər istifadə etmək asan olan orkestrləşdirmə sistemləri görünür. Mikroservis arxitekturası da yuxarıda təsvir edilən hər şeyi sadələşdirmək məqsədi ilə ortaya çıxdı - daha az əlaqələr, idarə etmək daha asandır. Təcrübəmdə tam mikroservis arxitekturası tapmadım, deyərdim ki, 50-50 - 50 faiz mikroservislər, qara qutular daxil olub, emal olunub, qalan 50-si cırıq monolitdir, xidmətlər digərlərindən ayrı işləyə bilmir. komponentlər. Bütün bunlar yenidən həm tərtibatçıların, həm də idarəçilərin bilik səviyyəsinə məhdudiyyətlər qoydu.
Müəyyən bir resursun ekspert bilikləri səviyyəsində oxşar "yelləncəklər" bu günə qədər davam edir. Amma biz bir qədər yayınırıq, vurğulamağa dəyər çoxlu məqamlar var.
İnşaat Mühəndisi / Buraxılış Mühəndisi
Proqram qurma proseslərinin və buraxılışlarının standartlaşdırılması vasitəsi kimi ortaya çıxan çox yüksək ixtisaslaşmış mühəndislər. Geniş yayılmış Agile-in tətbiqi prosesində, görünür ki, onlara tələbat dayanıb, lakin bu, belə deyil. Bu ixtisaslaşma proqram təminatının sənaye miqyasında yığılması və çatdırılmasının standartlaşdırılması vasitəsi kimi ortaya çıxdı, yəni. bütün şirkət məhsulları üçün standart texnikalardan istifadə. DevOps-un meydana çıxması ilə tərtibatçılar funksiyalarını qismən itirdilər, çünki məhsulu çatdırılma üçün hazırlamağa başlayanlar və dəyişən infrastrukturu və keyfiyyətdən asılı olmayaraq mümkün qədər tez çatdırılma yanaşmasını nəzərə alaraq, zaman keçdikcə onlar öz funksiyalarını itirdilər. dəyişikliklərin dayandırıcısı, çünki keyfiyyət standartlarına riayət etmək istər-istəməz tədarükləri ləngidir. Beləliklə, yavaş-yavaş, Quraşdırma/Sərbəst mühəndislərinin funksionallığının bir hissəsi sistem administratorlarının çiyinlərinə keçdi.
Əməliyyatlar çox fərqlidir
Biz təkrar-təkrar irəliləyirik, böyük bir məsuliyyət dairəsinin olması və ixtisaslı kadrların olmaması bizi yağışdan sonra göbələk kimi ciddi ixtisaslaşmaya sövq edir, müxtəlif əməliyyatlar görünür:
- TechOps - enikey sistem administratorları, aka HelpDesk Engineer
- LiveOps - ilk növbədə istehsal mühitlərinə cavabdeh olan sistem administratorları
- CloudOps - ictimai buludlarda ixtisaslaşan sistem administratorları Azure, AWS, GCP və s.
- PlatOps/InfraOps/SysOps - infrastruktur sistem administratorları.
- NetOps - şəbəkə administratorları
- SecOps - informasiya təhlükəsizliyi üzrə ixtisaslaşmış sistem administratorları - PCI uyğunluğu, MDB uyğunluğu, yamaqlar və s.
DevOps (nəzəri olaraq) inkişaf dövrünün bütün proseslərini - inkişaf, sınaqdan keçirmə, məhsulun arxitekturasını anlayan, təhlükəsizlik risklərini qiymətləndirməyi bacaran, yanaşmalar və avtomatlaşdırma vasitələri ilə ən azı yüksək səviyyədə tanış olan bir şəxsdir. səviyyə, buna əlavə olaraq, emaldan əvvəl və sonrakı emalları da başa düşür. Həm Əməliyyatlar, həm də İnkişaf üçün vəkil kimi çıxış edə bilən şəxs, bu iki sütun arasında əlverişli əməkdaşlığa imkan verir. Komandalar tərəfindən işin planlaşdırılması və müştəri gözləntilərinin idarə edilməsi proseslərini başa düşür.
Bu cür iş və vəzifələri yerinə yetirmək üçün bu şəxs təkcə inkişaf və sınaq proseslərini deyil, həm də məhsul infrastrukturunun idarə edilməsini, həmçinin resursların planlaşdırılmasını idarə etmək vasitələrinə malik olmalıdır. Bu anlayışda DevOps nə İT, nə R&D, nə də hətta PMO-da yerləşə bilməz; o, bütün bu sahələrə - şirkətin texniki direktoru, Baş Texniki Direktora təsir göstərməlidir.
Bu sizin şirkətinizdə doğrudurmu? - Şübhələnirəm. Əksər hallarda bu ya İT, ya da R&D-dir.
Vəsait çatışmazlığı və bu üç fəaliyyət sahəsindən ən azı birinə təsir göstərmək imkanı problemlərin ağırlığını bu dəyişikliklərin tətbiqinin daha asan olduğu yerə, məsələn, statik parametrlərə uyğun olaraq “çirkli” kodla əlaqədar buraxılışlara texniki məhdudiyyətlərin tətbiqinə yönəldəcək. analizator sistemləri. Yəni, PMO funksionallığın buraxılması üçün ciddi son tarix təyin etdikdə, Ar-Ge bu müddətlər ərzində yüksək keyfiyyətli nəticə verə bilməz və mümkün olduğu qədər istehsal edir, refaktorinqi sonraya buraxır, İT ilə əlaqəli DevOps texniki vasitələrdən istifadə edərək buraxılışı bloklayır. . Vəziyyəti dəyişdirmək səlahiyyətinin olmaması, məsul işçilər vəziyyətində, təsir edə bilməyəcəkləri şeylərə, xüsusən də bu işçilər səhvləri başa düşsələr və görürlərsə və onları necə düzəltmək olarsa, hiper-məsuliyyətin təzahürünə səbəb olur - "Xoşbəxtlik cəhalətdir", və nəticədə bu işçilərin tükənməsi və itirilməsi.
DevOps resurs bazarı
Müxtəlif şirkətlərin DevOps vəzifələri üçün bir neçə vakansiyaya baxaq.
Biz sizinlə görüşməyə hazırıq, əgər:
- Siz Zabbix sahibisiniz və Prometeyin nə olduğunu bilirsiniz;
- Haqqımızda Şirkətin Adı: Iptables;
- BASH PhD Tələbəsi;
- Professor Ansible;
- Linux Guru;
- Sazlamadan necə istifadə etməyi və tərtibatçılarla (php/java/python) birlikdə proqram problemlərini tapmağı bilmək;
- Marşrut sizi isterik etmir;
- Sistem təhlükəsizliyinə əhəmiyyətli diqqət yetirin;
- "Hər şeyi və hər şeyi" ehtiyat nüsxəsini çıxarın və həmçinin bu "hər şeyi və hər şeyi" uğurla bərpa edin;
- Sistemi minimumdan maksimum nəticə əldə etmək üçün necə konfiqurasiya edəcəyinizi bilirsiniz;
- Postgres və MySQL-də yatmazdan əvvəl replikasiya qurmaq;
- CI/CD-nin qurulması və tənzimlənməsi səhər yeməyi/nahar/şam yeməyi kimi sizin üçün zəruridir.
- AWS ilə təcrübəyə malik olmaq;
- Şirkətlə inkişaf etməyə hazır;
Belə ki:
- 1-dən 6-ya qədər - sistem administratoru
- 7 - bir az şəbəkə administrasiyası, bu da sistem administratoruna uyğundur, Orta səviyyə
- 8 - Orta səviyyəli sistem administratoru üçün məcburi olan bir az təhlükəsizlik
- 9-11 – Orta Sistem Administratoru
- 12 — Təyin edilmiş tapşırıqlardan asılı olaraq, Orta Sistem Administratoru və ya Quraşdırma Mühəndisi
- 13 - Virtuallaşdırma - Orta Sistem Administratoru və ya CloudOps adlanan, vəsaitlərdən səmərəli istifadə etmək və texniki xidmət yükünü azaltmaq üçün müəyyən bir hosting saytının xidmətləri haqqında qabaqcıl biliklər
Bu vakansiyanı ümumiləşdirərək deyə bilərik ki, uşaqlar üçün Orta/Böyük Sistem Administratoru kifayətdir.
Yeri gəlmişkən, Linux/Windows-da inzibatçıları ciddi şəkildə bölməməlisiniz. Əlbəttə, başa düşürəm ki, bu iki dünyanın xidmətləri və sistemləri fərqlidir, amma hamının əsası eynidir və özünə hörmət edən hər bir admin həm biri ilə tanışdır, həm də o biri ilə tanışdır və o, tanış olmasa da, olacaq. səlahiyyətli bir admin üçün onunla tanış olmaq çətin deyil.
Başqa bir vakansiyaya nəzər salaq:
- Yüksək yüklü sistemlərin qurulması təcrübəsi;
- Linux ƏS, ümumi sistem proqram təminatı və veb stek (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) üzrə mükəmməl bilik;
- Virtuallaşdırma sistemləri (KVM, VMWare, LXC/Docker) ilə iş təcrübəsi;
- Skript dillərində biliyi;
- Şəbəkə protokol şəbəkələrinin iş prinsiplərini başa düşmək;
- Xətaya davamlı sistemlərin qurulması prinsiplərini başa düşmək;
- Müstəqillik və təşəbbüskarlıq;
Gəlin baxaq:
- 1 – Baş Sistem Administratoru
- 2 - Bu yığına qoyulan mənadan asılı olaraq - Orta/Baş Sistem Administratoru
- 3 - İş təcrübəsi, o cümlədən, mənası ola bilər - "Klaster virtual maşınları qaldırmadı, lakin yaratdı və idarə etdi, bir Docker hostu var idi, konteynerlərə giriş mümkün deyildi" - Orta Sistem Administratoru
- 4 - Junior System Administrator - bəli, dildən asılı olmayaraq əsas avtomatlaşdırma skriptlərini yazmağı bilməyən admin, admin deyil - enikey.
- 5 - Orta Sistem Administratoru
- 6 – Baş Sistem Administratoru
Xülasə etmək üçün - Orta/Böyük Sistem Administratoru
Başqa biri:
- Devops təcrübəsi;
- CI/CD prosesləri yaratmaq üçün bir və ya bir neçə məhsuldan istifadə təcrübəsi. Gitlab CI üstünlüyü olacaq;
- Konteynerlərlə işləmək və virtuallaşdırma; Docker-dən istifadə etsəniz, yaxşıdır, amma k8-lərdən istifadə etsəniz, əla!
- Çevik komandada iş təcrübəsi;
- İstənilən proqramlaşdırma dilini bilmək;
Görək:
- 1 - Hmm... Uşaqlar nə demək istəyir? =) Çox güman ki, özləri də bunun arxasında nə gizləndiyini bilmirlər
- 2 - İnşaat mühəndisi
- 3 - Orta Sistem Administratoru
- 4 - Yumşaq bacarıq, hələlik bunu nəzərə almayacağıq, baxmayaraq ki, Çevik rahat şəkildə şərh olunan başqa bir şeydir.
- 5 - Çox ətraflı - bu bir skript dili və ya tərtib edilmiş bir dil ola bilər. Maraqlıdır, məktəbdə Paskal və Basic dillərində yazmaq onlara yaraşacaqmı? =)
Bu nöqtənin sistem administratoru tərəfindən niyə əhatə olunduğunu başa düşmək üçün 3-cü bəndlə bağlı bir qeyd də buraxmaq istərdim. Kubernetes sadəcə bir orkestrdir, şəbəkə sürücülərinə və virtuallaşdırma/izolyasiya hostlarına birbaşa əmrləri bir neçə əmrlə bağlayan və onlarla mücərrəd əlaqə yaratmağa imkan verən bir vasitədir, hamısı budur. Məsələn, “build framework” Make proqramını götürək, yeri gəlmişkən, mən çərçivə hesab etmirəm. Bəli, mən Make-ni hər yerdə, lazım olan və lazım olmayan yerdə itələmək modası haqqında bilirəm - məsələn, Maven-i Make-ə bükmək, məsələn, ciddi?
Əsasən, Make k8s kimi kompilyasiya, əlaqələndirmə və kompilyasiya mühiti əmrlərini sadələşdirən qabıq üzərində sarğıdır.
Bir dəfə mən OpenStack-in üstündəki işində k8-lərdən istifadə edən bir oğlanla müsahibə verdim və o, xidmətlərini necə yerləşdirdiyindən danışdı, lakin mən OpenStack haqqında soruşduqda məlum oldu ki, o, idarə olunur, həm də sistem tərəfindən qaldırılır. idarəçilər. Doğrudanmı sizcə, OpenStack-i quraşdırmış şəxs, arxasında hansı platformadan istifadə etməsindən asılı olmayaraq, k8-lərdən istifadə edə bilmir? =)
Bu ərizəçi əslində DevOps deyil, Sistem Administratoru və daha dəqiq desək, Kubernetes Administratorudur.
Bir daha ümumiləşdirək - Orta/Böyük Sistem Administratoru onlara kifayət edəcək.
Nə qədər qramla çəkin
Göstərilən vakansiyalar üçün təklif olunan əmək haqqı diapazonu 90k-200k təşkil edir
İndi Sistem Administratorları və DevOps Mühəndislərinin pul mükafatları arasında paralel çəkmək istərdim.
Prinsipcə, hər şeyi sadələşdirmək üçün iş təcrübəsinə əsaslanan qiymətləri səpələyə bilərsiniz, baxmayaraq ki, bu dəqiq olmayacaq, lakin məqalənin məqsədləri üçün kifayət edəcəkdir.
Bir təcrübə:
- 3 yaşa qədər - Junior
- 6 yaşa qədər - orta
- 6-dan çox - Senior
İşçi axtarış saytı təklif edir:
Sistem Administratorları:
- Junior - 2 yaş - 50k rub.
- Orta - 5 il - 70k rub.
- Yaşlı - 11 il - 100k rub.
DevOps Mühəndisləri:
- Junior - 2 yaş - 100k rub.
- Orta - 3 il - 160k rub.
- Yaşlı - 6 il - 220k rub.
"DevOps" təcrübəsinə görə, ən azı bir şəkildə SDLC-yə təsir edən təcrübə istifadə edilmişdir.
Yuxarıdakılardan belə nəticə çıxır ki, əslində şirkətlərin DevOps-a ehtiyacı yoxdur və həmçinin onlar İnzibatçı işə götürməklə ilkin planlaşdırılan xərclərin ən azı 50 faizinə qənaət edə bilirlər; üstəlik, onlar axtardıqları şəxsin məsuliyyətlərini daha aydın şəkildə müəyyən edə bilərlər. və ehtiyacı daha tez doldurun. Onu da unutmaq olmaz ki, vəzifələrin dəqiq bölgüsü bizə kadrlara olan tələbləri azaltmağa, eyni zamanda üst-üstə düşmə olmadığına görə kollektivdə daha əlverişli ab-hava yaratmağa imkan verir. Vakansiyaların böyük əksəriyyəti kommunal xidmətlər və DevOps etiketləri ilə doludur, lakin onlar DevOps Mühəndisi üçün faktiki tələblərə əsaslanmır, yalnız alət administratoru üçün sorğulardır.
DevOps mühəndislərinin hazırlanması prosesi də yalnız xüsusi işlərin, kommunal proqramların dəsti ilə məhdudlaşır və proseslər və onların asılılıqları haqqında ümumi anlayışı təmin etmir. Bir şəxs bu klasterdəki Fluentd yan arabası və giriş sistemi üçün AWS ELK yığını ilə birlikdə Terraform istifadə edərək AWS EKS-ni konsolda yalnız bir əmrdən istifadə edərək 10 dəqiqə ərzində yerləşdirə bilsə, əlbəttə ki, yaxşıdır, lakin o, logların özünün işlənməsi prinsipi və nə üçün lazım olduğu, əgər onlar üzrə ölçüləri toplamaq və xidmətin deqradasiyasını izləmək yollarını bilmirsinizsə, o zaman yenə də bəzi kommunal proqramlardan necə istifadə edəcəyini bilən eyni enikey olacaq.
Bununla belə, tələb təklif yaradır və biz DevOps mövqeyi üçün həddən artıq qızmış bazar görürük, burada tələblər faktiki rola uyğun gəlmir, ancaq sistem administratorlarına daha çox qazanmağa imkan verir.
Bəs onlar kimlərdir? DevOps və ya acgöz sistem administratorları? =)
Necə yaşamağa davam etmək olar?
İşəgötürənlər tələbləri daha dəqiq tərtib etməli və lazım olanları axtarmalı və etiketləri atmamalıdırlar. Siz DevOps-un nə etdiyini bilmirsiniz - bu halda onlara ehtiyacınız yoxdur.
İşçilər - Öyrən. Biliklərinizi daim təkmilləşdirin, proseslərin ümumi mənzərəsinə baxın və hədəfinizə gedən yolu izləyin. Kim istəyirsən ola bilərsən, sadəcə cəhd etməlisən.
Mənbə: www.habr.com