Rusya'da DevOps Durumu 2020

Bir şeyin hali nasıl anlaşılır?

Web sitelerindeki yayınlar veya deneyimler gibi çeşitli bilgi kaynaklarından oluşan fikrinize güvenebilirsiniz. Meslektaşlarınıza, tanıdıklarınıza sorabilirsiniz. Başka bir seçenek de konferansların konularına bakmaktır: program komitesi sektörün aktif temsilcileridir, bu nedenle ilgili konuları seçerken onlara güveniyoruz. Ayrı bir alan araştırma ve raporlardır. Ama bir problem var. Dünyada her yıl DevOps'un durumuyla ilgili araştırmalar yapılıyor, yabancı şirketler tarafından raporlar yayınlanıyor ve Rus DevOps hakkında neredeyse hiçbir bilgi yok.

Ancak böyle bir çalışmanın yapıldığı gün geldi ve bugün sonuçları hakkında konuşacağız. DevOps'un Rusya'daki durumu şirketler tarafından ortaklaşa incelendi "Ekspres 42"Ve"ontiko". Express 42, teknoloji şirketlerinin DevOps uygulamalarını ve araçlarını uygulamasına ve geliştirmesine yardımcı oluyor ve Rusya'da DevOps hakkında ilk konuşanlardan biri oldu. Çalışmanın yazarları Igor Kurochkin ve Vitaly Khabarov, Express 42'de analiz ve danışmanlık yapmakta olup, operasyondan teknik geçmişe ve farklı şirketlerde deneyime sahiptir. 8 yıl boyunca, meslektaşlarımız farklı kültürel ve mühendislik olgunluğunun yanı sıra farklı sorunları olan - startup'lardan işletmelere - onlarca şirket ve projeye baktılar.

Igor ve Vitaly raporlarında araştırma sürecinde hangi sorunların olduğunu, bunları nasıl çözdüklerini, ayrıca DevOps araştırmasının prensipte nasıl yürütüldüğünü ve Express 42'nin neden kendi araştırmasını yapmaya karar verdiğini anlattılar. Raporları görüntülenebilir burada.

DevOps Araştırması

Konuşma Igor Kurochkin tarafından başlatıldı.

DevOps konferanslarında izleyicilere düzenli olarak "Bu yıl için DevOps durum raporunu okudunuz mu?" diye soruyoruz. Çok azı ellerini kaldırıyor ve çalışmamız, onları yalnızca üçte birinin incelediğini gösterdi. Bu tür raporları hiç görmediyseniz hemen hepsinin birbirine çok benzediğini söyleyelim. Çoğu zaman "Geçen yıla kıyasla ..." gibi ifadeler vardır.

Burada ilk sorunumuz var ve ondan sonra iki sorun daha var:

1. Geçen yıl için elimizde veri yok. DevOps'un Rusya'daki durumu kimseyi ilgilendirmiyor;
2. Metodoloji. Hipotezlerin nasıl test edileceği, soruların nasıl oluşturulacağı, nasıl analiz edileceği, sonuçların nasıl karşılaştırılacağı, bağlantıların nasıl bulunacağı açık değildir;
3. terminoloji. Tüm raporlar İngilizce'dir, çeviri gereklidir, ortak bir DevOps çerçevesi henüz icat edilmemiştir ve herkes kendi raporunu bulur.

DevOps durum analizlerinin dünya çapında nasıl yapıldığına bir göz atalım.

Tarihsel bilgi

DevOps araştırması 2011'den beri yürütülmektedir. Konfigürasyon yönetim sistemlerinin geliştiricisi olan Puppet, bunları ilk uygulayan kişiydi. O zamanlar, altyapıyı kod biçiminde açıklayan ana araçlardan biriydi. 2013 yılına kadar, bu çalışmalar sadece kapalı anketlerdi ve kamuya açık raporlar yoktu.

2013 yılında, DevOps ile ilgili tüm büyük kitapların yayıncısı olan IT Revolution ortaya çıktı. Puppet ile birlikte, 4 temel metriğin ilk kez ortaya çıktığı ilk State of DevOps yayınını hazırladılar. Ertesi yıl, endüstri uygulamaları ve araçları üzerine düzenli teknoloji radarları ile tanınan bir danışmanlık firması olan ThoughtWorks dahil oldu. 2015 yılında ise metodoloji bölümü eklendi ve analizi nasıl yaptıkları belli oldu.

