DevOps nedir: Firmanızın kültürünü nasıl düzeltirsiniz?

Mert Susur
7 min readOct 6, 2018

DevOps son zamanlarda çok sık duyduğumuz bir terim. Türkiye’de ve dünyada DevOps Engineer gibi ünvanlar türemeye de başladı. Ancak bana kalırsa bir çok firma ve kişi bunu biraz yanlış anlamış durumda. Bu yazıda DevOps kültüründen ne anladığımı, firmaların bu kültürü nasıl uyguladıklarını ve sağlıklı bir teknoloji organizasyonunun nasıl bir kültüre sahip olması gerektiği hakkında konuşacağım.

Image Credit: ALL THAT YOU NEED TO KNOW ABOUT THE REVOLUTIONARY DEVOPS CULTURE.

Öncelikle kabul edelim, eğer firmanız bir rekabet içindeyse ‘klasik yöntemlerle’ başarılı olduğunuz dönem çoktan geçti. Çünkü yazılım geliştirme teknolojileri sizin üniversite yıllarınızda öğrendiğiniz gibi değil artık. Bulut teknolojilerinin ve çevik yazılım geliştirme yöntemlerinin tetiklediği akımlar işi bambaşka boyutlara götürdü. Örneğin sigorta yapmak, kredi vermek için artık şubeye ihtiyacınız yok. Başka bir ülkeye gittiğinizde hiç aracı olmayan taksi firmalarını kullanıyor, hiç oteli ve otel elemanı olmayan firmalardan rezervasyon yaptığınız harika odalarda kalıyorsunuz. Hatta artık servis elemanı ya da restoranı olmadan robotlarla yemek servisi yapan firmalar da var.

Dolayısıyla rekabet gün geçtikçe zorlaşıyor ve firmanızın klasik ürün geliştirme yöntemleri de tarihe karıştı bile.

Başka bir deyişle, artık yazılımcılar kodu yazıp test takımının test etmesi için duvarın üzerinden bozuk yazılımlarını fırlatıyorsa, hala sunucu istemek için çağrı açıp saatlerce (bakın günlerce bile demiyorum artık) bekliyorsanız hatta bazen sosyal ilişkinizle araya torpil sokuyorsanız ya da yazdığınız kodunuz günler sonra müşterinize ulaşıyorsa bu yazıyı daha da ciddi okumanızı öneriyorum.

Firmaların sektörde başarılı olup rekabet içinde kalabilmeleri için,

  • Sundukları hizmetlerle ve ürünlerle müşterilerini memnun etmeleri,
  • Bulundukları marketi çok iyi anlayıp, müşterileriyle ilişkide olup müşteri ihtiyaçlarını tespit etmeleri ve bunun nedenlerini anlamaları,
  • Yasal zorunlulukları yerine getirmeleri ve gerekli denetlemelerin gerçekleşebileceğine emin olmaları,
  • Olabilecek siber saldırılara ve güvenlik tehditlerine karşı hazır olmaları

gereklidir. Bunlar çok temel ihtiyaçlar gibi görünse de firmalar bu temel ihtiyaçları karşılamak için çok farklı yollar tercih edebilir. Bir çok geleneksel firma bu saydığım her madde için yeni bir departman oluşturma yolunu tercih etmekte. Yani müşteri ihtiyacını anlamaya çalışan ayrı bir departman, sunucuların yönetimi için ayrı bir departman ve güvenlik için ayrı bir departman oluşturma yoluna gitmektedir. Tabii ki bunun da finansal etkileri olacaktır.

Bu tarz geleneksel bir yaklaşımın çalışmadığını bu yazıyı okuyan bir çok kişi eminim ki zaman içerisinde tecrübe etmiştir. Bunun en temel sebebi farklı departmanlar oluşturmanın yarattığı bürokratik zorluklar ve bilgi silolarının zaman içerisinde büyümesiyle ortaya çıkan verimsizliktir. Örneğin organizasyonda bağımsız bir test ekibinin — daha havalı adıyla QA ekibinin- varlığı, yazılım ekibi ve müşteri arasında bir duvar oluşturmaktadır. Bir başka sorun da ürünün tamamını bilmeyen iki farklı ekibin oluşmasına sebebiyet vermesidir. Diğer taraftan da ekiplerin arasında politik bir takım sorunların ortaya çıkmasına da sebep olmaktadır ve nihayetinde bu durum da sürtüşmelere sebep verecektir. Çünkü ne yazık ki bu yaklaşım, aynı hedef doğrultusunda koşan iki ekibin de eline problemleri çözmelerine yardım edecek kadar yeterli yetkinlik verilmesine engel olmaktadır. Her ne kadar ideal bir dünyada bu iki ekibin beraber çalışmasını bekleseniz de yönetim tarafından oluşturulacak baskı ile insanların kendi silolarına nasıl çekildiğini bir çok defa gördüğünüzü tahmin ediyorum.

