Boşlukları Kapatmak: DevOps İletişiminin Önemi

DevOps metodolojisi bir süredir bizimle olmasına rağmen, hala hararetli tartışmaların merkezi. Şirketler bunu istiyor ama nasıl yaklaşacaklarından emin değiller.

DevOps her yerde. Ve bu ilginç bir trend olsa da, tam tersi değil, ürünlere uyarlanmalıdır.

Ama bazı insanlar bunu böyle görmüyor. Bana sık sık "Sence Docker'ı kullanmaya başlamalı mıyız yoksa doğrudan Kubernetes'e geçmeli miyiz?" gibi sorular soruluyor. Bu tür sorular, ürünün ne hakkında olduğunu bile bilmeden anlamsızdır.

Bulut, Kubernetes, kapsayıcılar, yapılandırma yönetimi, Kod olarak Altyapı gibi tüm bu süslü terimler, bazı iyileştirmeler vaat ediyor. Ancak teleskoplar astronomi için neyse, DevOps için de öyleler. Yararlı olabilirler, ancak gerekli değildirler.

Özünde DevOps, müşterinin sipariş ettiği ile geliştirme ekibinin teslim ettiği arasındaki boşluğu kapatmayı amaçlar. Kısa sürüm döngüleri, tasarıma yinelemeli yaklaşım ve tekrarlayan adımların otomasyonu üzerinde bir vurgu vardır. Bunları gerçeğe dönüştürmek için en önemli şeyin ne olduğunu düşünüyorsunuz?

“Harika iletişim” dediyseniz, haklısınız. Araçların hepsi iyi. Ancak, yalnızca iletişimi iyileştirdiklerinde onlara yatırılan paraya değer.

İletişimin bir yönü, işi yapmak için neyin gerekli olduğunu bilmektir. Ve iş, "kod depoya bağlı" anlamına gelmez. Bunu “müşteri üretimdeki değişimi gördü ve kabul etti” olarak düşünün.

Bu ilk adım belirlenir belirlenmez ve herkes ne olması gerektiğini bilir, onu yazmak için en iyi zaman budur. Neresi? Ben README.md korumanın büyük bir savunucusuyum. Bir ekipteki her kişi her zaman içine göz atabilir ve bir projenin durumunu bilebilir ve bu, projeye yeni başlayanlar için doğal bir yoldur.

Bir BENİOKU yazdıktan sonraki adım olan otomasyon isteğe bağlıdır. Yine de, süreci belgelemenin doğal bir sonucu. Ve evet, DevOps denince akla genellikle otomasyon gelir.

Bir dakika... Konu DevOps olduğunda otomasyon isteğe bağlı mı? DevOps, dağıtımları yapan kişinin departmanı değil mi?

İnsanların genellikle "DevOps mühendisi" teriminden anladıkları şey ya bir yazılım güvenilirliği mühendisi, bir platform mühendisi ya da bir operasyon otomasyon mühendisidir. Bunların hepsi DevOps uygulamasını sağlayan geçerli rollerdir, ancak toplu "DevOps mühendisi" terimini kullanmak biraz belirsiz olabilir.

Şimdi DevOps'un kendisine daha yakından bakalım.

DevOps Açıklaması

Önce size DevOps'un ne olmadığını göstereyim:

1. Bu sadece bir iş unvanı öneki değil
2. Bu bir takım değil (ama “Dev” ve “Ops” takımdır)
3. bu bir teknoloji değil
4. “Kodlama yapabilen bir sistem yöneticisi” anlamına gelmez.
5. “Bir şeyleri otomatikleştirmek” anlamına gelmez
6. "Artık operasyon ekibi yok" anlamına gelmez.

Bunu bilerek, geleceğe hazır olduğunuzdan emin olmak için bir şirkette basitçe “bir DevOps mühendisi tutamayacağınızın” veya “bir DevOps ekibi oluşturamayacağınızın” artık farkındasınız. DevOps, Çevik geliştirmeye benzer. Böyle bir Çevik geliştiriciyi işe alır mısınız? Muhtemelen değil. Çevik bir şekilde ürün geliştirirsiniz veya geliştirmezsiniz.

O halde DevOps nasıl tanımlanabilir? Bu bir metodoloji. Ya da belki bir kültür. Belki bir ruh bile. DevOps ilkelerine göre bir ürün yapmak, geliştirici, operasyon mühendisi veya ürün yöneticisi fark etmeksizin herkesin ortak bir vizyonu paylaştığı ve bunu iletişim yoluyla sürdürdüğü anlamına gelir. Daha az ölçüde, herkesin aynı araçları kullandığı anlamına da gelir. Bu araçlar tek bir insan grubuna yardım etmek için tasarlanmamıştır. Ürünü ileri itmek içindir.

