Son dövrlər belə elanlar interneti bürüyüb. Gözəl maaş olmasına baxmayaraq, içindəki dəhşətli boş sözlər narahat edir. Əvvəlcə «DevOps» və «mühəndis»in necə olursa olsun birləşə biləcəyi düşünülür, sonra isə tələblərdən ibarət rastgele bir siyahı təqdim edilir, bunların bir hissəsi açıq-aşkar sistem administratoru elanından götürülüb.
Bu yazıda DevOps-a necə gəldiyimiz barədə danışmaq istəyirəm və bununla indi nə etmək olar.
Bu cür vakansiyaları tənqid etmək mümkündür, amma fakt budur ki, onların sayı çoxdur və bazar belədir. Biz DevOps konfransı təşkil etdik və açıq şəkildə bəyan edirik: — DevOps mühəndisləri üçün deyil». Bir çoxlarına qəribə və dəhşətli görünsə də, tamamilə kommersiya fəaliyyətini həyata keçirən insanların bazara qarşı çıxmasının səbəbi nədir. İndi hər şeyi açıqlayacağıq.
Mədəniyyət və proseslər haqqında
DevOps-un mühəndislik disiplini olmadığını unutmayaq. Hər şey, tarixən rol ayrılığının məhsul keyfiyyətinə təsir etmədiyi ilə başladı. Programçılar yalnız kod yazdıqda, amma testdən xəbərləri olmadıqda, proqramlar buglarla doludur. Administratorlar proqramın necə və niyə yazıldığını umursamırsa, dəstək cəhənnəmə çevrilir.
Məsələn, sistem administratoru və SRE yanaşmaları arasındakı fərqi izah edən girişində başladı. Maraqlı araşdırmalar — görmək olar ki, ən yaxşı proqramçılar yeni dəyişikləri istehsala daha sürətlə yerləşdirməyi bacarır, saatda bir dəfədən az. Onlar əlləri ilə yalnız 10%-dən azını test edirlər (bu ). Onların bunu necə etdiyini bilirsinizmi? «Excel ya da öl» – hesabatın başlıqlarından biridir. Bu statistikaya test etmə baxımından detallı müzakirə üçün Barux Sadogurskinin başlıqlı başqa konfransımızda müraciət edə bilərsiniz, Heisenbug.
«Tərəfdaşlar arasında razılıq olmadıqda,
İşləri irəliləməyəcək,
Sadəcə acı olacaq.
Bir gün Lebed, Rəq və Şüka…»
Sizcə, veb proqramçılarının hansı hissəsi tətbiqlərinin istehsalda hansı şəraitdə işlədiyini anlayır? Onlardan nə qədərisə administratorlara gedib, verilənlərin düşməsi halında nə olacağını anlamağa çalışacaq? Ya da nə qədər testçilərə gedib, testləri necə düzgün yazmağı öyrənəcək? Orada daha təhlükəsizlik mütəxəssisləri, məhsul menecerləri və bir çox insan var.
DevOps-un ümumi ideyası rollar və departamentlər arasında əlaqəni qurmaqdır. Birincisi, bu, hər hansı bir cəfəngiyyatla deyil, ünsiyyət praktikası ilə əldə edilir. DevOps mədəniyyət, praktika, metodologiya və proseslər haqqındadır. Bu suallara cavab verən bir mühəndislik ixtisası yoxdur.
Dairəvi döngə
Onda «DevOps mühəndisliyi» disiplini hardan gəldi? Bizim bir versiyamız var! DevOps ideyaları o qədər yaxşı oldu ki, uğurlarının qurbanına çevrildi. Bu mövzu ətrafında bəzən şübhəli işçi agentləri və insan ticarəti ilə məşğul olanlar tüğyan etməyə başladı, özlərinə məxsus bir atmosfer var.
Təsəvvür edin: dünən siz Ximkdə dönər bişirirdiniz, bu gün isə artıq iri bir şəxs, senior işçi agentisiz. Burada namizəd axtarış və seçim prosesi var, hər şey çətin, başa düşmək lazımdır. Tutaq ki, şöbə müdiri deyir: X üzrə mütəxəssis tap. X-ə «mühəndis» sözünü əlavə edirik və iş tamamdır. Linux lazımdır? Yaxşı, o zaman bu tamamilə Linux mühəndisidir, DevOps istəsə — DevOps mühəndisi. Vəzifə yalnız başlıqdan ibarət deyil, içəridə də bir mətni yazmalısınız. Ən asanı — Google-dan bir neçə açar söz yazmaqdır, kimdə nə qədər xəyal gücü varsa. DevOps iki sözdən ibarətdir — «Dev» və «Ops», deməli, proqramçılarla administratorlara aid olan açar sözləri bir yerə yığmaq lazımdır. Beləliklə, 42 proqramlaşdırma dilini bilmək və eyni anda Kubernetes və Swarm istifadə etmək üçün iş yerləri yaranır. İş tam bu şəkildədir.
Beləliklə, insanların zehinlərində mənasız və amansız bir superqəhrəman-«DevOps» obrazı formalaşıb ki, o, hər kəsi Jenkins vasitəsilə yerləşdirməyi tənzimləyəcək və xoşbəxtlik gələcək. Ah, əgər hər şey bu qədər asan olsaydı. «Bundan başqa, sistem administratorlarını ovlamaq da olar, — deyə İnsan Resursları şöbəsinin müdiri düşünür, — moda sözdür, açar sözlər eynidir, tutmalıdılar».
Tələb təklifi doğurur və bütün bu absurd iş yerlərinə dəlisov sayda sistem administratorları hücum etdi. Onlar başa düşdü ki, əvvəllər etdikləri eyni işi daha yüksək maaşla «DevOps» adlandıraraq edə bilərlər. Serverləri SSH ilə bir-bir əl ilə necə tənzimlədinizsə, eləcə də davam edəcəksiniz, amma indi bu iddia olunmuş DevOps təcrübəsidir. Bu, bir baxımda mürəkkəb bir fenomen, köhnə administratorların dəyərləndirilməməsi və DevOps ətrafındakı həyəcanla əlaqədardır, amma ümumilikdə — nə oldu, oldu.
Beləliklə, bizdə tələb və təklif var. Özünü tükəndirən bir döngü ki, özünü qidalandırır. Biz bununla mübarizə aparırıq (o cümlədən, DevOops konfransını təşkil edərək).
Təbii ki, «DevOps»a adlarını dəyişən sistem administratorlarından savayı, digər iştirakçılar da var — məsələn, peşəkar SRE-lər və Infrastructure-as-Code inkişaf etdiriciləri.
İnsanlar DevOps-da (həqiqətən) nə ilə məşğuldur
Beləliklə, siz DevOps praktikasını öyrənmək və tətbiq etmək istəyirsiniz. Amma bunu necə etmək olar, hansı tərəfə baxmalısınız? Aydındır ki, məşhur açar sözlərlə kor-koranə hərəkət etmək lazım deyil.
Əgər iş varsa, kimsə buna baxmalıdır. Artıq təsdiq etdik ki, bu «DevOps mühəndisləri» deyil, bəs kim? Görünür ki, bunu vəzifə terminləri ilə yox, konkret iş sahələri ilə ifadə etmək daha doğru olar.
Birincisi, DevOps'un kalbi olan süreçler ve kültürle ilgilenmek mümkündür. Kültür, yavaş ve kolay olmayacak bir meseledir ve bu geleneksel olarak yöneticilerin sorumluluğunda olsa da, programcılardan yöneticilere kadar herkes bunun içinde yer alır. Birkaç ay önce Tim Lister :
«Kültür, organizasyonun temel değerleriyle belirlenir. Genellikle insanlar bunu fark etmez, ancak yıllarca danışmanlık yaparak, bunu gözlemlemeye alıştık. Bir şirkete girdiğimizde, sadece birkaç dakika içinde ne olduğunu hissetmeye başlarsınız. Bunu ‘aroma’ olarak adlandırıyoruz. Bazen bu aroma gerçekten hoş. Bazen mide bulandırıcı. (…) Kültürü, belirli eylemlerin arkasındaki değerler ve inançlar kavranmadan değiştiremezsiniz. Davranışı gözlemlenmesi kolaydır, ancak inançları aramak zordur. DevOps, her şeyin giderek daha karmaşık hale geldiği mükemmel bir örnektir.»
Tabii ki, bir teknik tarafı da var meselenin. Eğer yeni kodunuz bir ay boyunca test aşamasında kalıyorsa ve sürüm ise ancak bir yıl sonra çıkıyorsa, tüm bunları hızlandırmak fiziksel olarak mümkün değilse, iyi uygulamalara erişemeyebilirsiniz. İyi uygulamalar, iyi araçlarla desteklenir. Örneğin, Infrastructure-as-Code fikrini aklınızda tutarak, AWS CloudFormation ve Terraform'dan tutun da Chef-Ansible-Puppet'a kadar her şeyi kullanabilirsiniz. Tüm bunları bilmek ve yapabilmek gereklidir ve bu artık tam anlamıyla mühendislik disiplinidir. Sebep ile sonuçları karıştırmamak önemlidir: önce SRE prensiplerine göre çalışırsınız, ardından bu prensipleri belirli teknik çözümler haline getirirsiniz. Bu durumda SRE, yalnızca Jenkins'i nasıl yapılandırabileceğinizi değil, beş temel ilkeden bahseden çok kapsamlı bir metodolojidir:
- Roller ve departmanlar arasındaki iş birliğini geliştirmek
- Hataları işin ayrılmaz bir parçası olarak kabul etmek
- Değişiklikleri kademeli olarak gerçekleştirmek
- Araçları ve diğer otomasyonları kullanmak
- Ölçebileceğiniz her şeyi ölçmek
Bu sadece bir dizi ifade değil, somut bir . Örneğin, hataları kabul etme aşamasında risklerle ilgili olarak, bir şeyler yaparak hizmetlerin erişilebilirliğini ve erişilemezliğini ölçmeniz gerekecek, böylesi bir SLI () ve SLO (), yazılım sonrası raporları yazmayı öğrenmek ve bunun korkutucu olmamasını sağlamak gerekecek.
SRE disiplininde araç kullanımı, başarıya ulaşmanın yalnızca bir parçasıdır, ancak yine de önemli bir parçadır. Teknik anlamda sürekli gelişmemiz, dünyada neler olup bittiğini takip etmemiz ve bunu işimize nasıl uygulayacağımızı düşünmemiz gerekiyor.
Öz növbəsində, bu günlərdə Cloud Native həlləri çox populyarlaşmağa başladı. Müasir Cloud Native Computing Foundation anlayışına görə, Cloud Native texnologiyaları təşkilatlara müasir dinamik mühitlərdə, məsələn, ictimai, özəl və hibrid buludlarda miqyaslana bilən tətbiqləri inkişaf etdirmək və işə salmaq imkanı verir. Məsələn, konteynerlər, service mesh-lər, mikrosistemlər, dəyişməz infrastruktur və deklarativ API-lər göstərilə bilər. Bu texnikaların hamısı zəif bağlı sistemlərin elastik, idarə olunan və yaxşı müşahidə olunan olmasına kömək edir. Yaxşı avtomatlaşdırma mühəndislərə böyük dəyişikliklər etməyə imkan yaradır, tez-tez və proqnozlaşdırıla bilən nəticələrlə, bunu dəhşətli bir işə çevirmədən. Bütün bunlar Docker və Kubernetes kimi hamının tanıdığı alətlərin yığını ilə dəstəklənir.
Bu, olduqca mürəkkəb və geniş bir tərifdir, çünki sahə də olduqca çətindir. Bir tərəfdən, bu sistemə olan yeniliklərin əlavə edilməsi kifayət qədər asan olmalıdır. Digər tərəfdən, bir konteynerləşdirilmiş mühitin necə yaradılacağını anlamaq, burada zəif bağlı xidmətlərin software-defined infrastrukturda yaşaması və davamlı CI/CD vasitəsilə təmin edilməsi və DevOps məşğələlərinin ətrafında qurulması üçün bir çox şey öyrənmək lazım olacaq.
Bununla nə etməliyik
Hər kəs bu problemləri öz yoluna görə həll edir: məsələn, dövrü qırmaq üçün normal iş elanları yayımlaya bilərsiniz. DevOps və Cloud Native kimi sözlərin mənalarını anlamaq və onları düzgün və məqsədli istifadə etmək mümkündür. DevOps sahəsində inkişaf edib, düzgün yanaşmaları öz nümunənizlə nümayiş etdirmək mümkündür.
Biz konfrans təşkil edirik , bu da bir az əvvəl danışdığımız məsələlərə daha dərindən başa düşmək imkanı təqdim edir. Bunun üçün bir neçə təqdimat qrupu var:
- Prosesslər və mədəniyyət;
- Sayt Etibarlılığı Mühəndisliyi;
- Cloud Native;
Haraya getməli? Burada incə bir məqam var. Bir tərəfdən, DevOps qarşılıqlı əlaqə ilə bağlıdır və biz sizin fərqli bloklardan təqdimatlara qatılmanızı çox istəyirik. Digər tərəfdən, əgər siz bir inkişaf rəhbərisinizsə və konfransa konkret bir məsələyə diqqət yetirmək üçün gəlibsinizsə, heç kim sizi məhdudlaşdırmır - açıqdır ki, bu proseslər və mədəniyyət bloku olacaq. Unutmayın ki, konfransdan sonra sizdə qeydlər qalacaq (geribildirim forması doldurulduqdan sonra), ona görə də hər zaman daha az vacib təqdimatları daha sonra görə bilərsiniz.
Aydındır ki, konfransda eyni anda üç trəkə getmək mümkün deyil, buna görə də proqramı elə tərtib edirik ki, hər zaman fərqli zövqlərə uyğun mövzular olsun.
Yalnızca bir DevOps mühendisinin ne yapması gerektiğini anlamak kaldı! İlk olarak, gerçekten neyle uğraştığınızı belirlemeye çalışın. Bu kelime genellikle şunları tanımlamak için kullanılır:
- Altyapıyla ilgilenen geliştiriciler. Bu konuda en uygun olanlar SRE ve Cloud Native ile ilgili sunum gruplarıdır.
- Sistem yöneticileri. Burada işler daha karmaşık. DevOops, sistem yönetimi ile ilgili değil. Neyse ki, sistem yönetimiyle ilgili pek çok harika konferans, kitap, makale, çevrimiçi videolar vb. mevcut. Öte yandan, kültür ve süreçleri anlama, bulut teknolojilerini öğrenme ve Cloud Native ile yaşamın inceliklerini keşfetme konusunda gelişmekle ilgileniyorsanız, sizi aramızda görmekten mutluluk duyarız! Şunu düşünün: admin olarak çalışıyorsunuz, peki sonra ne yapacaksınız? Aniden hoş olmayan bir durumla karşılaşmamak için şu anda öğrenmeye başlamakta fayda var.
Başka bir seçenek daha var: ısrar ediyor ve DevOps mühendisiyim demeye devam ediyorsunuz. tam olarak DevOps mühendisi ve başka bir şey değil, ne anlama gelirse gelsin. O zaman üzülerek belirtmek zorundayız ki, DevOops - DevOps mühendisleri için bir konferans değil!
Slaid Münih'te
DevOops 2020 Moskova, 29-30 Nisan tarihlerinde Moskova'da gerçekleşecek, biletler zaten .
Ayrıca, 8 Şubat'a kadar. Formu doldururken, sunumunuzdan en fazla yararı alacak hedef kitleyi seçtiğinize dikkat edin (listenin içinde sürpriz var).
Mənbə: habr.com