2016 yılında, çalışmanın yazarları, kendi şirketleri DORA'yı (DevOps Araştırma ve Değerlendirme) kurarak yıllık bir rapor yayınladılar. Ertesi yıl, DORA ve Puppet son ortak raporlarını yayınladılar.

Ve sonra ilginç bir şey başladı:

2018'de şirketler ayrıldı ve iki bağımsız rapor yayınlandı: biri Puppet'ten, ikincisi Google ile birlikte DORA'dan. DORA, metodolojisini temel ölçütler, performans profilleri ve temel ölçütleri ve şirket çapındaki performansı etkileyen mühendislik uygulamalarıyla güçlendirmeye devam etti. Ve Puppet, sürecin bir açıklaması ve DevOps'un evrimi ile kendi yaklaşımını sundu. Ancak hikaye kök salmadı, 2019'da Puppet bu metodolojiyi terk etti ve raporların, temel uygulamaları ve DevOps'u kendi bakış açılarından nasıl etkilediklerini listeleyen yeni bir sürümünü yayınladı. Sonra başka bir olay oldu: Google, DORA'yı satın aldı ve birlikte başka bir rapor yayınladılar. Onu görmüş olabilirsin.

Bu yıl işler karmaşıklaştı. Puppet'in kendi anketini başlattığı biliniyor. Bizden bir hafta önce yaptılar ve çoktan bitti. İçinde yer aldık ve hangi konulara ilgi duyduklarına baktık. Puppet şimdi analizini yapıyor ve raporu yayınlamaya hazırlanıyor.

Ancak DORA ve Google'dan hala bir duyuru yok. Genellikle anketin başladığı Mayıs ayında, DORA'nın kurucularından Nicole Forsgren'in başka bir şirkete taşındığı bilgisi geldi. Dolayısıyla bu yıl DORA'dan araştırma ve rapor gelmeyeceğini varsaydık.

Rusya'da işler nasıl?