Bu sadece test ve yazılım ekipleri arasında yaşanan bir sorun değil tabii ki. Bunu, IT Operasyon — Yazılım, Güvenlik — Yazılım gibi farklı örneklerle de çeşitlendirmek mümkün.

İşte bu gibi yaklaşımların yarattığı sorunların karlılığı ve rekabeti etkilemesi elbette firmaları ve teknoloji geliştirenleri zaman içinde alternatifleri arama konusunda cesaretlendirdi. (Andrew McAfee & Erik Brynjolfsson — The Second Machine Age: Work, Progress, and Prosperity in a Time of Brilliant Technologies) DevOps akımı da bu sorunları çözmek için ortaya çıkmaya başladı.

DevOps akımının asıl ortaya çıkışı küçük firmaların ihtiyaçlarıyla oldu. Çünkü büyük geleneksel firmalar yazının başında anlattığım yollarla ellerindeki büyük maddi güç sayesinde baş edebilirken küçük firmaların onlara kafa tutması ve rekabet edebilmesi için hızlı geliştirilen, sağlam ve hızlıca ölçeklenebilir yazılımlara ihtiyacı vardı. Ancak küçük firmalardan ortaya çıkan bu akım zaman içerisinde büyük kurumsal firmaları da etkisi altına almaya başladı. Bunun en çarpıcı örneği ise Gartner’ın yaptığı araştırmaya göre büyük firmaların CEO’larının büyük bir kısmı yönetim kurulları tarafından bu tarz modern yöntemleri kabul edip kullanacak dönüşümü yapmaları için baskı görüyor olmaları.

DevOps akımı bu farklı bilgi yığınlarının bir araya gelip aynı potada eritilmesini hedefliyor. Bunun bir çok farklı yorumu yapılabilir, örneğin bu şekilde bakıldığında test ekibini temsilen bir kaç kişinin, yazılım geliştiricilerin ve IT operasyonundan bir kaç kişinin aynı takıma gelip beraber çalışması da DevOps olarak yorumlanabilir. Nitekim gördüğüm kadarıyla bir çok firma DevOps’u bu şekilde yorumlayıp böyle uygulamayı tercih ediyor. Bu tarz firmalar, belirli metriklerle bu değişimi ölçmeye başladıklarında bunun iyi yöndeki etkilerini elbette ki görmeye başlıyorlar ancak gizli tuttukları asıl potansiyelini de ne yazık ki gözden kaçırmış oluyorlar. Bu yazının geri kalanında bu firmalara ‘Eh işte’ firmalar diyeceğim. Çünkü sorunun kaynağını doğru tespit etmişler, ya dönüşümün birinci adımı olarak bunu uyguluyorlar ya da dönüşümü bitirdiklerini düşünüyorlar. Ancak ne olursa olsun başladıkları noktadan daha iyi bir noktaya ulaşmışlar. Ancak burada kalıcı olmaları çok mümkün olmayacaktır. Neden mi? Okumaya devam!

Gözlemlediğim firmalar arasında daha da başarılı olan firmalar genelde daha cesur davranıp bunu bir sonraki aşamaya götürebilen firmalar. Bu ‘iyi firmalar’ iyileştirme adımlarını uygularken asla ‘tamam olduk’ demeyip her zaman değişen koşullara göre daha da iyi hedefler koyup o hedefler doğrultusunda değişimi kabul eden firmalar. Bu firmalar sadece DevOps akımını okuyup takip etmekle kalmıyorlar firmaları için bir DevOps kültürü oluşturuyorlar.

Bu firmaların en önemli ortak özelliği yazılım ekiplerine ve mühendislerine çalıştıkları işin uçtan uca sorumluluğunu vermekten çekinmiyor, daha yalın bir süreç oluşturuyor hatta hata yapmaları için de gerekli yumuşak yastıkları yere seriyorlar. Böylelikle özgüvenli ve yeni şeyler denemekten korkmayan bir kültür oluşturuyorlar.

