DevOps'tan bahsederken asıl meseleyi kavramak zor mu oluyor? Uzman olmayanların bile konuya ulaşmasına yardımcı olacak canlı benzetmeler, çarpıcı formülasyonlar ve uzman tavsiyelerini sizin için topladık. Sonuçta bonus, Red Hat çalışanlarının kendi DevOps'udur.
DevOps terimi 10 yıl önce ortaya çıktı ve bir Twitter hashtag'inden BT dünyasında güçlü bir kültürel harekete, geliştiricileri işleri daha hızlı halletmeye, denemeler yapmaya ve ileriye doğru yinelemeye teşvik eden gerçek bir felsefeye dönüştü. DevOps, dijital dönüşüm kavramıyla ayrılmaz bir şekilde bağlantılı hale geldi. Ancak BT terminolojisinde sıklıkla olduğu gibi, DevOps son on yılda kendisi hakkında pek çok tanım, yorum ve yanlış anlama edindi.
Bu nedenle DevOps hakkında sıklıkla şu tür soruları duyabilirsiniz: Agile ile aynı şey midir? Yoksa bu özel bir metodoloji mi? Yoksa “işbirliği” kelimesinin başka bir eşanlamlısı mı?
DevOps pek çok farklı konsept içerir (sürekli teslimat, sürekli entegrasyon, otomasyon vb.), dolayısıyla önemli olanı ayrıştırmak, özellikle de konu hakkında tutkulu olduğunuzda zorlayıcı olabilir. Ancak, ister fikirlerinizi üstlerinize aktarmaya çalışıyor olun, ister ailenizden veya arkadaşlarınızdan birine işinizden bahsediyor olun, bu beceri çok faydalıdır. Bu nedenle DevOps'un terminolojik nüanslarını şimdilik bir kenara bırakıp büyük resme odaklanalım.
DevOps Nedir: 6 Tanım ve Analoji
Uzmanlardan DevOps'un özünü olabildiğince basit ve kısa bir şekilde açıklamalarını istedik, böylece değeri her düzeyde teknik bilgiye sahip okuyucular için netleşecektir. Bu görüşmelerin sonuçlarına dayanarak DevOps hakkındaki hikayenizi oluşturmanıza yardımcı olacak en çarpıcı benzetmeler ve çarpıcı formülasyonları seçtik.
1. DevOps kültürel bir harekettir
Kıdemli araştırma görevlisi Eveline Oehrlich şöyle diyor: "DevOps, her iki tarafın da (yazılım geliştiriciler ve BT sistemi operasyon uzmanları), birileri onu kullanmaya başlayana kadar yazılımın gerçek faydalar getirmediğini kabul ettiği kültürel bir harekettir: müşteriler, alıcılar, çalışanlar, asıl mesele bu değil" diyor kıdemli araştırma görevlisi Eveline Oehrlich DevOps Enstitüsü'nde analist. "Dolayısıyla, bu tarafların her ikisi de yazılımın hızlı ve kaliteli teslimini ortaklaşa sağlıyor."
2. DevOps, geliştiricileri güçlendirmekle ilgilidir.
"DevOps, geliştiricilere uygulamalara sahip olma, bunları çalıştırma ve teslimatı baştan sona yönetme yetkisi veriyor."
Sigorta şirketi Liberty Mutual'ın DevOps platformları direktörü Jai Schniepp, "Genellikle DevOps'tan, otomatikleştirilmiş süreçler oluşturup uygulayarak uygulamaların üretime teslimini hızlandırmanın bir yolu olarak bahsediliyor" diyor. “Ama benim için bu çok daha temel bir şey.” DevOps, geliştiricilere uygulamalara veya belirli yazılım parçalarına sahip olma, bunları çalıştırma ve teslimatlarını baştan sona yönetme yetkisi verir. DevOps, sorumluluk karmaşasını ortadan kaldırıyor ve otomatik, geliştirici odaklı bir altyapı oluşturmaya katılan herkese yol gösteriyor."
3. DevOps, uygulamaların oluşturulması ve sunulmasında işbirliği ile ilgilidir.
BMC'nin dijital iş otomasyonu başkanı ve başkanı Gur Staf, "Basitçe ifade etmek gerekirse DevOps, herkesin birlikte çalıştığı bir yazılım üretimi ve dağıtımı yaklaşımıdır" diyor.
4. DevOps bir boru hattıdır
"Konveyör montajı ancak tüm parçaların birbirine uyması durumunda mümkündür."
Gur Staff şöyle devam ediyor: "DevOps'u bir araba montaj hattına benzetiyorum." – Buradaki fikir, tüm parçaları önceden tasarlamak ve yapmaktır, böylece daha sonra bireysel ayarlamalar yapılmadan monte edilebilirler. Konveyör montajı ancak tüm parçaların birbirine uyması durumunda mümkündür. Bir motoru tasarlayan ve üretenlerin, onu gövdeye veya çerçeveye nasıl monte edeceklerini düşünmeleri gerekir. Frenleri yapanların tekerlekleri vs. düşünmesi gerekir. Aynı durum yazılım için de geçerli olmalıdır.
İş mantığı veya kullanıcı arayüzü oluşturan bir geliştiricinin, müşteri bilgilerini saklayan veritabanını, kullanıcı verilerini korumaya yönelik güvenlik önlemlerini ve hizmet büyük, hatta belki de milyonlarca dolarlık bir kullanıcı kitlesine hizmet etmeye başladığında tüm bunların nasıl çalışacağını düşünmesi gerekir. "
“İnsanların yalnızca kendi görevlerine odaklanmak yerine işbirliği yapmalarını ve işin diğerlerinin yaptığı kısımlar hakkında düşünmelerini sağlamak, aşılması gereken en büyük engeldir. Bunu yapabilirseniz, dijital dönüşüm için mükemmel bir şansınız var," diye ekliyor Gur Personeli.
5. DevOps insanların, süreçlerin ve otomasyonun doğru birleşimidir
DevOps Enstitüsü'nün genel müdürü Jayne Groll, DevOps'u açıklamak için harika bir benzetme sundu. Onun sözleriyle, “DevOps üç ana bileşen kategorisine sahip bir tarif gibidir: insanlar, süreç ve otomasyon. Bu bileşenlerin çoğu diğer alanlardan ve kaynaklardan alınabilir: Yalın, Çevik, SRE, CI/CD, ITIL, liderlik, kültür, araçlar. Her iyi tarif gibi DevOps'un da sırrı, uygulama oluşturma ve yayınlama hızını ve verimliliğini artırmak için doğru oranların nasıl elde edileceği ve bu bileşenlerin nasıl karıştırılacağıdır."
6. DevOps, programcıların Formula 1 takımı gibi çalıştığı zamandır
"Yarış baştan sona planlanmadı, tam tersine bitişten başlangıca planlandı."
Red Hat'in bulut platformu pazarlamasının kıdemli yöneticisi ve DevOps'a özgü haber bülteninin yayıncısı Chris Short, "Bir DevOps girişiminden ne beklenmesi gerektiği hakkında konuştuğumda, örnek olarak NASCAR veya Formula 1 yarış takımını düşünüyorum" diyor. – Böyle bir takımın liderinin tek bir hedefi vardır: Takımın elindeki kaynakları ve karşılaştığı zorlukları hesaba katarak yarış sonunda mümkün olan en yüksek sırayı almak. Bu durumda yarış baştan sona değil, tam tersine bitişten başa doğru planlanır. Öncelikle iddialı bir hedef belirlenir ve ardından bu hedefe ulaşmanın yolları belirlenir. Daha sonra bunlar alt görevlere bölünüyor ve ekip üyelerine devrediliyor.”
"Takım yarıştan önceki tüm haftayı pit stopu mükemmelleştirmekle geçiriyor. Yorucu bir yarış gününde formda kalmak için kuvvet antrenmanı ve kardiyo yapıyor. Yarış sırasında ortaya çıkabilecek sorunları çözmek için birlikte çalışarak pratikler yapar. Aynı şekilde geliştirme ekibinin de yeni sürümleri sık sık yayınlama becerisini geliştirmesi gerekir. Bu tür becerilere ve iyi işleyen bir güvenlik sistemine sahipseniz, yeni sürümlerin üretime sürülmesi de daha sık gerçekleşir. Bu dünya görüşünde artan hız, artan güvenlik anlamına geliyor” diyor Short.
Short şunu ekliyor: "Bu, 'doğru olanı' yapmakla ilgili değil, önemli olan, arzu edilen sonucun önünde duran mümkün olduğu kadar çok şeyi ortadan kaldırmaktır. Gerçek zamanlı olarak aldığınız geri bildirimlere göre işbirliği yapın ve uyum sağlayın. Anormalliklere karşı hazırlıklı olun ve bunların hedefinize doğru ilerleme üzerindeki etkilerini en aza indirmek için kaliteyi artırmaya çalışın. DevOps dünyasında bizi bekleyen şey bu.”
DevOps nasıl ölçeklendirilir: Uzmanlardan 10 ipucu
Sadece DevOps ve toplu DevOps tamamen farklı şeylerdir. Birinciden ikinciye giden yolda engelleri nasıl aşacağınızı size anlatacağız.
Birçok kuruluş için DevOps'a yolculuk kolay ve keyifli bir şekilde başlar. Küçük tutkulu ekipler oluşturulur, eski süreçler yenileriyle değiştirilir ve ilk başarıların gelmesi uzun sürmez.
North Highland danışmanlık şirketinin genel müdürü ve dijital başkanı Ben Grinnell, ne yazık ki bu sadece sahte bir parıltı, bir ilerleme yanılsaması, diyor. Erken kazanımlar kesinlikle cesaret vericidir, ancak DevOps'un kuruluş genelinde yaygın olarak benimsenmesi nihai hedefine ulaşılmasına yardımcı olmazlar.
Sonuçta “biz” ve “onlar” arasında bir bölünme kültürünün ortaya çıktığını görmek kolaydır.
Ben Grinnell şöyle açıklıyor: "Genellikle kuruluşlar, diğerlerinin bu yolu takip edip edemeyeceğini veya etmeye istekli olup olmayacağını dikkate almadan, ana DevOps'un önünü açacağını düşünerek bu öncü projeleri başlatıyor." – Bu tür projeleri uygulayacak ekipler genellikle benzer şeyleri başka yerlerde yapmış ancak kuruluşunuzda yeni olan, kendine güvenen “Varanglılar”dan seçilir. Aynı zamanda herkes için bağlayıcı olan kuralları yıkmaya ve yıkmaya teşvik ediliyorlar. Sonuçta bilgi ve becerilerin aktarımını engelleyen bir “biz” ve “onlar” kültürü oluştuğunu görmek kolaydır.”
"Ve bu kültürel sorun, DevOps'un ölçeklendirilmesinin zor olmasının nedenlerinden yalnızca biri. DevOps ekipleri, hızla büyüyen, BT öncelikli şirketler için tipik olan, artan teknik zorluklarla karşı karşıyadır," dedi Scalyr'in kurucusu ve başkanı Steve Newman.
“Modern dünyada ihtiyaç doğduğu anda hizmetler değişiyor. Steve Newman, sürekli olarak yeni özellikleri hayata geçirmek ve uygulamak harika, ancak bu süreci koordine etmek ve ortaya çıkan sorunları ortadan kaldırmak gerçek bir baş ağrısıdır, diye ekliyor. – Çok hızlı büyüyen organizasyonlarda, işlevler arası ekiplerdeki mühendisler, değişime ve bunun yarattığı bağımlılık düzeyindeki basamaklı etkilere ilişkin görünürlüğü sürdürmek için çabalıyor. Üstelik mühendisler bu fırsattan mahrum bırakıldıklarında mutlu olmuyorlar ve bunun sonucunda ortaya çıkan sorunların özünü anlamaları da zorlaşıyor.”
Yukarıda açıklanan bu zorlukların üstesinden nasıl gelinebilir ve büyük bir kuruluşta DevOps'un kitlesel olarak benimsenmesine nasıl geçilebilir? Nihai hedefiniz yazılım geliştirme döngünüzü ve iş süreçlerinizi hızlandırmak olsa bile uzmanlar sabırlı olmanızı tavsiye ediyor.
1. Kültür değişiminin zaman aldığını unutmayın.
Jayne Groll, DevOps Enstitüsü İcra Direktörü: "Bence DevOps'un genişletilmesi, çevik geliştirme kadar artımlı ve yinelemeli olmalı (ve aynı derecede kültüre de dokunmalıdır). Agile ve DevOps küçük ekipleri vurguluyor. Ancak bu ekiplerin sayısı ve entegrasyonu arttıkça, daha fazla insanın yeni çalışma yöntemlerini benimsemesiyle sonuçlanıyoruz ve bunun sonucunda da büyük bir kültürel dönüşüm yaşanıyor."
2. Platformu planlamaya ve seçmeye yeterince zaman ayırın
Perfecto'nun Baş Teknik Evangelisti Eran Kinsbruner: "İşe yarayacak şekilde ölçeklendirme yapmak için DevOps ekiplerinin öncelikle geleneksel süreçleri, araçları ve becerileri birleştirmeyi öğrenmesi, ardından DevOps'un her bir aşamasını yavaş yavaş beslemesi ve stabilize etmesi gerekiyor. Her şey, kullanıcı öykülerinin ve değer akışlarının dikkatli bir şekilde planlanmasıyla başlar, ardından gövde tabanlı geliştirme veya kodun dallara ayrılması ve birleştirilmesi için en uygun diğer yaklaşımlar kullanılarak yazılım ve sürüm kontrolü yazılması gelir."
“Ardından otomasyon için ölçeklenebilir bir platformun zaten gerekli olduğu entegrasyon ve test aşaması geliyor. DevOps ekiplerinin beceri düzeylerine ve projenin nihai hedeflerine uygun doğru platformu seçmesinin önemli olduğu nokta burasıdır.
Bir sonraki aşama, üretime dağıtımdır ve bu, düzenleme araçları ve kapsayıcılar kullanılarak tamamen otomatikleştirilmelidir. DevOps'un tüm aşamalarında (üretim simülatörü, QA ortamı ve gerçek üretim ortamı) sanallaştırılmış ortamlara sahip olmak ve ilgili sonuçları elde etmek amacıyla testler için her zaman yalnızca en son verileri kullanmak önemlidir. Analitiklerin akıllı olması ve büyük verileri hızlı ve eyleme dönüştürülebilir geri bildirimle işleyebilmesi gerekiyor."
3. Suçluluğu sorumluluktan çıkarın.
Gordon Haff, RedHat Evangelisti: “Deneyselliğe izin veren ve teşvik eden bir sistem ve atmosfer yaratmak, çevik yazılım geliştirmede başarılı başarısızlıklar olarak bilinen durumlara olanak tanır. Bu, başarısızlıklardan başkasının sorumlu olmadığı anlamına gelmez. Hatta “sorumlu olmak” artık “kazaya sebep olmak” anlamına gelmediğinden kimin sorumlu olduğunu tespit etmek daha da kolaylaşıyor. Yani sorumluluğun özü niteliksel olarak değişir. Dört faktör kritik hale geliyor: aksaklığın boyutu, yaklaşımlar, üretim süreçleri ve teşvikler.” (Bu faktörler hakkında daha fazla bilgiyi Gordon Huff'ın "DevOps dersleri: sağlıklı deneylerin 4 yönü" başlıklı makalesinde okuyabilirsiniz.)
4. İleriye giden yolu temizleyin
North Highland danışmanlık şirketinin genel müdürü ve dijital başkanı Ben Grinnell: “Ölçeğe ulaşmak için öncü projelerle birlikte bir “yol temizleme” programı başlatmanızı öneriyorum. Bu programın amacı, DevOps öncülerinin geride bıraktığı eski kurallar ve buna benzer çöpleri temizlemek, böylece ileriye giden yolun açık kalmasını sağlamaktır."
“Yeni çalışma yöntemlerinin başarılarını geniş çapta kutlayarak, öncü grubun çok ötesine geçen iletişim yoluyla insanlara organizasyonel destek ve ivme kazandırın. DevOps projelerinin bir sonraki dalgasına dahil olan ve DevOps'u ilk kez kullanma konusunda endişeli olan kişilere koçluk yapın. Ve bu insanların öncülerden çok farklı olduğunu unutmayın.”
5. Araçları demokratikleştirin
Scalyr'in kurucusu ve başkanı Steve Newman: "Araçlar insanlardan saklanmamalı ve zaman ayırmaya istekli herkes için öğrenmesi nispeten kolay olmalıdır. Günlükleri sorgulama yeteneği, bir aracı kullanma "sertifikalı" üç kişiyle sınırlıysa, çok büyük bir bilgi işlem ortamınız olsa bile, sorunu çözebilecek en fazla üç kişi her zaman hazır olacaktır. Yani burada ciddi (ticari) sonuçlara yol açabilecek bir darboğaz var.”
6. Ekip çalışması için ideal koşulları yaratın
ITV Ortak Platform başkanı Tom Clark: "Her şeyi yapabilirsiniz ama her şeyi aynı anda yapamazsınız. Bu nedenle büyük hedefler belirleyin, küçük başlayın ve hızlı yinelemelerle ilerleyin. Zamanla işleri halletme konusunda itibar kazanacaksınız, böylece başkaları da sizin yöntemlerinizi kullanmak isteyecektir. Son derece etkili bir ekip oluşturma konusunda endişelenmeyin. Bunun yerine insanlara ideal çalışma koşulları sağlayın, verimlilik de gelecektir.”
7. Conway Yasasını ve Kanban kurullarını unutmayın
CollabNetVersionOne Yazılım Teslimatı ve DevOps Stratejisi Direktörü Logan Daigle: “Conway Yasasının sonuçlarını anlamak önemlidir. Benim gevşek ifademle bu yasa, DevOps da dahil olmak üzere yarattığımız ürünlerin ve bunu yapmak için kullandığımız süreçlerin kuruluşumuzla aynı şekilde yapılandırıldığını belirtiyor."
"Bir organizasyonda çok sayıda silo varsa ve yazılımı planlarken, oluştururken ve piyasaya sürerken kontrol birçok kez el değiştirirse, ölçeklendirmenin etkisi sıfır veya kısa ömürlü olacaktır. Bir kuruluş, pazar odaklı finanse edilen ürünler etrafında çapraz işlevli ekipler kurarsa, başarı şansı önemli ölçüde artar."
“Ölçeklendirmenin bir diğer önemli yönü, devam eden tüm çalışmaların (WIP, devam eden çalışma) Kanban panolarında görüntülenmesidir. Bir kuruluş, insanların bunları görebileceği bir yere sahip olduğunda, işbirliğini büyük ölçüde teşvik eder ve bu da ölçeklendirme üzerinde olumlu bir etkiye sahiptir."
8. Eski yara izlerini arayın
DevOps danışmanı ve Team Topologies kitabının ortak yazarı Manuel Pais: "DevOps uygulamalarını Dev and Ops'un ötesine taşımak ve bunları diğer işlevlere uygulamaya çalışmak pek de ideal bir yaklaşım değil. Bunun kesinlikle bir etkisi olacaktır (örneğin, manuel kontrolün otomatikleştirilmesi), ancak teslimat ve geri bildirim süreçlerini anlamaya başlarsak çok daha fazlasını başarabiliriz."
“Bir kuruluşun BT sisteminde eski yara izleri (geçmişteki olayların sonucu olarak uygulanan ancak (ürünlerdeki, teknolojilerdeki veya süreçlerdeki değişiklikler nedeniyle) geçerliliğini kaybetmiş prosedürler ve yönetim mekanizmaları) varsa, o zaman bunların kesinlikle kaldırılması gerekir Verimsiz veya gereksiz süreçleri otomatikleştirmek yerine düzeltin veya düzeltin.
9. DevOps seçeneklerini çoğaltmayın
Patlıcan Operasyon Direktörü Anthony Edwards: "DevOps çok belirsiz bir terim, dolayısıyla her ekip kendi DevOps sürümünü oluşturuyor. Ve bir kuruluşun birdenbire birbirleriyle pek iyi geçinemeyen 20 çeşit DevOps'a sahip olması daha kötü bir şey olamaz. Üç geliştirme ekibinin her birinin, geliştirme ve ürün yönetimi arasında kendine ait özel bir arayüze sahip olması imkansızdır. Ürünlerin, bir üretim simülatörüne aktarıldığında geri bildirimin ele alınması konusunda kendine özgü beklentileri de olmamalıdır. Aksi takdirde DevOps'u hiçbir zaman ölçeklendiremezsiniz."
10. DevOps'un iş değerini duyurun
Scalyr'in kurucusu ve başkanı Steve Newman: “DevOps'un değerinin farkına varmak için çalışın. Öğrenin ve yaptığınız işin yararları hakkında konuşmaktan çekinmeyin. DevOps inanılmaz bir zaman ve para tasarrufu sağlar (bir düşünün: daha az kesinti, daha kısa ortalama kurtarma süresi) ve DevOps ekipleri, bu girişimlerin iş başarısı için önemini yorulmadan vurgulamalı (ve vaaz etmelidir). Bu şekilde taraftar çevrenizi genişletebilir ve DevOps'un kuruluştaki etkisini artırabilirsiniz."
BONUS
Üzerinde Kendi DevOps'umuz 13 Eylül'de gelecek - evet, bir yazılım üreticisi olarak Red Hat'in kendi DevOps ekipleri ve uygulamaları var.
Kuruluş genelindeki diğer gruplar için dahili otomasyon hizmetleri geliştiren mühendisimiz Mark Birger, Red Hat DevOps ekibinin uygulamaları Ansible tarafından yönetilen Hat Virtualization sanal ortamlarından tam teşekküllü konteyner formatına nasıl geçirdiğini kendi hikayesini saf Rusça olarak anlatacak. OpenShift platformu.
Ama hepsi bu kadar değil:
Kuruluşlar iş yüklerini konteynerlere taşıdığında geleneksel uygulama izleme yöntemleri çalışmayabilir. İkinci konuşmamızda, kayıt tutma şeklimizi değiştirme konusundaki motivasyonumuzu açıklayacağız ve bizi modern kayıt tutma ve izleme yöntemlerine götüren yolun devamını göstereceğiz.
Kaynak: habr.com