Bu anlayışla yola çıkmak, en büyük engel olan ciddi bir zihniyet değişikliğini gerektiriyor. Nedenmiş? Bunun nedeni, insanların konfor alanlarından çıkmaları ve farklı yetkinliklere sahip insanlarla işbirliği yapmaya başlamaları gerektiğidir. Geliştiricilerin aniden bulutun nasıl çalıştığını öğrenmesi ve kendi kodlarını dağıtmaya başlaması gerekiyor. Operasyon personelinin manuel kurulumlardan vazgeçmesi ve kodlamaya başlaması gerekiyor. Herkesin yeni kavramlar öğrenmesi gerekiyor. Herkesin yeni sorumlulukları var.

Bu kolay değil, ancak iyi iletişim ve ortak bir hedefle oldukça ulaşılabilir. Bu iletişim, bir kültür oluşturmayı, hafif süreçler kurmayı ve uygun belgeleri korumayı içerir.

DevOps Otomasyonu Belgelemedir

Muhtemelen hiç böyle düşünmediniz. Ancak DevOps ile yaygın olarak ilişkilendirilen araçların çoğu dokümantasyon araçlarıdır :

• Okunabilirlik için yazılmış derleme komut dosyaları , derleme sürecini belgelemeye yarar
• Sürekli entegrasyon boru hatları , tek parçaların oluşturulmasından bütün bir ürüne kadar entegrasyon sürecini belgeler.
• Sürekli dağıtım işlem hatları , müşterinizin kullanabileceği bir ürünün nasıl dağıtılacağını belgeleyerek daha da ileri gider
• Konfigürasyon yönetim dosyaları , kurulum ve konfigürasyon sürecini belgelemektedir.
• Kod olarak altyapı özellikleri , gerekli altyapıyı (aslında oldukça resmi olarak!)
• Kapsayıcılar, belirli bir mikro hizmetin nasıl oluşturulacağını ve yapılandırılacağını belgeleyen kendi Dockerfile birlikte gelir.

Tüm bu süslü kavramlar temelde tek bir şey yapar: Süreçleri belgeleyerek ekip üyelerinin daha iyi iletişim kurmasına yardımcı olurlar. Bu işlemler daha sonra manuel olarak çalıştırılabilir veya otomatikleştirilebilir. Önemli olan, bir projedeki her paydaşın onları takip edebilmesidir.

İşlemlerinizi kod olarak belgelemenin, normal kullanım kılavuzlarına göre büyük bir avantajı vardır. Kod doğrulanabilir ve öngörülü davranır. Aynı girdi verildiğinde, aynı çıktıyı üretir.

Yazılı talimatlarla, okuyucu sayısı kadar yoruma sahip olacaksınız. Belirsiz veya belirsiz belgeler yazarsanız, onu okuyan kişi boşlukları dolduracaktır. Mesele şu ki, boşluklara neyin girdiğini kontrol edemezsiniz.

Kod ile çok daha basit. Somut adımlar olmadan program çalışmayı durduracaktır. Bu somut adımlar, DevOps iletişiminin önemli bir yönüdür.

DevOps İletişimi: Geliştirme ve Operasyonlar Arasındaki Boşluğu Kapatmanın Tek Yolu

Phoenix Projesi kitabında, büyük bir projeyi uygulamakla görevlendirilen yeni terfi eden bir yöneticinin sorunlarına tanık oluyoruz. Kimse ne olduğunu bilmediğinden, herkes fazla ilerleme kaydetmeden yangınlarla mücadele ediyor. Kitap alt başlığı, bunun bir DevOps hikayesi olduğundan bahseder. Buna katılıyorum.

Ancak ilginç olan, kitap boyunca tek bir yeni aracın tanıtılmamasıdır. Yalnızca iletişimi geliştirerek bir DevOps durumu elde edebilir misiniz? Kitabın kahramanları başardı, yani sizin için de umut var!

Kahramanların yaklaşımı “eski okul” olarak kabul edilebilse de (uygun bir hata izleme sistemi yerine gerçek kağıt kartları kullanmak), ancak ilgili tüm taraflar birbiriyle konuşmaya başladığında işler daha iyiye doğru değişmeye başlar.

