Express 42'nin yönetici ortağı ve yazar Alexander Titov, bu bilgiyle nereye gidileceği, projede ne yapılacağı ve ne kadar kazanılacağı, röportajda ne söyleneceği ve sorulacağı diyor .
Merhaba! DevOps terimi 2009'dan beri var olmasına rağmen Rus toplumunda hala bir fikir birliği yok. Muhtemelen bazılarının DevOps'u bir uzmanlık alanı olarak gördüğünü, bazılarının bunu bir felsefe olarak gördüğünü ve bazılarının da bu terimi bir dizi teknoloji olarak gördüğünü fark etmişsinizdir. Zaten birçok kez performans sergiledim Bu yönün gelişimi hakkında, bu yüzden bu makalede ayrıntıya girmeyeceğim. Express 42'ye aşağıdakileri dahil ettiğimizi söyleyeyim:
DevOps, ekipteki tüm uzmanların üretime katıldığı özel bir metodoloji, dijital ürün yaratma kültürüdür.
Klasik kurumsal geliştirmede her şey sırayla ilerler: programlama, test etme ve ancak ondan sonra operasyon ve bu sürecin fikirden üretime kadar olan hızı 3 aydır. Bu, dijital ürünler için küresel bir sorundur çünkü müşterilerden hızlı bir şekilde geri bildirim almak imkansızdır.
DevOps'ta geliştirme, test ve operasyon süreçlerinin eş zamanlı yürümesini sağlayacak araçlar ve yaklaşımlar tasarlanıyor.
Bu yaklaşımdan ne sonuç çıkıyor?
- Gelip üretimle ilgili tüm sorunları çözecek bir “mühendis” kiralayamazsınız. Tekniği tüm ekibin uygulaması gerekir.
- DevOps, yükseltilecek bir sonraki sistem yöneticisi biçimi DEĞİLDİR. "DevOps mühendisi", "Çevik geliştirici" ile hemen hemen aynı sese sahiptir.
- Bir ekibin Kubernetes, Ansible, Prometheus, Mesosfer ve Docker kullanıyor olması orada DevOps uygulamalarının yapıldığı anlamına gelmez.
DevOps'tan sonraki hayat asla aynı olmayacak
DevOps yaklaşımı her şeyden önce farklı bir düşünce biçimi, gelişimin bir bütün olarak algılanması ve süreçteki yerinin anlaşılmasıdır. Çevrimiçi kursumuzu 2 bloğa ayırdık:
1. Kendi kaderini tayin etme
Öncelikle DevOps yaklaşımının özünü detaylı bir şekilde inceliyoruz ve öğrenciler ekipte yeni roller keşfediyor, hangisinin daha fazla yanıt verdiğini görüyor ve hangi yönü geliştirmeleri gerektiğini kendileri belirliyor.
2. Araçlar ve uygulamalar
Öğrenciler DevOps yöntemi açısından belirli teknolojilerde uzmanlaşırlar.
DevOps araçları hem DevOps yaklaşımında hem de klasik geliştirmede kullanılabilir. En bariz örnek, Ansible konfigürasyon yönetimi aracının kullanılması olacaktır. İşletim sistemi ayarlarından uygulama yazılımına kadar sistemin farklı durumlarının tanımlandığı anlamına gelen DevOps uygulaması "Kod Olarak Altyapı"yı uygulamak için oluşturulmuş ve tasarlanmıştır. Açıklama katmanlara bölünmüştür ve karmaşık, sürekli değişen bir konfigürasyonu yönetmenize olanak tanır. Ancak mühendisler genellikle birden çok makinede bash komut dosyalarını çalıştırmanın bir yolu olarak Ansible'ı kullanır. Bu ne kötü ne de iyi ancak Ansible'ın varlığının şirkette DevOps'un varlığını garanti etmediğini anlamalısınız.
Biz sürecin içindeyiz Ünlü Reddit'e benzer bir uygulama geliştirme sürecine dalmış olacaksınız, monolitik versiyonundan başlayarak adım adım mikro hizmetlere ilerleyeceksiniz. Adım adım yeni araçlarda ustalaşacağız: Git, Ansible, Gitlab ve Kubernetes ve Prometheus ile bitireceğiz.
Uygulamalar açısından, DevOps El Kitabı'nda açıklanan üç yolun taktiklerini takip edeceğiz: sürekli dağıtım uygulamaları, geri bildirim uygulamaları ve tüm kursun özü, sisteminizle birlikte sürekli öğrenme uygulamasıdır.
Bu bilgi uzmanların her birine ne veriyor?
Sistem yöneticileri için
Uygulamalar, yönetimden uzaklaşarak sürekli bir dağıtım hattı ve yazılım dağıtımı için bir altyapı platformu oluşturmaya doğru ilerlemenizi sağlayacaktır. Mesele şu ki, geliştiriciler için değişiklikleri hızlı bir şekilde üretime aktarmalarına yardımcı olan bir altyapı platformu olan bir ürün yaratıyor.
Daha önce sistem yöneticileri son kaleydi ve sonrasında her şey üretime geçiyordu. Ve temelde sürekli yangınla mücadeleyle meşgullerdi - bunun ışığında işin ihtiyaçlarını araştırmak, ürünü ve kullanıcıya faydalarını düşünmek oldukça zor.
DevOps yöntemi sayesinde düşünce değişir. Sistem yöneticisi, konfigürasyonun koda nasıl çevrileceğini, bunun için hangi uygulamaların mevcut olduğunu anlar.
Bu önemlidir, çünkü şirketler giderek her şeyi otomatikleştirmeye ihtiyaç duymadıklarının farkına varıyorlar. eski tarz sistem yöneticilerinin esasen yapmaya alışkın olduğu şey, ayrıca bu çok az iletişim kurdu ve yapılan tüm değişiklikler hakkında ekibi bilgilendirmedi. Ekipler artık iç altyapı ürününün üreticisi olacak ve ayrı süreçlerin tek bir süreçte birleştirilmesine yardımcı olacak kişileri arıyor.
geliştiriciler
Geliştirici yalnızca algoritmalarda düşünmeyi bırakır. Altyapıyla çalışma becerisi, peyzajın mimari farkındalığı becerisini kazanır. Böyle bir geliştirici, uygulamanın nasıl çalıştığını, sürekli dağıtım hattından nasıl geçtiğini, nasıl izleneceğini, müşteriye fayda sağlayacak şekilde nasıl kaydedileceğini anlar. Sonuç olarak, tüm bu bilgiler ilgili kodu yazmanıza olanak tanır.
Test kullanıcıları için
Test uzun süredir otomatik moda geçiyor; hepimiz birçok testin yapılmaması, yazılı olması gerektiğini söylüyoruz :) Test, ürününüzün tüm teslimat sürecinin bir parçası haline gelir. Bir test uzmanının yalnızca kodun nasıl yazılacağını öğrenmesi değil, aynı zamanda onu sürekli dağıtım sistemlerine nasıl entegre edeceğini, teslimatın tüm aşamalarında koddan nasıl geri bildirim alacağını ve hataları tespit etmek için testi sürekli olarak nasıl geliştireceğini anlaması gerekir. mümkün olduğu kadar erken.
Yani o çıkıyor üç aşamanın tümü aynı anda gerçekleşir. Örneğin, şöyle görünebilir:
Geliştirici kodu yazar, hemen bunun için testler yazar ve çalıştırılması gereken kod için bir docker konteynerini tanımlar. Ayrıca bu hizmetin üretimdeki işleyişini izleyecek izlemeyi de hemen açıklar ve tüm bunları taahhüt eder.
Sürekli entegrasyon başladığında süreçler eş zamanlı olarak çalışır. Hizmet başlar ve yapılandırılır. Aynı zamanda docker konteyneri başlatılır ve çalışıp çalışmadığı kontrol edilir. Aynı zamanda tüm bilgiler kayıt sistemine gider. Ve böylece geliştirmenin her aşamasında - sistem yöneticileri, geliştiriciler ve test uzmanlarından oluşan gerçek bir ekip çalışması ortaya çıkıyor.
DevOps okudum, sırada ne var?
Bildiğiniz gibi sahada olan kişi savaşçı değildir. Eğer şirketiniz bu yöntemi kullanmazsa edinilen beceriler boşta kalacaktır. DevOps yaklaşımlarını öğrendikten sonra büyük ihtimalle kurumsal gelişimde dişli olmak istemeyeceksiniz. Bir istisna olabilir: Ekipte sistem yöneticisisiniz ve tüm süreçleri yeni bir şekilde yeniden oluşturabilirsiniz. Bu yaklaşımı kullanan pek çok firmanın karantinadan etkilenmediğini ve uzman aradığını da burada eklemekte fayda var. Çünkü DevOps çevrimiçi ürünler yaratmayla ilgilidir.
Şimdi işin iyi yönlerine gelelim: DevOps uygulamalarına ve araçlarına hakim olmak, iş gücü piyasasındaki değerinizin yaklaşık %30'unu oluşturur. Maaşlar 140 bin ruble'den başlıyor ancak doğal olarak ana uzmanlığınıza ve işlevselliğinize göre belirleniyor.
Test otomasyonunun, bulut teknolojilerini kullanarak mikro hizmet uygulamalarının geliştirilmesinin, altyapı mühendisleri için açık pozisyonların ve DevOps'a her türlü referansın bulunduğu "altyapı odaklı" olarak işaretlenmiş açık pozisyonlara bakabilirsiniz. Bu tanımla her şirketin farklı bir şeyi ifade ettiğini unutmayın; açıklamayı dikkatlice okuyun.
Kursumuzu başlatırken aklıma bir fikir geldi: kurstan sonra birçok kişi DevOps mühendisinin tuzağına düşüyor. Yukarıda belirtilen başlıkta bir boş pozisyon buluyorlar, iyi bir teklif alıyorlar ve sonra işe geliyorlar ve Jenkins'te üç sayfalık bir bash senaryosu bulundurmak zorunda kalacaklarını fark ediyorlar. Kubernetes, ChatOps, canary sürümleri ve bunların hepsi nerede? Ancak hiçbir şey yok çünkü şirketin metodoloji olarak DevOps'a ihtiyacı yok, bireysel yenilikleri kullanıyor.
Bu da yazılım teslim sürecinin nasıl işlediğini, teknoloji yığınını ve hangi sorumlulukları yerine getireceğinizi şirketten yoğun bir şekilde öğrenmeniz için bir nedendir.
İşveren sorularınızı soyut bir şekilde, sanki bir kitaptan geliyormuş gibi, ayrıntılar olmadan yanıtlıyorsa, büyük olasılıkla şirkette henüz bir DevOps süreci yoktur, ancak bu, çevrimiçi olup olmadığı konusunda şirketi ve ürünlerini reddetmek, incelemek için bir neden değildir. firmanın kendi geliştirdiği hizmetler, mobil uygulamalar, ürün fikirleri.
Cevabınız evet ise DevOps uygulamalarında iyi sonuçlar ortaya koyarken bu sistemlerle doğrudan çalışmanız gerekip gerekmediğini veya bu hizmetlerin ekiplerine yatay hareket imkanının olup olmadığını açıklayın. Cevabınız evet ise, o zaman gitmeye, aktif ve faydalı olmaya değer ve kursumuzu tamamlarsanız ikincisi garanti edilir.
Devops uygulayıcılarının gerçek değeri yalnızca geliştirme/yönetim/test deneyimiyle kazandıklarını unutmamak önemlidir. Ancak o zaman bilgi soyut olmaktan çıkıp uzmanı (her anlamda) zenginleştirecektir. Bu nedenle, "DevOps'u sıfırdan öğrenmek" fikri, eğer elinize hiç kamera tutmadıysanız veya çekim yönetmediyseniz "lensleri sıfırdan kullanmayı" öğrenmekle hemen hemen aynıdır. Kursun size uygun olup olmadığına karar vermenize yardımcı olmak için yeterli bilgi seviyenizi kontrol edecek bir giriş testi yaptık.
Bence hilelerden biri - eğitim süresince her öğrencinin hangi yönde gelişmek istediğini kendisi belirlemesidir. Bir geliştiricinin altyapı mühendisi olması ve yöneticinin kod yazmakla ilgilendiğini fark etmesi ve ardından dili daha fazla incelemesi ve bunu edindiği DevOps becerileriyle desteklemesi durumunda geçişleri sıklıkla görürüz. Bu nedenle kariyerinin bir dönüm noktasına geldiğini düşünenleri özellikle memnuniyetle karşılıyoruz. Kurs 28 Mayıs'ta başlıyor ancak derslerin başlamasından 2 hafta sonra katılabilirsiniz. Programı görüntüleyebilir ve testi çözebilirsiniz. . OTUS'ta görüşürüz!
Kaynak: habr.com