Yakın zamanda Logrocon'un ev sahipliği yaptığı DevOpsForum 2019'a katıldım. Bu konferansta katılımcılar, iş ve geliştirme ile bilgi teknolojisi hizmet uzmanları arasında etkili etkileşim için çözümler ve yeni araçlar bulmaya çalıştı.
Konferans başarılıydı: gerçekten çok sayıda faydalı rapor, ilginç sunum formatları ve konuşmacılarla çok fazla iletişim vardı. Ve kimsenin bana bir şey satmaya çalışmaması özellikle önemli; bu, büyük konferanslardaki konuşmacıların son zamanlarda suçlu olduğu bir şey.
Raiffeisenbank, Alfastrakhovanie, Mango Telecom'un otomasyon uygulama deneyimi ve kesinti altındaki diğer detayların konuşmalarından bir alıntı.
Adım Yana, test uzmanı olarak çalışıyorum, otomasyonun yanı sıra DevOps ile de ilgileniyorum ve konferanslara ve buluşmalara katılmayı seviyorum. Son iki yılda Oleg Bunin'in konferanslarına (HighLoad++, TeamLead Conf), Jug etkinliklerine (Heisenbug, JPoint), TestCon Moskova, DevOps Pro Moskova, Big Data Moskova'ya gittim.
Öncelikle konferans programına dikkat çekiyorum. Raporun neyle ilgili olacağına daha az, konuşmacıya daha çok bakıyorum. Rapor çok teknolojik ve ilgi çekici çıksa bile rapordaki en iyi uygulamalardan bazılarını şirketinizde uygulayabileceğiniz bir gerçek değil. Ve sonra bir konuşmacıya ihtiyacınız var.
Raiffeisenbank'ta boru hattının ucunda ışık var
Genellikle kenarda ilgimi çeken konuşmacıları ararım. DevOpsForum 2019'da Raiffeisenbank'tan konuşmacı Mikhail Bizhan ilgimi çekti. Konuşmasında ekiplerini yavaş yavaş DevOps'a nasıl bağladıklarını, buna neden ihtiyaç duyduklarını ve DevOps dönüşümü fikrini iş dünyasına nasıl satabileceklerini anlattı. Genel olarak boru hattının sonundaki ışığın nasıl görüleceğinden bahsettim.
Mikhail Bizhan, Raiffeisenbank otomasyon direktörü
Artık şirketlerinde “DevOps” yok. Yani çalışıyor ama her takımda değil. DevOps'u uygularken hem belirli mühendisler açısından hem de ürün ihtiyacı ve bu ürünün üzerine kurulduğu platformun olgunluğu açısından ekiplerin hazır olmasına güvenirler. Misha, bir işletmeye DevOps'a neden ihtiyaç duyulduğunu nasıl açıklayacağını anlattı.
Bankacılık segmentinin çeşitli büyüme etkenleri var: hizmetlerin maliyeti ve müşteri tabanının genişletilmesi. Hizmetlerin maliyetini artırmak çok iyi bir etken değildir ancak müşteri tabanını büyütmek tam tersidir. Rakipler nesnel olarak harika bir ürün piyasaya sürerse, tüm müşteriler oraya gider ve zamanla pazar dengelenir. Bu nedenle yeni ürünlerin pazara sunulması ve piyasaya sürülme hızı bankaların odaklandığı konuların başında geliyor. DevOps tam olarak bunun içindir ve işletmeler bunu anlıyor.
Bir sonraki önemli not: DevOps her zaman pazara sunma süresini kısaltmaz. DevOps tek başına çalışamaz; bir ürünü geliştirmeden üretime (koddan müşteriye) kadar yaratma ve pazara sunma sürecinin sadece bir parçasıdır. Ancak koddan önceki her şey doğrudan DevOps ile ilgili değildir. Yani pazarlamacılar yıllarca pazarı inceleyebilir ve tüm hayatlarını rakipleri yakalamakla geçirebilirler. Müşterinin neye ihtiyacı olduğunu hızlı bir şekilde anlamak ve şu veya bu özelliğin uygulanmasını planlamak gerekir - çoğu zaman bu, DevOps'un çalışması ve şirketin hedefine ulaşması için yeterli olmayan şeydir. Bu nedenle Raiffeisenbank, öncelikle DevOps'un nasıl kullanılacağını öğrenmenin gerekli olduğu konusunda işletmelerle anlaştı. Otomasyon adına otomasyonun yeni müşteriler için verilen mücadelede pek bir faydası olmayacak.
Genel olarak Misha, DevOps'un akıllıca ama akıllıca uygulanması gerektiğine inanıyor. Ve dönüşümün başlangıcında ekibin verimliliğinin düşeceği, daha az para kazanacağı, ancak daha sonra haklı çıkacağı gerçeğine hazırlıklı olmalıyız.
Mango Telekom'da test otomasyonu
Bir testçi olarak benim için bir başka ilginç rapor da Mango Telecom'dan Egor Maslov tarafından verildi. Sunumun adı "SCRUM ekibinde tam test döngüsünün otomasyonu" idi. Egor, DevOps'un SCRUM için özel olarak yaratıldığına inanıyor ancak aynı zamanda DevOps'u bir SCRUM ekibine dahil etmek oldukça sorunlu. Bunun nedeni, SCRUM ekibinin her zaman bir yere koşması, yeniliklerle dikkati dağıtacak ve süreci yeniden inşa edecek zamanın olmamasıdır. Sorun aynı zamanda SCRUM'un ekipteki alt ekiplerin (test ekibi, geliştirme ekibi vb.) ayrılmasını içermemesinde de yatmaktadır. Ayrıca, mevcut bir süreci otomatikleştirmek için dokümantasyona ihtiyaç vardır ve SCRUM'da çoğu zaman tamamen dokümantasyon yoktur - "ürün bir tür yazıdan daha önemlidir."
SCRUM'a geçtikten sonra test uzmanları, özelliklerin nasıl test edileceği konusunda geliştiricilere danışmaya başladı. Yavaş yavaş, işlevsellik hacmi arttı, belge yoktu ve işlevsellikte testlerin kapsamına girmeyen birçok hata yakalamaya başladılar ve genel olarak bunu kimin ve ne zaman test ettiği artık belli değildi. Kısaca kafa karışıklığı ve kararsızlık. Test otomasyonuna geçmeye karar verdik. Ancak o zaman bile tam bir başarısızlık yaşandı. Şirket içi test uzmanlarının bilmediği bir yığın üzerine yazan dış kaynaklı otomasyon uzmanlarını işe aldılar. Otomatik testlerin çerçevesi elbette işe yaradı, ancak dış kaynak sağlayıcılar gittikten sonra bu süreç iki hafta sürdü. Daha sonra iki numaralı otomatik testi uygulamaya koyma girişimi oldu. Her şeyin şirket içinde, kendi başınıza (doğru vektör: dahili uzmanlık oluşturmak) SCRUM çerçevesinde inşa edilmesi ve süreçte dokümantasyon oluşturulması gerektiği gerçeğiyle başladı. Otomasyon yığını, ürünün yığınına eşit olmalıdır (burada ekliyorum, JavaScript projenizi başka bir şeyle test etmeyin). Sprint'in sonunda, tüm takımla birlikte otomatik testin nasıl çalıştığını gösteren bir demo yaptılar (faydalı). Böylece tüm ekip üyelerinin otomasyon sürecine katılımı, otomatik testlere olan güven ve bu otomatik testin mutlaka kullanılma (ve sürekli başarısızlık nedeniyle bir ay içinde yorumlanmayacak) şansı arttı.
Bu arada, DevOpsForum 2019'da açık bir mikrofon vardı - uzun zamandır bilinen ve bence faydalı bir konuşma formatı. Bu şekilde dolaşıyorsunuz, raporları dinliyorsunuz ve ardından konferansta belirli bir konuyu veya sorunu tartışmaya, sorunun çözümüyle ilgili deneyimi paylaşmaya değer olduğuna karar veriyorsunuz.
Organizatörlerin bir dizi kısa rapor hazırladıklarını da fark ettim. Her rapor en fazla 10 dakika sürer ve ardından sorular gelir. Bu sayede birçok konuyu aynı anda ele alabilir ve ilginizi çeken konuşmacılara sorular sorabilirsiniz.
Sunumlar arasında konferans ortaklarının standlarında dolaştım ve birçok şey çaldım/kazandım. Ah, bildiriye bayıldım!
Alfastrakhovanie'deki geliştirme direktörüyle yuvarlak masa ve DevOps sorunları
Benim için DevOpsForum 2019 pastasının kreması, DevOps uzmanlarıyla bir saat süren genel kurul oturumuydu. Dört oturum katılımcısı DevOps'a farklı açılardan bakmaya davet edildi: Anton Isanin (Alfastrakhovanie, geliştirme direktörü), Nailya Zamashkina (Fintech Lab, işletme müdürü), Oleg Egorkin (Rostelecom, Agile koçu) ve Anton Martyanov (bağımsız uzman, DevOps'u inceledi) iş açısından).
Uzmanlar insanlara daha yakın oturdu ve sonra olaylar olmaya başladı: Tam bir saat boyunca izleyicilerden katılımcılar sorularını sordu ve uzmanlar suçu üstlendi. Bazen gerçek tartışmalar oluyordu. Sorular çok farklıydı; örneğin: DevOps mühendislerine ihtiyaç var mı, neden sistem yöneticileri olarak eğitilemiyorlar, DevOps herkese sunulmalı mı, değeri nedir vb.
Daha sonra Anton Isanin ile bizzat görüştüm. DevOps kültürünü her eve taşımanın gerekliliğini tartıştık ve DevOps dönüşümünün karanlık tarafını ortaya çıkardık.
Herkesin bir araya gelerek DevOps'a hem ürün hem de işletme ve ekip açısından ihtiyaç duyulduğuna karar verdiğini düşünelim. Hadi uygulamaya geçelim. Her şey yolunda gitti. Nefes verdik. DevOps bizi müşteriye yaklaştırdı, artık onun tüm isteklerini hızlı bir şekilde yerine getirebiliyoruz. Sonuç olarak, katı düzenlemelere ve gereksinimlere sahip büyük bir Operasyon departmanımız var ve bu departman sürekli olarak üründe kusurlar buluyor ve çok sayıda talep oluşturuyor. Üstelik, müşteri beklenmedik bir şekilde düğmeyi yeşil yerine sarıya boyamak istese bile tüm kusurlara "acil" durumu atanır. Proje büyüyor, sürüm sayısı artıyor ve buna bağlı olarak müşteriler tarafından yeni işlevsellikteki kusurların ve yanlış anlaşılmaların sayısı artıyor. Ops, kusurları raporlamak için 10 kişiyi daha işe alırken, geliştirme ise bunları kapatmak için 15 kişiyi daha işe alıyor. Ve ekip, yeni özellikler sunmak yerine, sonsuz sayıda SD'yle çalışarak, kullanıcıya hem işlevselliği hem de desteği aynı anda açıklıyor. Sonuç olarak, hem Operasyonlar hem de geliştirme iş başında, ancak müşteri ve işletme mutsuz: yeni özellikler takılıp kalıyor. DevOps'un var olduğu anlaşılıyor, ancak yok gibi görünüyor.
DevOps'u uygulama ihtiyacıyla ilgili olarak Anton, bunun doğrudan işin ölçeğine bağlı olduğunu açıkça belirtti. Yılda bir müşteriye hizmet vermek şirkete bir milyar dolar getiriyorsa DevOps'a gerek yoktur (bu müşteriye düzenli olarak yeni değişiklikler yapmanıza gerek olmaması koşuluyla). Her şey çikolatayla kaplı. Ancak iş büyürse ve daha fazla müşteri ortaya çıkarsa, buna uymanız gerekir. Kural olarak, başlangıçta şirkette harika Operasyonlar yoktur. Önce ürünü kesiyoruz ve ancak o zaman ürünün çalışabilmesi için sunuculara göz kulak olmamız ve sarf malzemelerini izlememiz gerektiğini anlıyoruz. İşte o zaman Ops ortaya çıkıyor. Operasyonların ayrı bir bölüm olarak gelişmeye bir dizi engel koymaya başlayacağı ve tüm teslimatların durmaya başlayacağı anlaşılmalıdır. Yani bu durumda DevOps kültürü zaten alakalı, ancak onun karanlık tarafını da unutmamalıyız.
Kaynak: habr.com