devops

• yaklaşık olarak 7 aydır görev yaptığım, macerası bol ama zor pozisyon.
  
  'devops bir title değil, bir kültürdür' olayına katılmadığımı söyleyim öncelikle. yönetim de sadece yöneticiyle değil takımla da ilgili bir olay mesela, ama 'yöneticilik bir title değildir' demek ne kadar saçma olacaksa, bence bu da öyle. devops herşeyden önce bir kültür evet, bir teknikler bütünü - bir sistematik, ve hatta bir sorun çözme biçimi. bir disiplin yani. ve her disiplin gibi, onu iyi anlamış, doğru uygulayan ve çevresindekilere doğru şekilde öğreten insanlara ihtiyaç duyuyor. bu da gayet önemli bir 'title' demek.
  
  ha evet, tabii ki kapısında 'devops' yazan bir ekip olmadan da çok güzel işlere imza atabilirsiniz, ama bu demek değildir ki 'devops' pratiklerine ihtiyacınız yok veya onları uygulamıyorsunuz.
  
  devops, benim için, otomasyon sanatı olsa gerek. her programcı bir şeyleri otomatize etmiyor mu diyebiliriz, ama bu çok daha geniş bir otomasyon. altyapının, networkün, makinelerin, işlerin, insanların ve süreçlerin otomasyonundan bahsediyoruz. hepsinin kendi içinde de değil, birbirleriyle etkileşimin otomasyonu.
  
  'geliştiricinin yaptığı commit, yayındaki web sitesine nasıl gidecek?'
  
  * committen önce, bu commitin yapılmasına sebep olan iş nereden ve nasıl geldi? nasıl tanımlandı? ekip, ihtiyacı olan şeyi geliştiriciye doğru şekilde aktarabildi mi?
  * geliştirici commiti nerede ve nasıl yaptı? önünde hazır bir development ortamı var mıydı? bu ortamı nasıl kurdu? bu ortamın hatasız ve istendiği gibi olduğundan emin miyiz? her geliştiricinin önünde aynı ortam olduğuna emin miyiz? bu ortamın, canlı yayın ortamını yeterli şekilde yansıttığından emin miyiz?
  * geliştirici bu commiti nereye gönderdi? bir git hosting mi satın aldık yoksa kendimiz mi kurduk? bu git alanı üzerinde yetkiler doğru tanımlanmış mı? aynı anda çeşitli geliştiricilerden çok sayıda commit geldiğinde, birbirlerine karışmadan ve sağlıklı şekilde süreç devam edebiliyor mu?
  * commit geldi, kalitesinden emin miyiz? otomatik testlere giriyor mu - giriyorsa nasıl giriyor? test patlarsa noluyor? ekipteki diğer kişiler tarafından kalite kontrolünden geçirildi mi?
  * herşey tamam, commitin kalitesinden eminiz, işi açan kişi, iş tanımının karşılandığını ve gerekli geliştirmenin hakkıyla yapıldığını düşünüyor mu?
  * bu özellik sitedeki başka herhangi bir şeye zarar veriyor mu? (bu tek cümle, kocaman bir qa sürecinin özeti aslında.) bunun cevabını alabilmek için tabi, commitle gelen değişikliği nasıl bir test ortamında ve ne şekilde yayına aldığınız şeklinde bambaşka dinamikler içeren bir süreci incelemek gerekiyor.
  * commit depoya kabul edildi;
  ** bu commit, geliştiricilerin günlük düzeninde önemli bir değişiklik yaratıyor mu? yaratıyorsa, nasıl bir bilgilendirme yapmalı?
  ** bu commit, daha önce stackte olmayan yeni bir araç gerektiriyor mu? bu araç nedir, nasıl kurulur, nasıl ayarlanır? yayındaki siteye zarar vermeden nasıl yayına dahil edilir?
  ** bu commit, veritabanında bir değişiklik gerektiriyor mu? bu değişiklikler, yayındaki web sitesine zarar vermeden nasıl uygulanır? bu değişiklikler, geliştiricilerin önündeki ortama nasıl uygulanır?
  * tüm gerekli değişiklikler tespit edildi ve bilgilendirmeler yapıldı, bu değişiklikler yayındaki websitesine nasıl yansıtılacak? (hey gidi koca 'deployment')
  
  hepsini bitirdik, geliştiricinin yazdığı kod yayına girdi. bir de o yayındaki sitelerin nasıl bir performansla çalıştığı, ayakta kalıp kalamadığı, farklı yükler altında nasıl davrandığı vs. konular var ki içinden çıkılmaz, kısa kesiyorum.
  
  bunların hepsini yapabilmek için de bazen geliştirici, bazen sistemci, bazen sre, arada dba, kimi zaman networkçü olmanız gerekiyor. öyle puppet ya da chef implemente etmekle olan bir iş değil yani. hatta en uyuz olduğum şey, devops'un araçlardan ibaret bir iş sanılması. otomasyondan konuşuyorsak, otomasyonu sağlayacak aracın hayati önemi olduğu doğru, ancak buradaki en önemli 'araç' insanın ta kendisi.
  
  ha bir de herkesin her konuda fikri olması durumu var. biri gelir 'olm siz docker kullanmazsanız olmaz o iş' der, biri gelir 'abi <insert çıkalı 3 gün olmuş teknoloji here> muhteşem ya nasıl kullanmazsın manyak mısın' der. bir ara herşeyin mikroservise dönüşmesi gerektiğini savunan bir dünya insan vardı, neyse şükür ki zamanla azaldılar. ya bu teknoloji/yöntemlerin hepsi, kendi içlerinde gayet güzel şeyler olabilir ama hali hazırda çalışan bir altyapı söz konusu ise, onun nasıl çalıştığını anlamadan, araştırmadan, bilmeden üstüne 'x kullanmalıyız çünkü bu ara çok hype' kafasıyla etrafa tavsiyeler yağdırmak, ne bileyim işte üzülüyorum... ucu sistem yönetimine dokunan bir alanda nasıl hype-driven iş yapılabildiğini de aklım almıyor, javascript kütüphanesi mi yahu bu?
  
  özet olarak, stres altında çalıştığınızda insanı hayatından soğutabilecek, ama doğru şartlarda bi o kadar da keyif vermesi mümkün ve çılgın miktarda yeni bilgi edinmeyi sağlayan/gerektiren bir alan. yalnız, ekosisteme hakim değilseniz çok can yakan bir learning curve'i var. etrafınız, naptığını biliyormuş gibi davranan insanlarla doluyken sizin hiçbir şey anlamıyor olmanız insanı salak gibi hissettiriyor ama inanın onlar da çok anlamıyor, detaylara pek takılmıyorlar sadece.
  
  öyleyken böyle sözlük. çok dolmuşum.