DevOps son birkaç yılda oldukça popüler bir konu haline geldi. Pek çok insan ona katılmayı hayal ediyor, ancak uygulamanın gösterdiği gibi, çoğu zaman yalnızca maaş seviyesi nedeniyle.
Bazı insanlar DevOps'u özgeçmişlerinde listeliyor, ancak terimin özünü her zaman bilmiyorlar veya anlamıyorlar. Bazı insanlar Ansible, GitLab, Jenkins, Terraform ve benzerlerini inceledikten sonra (liste zevkinize göre devam ettirilebilir) hemen bir “devopsist” olacağınızı düşünüyor. Bu elbette doğru değil.
Son birkaç yıldır ağırlıklı olarak DevOps'un çeşitli şirketlerde uygulanmasıyla ilgileniyorum. Bundan önce 20 yılı aşkın bir süre sistem yöneticiliğinden BT direktörlüğüne kadar çeşitli pozisyonlarda çalıştı. Şu anda Playgendary'de DevOps Baş Mühendisi.
DevOps kimdir?
Makale yazma fikri başka bir sorudan sonra ortaya çıktı: “DevOps kimdir?” Ne olduğu veya kim olduğu konusunda henüz belirlenmiş bir terim yok. Bazı yanıtlar zaten burada . Önce buradan ana noktaları öne çıkaracağım, ardından gözlemlerimi ve düşüncelerimi paylaşacağım.
DevOps, işe alınabilecek bir uzman, bir dizi yardımcı program veya mühendislerden oluşan bir geliştirici departmanı değildir.
DevOps bir felsefe ve metodolojidir.
Başka bir deyişle, geliştiricilerin sistem yöneticileriyle aktif olarak etkileşime girmesine yardımcı olan bir dizi uygulamadır. Yani iş süreçlerini birbirine bağlamak ve entegre etmek.
DevOps'un gelişiyle uzmanların yapısı ve rolleri aynı kaldı (geliştiriciler var, mühendisler var), ancak etkileşimin kuralları değişti. Departmanlar arasındaki sınırlar bulanıklaştı.
DevOps'un hedefleri üç noktada tanımlanabilir:
- Yazılımın düzenli olarak güncellenmesi gerekir.
- Yazılımın hızlı bir şekilde yapılması gerekiyor.
- Yazılımın rahatlıkla ve kısa sürede devreye alınması gerekir.
DevOps için tek bir araç yoktur. Birkaç ürünü yapılandırmak, teslim etmek ve incelemek DevOps'un şirkette ortaya çıktığı anlamına gelmez. Çok sayıda araç var ve hepsi farklı aşamalarda kullanılıyor ancak ortak bir amaca hizmet ediyor.
Ve bu DevOps araçlarının yalnızca bir kısmı
2 yılı aşkın bir süredir DevOps mühendisi pozisyonu için insanlarla röportaj yapıyorum ve terimin özünü net bir şekilde anlamanın ne kadar önemli olduğunu fark ettim. Paylaşmak istediğim belirli deneyimleri, gözlemleri ve düşünceleri biriktirdim.
Röportaj deneyimimden aşağıdaki resmi görüyorum: DevOps'u bir iş unvanı olarak gören uzmanlar genellikle meslektaşlarıyla yanlış anlaşılmalar yaşıyor.
Çarpıcı bir örnek vardı. Genç bir adam röportaja özgeçmişinde pek çok akıllıca sözle geldi. Son üç işinde 5-6 aylık tecrübeye sahipti. İki startup'ı "başarıya ulaşamadıkları" için bıraktım. Ancak üçüncü şirketle ilgili olarak, orada kimsenin onu anlamadığını söyledi: geliştiriciler Windows'ta kod yazıyor ve yönetici bu kodu normal Docker'da "sarılmaya" ve CI/CD hattına yerleştirilmeye zorluyor. Adam şu anki iş yeri ve meslektaşları hakkında pek çok olumsuz şey söyledi. Ben sadece cevap vermek istedim: "Yani fil satmayacaksın."
Sonra ona her aday için listemde üst sıralarda yer alan bir soruyu sordum.
— DevOps kişisel olarak sizin için ne anlama geliyor?
- Genel olarak mı yoksa nasıl algılıyorum?
Onun kişisel görüşü ilgimi çekti. Terimin teorisini ve kökenini biliyordu ama onlara kesinlikle karşı çıkıyordu. DevOps'un bir iş unvanı olduğuna inanıyordu. Sorunlarının kökü de burada yatıyor. Aynı görüşe sahip diğer uzmanların yanı sıra.
“DevOps büyüsü” hakkında çok şey duyan işverenler, gelip bu “sihri” yaratacak birini bulmak istiyor. “DevOps bir iştir” kategorisindeki başvuru sahipleri ise bu yaklaşımla beklentileri karşılayamayacaklarını anlamıyorlar. Ve genel olarak özgeçmişlerine DevOps yazdılar çünkü bu bir trend ve bunun için çok para ödüyorlar.
DevOps metodolojisi ve felsefesi
Metodoloji teorik ve pratik olabilir. Bizim durumumuzda bu ikincisi. Yukarıda bahsettiğim gibi DevOps, belirtilen hedeflere ulaşmak için kullanılan bir dizi uygulama ve stratejidir. Ve her durumda şirketin iş süreçlerine bağlı olarak önemli ölçüde farklılık gösterebilir. Bu onu daha iyi ya da daha kötü yapmaz.
DevOps metodolojisi yalnızca hedeflere ulaşmanın bir yoludur.
Şimdi DevOps felsefesinin ne olduğuna bakalım. Ve bu muhtemelen en zor sorudur.
Henüz resmileştirilmediği için kısa ve öz bir cevap formüle etmek oldukça zordur. DevOps felsefesinin taraftarları pratikle daha fazla meşgul oldukları için felsefe yapmaya zaman kalmıyor. Ancak bu çok önemli bir süreçtir. Üstelik doğrudan mühendislik faaliyetleriyle de ilgilidir. Uzmanlaşmış bir bilgi alanı bile var - .
Benim üniversitemde böyle bir konu yoktu, 90'lı yıllarda bulabildiğim materyallerle her şeyi kendi başıma çalışmak zorundaydım. Konu mühendislik eğitimi için isteğe bağlıdır, dolayısıyla cevabın resmileştirilmesi eksikliği. Ancak DevOps'a ciddi şekilde dalmış kişiler, şirketin tüm süreçlerinde belirli bir "ruh" veya "bilinçsiz kapsamlılık" hissetmeye başlar.
Kendi deneyimlerimi kullanarak bu felsefenin bazı “varsayımlarını” resmileştirmeye çalıştım. Sonuç şudur:
- DevOps, ayrı bir bilgi veya faaliyet alanına ayrılabilecek bağımsız bir şey değildir.
- Tüm şirket çalışanlarına faaliyetlerini planlarken DevOps metodolojisi rehberlik etmelidir.
- DevOps bir şirketteki tüm süreçleri etkiler.
- DevOps, hizmetlerinin geliştirilmesini ve maksimum müşteri konforunu sağlamak amacıyla bir şirket içindeki tüm süreçlerin zaman maliyetlerini azaltmak için mevcuttur.
- Modern dilde DevOps, şirketin her çalışanının zaman maliyetlerini azaltmayı ve etrafımızdaki BT ürünlerinin kalitesini artırmayı amaçlayan proaktif pozisyonudur.
Benim “varsayımlarımın” ayrı bir tartışma konusu olduğunu düşünüyorum. Ama artık üzerine inşa edilecek bir şey var.
DevOps Ne Yapar?
Buradaki anahtar kelime iletişimdir. Başlatıcısının tamamen aynı DevOps mühendisi olması gereken çok sayıda iletişim var. Nedenmiş? Çünkü bu felsefe ve metodolojidir ve ancak o zaman mühendislik bilgisidir.
Batı işgücü piyasası hakkında %100 güvenle konuşamam. Ancak Rusya'daki DevOps pazarı hakkında oldukça fazla şey biliyorum. Yüzlerce röportajın yanı sıra, geçtiğimiz bir buçuk yıl boyunca büyük Rus şirketleri ve bankaları için "DevOps'un Uygulanması" hizmetine yönelik yüzlerce teknik ön satışa katıldım.
Rusya'da DevOps hâlâ çok genç ama şimdiden trend olan bir konu. Bildiğim kadarıyla sadece Moskova'da 2019'da bu tür uzmanların eksikliği 1000'den fazla kişiydi. Ve işverenler için Kubernetes kelimesi neredeyse bir boğanın kırmızı paçavrası gibidir. Bu aracın taraftarları, gerekli olmadığı ve ekonomik açıdan karlı olmadığı durumlarda bile onu kullanmaya hazırdır. İşveren, hangi durumlarda neyin daha uygun olduğunu ve uygun dağıtımla Kubernetes kümesinin bakımını yapmanın, geleneksel bir küme şeması kullanarak bir uygulamayı dağıtmaktan 2-3 kat daha fazla maliyetli olduğunu her zaman anlamaz. Gerçekten ihtiyacınız olan yerde kullanın.
DevOps'u uygulamak para açısından pahalıdır. Ve tek başına değil, yalnızca diğer alanlarda ekonomik fayda sağladığı durumlarda haklı çıkar.
DevOps mühendisleri aslında öncüdür; bu metodolojiyi şirkette uygulayan ve süreçleri oluşturan ilk kişiler onlardır. Bunun başarılı olması için uzmanın her seviyedeki çalışanlarla ve meslektaşlarıyla sürekli etkileşim halinde olması gerekir. Genelde söylediğim gibi, temizlikçi kadından CEO'ya kadar tüm şirket çalışanları DevOps uygulama sürecine dahil edilmelidir. Ve bu bir önkoşuldur. Ekibin en kıdemsiz üyesi DevOps'un ne olduğunu ve belirli organizasyonel eylemlerin neden gerçekleştirildiğini bilmiyor ve anlamıyorsa başarılı uygulama işe yaramayacaktır.
Ayrıca DevOps mühendisinin zaman zaman bir yönetim kaynağı kullanması gerekir. Örneğin, ekibin DevOps araçlarını ve metodolojisini kabul etmeye hazır olmadığı durumlarda "çevresel direncin" üstesinden gelmek.
Geliştiricinin yalnızca kod ve testler yazması gerekir. Bunu yapmak için, tüm proje altyapısını dağıtacağı ve yerel olarak destekleyeceği süper güçlü bir dizüstü bilgisayara ihtiyacı yok. Örneğin, bir ön uç geliştirici, veritabanı, S3 emülatörü (minio) vb. dahil olmak üzere uygulamanın tüm öğelerini dizüstü bilgisayarında tutar. Yani bu yerel altyapının bakımına çok zaman harcıyor ve böyle bir çözümün tüm sorunlarıyla tek başına mücadele ediyor. Ön kısım için kod geliştirmek yerine. Bu tür kişiler her türlü değişime karşı oldukça dirençli olabilirler.
Ancak tam tersine yeni araç ve yöntemleri tanıtmaktan mutlu olan ve bu sürece aktif olarak katılan ekipler var. Ancak bu durumda bile DevOps mühendisi ile ekip arasındaki iletişim iptal edilmedi.
DevOps'a ihtiyaç duyulmadığında
DevOps'a ihtiyaç duyulmayan durumlar vardır. Bu bir gerçek; anlaşılması ve kabul edilmesi gerekiyor.
Her şeyden önce bu, kârlarının doğrudan müşterilere bilgi hizmetleri sağlayan BT ürünlerinin varlığına veya yokluğuna bağlı olmadığı tüm şirketler (özellikle küçük işletmeler) için geçerlidir. Ve burada, statik bir "kartvizit" veya dinamik haber blokları vb. Gibi şirketin web sitesinden bahsetmiyoruz.
Müşterinizin memnuniyeti ve size tekrar dönme isteği, müşteriyle etkileşim için bu bilgi hizmetlerinin varlığına, kalitesine ve hedeflemesine bağlı olduğunda DevOps gereklidir.
Çarpıcı bir örnek, tanınmış bir bankadır. Şirketin geleneksel müşteri ofisleri bulunmuyor, belge akışı posta veya kurye aracılığıyla yapılıyor ve birçok çalışan evden çalışıyor. Şirket sadece bir banka olmaktan çıktı ve bence gelişmiş DevOps teknolojileriyle bir BT şirketine dönüştü.
Tematik buluşmaların ve konferansların kayıtlarında başka birçok örnek ve ders bulunabilir. Bazılarını bizzat ziyaret ettim; bu yönde gelişmek isteyenler için çok faydalı bir deneyim. DevOps ile ilgili iyi dersler ve materyaller içeren YouTube kanallarının bağlantıları:
Şimdi işinize bakın ve şunu düşünün: Şirketiniz ve kârı, müşteri etkileşimini sağlamak için BT ürünlerine ne kadar bağlı?
Şirketiniz küçük bir mağazada balık satıyorsa ve tek BT ürünü iki 1C: Kurumsal yapılandırma (Muhasebe ve UNF) ise, DevOps hakkında konuşmak pek mantıklı değildir.
Büyük bir ticaret ve imalat işletmesinde çalışıyorsanız (örneğin av tüfekleri üretiyorsanız), o zaman bunu düşünmelisiniz. İnisiyatif alabilir ve DevOps'u uygulama olanaklarını yönetiminize iletebilirsiniz. Aynı zamanda bu süreci yönetin. Proaktif bir konum DevOps felsefesinin önemli ilkelerinden biridir.
Yıllık mali cironun boyutu ve hacmi, şirketinizin DevOps'a ihtiyacı olup olmadığının belirlenmesinde ana kriter değildir.
Müşterilerle doğrudan etkileşime girmeyen büyük bir sanayi kuruluşu düşünelim. Örneğin bazı otomobil üreticileri ve otomobil imalat şirketleri. Şimdi emin değilim ama geçmiş tecrübelerime dayanarak, uzun yıllar boyunca tüm müşteri etkileşimlerinin e-posta ve telefon aracılığıyla yapıldığını gördüm.
Müşterileri sınırlı sayıda araba satıcıları listesidir. Ve her birine üreticiden bir uzman atanıyor. Tüm dahili belge akışı SAP ERP üzerinden gerçekleşir. İç çalışanlar aslında bilgi sisteminin müşterileridir. Ancak bu IS, küme sistemlerini yönetmenin klasik araçlarıyla kontrol edilir. Bu, DevOps uygulamalarını kullanma olasılığını dışlar.
Dolayısıyla sonuç: Metodolojinin hedeflerini makalenin başından itibaren hatırlarsak, bu tür işletmeler için DevOps'un uygulanması kritik derecede önemli bir şey değildir. Ancak bugün bazı DevOps araçlarını kullandıklarını da göz ardı etmiyorum.
Öte yandan DevOps metodolojisini, felsefesini, uygulamalarını ve araçlarını kullanarak yazılım geliştiren çok sayıda küçük şirket var. DevOps'u uygulama maliyetinin, yazılım pazarında etkili bir şekilde rekabet etmelerine olanak tanıyan maliyet olduğuna inanıyorlar. Bu tür şirketlerin örnekleri görülebilir .
DevOps'un gerekli olup olmadığını anlamanın ana kriteri: BT ürünlerinizin şirket ve müşteriler için ne kadar değerli olduğu.
Şirketin kâr getiren ana ürünü yazılım ise DevOps'a ihtiyacınız vardır. Diğer ürünleri kullanarak gerçek para kazanmanız o kadar da önemli değil. Buna çevrimiçi mağazalar veya oyun içeren mobil uygulamalar da dahildir.
Tüm oyunlar, oyuncuların doğrudan veya dolaylı finansmanı sayesinde var olur. Playgendary'de, yaratımlarına doğrudan dahil olan 200'den fazla kişiyle ücretsiz mobil oyunlar geliştiriyoruz. DevOps'u nasıl kullanırız?
Evet, yukarıda anlatılanlarla tamamen aynı. Geliştiriciler ve testçilerle sürekli iletişim halindeyim ve çalışanlara DevOps metodolojisi ve araçları hakkında şirket içi eğitimler veriyorum.
Artık Unity ile tüm montaj hatlarını yürütmek ve ardından App Store ve Play Market'e dağıtım yapmak için Jenkins'i bir CI/CD işlem hatları aracı olarak aktif olarak kullanıyoruz. Klasik araç setinden daha fazlası:
- Asana - proje yönetimi için. Jenkins ile entegrasyon yapılandırıldı.
- Google Meet - görüntülü toplantılar için.
- Slack - Jenkins'ten gelen bildirimler de dahil olmak üzere iletişimler ve çeşitli uyarılar için.
- Atlassian Confluence - dokümantasyon ve grup çalışması için.
Acil planlarımız arasında SonarQube kullanarak statik kod analizinin başlatılması ve Sürekli Entegrasyon aşamasında Selenium kullanılarak otomatik kullanıcı arayüzü testinin gerçekleştirilmesi yer alıyor.
Bunun yerine bir sonuca
Şu düşünceyle bitirmek istiyorum: Yüksek vasıflı bir DevOps mühendisi olmak için insanlarla canlı olarak nasıl iletişim kurulacağını öğrenmek hayati önem taşıyor.
DevOps mühendisi bir takım oyuncusudur. Ve başka hiçbir şey yok. Meslektaşlarıyla iletişim kurma girişimi, bazı koşulların etkisi altında değil, kendisinden gelmelidir. Bir DevOps uzmanının ekip için en iyi çözümü görmesi ve önermesi gerekir.
Ve evet, herhangi bir çözümün uygulanması çok fazla tartışma gerektirecektir ve sonunda tamamen değişebilir. Bağımsız olarak gelişen, fikirlerini öneren ve uygulayan böyle bir kişinin hem ekip hem de işveren açısından değeri giderek artar. Bu, sonuçta aylık ücretinin miktarına veya ek ikramiye şeklinde yansır.
Kaynak: habr.com