Geliştirme ve operasyonlar arasındaki işbirliğini geliştirmenin, yalnızca hizmet düzeyi anlaşmaları veya olay biriktirme listeleri gibi daha iyi arabirimler oluşturarak mümkün olduğunu düşünebilirsiniz. ama tam tersi doğru. Arayüzleri yıkarak ve empati ve ortak bir amaç getirerek, ortak bir amaç için çalışan bir ekibe sahip olacaksınız.

DevOps Ekip Yapısı: Ekipte Kimler Var?

İdeal olarak, her ürünün yalnızca bir ekibi olmalıdır: ürün ekibi.

Bir zamanlar diğer ekiplerle ortak bir amacın olmadığı bir geliştirme ekibindeydim. Geliştirme ekibi mümkün olduğunca çok değişiklik yapmak istedi. Doğrulama ekibi, kusurların ortaya çıkmasını önlemekle görevlendirildi. Farklı yöneticileri vardı ve ayrı ayrı değerlendirildiler.

Sonuç? Geliştirme ve Doğrulama, hata raporlarıyla masa tenisi oynadı. Doğrulama, geçemeyecek bir test bulduğunda, Geliştirme, kendi kodlarını hatasız hale getirmeye çalışmaktan çok, test kodunun kendisindeki kusurları bulmakla ilgilendi.

Raporları, karşı raporları vb. düzgün bir şekilde doldurmak için çok büyük bir ek yük gerektiğinden, serbest bırakma döngüsü elbette balonlandı. Çoğu kişinin anlamadığı görünen şey, ürün açısından her iki ekibin de ortak bir hedefi paylaşması ve bunu başarmak için birlikte çalışması gerektiğiydi. Ancak uygun işbirliği ve silo zihniyetinin eksikliği, fark edilmesini çok zorlaştırdı.

Atıkla Mücadele Ortak Bir Çabadır

Çevik Yazılım Geliştirme Manifestosu'na (ki bu da bizi DevOps ile tanıştırdı) ilham veren yalın üretim zihniyeti, atıkla mücadele hakkındaydı. İsraf derken, müşterinin sipariş ettiği şeyle doğrudan ilgili olmayan her şeyi kastediyoruz. Birikmiş devam eden işler bir israftır. Açıkça salıvermeye yol açmayan bir sürecin her adımı bir israftır.

Ancak atık sadece yüksek bir seviyeden görülebilir. Tek bir ekip kapsamında bazı prosedürler gerekli görünebilir. Ürün açısından, yine de, işe yaramaz olabilirler.

Hangi çabaların boşa gittiğini anlamak için güçlerinizi birleştirmeli ve sevk edilen bir ürünün yaşam döngüsünü göz önünde bulundurmalısınız. Ayrıca bir müşterinin bakış açısından da düşünmeniz gerekir. Bu özellik müşterinin istediği bir şey mi? Değilse, şu anda atlayabilirsiniz. Süreçleriniz basit ve yalın mı? Özellikle ekip sınırlarını aşanlara daha yakından bakın.

Bir ürünün geliştirilmesinin olabildiğince verimli olduğundan emin olmak ister misiniz? Nasıl çalıştığınızı görmesi için bir yabancıyı davet edin. Ekibinizin bir parçası olmayan bir kişi, anlayışlı sorular sorabilir ve iyileştirme için yeni alanlar belirleyebilir.

DevOps İlkeleri: Sakin Olun

CALMS, DevOps'u nasıl uygulamanız gerektiğinin çok doğru bir açıklamasıdır:

• kültür
• bir otomasyon
• yalın
• ölçüm
• S haring

Sandviç gibi oluştuğuna dikkat edin. Ortadaki üç değer daha teknikken, dış değerler yumuşak becerilerle ilgilidir. Ancak tüm kültürün temeli iletişimdir: İşlerin nasıl olması gerektiği konusunda bir fikir birliğine varana kadar değerlerimizi ve inançlarımızı diğer ekip üyeleriyle paylaşırız.

Aynı şey paylaşmak için de geçerli. Yemek gibi temel bir şeyi paylaşmak iletişim gerektirmez. Bununla birlikte, hareketin kendisi de bir iletişim eylemi olarak görülebilir. "Seni önemsiyorum, bu yüzden seninle paylaşıyorum." Kapsamı sadece sözlü iletişimle sınırlamak istemiyoruz.

Ancak fikirleri ve araçları paylaşmak iletişim gerektirir. Bunları nasıl paylaşmalıyız? Onları nereye koyacağız? Takımdaki herkes için mi yoksa sadece daha küçük bir grup için mi faydalılar?

