Şu anda bu neredeyse piyasadaki en pahalı pozisyondur. "DevOps" mühendislerinin etrafındaki yaygara hayal edilebilecek tüm sınırların ötesinde, hatta Kıdemli DevOps mühendisleri için daha da kötü.
Entegrasyon ve otomasyon departmanının başkanı olarak çalışıyorum, sanırım İngilizce kod çözme - DevOps Yöneticisi. İngilizce transkriptin günlük aktivitelerimizi yansıtması pek olası değildir, ancak bu durumda Rusça versiyon daha doğrudur. Faaliyetimin doğası gereği, ekibimin gelecekteki üyeleriyle röportaj yapma ihtiyacı duymam doğaldır ve geçtiğimiz yıl boyunca yaklaşık 50 kişi benim aracılığımla geçti ve aynı sayıda kişi, çalışanlarımla ön ekranda kesildi.
Hala iş arkadaşları arıyoruz çünkü DevOps etiketinin arkasında farklı türden mühendislerden oluşan çok geniş bir katman saklanıyor.
Aşağıda yazılanların hepsi benim kişisel görüşümdür, katılmanıza gerek yok ancak konuya olan tavrınıza biraz renk katacağını kabul ediyorum. Gözden düşme riskine rağmen fikrimi yayınlıyorum çünkü yeri olduğuna inanıyorum.
Şirketlerin DevOps mühendislerinin kim olduğu konusunda farklı anlayışları vardır ve bir kaynağı hızlı bir şekilde işe almak adına bu etiketi herkese asarlar. Durum oldukça garip, çünkü şirketler bu kişilere gerçekçi olmayan ücretler ödemeye hazırlar ve çoğu durumda onlar için bir araç yöneticisi alıyorlar.
Peki DevOps mühendisleri kimlerdir?
Ortaya çıkış tarihiyle başlayalım - Geliştirme Operasyonları, beklenen bir sonuç olarak, ürün üretim hızını artırmak için küçük ekipler arasındaki etkileşimi optimize etmeye yönelik bir başka adım olarak ortaya çıktı. Buradaki fikir, geliştirme ekibini ürün ortamını yönetmeye yönelik prosedürler ve yaklaşımlar bilgisi ile güçlendirmekti. Başka bir deyişle geliştirici, ürününün belirli koşullarda nasıl çalıştığını anlamalı ve bilmelidir, ürününü nasıl dağıtacağını, performansı artırmak için ortamın hangi özelliklerinin ayarlanabileceğini anlamalıdır. Böylece bir süre DevOps yaklaşımına sahip geliştiriciler ortaya çıktı. DevOps geliştiricileri, faaliyetlerini ve üretim ortamının performansını basitleştirmek için derleme ve paketleme komut dosyaları yazdı. Bununla birlikte, çözüm mimarisinin karmaşıklığı ve altyapı bileşenlerinin karşılıklı etkisi zaman içinde ortamların performansını kötüleştirmeye başladı; her yinelemede, belirli bileşenlerin giderek daha derinlemesine anlaşılması gerekti ve bu da geliştiricinin ek karmaşıklık nedeniyle üretkenliğini azalttı. Belirli bir görev için bileşenleri anlama ve sistemleri ayarlama maliyetleri. Geliştiricinin kendi maliyeti arttı, ürünün maliyeti de onunla birlikte arttı, ekipteki yeni geliştiricilere yönelik gereksinimler keskin bir şekilde arttı, çünkü geliştirme "yıldızının" sorumluluklarını da karşılamaları gerekiyordu ve doğal olarak "yıldızlar" azaldı ve daha az mevcut. Şunu da belirtmek gerekir ki, deneyimlerime göre çok az geliştirici işletim sistemi çekirdeği tarafından paket işlemenin ayrıntıları, paket yönlendirme kuralları ve ana bilgisayar güvenliği hususlarıyla ilgilenmektedir. Mantıklı adım, bu konuya aşina olan bir yöneticiyi çekmek ve ona benzer sorumluluklar vermekti; bu, tecrübesi sayesinde aynı göstergelerin "yıldız" gelişiminin maliyetine kıyasla daha düşük bir maliyetle elde edilmesini mümkün kıldı. Bu tür yöneticiler bir ekibe yerleştirildi ve asıl görevi, belirli bir ekibin kurallarına göre, bu ekibe tahsis edilen kaynaklarla test ve üretim ortamlarını yönetmekti. Aslında DevOps çoğunluğun zihninde bu şekilde ortaya çıktı.
Zaman içinde kısmen veya tamamen bu sistem yöneticileri, bu özel ekibin geliştirme alanındaki ihtiyaçlarını, geliştiriciler ve testçiler için hayatı nasıl kolaylaştıracaklarını, bir güncellemeyi nasıl kullanıma sunacaklarını ve Cuma günü geceyi orada geçirmek zorunda kalmamayı anlamaya başladılar. ofis, dağıtım hatalarını düzeltiyor. Zaman geçti ve artık "yıldızlar", geliştiricilerin ne istediğini anlayan sistem yöneticileriydi. Etkiyi en aza indirmek için yönetim yardımcı programları ortaya çıkmaya başladı; herkes işletim sistemi düzeyini izole etmenin eski ve güvenilir yöntemlerini hatırladı; bu, güvenlik gereksinimlerini, ağ bölümünün yönetimini ve ana bilgisayar yapılandırmasını bir çözüm olarak en aza indirmeyi mümkün kıldı. bütünüyle ve sonuç olarak yeni "yıldızlara" olan gereksinimleri azaltın.
"Harika" bir şey ortaya çıktı - liman işçisi. Neden harika? Evet, yalnızca bir chroot veya hapishanede ve OpenVZ'de izolasyon oluşturmak, işletim sistemi hakkında önemsiz olmayan bilgi gerektirdiğinden, bunun tersine, yardımcı program, belirli bir ana bilgisayarda gerekli her şeyi içeride ve elde bulundurarak izole edilmiş bir uygulama ortamı oluşturmanıza olanak tanır geliştirmenin dizginlerini tekrar devralır ve sistem yöneticisi yalnızca tek bir ana bilgisayarla yönetim yapabilir, böylece güvenlik ve yüksek kullanılabilirlik sağlanır; bu da mantıksal bir basitleştirmedir. Ancak ilerleme durmuyor ve sistemler yine giderek daha karmaşık hale geliyor, giderek daha fazla bileşen var, bir ana bilgisayar artık sistemin ihtiyaçlarını karşılamıyor ve kümeler oluşturmak gerekiyor, yine sistem yöneticilerine geri dönüyoruz. bu sistemleri kurabiliyoruz.
Döngüden döngüye, geliştirmeyi ve/veya yönetimi basitleştiren çeşitli sistemler ortaya çıkar, standart süreçten sapmanız gerekene kadar kullanımı kolay olan orkestrasyon sistemleri ortaya çıkar. Mikro hizmet mimarisi ayrıca yukarıda açıklanan her şeyi basitleştirmek amacıyla ortaya çıktı: daha az ilişki, yönetimi daha kolay. Deneyimlerime göre tamamen bir mikro hizmet mimarisi bulamadım, mikro hizmetlerin yüzde 50 ila 50 - 50'si, kara kutular geldi, işlenmiş çıktı, geri kalan 50'si yırtılmış bir monolit, hizmetler diğerlerinden ayrı çalışamıyor diyebilirim. bileşenler. Bütün bunlar yine hem geliştiricilerin hem de yöneticilerin bilgi düzeyine kısıtlamalar getirdi.
Belirli bir kaynağın uzman bilgisi düzeyindeki benzer "sallantılar" bugün de devam ediyor. Ama biraz konu dışına çıkıyoruz, altını çizmeye değer pek çok nokta var.
İnşaat Mühendisi/Sürüm Mühendisi
Yazılım oluşturma süreçlerini ve sürümlerini standartlaştırmanın bir yolu olarak ortaya çıkan son derece uzman mühendisler. Çevik'in yaygın olarak tanıtılması sürecinde, artık talep görmüyorlar gibi görünüyor, ancak bu durumdan çok uzak. Bu uzmanlaşma, yazılımın montajını ve dağıtımını endüstriyel ölçekte standartlaştırmanın bir yolu olarak ortaya çıktı; tüm şirket ürünleri için standart tekniklerin kullanılması. DevOps'un gelişiyle geliştiriciler işlevlerini kısmen kaybettiler, ürünü teslimata hazırlamaya başlayan geliştiriciler olduğu için, değişen altyapı ve kaliteden bağımsız olarak olabildiğince hızlı teslimat yaklaşımı göz önüne alındığında, zamanla Kalite standartlarına bağlılık teslimatları kaçınılmaz olarak yavaşlatacağından değişiklikleri durdurur. Böylece, Oluşturma/Sürüm mühendislerinin işlevlerinin bir kısmı yavaş yavaş sistem yöneticilerinin omuzlarına geçti.
Operasyonlar çok farklı
Devamlı devam ediyoruz, çok çeşitli sorumlulukların varlığı ve kalifiye personel eksikliği bizi yağmurdan sonra mantar oluşması gibi katı uzmanlaşmaya itiyor, çeşitli Operasyonlar ortaya çıkıyor:
- TechOps - enikey sistem yöneticileri, diğer adıyla HelpDesk Mühendisi
- LiveOps - öncelikli olarak üretim ortamlarından sorumlu sistem yöneticileri
- CloudOps - Azure, AWS, GCP vb. genel bulutlarda uzmanlaşmış sistem yöneticileri.
- PlatOps/InfraOps/SysOps - altyapı sistem yöneticileri.
- NetOps - ağ yöneticileri
- SecOps - bilgi güvenliği konusunda uzmanlaşmış sistem yöneticileri - PCI uyumluluğu, CIS uyumluluğu, yama uygulama vb.
DevOps (teoride) geliştirme döngüsünün tüm süreçlerini (geliştirme, test etme) ilk elden anlayan, ürün mimarisini anlayan, güvenlik risklerini değerlendirebilen, yaklaşımlara ve otomasyon araçlarına en azından yüksek düzeyde aşina olan bir kişidir. seviye, buna ek olarak, ön işleme ve son işlem ürün sürüm desteğini de anlar. Bu iki sütun arasında olumlu işbirliğine olanak tanıyan, hem Operasyonların hem de Geliştirmenin savunucusu olarak hareket etme yeteneğine sahip bir kişi. Ekipler tarafından işlerin planlanması ve müşteri beklentilerinin yönetilmesi süreçlerini anlar.
Bu tür işlerin ve sorumlulukların yerine getirilmesi için bu kişinin yalnızca geliştirme ve test süreçlerini değil, aynı zamanda ürün altyapısının yönetimini ve kaynak planlamasını da yönetebilecek imkanlara sahip olması gerekir. Bu anlayışa göre DevOps, ne BT'de, ne Ar-Ge'de, hatta PMO'da bulunamaz; tüm bu alanlarda - şirketin teknik direktörü, Baş Teknik Sorumlusu - nüfuz sahibi olmalıdır.
Bu sizin şirketinizde de geçerli mi? - Ben şüpheliyim. Çoğu durumda bu ya BT ya da Ar-Ge'dir.
Fon eksikliği ve bu üç faaliyet alanından en az birini etkileme yeteneği, sorunların ağırlığını, statik yasaya göre "kirli" kodla bağlantılı olarak sürümlere teknik kısıtlamaların uygulanması gibi bu değişikliklerin uygulanmasının daha kolay olduğu yerlere kaydıracaktır. analizör sistemleri. Yani PMO, işlevselliğin yayınlanması için kesin bir son tarih belirlediğinde, Ar-Ge bu son tarihler içinde yüksek kaliteli bir sonuç üretemez ve bunu elinden gelen en iyi şekilde üretir, yeniden düzenlemeyi sonraya bırakır, BT ile ilgili DevOps, sürümü teknik yollarla engeller. . Sorumlu çalışanlar söz konusu olduğunda durumu değiştirme yetkisinin olmaması, etkileyemedikleri şeyler konusunda aşırı sorumluluğun ortaya çıkmasına yol açar, özellikle de bu çalışanlar hataları anlayıp görürse ve bunların nasıl düzeltileceği - "Mutluluk cehalettir", ve bunun sonucunda da bu çalışanların tükenmişliği ve kaybı yaşanmaktadır.
DevOps kaynak pazarı
Farklı şirketlerdeki DevOps pozisyonları için çeşitli açık pozisyonlara bakalım.
Aşağıdaki durumlarda sizinle görüşmeye hazırız:
- Zabbix'in sahibisin ve Prometheus'un ne olduğunu biliyorsun;
- Iptable'lar;
- BASH Doktora Öğrencisi;
- Profesör Ansible;
- Linux Gurusu;
- Hata ayıklamayı nasıl kullanacağınızı ve geliştiricilerle birlikte uygulama sorunlarını nasıl bulacağınızı öğrenin (php/java/python);
- Yönlendirme sizi histerik yapmaz;
- Sistem güvenliğine büyük önem verin;
- "Her şeyi ve her şeyi" yedekleyin ve ayrıca bu "her şeyi ve her şeyi" başarıyla geri yükleyin;
- Sistemi minimumdan maksimumu elde edecek şekilde nasıl yapılandıracağınızı biliyorsunuz;
- Postgres ve MySQL'de yatmadan önce çoğaltmayı ayarlayın;
- CI/CD'yi kurmak ve ayarlamak sizin için kahvaltı/öğle yemeği/akşam yemeği kadar gereklidir.
- AWS deneyimine sahip;
- Şirketle birlikte gelişmeye hazır;
Yani:
- 1'den 6'ya kadar - sistem yöneticisi
- 7 - Sistem yöneticisine de uyan küçük bir ağ yönetimi, Orta seviye
- 8 - Orta düzey bir sistem yöneticisi için zorunlu olan küçük bir güvenlik
- 9-11 – Orta Sistem Yöneticisi
- 12 — Atanan görevlere bağlı olarak Orta Sistem Yöneticisi veya İnşaat Mühendisi
- 13 - Sanallaştırma - Orta Sistem Yöneticisi veya CloudOps olarak adlandırılan, fonların verimli kullanımı ve bakım yükünün azaltılması için belirli bir barındırma sitesinin hizmetlerine ilişkin ileri düzey bilgi
Bu boşluğu özetlemek gerekirse Orta/Kıdemli Sistem Yöneticisinin bu arkadaşlar için yeterli olduğunu söyleyebiliriz.
Bu arada Linux/Windows'ta yöneticileri çok fazla bölmemek gerekiyor. Tabii ki, bu iki dünyanın hizmetlerinin ve sistemlerinin farklı olduğunu anlıyorum, ancak hepsinin temeli aynı ve kendine saygısı olan her yönetici hem birine hem de diğerine aşinadır ve aşina olmasa bile, Yetkili bir yöneticinin buna aşina olması zor olmamalıdır.
Başka bir boş pozisyona bakalım:
- Yüksek yüklü sistemlerin inşasında deneyim;
- Linux işletim sistemi, genel sistem yazılımı ve web yığını (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) hakkında mükemmel bilgi;
- Sanallaştırma sistemleri (KVM, VMWare, LXC/Docker) konusunda deneyim;
- Komut dosyası dillerinde yeterlilik;
- Ağ protokolü ağlarının çalışma prensiplerinin anlaşılması;
- Hataya dayanıklı sistemler oluşturma ilkelerinin anlaşılması;
- Bağımsızlık ve inisiyatif;
Şuna bakalım:
- 1 – Kıdemli Sistem Yöneticisi
- 2 - Bu yığına yüklenen anlama bağlı olarak - Orta/Kıdemli Sistem Yöneticisi
- 3 - İş deneyimi, şu anlama gelebilir: "Küme yükselmedi, ancak sanal makineler oluşturdu ve yönetti, bir Docker ana bilgisayarı vardı, kapsayıcılara erişim mevcut değildi" - Orta Sistem Yöneticisi
- 4 - Yardımcı Sistem Yöneticisi - evet, dilden bağımsız olarak temel otomasyon komut dosyalarının nasıl yazılacağını bilmeyen bir yönetici, bir yönetici değil - enikey.
- 5 - Orta Sistem Yöneticisi
- 6 – Kıdemli Sistem Yöneticisi
Özetlemek gerekirse - Orta/Kıdemli Sistem Yöneticisi
Başka bir:
- Deneyimi geliştirir;
- CI/CD süreçleri oluşturmak için bir veya daha fazla ürünü kullanma deneyimi. Gitlab CI bir avantaj olacaktır;
- Konteynerler ve sanallaştırmayla çalışma; Docker kullandıysanız iyi, ancak k8 kullandıysanız harika!
- Çevik bir ekipte çalışma deneyimi;
- Herhangi bir programlama dili bilgisi;
Göreceğiz:
- 1 - Hmm... Adamlar ne demek istiyor? =) Büyük ihtimalle kendileri de bunun arkasında neyin saklı olduğunu bilmiyorlar
- 2 - İnşaat Mühendisi
- 3 - Orta Sistem Yöneticisi
- 4 - Yumuşak beceri, şimdilik bunu dikkate almayacağız, ancak Agile uygun şekilde yorumlanan başka bir şeydir.
- 5 - Çok ayrıntılı - bir betik dili veya derlenmiş bir dil olabilir. Acaba okulda Pascal ve Basic ile yazmak onlara yakışacak mı? =)
Bu noktanın neden sistem yöneticisi tarafından ele alındığının anlaşılmasını güçlendirmek için 3. maddeye ilişkin bir not da bırakmak istiyorum. Kubernetes yalnızca bir orkestrasyondur, ağ sürücülerine ve sanallaştırma/izolasyon ana bilgisayarlarına doğrudan komutları birkaç komutla saran ve onlarla iletişimi soyut hale getirmenize olanak tanıyan bir araçtır, hepsi bu. Örneğin, 'build framework' Make'i ele alalım, bu arada ben bunu bir çerçeve olarak görmüyorum. Evet, Make'i gerekli olan ve olmayan her yere itme modasını biliyorum - örneğin Maven'i Make'e sarmak, ciddi anlamda mı?
Temelde Make, tıpkı k8s gibi derlemeyi, bağlamayı ve derleme ortamı komutlarını basitleştiren, kabuğun üzerindeki bir sarmalayıcıdır.
Bir keresinde, OpenStack üzerindeki çalışmalarında k8'leri kullanan bir adamla röportaj yaptım ve o, bunun üzerinde hizmetleri nasıl dağıttığını anlattı, ancak OpenStack hakkında soru sorduğumda bunun sistem tarafından yönetildiği ve yükseltildiği ortaya çıktı. yöneticiler. Gerçekten OpenStack kurulumu yapmış bir kişinin arkasında hangi platformu kullanırsa kullansın k8s kullanamayacağını mı düşünüyorsunuz?
Bu başvuru sahibi aslında bir DevOps değil, bir Sistem Yöneticisi ve daha doğrusu bir Kubernetes Yöneticisidir.
Bir kez daha özetleyelim; Orta/Kıdemli Sistem Yöneticisi onlara yetecektir.
Gramda ne kadar asılır
Belirtilen boş pozisyonlar için önerilen maaş aralığı 90k-200k'dir
Şimdi Sistem Yöneticileri ile DevOps Mühendislerinin parasal ödülleri arasında bir paralellik kurmak istiyorum.
Prensip olarak, işleri basitleştirmek için notları iş deneyimine göre dağıtabilirsiniz, ancak bu kesin olmayacak, ancak makalenin amaçları açısından yeterli olacaktır.
deneyimi:
- 3 yıla kadar – Junior
- 6 yaşına kadar – Orta
- 6'dan fazla - Kıdemli
Çalışan arama sitesi şunları sunar:
Sistem Yöneticileri:
- Junior - 2 yıl - 50 bin ovmak.
- Orta - 5 yıl - 70 bin ovmak.
- Kıdemli - 11 yıl - 100 bin ovmak.
DevOps Mühendisleri:
- Junior - 2 yıl - 100 bin ovmak.
- Orta - 3 yıl - 160 bin ovmak.
- Kıdemli - 6 yıl - 220 bin ovmak.
"DevOps" deneyimine göre, en azından bir şekilde SDLC'yi etkileyen deneyim kullanıldı.
Yukarıdakilerden, aslında şirketlerin DevOps'a ihtiyaç duymadığı ve ayrıca bir Yönetici kiralayarak başlangıçta planlanan maliyetlerden en az yüzde 50 tasarruf edebilecekleri ve ayrıca aradıkları kişinin sorumluluklarını daha net tanımlayabilecekleri sonucu çıkıyor. ve ihtiyacı daha hızlı doldurun. Ayrıca, net bir sorumluluk paylaşımının, personel gereksinimlerini azaltmamıza ve aynı zamanda örtüşmelerin olmaması nedeniyle ekipte daha olumlu bir atmosfer yaratmamıza olanak sağladığını da unutmamalıyız. Boş pozisyonların büyük çoğunluğu yardımcı programlar ve DevOps etiketleriyle doludur, ancak bunlar bir DevOps Mühendisi için gerçek gereksinimleri temel almaz; yalnızca bir araç yöneticisine yönelik talepleri temel alır.
DevOps mühendislerini eğitme süreci de yalnızca bir dizi belirli çalışma ve yardımcı programla sınırlıdır ve süreçlere ve bunların bağımlılıklarına ilişkin genel bir anlayış sağlamaz. Bir kişinin Terraform'u kullanarak AWS EKS'yi bu kümedeki Fluentd sepeti ve kayıt sistemi için AWS ELK yığınıyla birlikte konsolda yalnızca bir komut kullanarak 10 dakika içinde dağıtabilmesi kesinlikle iyidir; Günlüklerin kendisini işleme ilkesi ve bunların ne için gerekli olduğu, bunlar üzerinde metriklerin nasıl toplanacağını ve hizmetin bozulmasını nasıl izleyeceğinizi bilmiyorsanız, o zaman bazı yardımcı programların nasıl kullanılacağını bilen yine aynı enikey olacaktır.
Ancak talep, arz yaratır ve DevOps pozisyonu için gereksinimlerin gerçek role karşılık gelmediği, yalnızca sistem yöneticilerinin daha fazla kazanmasına izin verdiği aşırı ısınmış bir pazar görüyoruz.
Peki onlar kim? DevOps mu yoksa açgözlü sistem yöneticileri mi? =)
Daha fazla yaşamak nasıl?
İşverenler gereksinimleri daha kesin bir şekilde formüle etmeli ve tam olarak ihtiyaç duyulan kişileri aramalı ve etrafa etiket atmamalıdır. DevOps'un ne yaptığını bilmiyorsunuz; bu durumda onlara ihtiyacınız yok.
İşçiler - Öğrenin. Bilginizi sürekli geliştirin, süreçlerin genel resmine bakın ve hedefinize giden yolu takip edin. İstediğiniz kişi olabilirsiniz, sadece denemelisiniz.
Kaynak: habr.com