Eğer ilginizi çektiyse DevOps kültüründen devam edelim.

Doğru DevOps kültürünü oluşturmak ne yazık ki sadece teknoloji ekiplerinde değişimi sağlamakla olmuyor. Kökten bir şekilde firmanın bakış açısını değiştirmek gerekiyor. Çünkü teknoloji ekipleri günün sonunda iş birimlerinin ihtiyaçlarını karşılamak için çalışıyorlar. Durum böyle olunca teknoloji ekibi ne kadar sağlıklı ve hızlı olursa olsun iş birimleri onların hızına ulaşamadığı sürece firmanın başarısından söz etmek mümkün olmuyor. Bunun bir örneğini çalıştığım bir firmanın pazarlama departmanıyla teknoloji departmanı arasındaki sorunlu ilişkiyle yaşadım. Yazılım departmanı çevik ve hızlı bir yazılım geliştirme sürecini benimsemiş ‘çok iyi’ performansla çalışan bir ekip olmasına karşın bir türlü başarılı bir iş ortaya çıkartamıyordu. Tüm işler tamamlansa da müşteriye bir türlü ürünü ulaştıramıyor ve sürekli gecikmeler yaşanıyordu. Bu sorunu incelemek için yapılan retrospektif toplantılarında sorunun yazılım ekibinin işin içine yeterince alınmadığı ve pazarlama departmanının karar veren ve onay veren bürokratik bir operasyona sahip olduğunu gördük. Pazarlama departmanı tasarım kararlarını verip yazılım ekibine iletiyor, ancak yazılım ekibi bunu uygulamaya çalışınca başka sorunlar ortaya çıkıyordu. Bu sorunu çözmek için pazarlama departmanıyla ortak bir retrospektif toplantısı yapıldı ve sorunu araştırmaya başladık. Günün sonunda sorunun, pazarlama departmanının yasal zorunlulukları uygulamaya çalışırken hukuk bölümüyle aralarında yaşanan bir politik krizden kaynaklandığını gördük. Çözümü de basitti, bu üç ekibin beraber çalışması. Üç ekibin bir araya gelmesiyle Lead Time (isterlerin oluşturulduktan sonra müşteriye ne kadar sürede ulaştırıldığını ölçer) adını verdiğimiz metriğin 2 hafta 3 günden 1 haftaya kadar indiğini gözlemledik. Yani firma 2 kat daha hızlı müşteriye ulaşıyordu. Bu basit değişiklik sadece daha hızlı markete ulaşmamızı değil aynı zamanda da Hukuk ve Pazarlama departmanları arasındaki politik problemlerin çözülmesine de yardımcı oldu. Çünkü ekiplerin üzerindeki zaman baskısı azalmış, işler hızlanmış ve daha da önemlisi bir başarıyı beraber elde etmiş olmuşlardı.

Bir diğer dikkate alınması gereken nokta da ‘eh işte’ firmalarının yaptığını düşündüğüm bir hata olan bilgi silolarını daraltmak. Yani ekip içerisinde sadece test yapan, sadece IT operasyonuyla ilgilenen kişilerin olması. Bu az önce de söylediğim gibi tabii ki farklı departmanlara bölünmesinden daha faydalı olsa da yine de yazılımcılara ya da IT personeline ya da testçiye gereken yetkinliği vermediği için verimsizliklere yol açabiliyor. Örneğin yazılımcının bir ürünü çıkartmak için bir sunucuya ihtiyacı varsa bunu IT personeline söylüyor ve o da bunun için çalışıyor. Ancak yazılımcı eğer bu ihtiyacını önceden planlamadıysa bu iş IT personelinin işleri arasında önceliğe göre sıraya giriyor ve beklemeye sebep oluyor. Benzer şekilde yazılımcı bir işi bitirip, testçiye otomasyon testi yazması (Evet, yazması. Manuel test yapan kişiler varsa ekibinizde o zaman bu sürecin çok daha gerisindesiniz demektir.) için işi teslim ediyor ve kendisi başka bir işe atlıyor diyelim. Bu durumda test yapan kişi sorunlar buldukça başlıyor yazılımcının ensesinde boza pişirmeye. Yazılımcı da bu durumda aynı anda birden fazla iş yapmaya başlıyor. Zaman baskısının olduğu projelerde bu durum stres durumunu tetikliyor ve politik sorunlar ortaya çıkmaya başlıyor, sürtüşmeler yaşanıyor. Sürtüşmenin olduğu yerde ne kalite ne de sağlıklı bir kültürden bahsedilebilir çünkü zaman baskısı yüzünden iş suçlamalara ve topu başkalarına atmakla son bulacaktır.