DevOps araştırması yapmadık. Konferanslarda konuştuk, başkalarının bulgularını yeniden anlattık ve Raiffeisenbank 2019 için "DevOps Durumu"nu tercüme etti (duyurularını Habré'de bulabilirsiniz), onlara çok teşekkürler. Ve hepsi bu.

Bu nedenle, DORA metodolojilerini ve bulgularını kullanarak Rusya'da kendi araştırmamızı yaptık. Araştırmamız için terminoloji ve çeviri senkronizasyonu da dahil olmak üzere Raiffeisenbank'tan meslektaşlarımızın raporunu kullandık. Sektörle ilgili sorular ise DORA raporlarından ve bu yılki Puppet anketinden alındı.

Araştırma süreci

Rapor sadece son kısımdır. Tüm araştırma süreci dört ana adımdan oluşur:

Hazırlık aşamasında sektör uzmanlarıyla görüştük ve bir hipotez listesi hazırladık. Bunlara dayanarak, sorular derlendi ve Ağustos ayının tamamı için bir anket başlatıldı. Ardından raporun kendisini analiz edip hazırladık. DORA için bu süreç 6 ay sürmektedir. 3 ay içinde tanıştık ve şimdi zar zor yeterli zamanımız olduğunu anlıyoruz: yalnızca analizi yaparak hangi soruları sormanız gerektiğini anlıyorsunuz.

Katılımcılar

Tüm yabancı raporlar, katılımcıların bir portresiyle başlar ve çoğu Rusya'dan değildir. Rus yanıt verenlerin yüzdesi yıldan yıla %5 ile %1 arasında dalgalanıyor ve bu herhangi bir sonuca varılmasına izin vermiyor.

Accelerate State of DevOps 2019 raporundan harita:

Çalışmamızda 889 kişiyle görüşmeyi başardık - bu oldukça fazla (DORA raporlarında yılda bin kişi hakkında anket yapıyor) ve burada hedefe ulaştık:

Doğru, tüm katılımcılarımız sona ulaşmadı: tamamlama yüzdesinin yarısından biraz daha az olduğu ortaya çıktı. Ancak bu bile temsili bir numune almak ve bir analiz yapmak için yeterliydi. DORA, raporlarında doluluk yüzdelerini açıklamadığından burada bir karşılaştırma yapılmaz.

Sektörler ve pozisyonlar

Yanıtlayıcılarımız bir düzine sektörü temsil ediyor. Bilgi teknolojisinde yarım çalışma. Bunu finansal hizmetler, ticaret, telekomünikasyon ve diğerleri izlemektedir. Pozisyonlar arasında uzmanlar (geliştirici, testçi, operasyon mühendisi) ve yönetim kadrosu (ekip, grup, alan, müdür) vardır:

Her iki kişiden biri orta ölçekli bir şirkette çalışıyor. Her üç kişiden biri büyük şirketlerde çalışıyor. Çoğu, 9 kişiye kadar olan ekipler halinde çalışır. Ayrı olarak, ana faaliyetleri sorduk ve çoğunluk bir şekilde operasyonla ilgili ve yaklaşık% 40'ı geliştirme ile ilgileniyor:

Bu nedenle, farklı sektörlerin, şirketlerin, ekiplerin temsilcilerinin karşılaştırması ve analizi için bilgi topladık. Meslektaşım Vitaly Khabarov analizden bahsedecek.

Analiz ve karşılaştırma

Vitaly Khabarov: Anketimizi tamamlayan, anketleri dolduran ve hipotezlerimizin daha fazla analiz edilmesi ve test edilmesi için bize veri sağlayan tüm katılımcılara çok teşekkür ederiz. Müşterilerimiz ve müşterilerimiz sayesinde, endüstri endişelerini belirlememize ve araştırmamızda test ettiğimiz hipotezleri formüle etmemize yardımcı olan zengin bir deneyime sahibiz.

Ne yazık ki, bir yandan soru listesini, diğer yandan verileri alıp bir şekilde karşılaştıramaz, "Evet, her şey böyle çalışıyor, biz haklıydık" deyip dağılamazsınız. Hayır, yanılmadığımızdan ve vardığımız sonuçların güvenilir olduğundan emin olmak için metodolojiye ve istatistiksel yöntemlere ihtiyacımız var. Ardından, bu verilere dayanarak daha fazla çalışmamızı inşa edebiliriz:

Temel Metrikler

“Accelerate State of DevOps” kitabında detaylı olarak anlattıkları DORA metodolojisini esas aldık. Temel ölçütlerin Rusya pazarı için uygun olup olmadığını, DORA'nın "Rusya'daki sektör yabancı sektörle nasıl örtüşüyor?" sorusunu yanıtlamak için kullandığı şekilde kullanılıp kullanılamayacağını kontrol ettik.

Anahtar metrikler:

1. Dağıtım sıklığı. Uygulamanın yeni bir sürümü üretim ortamına ne sıklıkla dağıtılır (düzeltmeler ve olay yanıtı hariç planlanan değişiklikler)?
2. Teslimat süresi. Bir değişikliği gerçekleştirme (işlevselliği kod olarak yazma) ile değişikliği üretim ortamına dağıtma arasındaki ortalama süre nedir?
3. iyileşme süresi. Bir olayın, hizmetin bozulmasının veya uygulama kullanıcılarını etkileyen bir hatanın keşfedilmesinin ardından bir uygulamayı üretim ortamına geri yüklemek ortalama ne kadar sürer?
4. Başarısız değişiklikler Üretim ortamındaki konuşlandırmaların yüzde kaçı uygulamada bozulmaya veya olaylara neden oluyor ve iyileştirme gerektiriyor (değişikliklerin geri alınması, bir düzeltmenin veya yamanın geliştirilmesi)?

DORA, araştırmasında bu ölçümler ile kurumsal performans arasında bir bağlantı bulmuştur. Çalışmamızda da test ediyoruz.

Ancak dört temel ölçümün bir şeyi etkileyebileceğinden emin olmak için anlamanız gerekir - bunlar bir şekilde birbirleriyle ilişkili mi? DORA, bir uyarıyla olumlu yanıt verdi: başarısız değişiklikler (Değişim Başarısızlık Oranı) ile diğer üç ölçüm arasındaki ilişki biraz daha zayıf. Hemen hemen aynı resmi elde ettik. Teslim süresi, dağıtım sıklığı ve kurtarma süresi birbiriyle ilişkiliyse (bu ilişkiyi Pearson korelasyonu ve Chaddock ölçeği aracılığıyla kurduk), o zaman başarısız değişikliklerle bu kadar güçlü bir korelasyon yoktur.

Prensip olarak, yanıt verenlerin çoğu, üretimde oldukça az sayıda olay yaşadıkları yanıtını verme eğilimindedir. Başarısız değişiklikler açısından yanıtlayan grupları arasında hala önemli bir fark olduğunu daha sonra görecek olsak da, bu metriği bu bölümleme için henüz kullanamıyoruz.

Bunu, (bazı müşterilerimizle yapılan analiz ve iletişim sırasında ortaya çıktığı gibi) olay olarak kabul edilen şeyin algılanmasında küçük bir fark olmasına bağlıyoruz. Teknik pencerede hizmetimizin performansını eski haline getirmeyi başardıysak, bu bir olay olarak kabul edilebilir mi? Muhtemelen hayır, çünkü her şeyi düzelttik, harikayız. Uygulamamızı bizim için normal, tanıdık bir modda 10 kez tekrarlamak zorunda kalsak bunu bir olay olarak kabul edebilir miyiz? Öyle görünmüyor. Bu nedenle, başarısız değişikliklerin diğer metriklerle ilişkisi sorusu açık kalmaktadır. Daha da geliştireceğiz.

Burada önemli olan, teslimat süreleri, kurtarma süreleri ve dağıtım sıklığı arasında önemli bir ilişki bulmamızdır. Bu nedenle, yanıtlayanları performans gruplarına daha fazla bölmek için bu üç ölçümü aldık.

Gram olarak ne kadar asmak?

Hiyerarşik küme analizi kullandık:

• Yanıtlayanları, her yanıtlayanın koordinatının sorulara verdiği yanıtlar olduğu n boyutlu bir alana dağıtıyoruz.
• Her yanıtlayan küçük bir küme olarak bildirilir.
• Birbirine en yakın iki kümeyi daha büyük bir kümede birleştiriyoruz.
• Bir sonraki küme çiftini bulup daha büyük bir kümede birleştiriyoruz.

Bu, tüm yanıtlayanlarımızı ihtiyacımız olan küme sayısına göre gruplandırmamızın yoludur. Bir dendrogram (kümeler arasındaki bağlantı ağacı) yardımıyla iki komşu küme arasındaki mesafeyi görürüz. Bize sadece bu kümeler arasında belirli bir mesafe sınırı belirleyip "Bu iki grup birbirinden oldukça ayırt edilebilir çünkü aralarındaki mesafe çok büyük" diyebilmek kalıyor.

Ancak burada gizli bir sorun var: küme sayısında herhangi bir kısıtlamamız yok - 2, 3, 4, 10 küme elde edebiliyoruz. Ve ilk fikir şuydu - neden tüm katılımcılarımızı DORA'nın yaptığı gibi 4 gruba ayırmayalım. Ancak bu gruplar arasındaki farkların önemsiz hale geldiğini gördük ve yanıtlayanın komşu gruba değil de gerçekten kendi grubuna ait olduğundan emin olamayız. Rusya pazarını henüz dört gruba ayıramayız. Bu nedenle, aralarında istatistiksel olarak anlamlı bir fark bulunan üç profil üzerinde karar kıldık:

Ardından, profili kümelere göre belirledik: her grup için her metriğe ilişkin medyanı aldık ve bir performans profilleri tablosu derledik. Aslında, her gruptaki ortalama katılımcının performans profillerini aldık. Üç verimlilik profili belirledik: Düşük, Orta, Yüksek:

Burada, performans profilini belirlemek için 4 temel ölçütün uygun olduğu ve bunların hem Batı hem de Rusya pazarlarında işe yaradığı hipotezimizi doğruladık. Gruplar arasında fark vardır ve istatistiksel olarak anlamlıdır. Başlangıçta yanıt verenleri bu parametreye göre bölmemiş olsak da, ortalama açısından başarısız değişikliklerin metriği açısından performans profilleri arasında önemli bir fark olduğunu vurgulamak isterim.

Sonra soru ortaya çıkıyor: tüm bunlar nasıl kullanılır?

Nasıl kullanılır?

Herhangi bir takımı, 4 temel ölçütü alıp masaya uygularsak, vakaların %85'inde tam bir eşleşme elde edemeyiz - bu sadece ortalama bir katılımcıdır ve gerçekte olan değil. Hepimiz (ve her takım) biraz farklıyız.

Kontrol ettik: yanıtlayanlarımızı ve DORA performans profilini aldık ve kaç yanıtlayanın şu veya bu profile uyduğuna baktık. Ankete katılanların yalnızca %16'sının kesinlikle profillerden birine girdiğini bulduk. Geri kalan her şey, aralarında bir yere dağılmış durumda:

Bu, verimlilik profilinin sınırlı bir kapsama sahip olduğu anlamına gelir. İlk yaklaşımda nerede olduğunuzu anlamak için şu tabloyu kullanabilirsiniz: "Ah, görünüşe göre Orta veya Yüksek'e daha yakınız!" Bundan sonra nereye gideceğinizi anlarsanız, bu yeterli olabilir. Ancak hedefiniz sürekli, sürekli gelişme ise ve tam olarak nerede gelişeceğinizi ve ne yapacağınızı daha iyi bilmek istiyorsanız, o zaman ek fonlara ihtiyaç vardır. Onlara hesap makinesi adını verdik:

• DORA hesap makinesi
• Hesap Makinesi Express 42* (geliştirme aşamasında)
• Kendi geliştirme (kendi dahili hesap makinenizi oluşturabilirsiniz).

Ne için gerekliler? Anlamak:

• Organizasyonumuzdaki ekip standartlarımıza uygun mu?
• Değilse, şirketimizin sahip olduğu uzmanlık çerçevesinde yardımcı olabilir, hızlandırabilir miyiz?
• Eğer öyleyse, daha iyisini yapabilir miyiz?

Bunları şirket içinde istatistik toplamak için de kullanabilirsiniz:

• Hangi takımlarımız var?
• Ekipleri profillere ayırın;
• Bakın: Oh, bu komutlar düşük performans gösteriyor (biraz geri çekilmiyorlar), ancak bunlar harika: her gün hatasız konuşlandırılıyorlar, bir saatten daha kısa bir teslim süreleri var.

Ve sonra şirketimizde henüz eşit seviyede olmayan ekipler için gerekli uzmanlık ve araçlar olduğunu öğrenebilirsiniz.

Veya şirket içinde harika hissettiğinizi anlarsanız, birçok kişiden daha iyisiniz, o zaman biraz daha geniş görünebilirsiniz. Bu sadece Rus endüstrisi: Kendimizi hızlandırmak için Rus endüstrisinde gerekli uzmanlığı alabilir miyiz? Express 42 hesap makinesi burada yardımcı olacaktır (geliştirme aşamasındadır). Rusya pazarını aştıysanız, o zaman bakın DORA hesap makinesi ve dünya pazarına

İyi. Ve DORA hesap makinesinde Elit grubundaysanız ne yapmalısınız? Burada iyi bir çözüm yok. Büyük olasılıkla sektörün ön saflarındasınız ve daha fazla hızlanma ve güvenilirlik, dahili Ar-Ge ve daha fazla kaynak harcama yoluyla mümkündür.

En tatlı karşılaştırmaya geçelim.

Karşılaştırma

Başlangıçta Rus endüstrisini Batı endüstrisi ile karşılaştırmak istedik. Doğrudan karşılaştırırsak, daha az profilimizin olduğunu ve bunların birbirine biraz daha karıştığını, sınırların biraz daha bulanık olduğunu görüyoruz:

Seçkin performans gösterenlerimiz, Yüksek performans gösterenler arasında gizlidir, ancak oradalar - bunlar, önemli yüksekliklere ulaşmış seçkin, tek boynuzlu atlardır. Rusya'da Elit profil ile Yüksek profil arasındaki fark henüz yeterince önemli değil. Mühendislik kültürünün, mühendislik uygulamalarının uygulama kalitesinin ve şirketlerdeki uzmanlığın artması nedeniyle gelecekte bu ayrışmanın gerçekleşeceğini düşünüyoruz.

Rus endüstrisi içinde doğrudan bir karşılaştırmaya geçersek, Yüksek profilli ekiplerin her açıdan daha iyi olduğunu görebiliriz. Ayrıca, bu ölçümler ile kurumsal performans arasında bir ilişki olduğu hipotezimizi de doğruladık: Yüksek profilli ekiplerin yalnızca hedeflere ulaşmakla kalmayıp aynı zamanda onları aşma olasılığı da çok daha yüksektir.
Yüksek profilli ekipler olalım ve burada durmayalım:

Ancak bu yıl özel ve şirketlerin bir pandemide ne durumda olduğunu kontrol etmeye karar verdik: Yüksek profilli ekipler sektör ortalamasından çok daha iyi durumda ve kendilerini daha iyi hissediyor:

• 1,5-2 kat daha fazla yeni ürün çıkarma olasılığı,
• Uygulama altyapısının güvenilirliğini ve/veya performansını artırma olasılığı 2 kat daha fazladır.

Yani, daha hızlı geliştirmelerine, yeni ürünleri piyasaya sürmelerine, mevcut ürünleri modifiye etmelerine ve böylece yeni pazarları ve yeni kullanıcıları fethetmelerine zaten yardımcı olan yetkinlikler:

Ekiplerimize başka neler yardımcı oldu?

mühendislik uygulamaları

Test ettiğimiz her uygulama için önemli bulguları size anlatacağım. Belki başka bir şey ekiplere yardımcı oldu, ancak biz DevOps'tan bahsediyoruz. DevOps içinde, farklı profillere sahip ekipler arasında bir fark görüyoruz.

Hizmet Olarak Platform

Platform yaşı ile takım profili arasında anlamlı bir ilişki bulamadık: Platformlar, hem Alt Takımlar hem de Yüksek Takımlar için yaklaşık aynı zamanlarda ortaya çıktı. Ancak ikincisi için platform, program kodu aracılığıyla kontrol için ortalama olarak daha fazla hizmet ve daha fazla programlama arabirimi sağlar. Ayrıca platform ekiplerinin, geliştiricilerinin ve ekiplerinin platformu kullanmalarına, sorunlarını ve platformla ilgili olayları daha sık çözmelerine ve diğer ekipleri eğitmelerine yardımcı olma olasılığı daha yüksektir.

Kod olarak altyapı

Burada her şey oldukça standart. Altyapı kodunun çalışmasının otomasyonu ile altyapı deposunda ne kadar bilgi depolandığı arasında bir ilişki bulduk. Yüksek profil komutları, havuzlarda daha fazla bilgi depolar: bu, altyapı yapılandırması, CI / CD ardışık düzeni, ortam ayarları ve yapı parametreleridir. Bu bilgileri daha sık depolarlar, altyapı koduyla daha iyi çalışırlar ve altyapı koduyla çalışmak için daha fazla işlem ve görevi otomatikleştirirler.

İlginç bir şekilde, altyapı testlerinde önemli bir fark görmedik. Bunu, Yüksek profilli ekiplerin genel olarak daha fazla test otomasyonuna sahip olmasına bağlıyorum. Belki de altyapı testleriyle ayrı ayrı dikkatleri dağılmamalı, daha çok uygulamaları kontrol ettikleri testlerle ve onlar sayesinde neyi ve nerede kırdıklarını zaten görüyorlar.

Entegrasyon ve teslimat

En sıkıcı bölüm, çünkü ne kadar çok otomasyona sahip olursanız, kodla o kadar iyi çalışırsanız, daha iyi sonuçlar alma olasılığınızın o kadar yüksek olduğunu onayladık.

Mimari

Mikro hizmetlerin performansı nasıl etkilediğini görmek istedik. Gerçekte, mikro hizmetlerin kullanımı performans göstergelerinde bir artışla ilişkili olmadığı için bunu yapmazlar. Mikro hizmetler, hem Yüksek profilli komutlar hem de Düşük profilli komutlar için kullanılır.

Ancak önemli olan, Yüksek ekipler için bir mikro hizmet mimarisine geçişin, hizmetlerini bağımsız olarak geliştirmelerine ve kullanıma sunmalarına olanak sağlamasıdır. Mimari, geliştiricilerin ekip dışından birini beklemeden özerk hareket etmelerine izin veriyorsa, bu, hızı artırmak için önemli bir yetkinliktir. Bu durumda, mikro hizmetler yardımcı olur. Ve sadece onların uygulanması büyük bir rol oynamıyor.

Tüm bunları nasıl keşfettik?

DORA metodolojisini tamamen kopyalamak için iddialı bir planımız vardı, ancak kaynaklarımız yoktu. DORA çok fazla sponsorluk kullanıyorsa ve araştırmaları yarım yıl sürüyorsa, araştırmamızı kısa sürede yaptık. DORA'nın yaptığı gibi bir DevOps modeli oluşturmak istedik ve bunu gelecekte yapacağız. Şimdiye kadar kendimizi ısı haritalarıyla sınırladık:

Mühendislik uygulamalarının her profildeki ekipler arasındaki dağılımına baktık ve Yüksek profilli ekiplerin ortalama olarak mühendislik uygulamalarını kullanma olasılıklarının daha yüksek olduğunu gördük. Tüm bunlar hakkında daha fazla bilgiyi bizim yazımızda okuyabilirsiniz. rapor.

Değişiklik olsun diye, karmaşık istatistiklerden basit istatistiklere geçelim.

Başka neler keşfettik?

Araçlar

Komutların çoğunun Linux ailesinin işletim sistemi tarafından kullanıldığını gözlemliyoruz. Ancak Windows hala trendde - yanıtlayanlarımızın en az dörtte biri Windows'un sürümlerinden birini veya diğerini kullandığını belirtti. Görünüşe göre pazarın bu ihtiyacı var. Dolayısıyla bu yetkinliklerinizi geliştirebilir, konferanslarda sunumlar yapabilirsiniz.

Orkestratörler arasında kimse için bir sır değil, Kubernetes önde (%52). Sıradaki düzenleyici Docker Swarm'dır (yaklaşık %12). En popüler CI sistemleri Jenkins ve GitLab'dır. En popüler konfigürasyon yönetim sistemi Ansible'dır ve onu çok sevdiğimiz Shell takip eder.

Amazon şu anda lider bulut barındırma sağlayıcısıdır. Rus bulutlarının payı giderek artıyor. Gelecek yıl, Rus bulut sağlayıcılarının pazar paylarının artıp artmayacağını görmek ilginç olacak. Onlar, kullanılabilirler ve bu iyi:

Biraz daha istatistik verecek olan Igor'a söz veriyorum.

Uygulamaların yaygınlaştırılması

Igor Kurochkin: Ayrı olarak, katılımcılara dikkate alınan mühendislik uygulamalarının şirkette nasıl dağıtıldığını belirtmelerini istedik. Çoğu şirkette, farklı kalıplardan oluşan karma bir yaklaşım vardır ve pilot projeler çok popülerdir. Profiller arasında da küçük bir fark gördük. Yüksek profilli temsilciler, küçük uzman ekipleri iş süreçlerini, araçları değiştirdiğinde ve başarılı uygulamaları diğer ekiplerle paylaştığında, "Aşağıdan inisiyatif" modelini daha sık kullanır. Medium'da bu, toplulukların ve mükemmellik merkezlerinin oluşturulması yoluyla tüm şirketi etkileyen yukarıdan aşağıya bir girişimdir:

Çevik ve DevOps

Agile ve DevOps arasındaki bağlantı sorusu sektörde sıklıkla tartışılır. Bu sorun, 2019/2020 Çevik Durumu Raporunda da dile getirildi, bu nedenle şirketlerde Çevik ve DevOps faaliyetlerinin nasıl bağlantılı olduğunu karşılaştırmaya karar verdik. Çevik olmayan DevOps'un nadir olduğunu gördük. Yanıt verenlerin yarısı için Agile'ın yayılması çok daha erken başladı ve yaklaşık %20'si eşzamanlı başlangıcı gözlemledi ve Düşük profilin işaretlerinden biri Agile ve DevOps uygulamalarının olmaması olacak:

Komut topolojileri

Geçen yılın sonunda kitap "Takım topolojileriKomut topolojilerini tanımlamak için bir çerçeve öneren ”. Rus şirketleri için geçerli olup olmadığı bizim için ilginç hale geldi. Ve şu soruyu sorduk: “Hangi kalıpları buluyorsunuz?”.

Altyapı ekiplerinin, geliştirme, test ve operasyon için ayrı ekiplerin yanı sıra, yanıt verenlerin yarısında gözlemlendiği görülmektedir. Ayrı DevOps ekipleri, aralarında Yüksek temsilcilerin daha yaygın olduğu %45'i kaydetti. Ardından, Yüksek'te daha yaygın olan çapraz işlevli ekipler gelir. Yüksek, Orta profillerde ayrı SRE komutları görünür ve Düşük profilde nadiren görülür:

DevQaOps oranı

Bu soruyu FaceBook'ta Skyeng platform ekibinin ekip liderinden gördük - şirketlerdeki geliştiricilerin, testçilerin ve yöneticilerin oranıyla ilgileniyordu. Bunu sorduk ve profillere göre yanıtlara baktık: Yüksek profilli temsilcilerin her geliştirici için daha az test ve operasyon mühendisi var:

2021 yılı için planlar

Gelecek yılın planlarında, katılımcılar aşağıdaki faaliyetleri kaydetti:

Burada DevOps Live 2020 konferansı ile kesişimi görebilirsiniz.Programı dikkatlice inceledik:

• Ürün olarak altyapı
• DevOps dönüşümü
• DevOps uygulamalarının dağılımı
• DevSecOps
• Vaka kulüpleri ve tartışmalar

Ancak sunumumuzun süresi tüm konuları kapsamaya yetmiyor. Perde arkasında kaldı:

• Hizmet ve ürün olarak platform;
• Kod, ortamlar ve bulutlar olarak altyapı;
• Sürekli Entegrasyon ve Teslimat;
• Mimari;
• DevSecOps kalıpları;
• Platform ve işlevler arası ekipler.

Rapor ciltli bir 50 sayfamız var ve bunu daha ayrıntılı olarak görebilirsiniz.

Özetle

Araştırmamızın ve raporumuzu geliştirme, test etme ve operasyonlara yönelik yeni yaklaşımları denemeniz için size ilham vermenin yanı sıra gezinmenize, çalışmadaki diğer katılımcılarla kendinizi karşılaştırmanıza ve kendi yaklaşımlarınızı geliştirebileceğiniz alanları belirlemenize yardımcı olacağını umuyoruz.

DevOps'un Rusya'daki durumuna ilişkin ilk çalışmanın sonuçları:

• Anahtar metrikler. Temel ölçütlerin (teslim süresi, dağıtım sıklığı, kurtarma süresi ve değişiklik hataları) geliştirme, test ve operasyon süreçlerinin etkinliğini analiz etmek için uygun olduğunu bulduk.
• Profiller Yüksek, Orta, Düşük. Toplanan verilere dayanarak, metrikler, uygulamalar, süreçler ve araçlar açısından ayırt edici özelliklere sahip farklı Yüksek, Orta, Düşük gruplarını istatistiksel olarak ayırt edebiliriz. Yüksek profilin temsilcileri, Düşük profilden daha iyi sonuçlar gösteriyor. Hedeflerine ulaşma ve aşma olasılıkları daha yüksektir.
• Göstergeler, salgın ve 2021 planları. Bu yıl özel bir gösterge, şirketlerin pandemi ile nasıl başa çıktığıdır. Yüksek temsilciler daha başarılı oldu, artan kullanıcı etkileşimi yaşadı ve başarının ana nedenleri verimli geliştirme süreçleri ve güçlü bir mühendislik kültürüydü.
• DevOps uygulamaları, araçları ve bunların geliştirilmesi. DevOps uygulamalarının ve araçlarının geliştirilmesi, DevSecOps uygulamalarının devreye alınması ve organizasyon yapısındaki değişiklikler şirketlerin gelecek yıl için ana planlarında yer alıyor. DevOps uygulamalarının etkili bir şekilde uygulanması ve geliştirilmesi, pilot projeler, toplulukların ve mükemmellik merkezlerinin oluşturulması, şirketin üst ve alt kademelerindeki girişimler yardımıyla gerçekleştirilir.

Geri bildirimlerinizi, hikayelerinizi, geri bildirimlerinizi duymak isteriz. Çalışmaya katılan herkese teşekkür eder, gelecek yıl katılımınızı dört gözle bekleriz.

Kaynak: habr.com