Bir BT şirketinin 2019'da başarılı olması için ne gerekiyor? Konferanslarda ve buluşmalarda konuşmacılar, normal insanların her zaman anlayamadığı çok sayıda yüksek sesli söz söylerler. Dağıtım süresi, mikro hizmetler, monolitin terk edilmesi, DevOps dönüşümü ve çok daha fazlası için verilen mücadele. Sözlü güzelliği bir kenara bırakırsak ve doğrudan ve Rusça konuşursak, o zaman her şey basit bir teze indirgenir: yüksek kaliteli bir ürün yapın ve bunu ekip için rahatlıkla yapın.
İkincisi kritik öneme sahip hale geldi. İş dünyası sonunda, rahat bir geliştirme sürecinin üretkenliği artırdığı ve her şeyde hata ayıklanıp saat gibi çalıştığı takdirde, kritik durumlarda manevra alanı da sağladığı sonucuna varmıştır. Bir zamanlar, bu manevra uğruna, belli bir akıllı kişi yedeklemelerle geldi, ancak endüstri gelişiyor ve biz de DevOps mühendislerine geldik - geliştirme ile dış altyapı arasındaki etkileşim sürecini yeterli ve uygun bir şeye dönüştüren insanlar. Şamanizmle alakası yok.
Tüm bu "modüler" hikaye harika, ama... Öyle oldu ki bazı yöneticilere aniden DevOps adı verildi ve DevOps mühendislerinin kendilerinin en azından telepati ve durugörü becerilerine sahip olmaları istenmeye başlandı.
Altyapı sağlamanın modern sorunlarından bahsetmeden önce, bu terimle ne kastettiğimizi tanımlayalım. Şu anda durum öyle gelişti ki bu kavramın ikiliğine ulaştık: altyapı şartlı olarak dış ve şartlı olarak içsel olabilir.
Dış altyapı derken, ekibin geliştirmekte olduğu hizmet veya ürünün işlevselliğini sağlayan her şeyi kastediyoruz. Bunlar, ürünün işlevselliğini sağlayan uygulama veya web sitesi sunucuları, barındırma ve diğer hizmetlerdir.
Dahili altyapı, geliştirme ekibinin kendisi ve genellikle çok sayıda bulunan diğer çalışanlar tarafından kullanılan hizmetleri ve ekipmanı içerir. Bunlar, kod depolama sistemlerinin dahili sunucuları, yerel olarak dağıtılan bir görev yöneticisi ve kurumsal intranet içinde var olan her şey, her şey, her şeydir.
Sistem yöneticisi bir şirkette ne yapar? Bu kurumsal intranetin yönetimine ek olarak, çoğu zaman ofis ekipmanlarının çalışabilirliğini sağlamaya yönelik ekonomik kaygıların yükünü de üstleniyor. Yönetici, arka odadan yeni bir sistem birimini veya kullanıma hazır yedek bir dizüstü bilgisayarı hızla sürükleyecek, yeni bir klavye verecek ve Ethernet kablosunu uzatarak ofislerde dört ayak üzerinde gezinecek olan aynı adamdır. Yönetici, yalnızca iç ve dış sunucuların değil, aynı zamanda bir işletme yöneticisinin yerel sahibi ve yöneticisidir. Evet, bazı yöneticiler donanım olmadan yalnızca sistem düzleminde çalışabilir. Ayrı bir “altyapı sistem yöneticileri” alt sınıfına ayrılmalıdırlar. Ve bazıları yalnızca ofis ekipmanlarının servisi konusunda uzmanlaşıyor; neyse ki, şirkette yüzden fazla kişi varsa iş asla bitmiyor. Ama ikisi de devop değil.
DevOps kimdir? Devop'lar, yazılım geliştirmenin dış altyapıyla etkileşiminden bahseden adamlardır. Daha doğrusu, modern devop'lar, geliştirme ve dağıtım süreçlerine, güncellemeleri ftp'ye yükleyen yöneticilerin şimdiye kadar dahil olduğundan çok daha derin bir şekilde dahil oluyor. Artık bir DevOps mühendisinin temel görevlerinden biri, geliştirme ekipleri ile ürün altyapısı arasında rahat ve etkili bir şekilde yapılandırılmış bir etkileşim süreci sağlamaktır. Geri alma ve dağıtım sistemlerinin dağıtımından sorumlu olanlar bu kişilerdir; geliştiricilerin yükünün bir kısmını alan ve son derece önemli görevlerine mümkün olduğunca yoğunlaşanlar da bu kişilerdir. Aynı zamanda devop'lar asla yeni bir kablo çekmeyecek veya arka odadan yeni bir dizüstü bilgisayar çıkarmayacak (c) KO
Yakalamak nedir?
“DevOps Kimdir?” sorusuna Sahadaki çalışanların yarısı "Eh, kısacası bu yönetici ..." gibi bir şeye ve metnin devamına cevap vermeye başlıyor. Evet, bir zamanlar DevOps mühendisi mesleği hizmet bakımı açısından en yetenekli yöneticiler arasında yeni ortaya çıkarken, aralarındaki farklar herkes için açık değildi. Ancak artık takımdaki devops ve admin'in işlevleri kökten farklılaştığında, bunları birbiriyle karıştırmak, hatta eşitlemek kabul edilemez.
Peki bu iş açısından ne anlama geliyor?
İşe alma, her şey bununla ilgili.
"Sistem Yöneticisi" için açık pozisyon açıyorsunuz ve orada listelenen gereksinimler şunlardır: "geliştirme ve müşterilerle etkileşim", "CI/CD dağıtım sistemi", "şirketin sunucularının ve ekipmanlarının bakımı", "dahili sistemlerin yönetimi" vb. Açık; işverenin saçma sapan konuştuğunu anlıyorsunuz. İşin püf noktası, boş pozisyon unvanının "Sistem Yöneticisi" yerine "DevOps Mühendisi" olması gerektiğidir ve bu unvan değiştirilirse her şey yerine oturur.
Ancak böyle bir boşluğu okurken kişi nasıl bir izlenim edinir? Şirketin hem versiyon kontrol hem de izleme sistemini kullanacak ve bükücüyü dişleriyle sıkacak bir çoklu makine operatörü aradığı...
Ancak işgücü piyasasında uyuşturucu bağımlılığının derecesini arttırmamak için boş pozisyonları özel adlarıyla adlandırmak ve DevOps mühendisi ile sistem yöneticisinin iki farklı varlık olduğunu açıkça anlamak yeterlidir. Ancak bazı işverenlerin bir adaya mümkün olan en geniş gereksinim listesini sunma yönündeki önlenemez arzusu, "klasik" sistem yöneticilerinin etraflarında olup bitenleri anlamaktan vazgeçmesine yol açıyor. Ne yani meslek değişiyor ve onlar çağın gerisinde mi kalıyor?
Hayır hayır ve bir kez daha hayır. Şirketin dahili sunucularını yönetecek veya L2/L3 destek pozisyonlarını işgal edecek ve diğer çalışanlara yardım edecek altyapı yöneticileri gitmedi ve gitmeyecek.
Bu uzmanlar DevOps mühendisi olabilir mi? Elbette yapabilirler. Aslında bu, sistem yönetimi becerileri gerektiren ilgili bir ortamdır ancak buna ek olarak izleme, dağıtım sistemleriyle çalışma ve genel olarak geliştirme ve test ekibiyle yakın etkileşim de eklenir.
Başka Bir DevOps Sorunu
Aslında her şey sadece işe alımlarla ve adminler ile devop'lar arasındaki sürekli kafa karışıklığıyla sınırlı değil. Bir noktada işletme, güncellemelerin teslim edilmesi ve geliştirme ekibinin nihai altyapıyla etkileşimi sorunuyla karşı karşıya kaldı.
Belki de bir amcanın gözleri parıldayan bir konferansta sahneye çıkıp şöyle demesiydi: “Bunu yapıyoruz ve buna DevOps diyoruz. Bu adamlar tüm sorunlarınızı çözecek” diyerek DevOps uygulamalarını hayata geçirdikten sonra şirkette hayatın ne kadar güzel olduğunu anlatmaya başladı.
Ancak her şeyin olması gerektiği gibi çalışmasını sağlamak için bir DevOps mühendisini işe almak yeterli değildir. Şirketin tam bir DevOps dönüşümünden geçmesi gerekiyor; yani DevOps'umuzun rolü ve yetenekleri, ürün geliştirme ve test ekibi tarafından da açıkça anlaşılmalıdır. Bu konuyla ilgili bazı yerlerde yaşanan tüm vahşeti bütünüyle gösteren “harika” bir hikayemiz var.
Durum. DevOps'un, nasıl çalışacağını gerçekten derinlemesine incelemeden bir sürüm geri alma sistemini dağıtması gerekir. Users sisteminde ad, soyad ve şifre için ayrı alanların bulunduğunu varsayalım. Ürünün yeni bir sürümü çıkıyor, ancak geliştiriciler için "geri alma" her şeyi düzeltecek sihirli bir değnekten başka bir şey değil ve bunun nasıl çalıştığını bile bilmiyorlar. Örneğin, bir sonraki yamada geliştiriciler ad ve soyadı alanlarını birleştirdiler, üretime sundular, ancak sürüm bazı nedenlerden dolayı yavaş. Ne oluyor? Yönetim devops'a geliyor ve “Düğmeyi çek!” diyor, yani önceki versiyona dönmesini istiyor. Devops ne yapar? Önceki sürüme geri dönüyor, ancak geliştiriciler bu geri almanın nasıl yapıldığını anlamak istemediklerinden kimse devops ekibine veritabanının da geri alınması gerektiğini söylemedi. Sonuç olarak, bizim için her şey çöküyor ve yavaş bir web sitesi yerine kullanıcılar "500" hatası görüyor çünkü eski sürüm yeni veritabanının alanlarıyla çalışmıyor. Devops'un bundan haberi yok. Geliştiriciler sessiz. Yönetim sinirlerini ve parasını kaybetmeye başlar ve yedekleri hatırlayarak "en azından bir şeyin işe yaraması" için onlardan geri dönmeyi teklif eder. Sonuç olarak kullanıcılar belirli bir süre içinde tüm verilerini kaybederler.
Tabii ki fındıklar, "düzgün bir geri alma sistemi oluşturmayan" devops'a gidiyor ve bu hikayedeki geyiğin geliştiriciler olması kimsenin umrunda değil.
Sonuç basit: DevOps'a normal bir yaklaşım olmadan, pek işe yaramaz.
Unutulmaması gereken en önemli şey: Bir DevOps mühendisi bir sihirbaz değildir ve kaliteli iletişim ve geliştirme ile iki yönlü etkileşim olmadan görevleriyle baş edemez. Geliştiriciler "sorunlarıyla" yalnız bırakılamaz veya "geliştiricilere karışmayın, onların işi kodlamadır" komutu verilip, kritik bir anda her şeyin olması gerektiği gibi çalışacağını umulamaz. Bu iş böyle yürümüyor.
Esas itibarıyla DevOps, yönetim ve teknoloji arasındaki sınırda yer alan bir yetkinliktir. Üstelik bu kokteylde yönetimden çok teknolojinin olması gerektiği de aşikâr değil. Gerçekten daha hızlı ve daha verimli geliştirme süreçleri oluşturmak istiyorsanız devops ekibinize güvenmelisiniz. Doğru araçları biliyor, benzer projeleri hayata geçirdi, nasıl yapılacağını biliyor. Ona yardım edin, tavsiyelerini dinleyin, onu bir tür özerk birime izole etmeye çalışmayın. Yöneticiler kendi başlarına çalışabiliyorsa devop'lar bu durumda işe yaramaz; eğer siz kendiniz bu yardımı kabul etmek istemiyorsanız, onlar sizin daha iyi olmanıza yardımcı olamayacaklardır.
Ve son bir şey: altyapı yöneticilerini rahatsız etmeyi bırakın. Kendilerine ait, son derece önemli bir çalışma cepheleri var. Evet, bir yönetici DevOps mühendisi olabilir ancak bu, baskı altında değil, kişinin kendi isteği üzerine gerçekleşmelidir. Ve bir sistem yöneticisinin sistem yöneticisi olarak kalmak istemesinde yanlış bir şey yoktur - bu onun ayrı mesleği ve onun hakkıdır. Profesyonel bir dönüşüm geçirmek istiyorsanız, yalnızca teknolojik becerileri değil aynı zamanda yönetim becerilerini de geliştirmeniz gerekeceğini asla unutmamalısınız. Büyük olasılıkla, tüm bu insanları bir araya getirip onlara aynı dilde iletişim kurmayı öğretmek bir lider olarak sizin elinizde olacaktır.
Kaynak: habr.com