Son zamanlar interneti belə reklamlar bürüdü. Xoş maaşa baxmayaraq, içəridə vəhşi bidət yazılmasından utanmaya bilmirsən. Əvvəlcə güman edilir ki, "DevOps" və "mühəndis" bir şəkildə bir sözə yapışdırıla bilər və sonra təsadüfi tələblər siyahısı var, bəziləri sistematik vakansiyadan aydın şəkildə kopyalanır.
Bu yazıda həyatın bu nöqtəsinə necə gəldiyimiz, DevOps-un əslində nə olduğu və indi onunla nə edəcəyimiz haqqında bir az danışmaq istərdim.
Bu cür vakansiyaları hər cür qınamaq olar, amma fakt faktlığında qalır: onların çoxu var və hazırda bazar belə işləyir. Biz devops konfransı keçirdik və açıq şəkildə bəyan edirik: “ - DevOps mühəndisləri üçün deyil." Bu, çoxlarına qəribə və vəhşi görünəcək: niyə tamamilə kommersiya tədbiri keçirən insanlar bazara qarşı çıxırlar? İndi hər şeyi izah edəcəyik.
Mədəniyyət və proseslər haqqında
DevOps-un mühəndislik sahəsi olmadığından başlayaq. Hamısı ondan başladı ki, tarixən formalaşmış rol bölgüsü məhsulların keyfiyyəti üçün işləmir. Proqramçılar yalnız proqramlaşdırdıqda, lakin sınaq haqqında heç nə eşitmək istəmədikdə, proqram səhvlərlə doludur. Adminlər proqram təminatının necə və nə üçün yazıldığına əhəmiyyət vermədikdə, dəstək cəhənnəmə çevrilir.
Məsələn, sistem administratoru ilə xidmətin idarə edilməsinə SRE yanaşması arasındakı fərqi təsvir etmək . daxilində maraqlı araşdırmalar aparılıb — aydındır ki, ən yaxşı tərtibatçılar hansısa yolla istehsala yeni dəyişiklikləri saatda bir dəfədən daha tez yerləşdirməyi bacarırlar. Əlləri ilə 10% -dən çox olmayan test edirlər (bunu buradan görmək olar ). Bunu necə edirlər? Hesabatın başlıqlarından birində “Mükəmməl ol, ya öl” deyilir. Test kontekstində bu statistikanın ətraflı müzakirəsi üçün Baruch Sadogurskinin əsas çıxışına müraciət edə bilərsiniz. digər konfransımızda, Heisenbug.
“Yoldaşlar arasında razılıq olmadıqda,
Onlar üçün işlər yaxşı getməyəcək,
Və ondan heç nə çıxmayacaq, yalnız əzab.
Bir vaxtlar Qu, Xərçəng və Pike..."
Sizcə, veb proqramçıların hansı hissəsi onların tətbiqlərinin istehsalda istifadə olunduğu şərtləri həqiqətən başa düşür? Onlardan neçəsi adminlərə gedəcək və verilənlər bazası çöksə nə olacağını anlamağa çalışacaq? Bəs onlardan hansı testerlərin yanına gedib testləri düzgün yazmağı öyrətmələrini xahiş edəcək? Həm də mühafizəçilər, məhsul menecerləri və bir çox başqa insanlar var.
DevOps-un ümumi ideyası rollar və şöbələr arasında əməkdaşlıq yaratmaqdır. Əvvəla, bu, bəzi ağıllı şəkildə konfiqurasiya edilmiş proqram təminatı ilə deyil, ünsiyyət təcrübəsi ilə əldə edilir. DevOps mədəniyyət, təcrübə, metodologiya və proseslər haqqındadır. Bu suallara cavab verə biləcək mühəndislik ixtisası yoxdur.
Vicious circle
O zaman "devops engineering" intizamı haradan gəldi? Bir versiyamız var! DevOps ideyaları yaxşı idi - o qədər yaxşı idi ki, öz uğurlarının qurbanı oldular. Bəzi kölgəli işəgötürənlər və öz atmosferi olan insan alverçiləri bütün bu mövzu ətrafında fırlanmağa başladılar.
Təsəvvür edin: dünən Ximkidə şawarma hazırlayırsınız və bu gün artıq böyük bir insansınız, böyük işəgötürənsiniz. Namizədlərin axtarışı və seçilməsi ilə bağlı bütöv bir proses var, hər şey asan deyil, başa düşmək lazımdır. Deyək ki, şöbə müdiri deyir: X-də mütəxəssis tapın. X-ə “mühəndis” sözünü təyin edirik və işimiz bitdi. Linux lazımdır? Yaxşı, bu, mütləq Linux mühəndisidir, əgər DevOps istəyirsinizsə, DevOps mühəndisi. Vakansiya təkcə başlıqdan ibarət deyil, həm də içəriyə bəzi mətnlər daxil edilməlidir. Ən asan yol, təsəvvürünüzdən asılı olaraq Google-dan bir sıra açar sözlər daxil etməkdir. DevOps iki sözdən ibarətdir - "Dev" və "Ops", bu o deməkdir ki, biz tərtibatçılar və idarəçilər ilə əlaqəli açar sözləri bir yığında birləşdirməliyik. 42 proqramlaşdırma dilində bilik və 20 il Kubernetes və Swarm-dan eyni vaxtda istifadə ilə bağlı vakansiyalar belə görünür. İş qrafiki.
Müəyyən bir "devops" superqəhrəmanının mənasız və amansız obrazı insanların şüurunda belə kök saldı, o, hər kəsi Jenkins-ə yerləşdirmək üçün konfiqurasiya edəcək və xoşbəxtlik gələcək. Ah, kaş hər şey bu qədər sadə olsaydı. HR hesab edir ki, "Sistem administratorlarını da belə ovlaya bilərsiniz," bu dəbli sözdür, açar sözlər eynidir, onlar yemi götürməlidirlər."
Tələb tədarükü yaradır və bütün bu zibil vakansiyaları çoxlu sayda sistem administratoru ilə doldurulub ki, onlar başa düşdülər: siz hər şeyi əvvəlki kimi edə bilərsiniz, ancaq özünüzü “devops” adlandırmaqla bir neçə dəfə daha çox şey əldə edə bilərsiniz. SSH vasitəsilə serverləri bir-bir konfiqurasiya etdiyiniz kimi, onları konfiqurasiya etməyə davam edəcəksiniz, lakin indi bu, guya devops təcrübəsidir. Bu, qismən klassik adminlərin qiymətləndirilməməsi və DevOps ətrafındakı şırınga ilə əlaqəli bir növ mürəkkəb hadisədir, lakin ümumiyyətlə, baş verənlər baş verdi.
Beləliklə, tələb və təklifimiz var. Özünü qidalandıran pis bir dairə. Buna qarşı mübarizə aparırıq (o cümlədən DevOops konfransını yaratmaqla).
Əlbəttə ki, özlərini "devops" adlandıran sistem administratorlarından başqa, digər iştirakçılar da var - məsələn, peşəkar SRE-lər və ya İnfrastruktur-kod tərtibatçıları.
İnsanlar DevOps-da nə edir (həqiqətən)
Beləliklə, siz DevOps təcrübələrini öyrənmək və tətbiq etməkdə irəli getmək istəyirsiniz. Bəs bunu necə etmək, hansı istiqamətə baxmaq lazımdır? Aydındır ki, məşhur açar sözlərə kor-koranə etibar etməməlisiniz.
İş varsa, kimsə görməlidir. Artıq bildik ki, bunlar “devops mühəndisləri” deyil, bəs kimlərdir? Bunu vəzifələrə görə deyil, konkret iş sahələrinə görə formalaşdırmaq daha düzgün görünür.
Birincisi, siz DevOps-un ürəyinə - proseslərə və mədəniyyətə müraciət edə bilərsiniz. Mədəniyyət yavaş və çətin bir işdir və ənənəvi olaraq menecerlərin məsuliyyəti olsa da, proqramçılardan tutmuş idarəçilərə qədər hər kəs bu və ya digər şəkildə iştirak edir. Bir neçə ay əvvəl Tim Lister :
“Mədəniyyət təşkilatın əsas dəyərləri ilə müəyyən edilir. Adətən insanlar bunu hiss etmirlər, amma uzun illər konsaltinqdə işlədiyimiz üçün biz bunu hiss etməyə öyrəşmişik. Bir şirkətə daxil olursunuz və sözün əsl mənasında bir neçə dəqiqə ərzində nə baş verdiyini hiss etməyə başlayırsınız. Biz buna "ləzzət" deyirik. Bəzən bu qoxu həqiqətən gözəldir. Bəzən bulantıya səbəb olur. (...) Xüsusi hərəkətlərin arxasında duran dəyərlər və inanclar başa düşülməyənə qədər mədəniyyəti dəyişdirə bilməzsiniz. Davranışı müşahidə etmək asandır, amma inancları axtarmaq çətindir. DevOps işlərin getdikcə daha da mürəkkəbləşdiyinin sadəcə gözəl nümunəsidir.”
Təbii ki, məsələnin texniki tərəfi də var. Yeni kodunuz bir ay ərzində sınaqdan keçirilirsə, ancaq bir il sonra buraxılırsa və hamısını sürətləndirmək fiziki cəhətdən mümkün deyilsə, yaxşı təcrübələrə əməl etməyə bilərsiniz. Yaxşı təcrübələr yaxşı vasitələrlə dəstəklənir. Məsələn, İnfrastructure-as-Code ideyasını nəzərə alaraq, AWS CloudFormation və Terraform-dan tutmuş Chef-Ansible-Puppet-ə qədər hər şeydən istifadə edə bilərsiniz. Bütün bunları bilmək və bacarmaq lazımdır və bu, artıq kifayət qədər mühəndislik intizamıdır. Səbəbi nəticə ilə qarışdırmamaq vacibdir: əvvəlcə SRE prinsiplərinə uyğun işləyirsiniz və yalnız bundan sonra bu prinsipləri bəzi xüsusi texniki həllər şəklində həyata keçirirsiniz. Eyni zamanda, SRE sizə Jenkins-in necə qurulacağını deyil, təxminən beş əsas prinsipi izah edən çox əhatəli bir metodologiyadır:
- Rollar və şöbələr arasında təkmilləşdirilmiş ünsiyyət
- Səhvləri işin ayrılmaz hissəsi kimi qəbul etmək
- Tədricən dəyişikliklər etmək
- Alətlərdən və digər avtomatlaşdırmadan istifadə
- Ölçülə bilən hər şeyi ölçmək
Bu, sadəcə bəzi ifadələr deyil, konkretdir . Məsələn, səhvləri qəbul etmək yolunda riskləri başa düşməli, SLI kimi bir şeydən istifadə edərək xidmətlərin mövcudluğunu və əlçatmazlığını ölçməli olacaqsınız.) və SLO (), postmortems yazmağı öyrənin və onları yazmaq qorxulu olmasın.
SRE intizamında alətlərdən istifadə mühüm olsa da, uğurun yalnız bir hissəsidir. Biz daim texniki cəhətdən inkişaf etməliyik, dünyada baş verənlərə və onun işimizdə necə tətbiq oluna biləcəyinə baxmalıyıq.
Öz növbəsində, Cloud Native həlləri indi çox populyarlaşdı. Bu gün Cloud Native Computing Foundation tərəfindən müəyyən edildiyi kimi, Cloud Native texnologiyaları təşkilatlara ictimai, özəl və hibrid buludlar kimi bugünkü dinamik mühitlərdə genişlənə bilən proqramlar hazırlamağa və işə salmağa imkan verir. Nümunələrə konteynerlər, xidmət şəbəkələri, mikroservislər, dəyişməz infrastruktur və deklarativ API-lər daxildir. Bütün bu üsullar sərbəst bağlanmış sistemlərin elastik, idarə oluna bilən və yüksək dərəcədə müşahidə oluna bilən qalmasına imkan verir. Yaxşı avtomatlaşdırma mühəndislərə işi çətinləşdirmədən tez-tez və proqnozlaşdırıla bilən nəticələrlə böyük dəyişikliklər etməyə imkan verir. Bütün bunlar Docker və Kubernetes kimi tanınmış alətlər yığını tərəfindən dəstəklənir.
Bu kifayət qədər mürəkkəb və geniş tərif ərazinin də kifayət qədər mürəkkəb olması ilə əlaqədardır. Bir tərəfdən, bu sistemə yeni dəyişikliklərin kifayət qədər sadə şəkildə əlavə edilməli olduğu iddia edilir. Digər tərəfdən, proqram təminatı ilə müəyyən edilmiş infrastrukturda sərbəst birləşdirilmiş xidmətlərin yaşadığı və orada davamlı CI/CD istifadə edərək çatdırıldığı bir növ konteyner mühitinin necə yaradılacağını anlamaq və bütün bunlar ətrafında DevOps təcrübələrini qurmaq - bütün bunlar daha çox tələb edir. daha bir it yeyir.
Bütün bunlarla nə etmək lazımdır
Hər kəs bu problemləri özünəməxsus şəkildə həll edir: məsələn, sızan dairəni qırmaq üçün normal vakansiyalar dərc edə bilərsiniz. Siz DevOps və Cloud Native kimi sözlərin nə demək olduğunu anlaya və onlardan düzgün və məqsədəuyğun istifadə edə bilərsiniz. Siz DevOps-da inkişaf edə və nümunənizlə düzgün yanaşmaları nümayiş etdirə bilərsiniz.
Konfrans edirik , bu da danışdığımız şeyləri daha dərindən araşdırmaq imkanı verir. Bunun üçün bir neçə hesabat qrupu var:
- Proseslər və mədəniyyət;
- Saytın etibarlılığı mühəndisliyi;
- Cloud Native;
Hara getməyi necə seçmək olar? Burada incə bir məqam var. Bir tərəfdən, DevOps qarşılıqlı əlaqə haqqındadır və biz həqiqətən müxtəlif bloklardan təqdimatlarda iştirak etməyinizi istəyirik. Digər tərəfdən, əgər siz konfransa diqqəti bir konkret tapşırıq üzərində cəmləmək üçün gələn bir inkişaf menecerisinizsə, o zaman heç kim sizi məhdudlaşdırmır - açıq-aydın bu, proseslər və mədəniyyət üzərində blok olacaq. Unutmayın ki, konfransdan sonra (əlaqə formasını doldurduqdan sonra) səsyazmalarınız olacaq ki, daha az əhəmiyyətli təqdimatlara daha sonra baxa bilərsiniz.
Aydındır ki, konfransın özündə siz birdən-birə üç trasa gedə bilməzsiniz, ona görə də proqramı elə təşkil edirik ki, hər vaxt intervalında hər zövqə uyğun mövzular olsun.
Qalan tək şey DevOps mühəndisisinizsə nə edəcəyinizi anlamaqdır! Əvvəlcə həqiqətən nə etdiyinizi müəyyənləşdirməyə çalışın. Adətən bu sözü çağırmağı xoşlayırlar:
- İnfrastruktur üzərində işləyən tərtibatçılar. SRE və Cloud Native haqqında hesabat qrupları sizin üçün ən uyğundur.
- Sistem administratorları. Burada daha mürəkkəbdir. DevOops sistem idarəçiliyi ilə bağlı deyil. Xoşbəxtlikdən, sistem idarəçiliyi mövzusunda çoxlu əla konfranslar, kitablar, məqalələr, İnternetdə videolar və s. Digər tərəfdən, mədəniyyət və prosesləri başa düşmək, bulud texnologiyaları və Cloud Native ilə həyatın təfərrüatlarını öyrənmək baxımından özünüzü inkişaf etdirmək istəyirsinizsə, o zaman sizi görməkdən məmnun olarıq! Bir düşünün: siz idarəçilik edirsiniz, sonra nə edəcəksiniz? Birdən xoşagəlməz bir vəziyyətə düşməmək üçün indi öyrənməlisiniz.
Başqa bir seçim də var: siz israr edirsiniz və olduğunuzu iddia etməyə davam edirsiniz xüsusilə DevOps mühəndisi və başqa heç nə, bu nə deməkdir. Onda sizi məyus etməliyik, DevOops DevOps mühəndisləri üçün konfrans deyil!
-dən sürüşdürün Münhendə
DevOops 2020 Moskva 29-30 aprel tarixlərində Moskvada keçiriləcək, biletlər artıq mövcuddur .
Alternativ olaraq edə bilərsiniz fevralın 8-dək. Nəzərə alın ki, formanı doldurarkən hesabatınızdan ən çox faydalanacaq hədəf auditoriyanı seçməlisiniz (siyahının içində bir sürpriz var).
Mənbə: www.habr.com