Bu yüzden ‘eh işte’ firmaların da sağlıklı bir kültürü oluşturması ne yazık ki kalıcı olmayacaktır. Danışmanlar ofisi terk ettikten sonra işler eski haline geri dönecek ya da daha kötüye gidecektir. Çünkü yeni bir kültürü organizasyonda kabul ettirebilmek için herkesin mutlu olması şarttır.

Bu tarz değişim projelerinin ne kadar zor olduğunu tartışmamıza bile gerek yok sanırım. Doğru yolu tespit etmek, insanları ikna etmek, dahil etmek ve daha da önemlisi değişim doğrultusunda oluşacak organizasyon ihtiyaçlarına uygun insan kaynağının yaratılması çok ama çok zor bir süreçtir.

Örneğin, bağımsız bir test departmanına sahip bir firmanın hala manuel olarak test yaptığını düşünelim. İnanmayacaksınız ama hala 100'lerce test senaryosunu elle koşan organizasyonlar var. Bir dönüşüm projesi kapsamında DevOps kültürünü uygulamak istediğinizde bu kişileri nasıl değerlendirebilirsiniz? Bu başlı başına bir sorun, ve elbette firmanın kültürü ve kişilerin yatkınlıklarıyla yakından ilgili olarak farklı çözümler bulmak mümkün olabilir. Örneğin bu ekiple tek tek görüşüp ne istediklerini anlamak ve mümkünse istediklerine en yakın kariyer yolunu onlara sunmak çok önemli. Mesela bu ekipten çok iyi Product Owner’lar çıkabilir, ya da yazılımcılığa geçiş yapmak veyahut test otomasyonunda görev almak isteyenler olabilir. Bu durumda bu kişiler için doğru zamanlamayla, doğru eğitimlerle kültürün içerisinde doğru yerleri bulmak da çok önemlidir.

Yani demek istediğim ‘en iyi’ performanslı firmalara dönüşmek için ‘eh işte’ firma yolundan geçmeniz gerekiyor olabilir. Hatta firmanız belki de işin o aşamasında yer alıyor olabilir. Ama önemli olan o durakta çok fazla beklememek. Kimse sonsuza kadar ‘eh işte’ kalmak istemez, çünkü ‘eh işte’ durumu adeta Hidrojen atomuna benzer, bir an önce stabil bir duruma geçmelidir. Bu süreci ya da siz yönetirsiniz ev su elde edersiniz ya da büyük bir patlama ile küçük parçalara ayrılırsınız.

‘Eh işte’ firmaların yaptığı bir başka hata ise DevOps kültürünü uygulayacağım diye DevOps Engineer işe almaktır. Bu durum yukarıda uzun uzun anlattığım bilgi yığınlarına yenisini ekler. Çünkü bu firmalar dönüşüm sırasında yazılımcılarını eğitip bu yetkinliği kazandırmak yerine hazır bu bilgiye sahip kişileri işe alıp mevcut ekibinin bu konuda yetkinlik kazanıp israfı önlemesinin önüne geçer.

Şöyle bir özetleyelim;

  • Eğer firmanızın daha iyi rekabet etmesini sağlamak istiyorsanız müşterilerinizi iyi bir şekilde anlayıp ihtiyaçlarını en hızlı şekilde çözmelisiniz.
  • Müşterilerinize hızlı ulaşmak istiyorsanız teknoloji departmanınıza yatırım yapmanız lazım.
  • Yatırım yaparken farklı bilgi yığınları oluşturup ekipleri izole ederek bürokratik bir kültür oluşturmak rekabette olduğunuz diğer firmalara fayda sağlayacaktır.
  • Sağlıklı bir teknoloji departmanı iyi bir kültüre sahip olmalıdır.
  • Bu kültürü oluşturmak için yazılım ekiplerine uçtan uca sahiplik vermek ekibinizi mutlu edeceği gibi hem özgüven sahibi hem de yenilikçi mühendisler yetiştirmenize katkı sağlayacaktır.

Bu konuda sorularınız ve eleştirileriniz için yorum yazabilir, bana twitter üzerinden ulaşabilir ya da anonim olarak soru sormak için curious cat’i kullanabilirsiniz.

Şimdilik esen kalın!

--

--