Yalnızca daha teknik yönlere (Otomasyon, Yalın ve Ölçüm) odaklanırsanız, DevOps'un önemli noktasını kaçırıyorsunuz. Yazarın yanında hiç kimsenin kullanmadığı otomatik bir dağıtım komut dosyasına sahip olmanın ne faydası var? Senaryo ona biraz zaman kazandırırsa, haklı olabilir. Ancak herkes bu senaryoyu paylaşırsa ne kadar zaman kazanılabileceğini hayal edin. Bu, atıkla mücadele hakkında bir şeyler söylüyor!

DevOps İşletmeyi Geliştirmeye Yaklaştırıyor

Bazıları DevOps'un operasyonları geliştirmeye yaklaştırdığını söylüyor. Bu doğru, ama gerçeğin tamamı bu değil. Doğru yapıldığında DevOps her birimi birbirine yaklaştırır. İşletmelerin ve müşterilerin, geliştirmenin ne yaptığını neredeyse gerçek zamanlı olarak görmelerini sağlar.

Bu daha kısa geri bildirim döngüsü, tüm paydaşlara fayda sağlar. İş genellikle daha görünürdür ve geliştiriciler de müşterilerin ürettikleri kodu nasıl kullandığını kolayca görebilir. Geleneksel dağıtımda, birinin hataları veya eksik gereksinimleri fark etmesi için birkaç ay bekleyebilirsiniz. Sürekli dağıtımla, herkes ortaya çıkan sorunlara tepki verebilir. Geliştiriciler, operasyonlar, işletme ve müşteriler bir odada oturabilir ve çalışma uygulamasını mevcut ihtiyaçlara göre değiştirebilir.

Önce DevOps Araçları? Tekrar düşün

Tabii ki, bunu mümkün kılmak için tüm araçlara ihtiyaç var.

Ancak hiçbir araç, şirket içinde iyi iletişim ve empatinin yerini tutamaz. Bir keresinde, yapım sürecinin bir takıma ait olduğu, sağlanan kodun ise başka bir takıma ait olduğu bir ürün gözlemledim.

Yapı sistemiyle ilgili sorunlar yaygındı. Geliştiriciler nasıl kullanılacağından emin değildi. Standart araçlara dayanıyordu, ancak web'de bulunan her belgenin işe yaramaz olduğu ortaya çıkacak şekilde özelleştirilmişlerdi.

Herkes durumu iyileştirmek istedi ancak iki takım arasında bir anlayış yoktu. Bu, her iki tarafın da diğer tarafa danışmadan yeni araçlar sunduğu anlamına geliyordu. Bu, farkı kapatmak yerine sadece genişletti.

Kuruluşunuzda bir DevOps dönüşümü başlatmak istiyorsanız, iletişim kurma şeklinizi geliştirmekle başlayın. Basitçe bir çözüm varsaymayın: Önce açık fikirli bir beyin fırtınası yapın. O zaman, örneğin, takım desteğinin ihtiyaçlarınız için yetersiz olduğunu görebilirsiniz. İşte o zaman mevcut araçlarınızı değiştirmeyi veya bazı yenilerini tanıtmayı düşünebilirsiniz; aksi takdirde büyük olasılıkla orijinal soruna katkıda bulunursunuz.

DevOps Kurmanın En Hızlı Yolu? Daha İyi İletişim!

Girişte, müşterilerin bana sıklıkla sorduğu sorudan bahsettim: "Docker ile mi gitmeliyim yoksa doğrudan Kubernetes'e mi geçmeliyim?" Bu makaleyi okuduktan sonra, böyle bir sorunun en iyi şekilde, bir DevOps zihniyetiyle bazı hazırlık çalışmaları yaptıktan sonra yanıtlandığını görebilirsiniz.

Ürün ekibinizin DevOps'un kendisi ve müşteri için faydalarını anladığını biliyorsanız, ekip ve müşteri, beklentilerini belirleyerek başlayabilir. Ardından mühendisler, geliştirme ve dağıtım modelini anlayabilir. Son olarak, hangi araçların gerekli olduğunu belirleyebilirsiniz.

Tüm gereksinimler belgelendikten sonra, teknoloji seçimlerini yapmak çok daha kolay.

İşimizi daha kolay ve daha yönetilebilir hale getiren tüm harika DevOps otomasyon araçlarının bir savunucusuyum. Ama günlük işimiz insanlarla çalışmak. Başka bir teknoloji sertifikası almak yerine DevOps en iyi uygulamalarının bu yönünü geliştirmek için biraz zaman ayıralım.