DevOps Eğitiminden Aklımda Kalanlar
Doğuş Teknoloji bir süredir önemli bir değişim süreci içerisinde. ACM firmasından alınan danışmanlıkla birlikte çevik metodolojilere geçilmeye başlandı. Modül bazında geçiş yapan ekipler haricinde Scaled Agile Framework benzeri bir çerçevede oturtulmaya çalışılmakta. İçinde bulunuğum ekip 4ncü sprint’in içerisinde ve yavaştan işler yoluna girmeye başladı diyebilirim.
Aslında çevik metodolojilere geçiş çok uzun zaman Waterfall üzerinde koşan bir firma için hiç de kolay değil. Sonuçta şirketin kültürünü köklü bir şekilde değiştirmesi, değişime adapte olması, tepe yönetimi dahil her bireyin bu değişimi kabullenerek kendisini hazırlaması gerekiyor. Benzer bir süreci, süreç sırasındaki sıkıntıları daha önceden çalıştığım ING Bank bünyesinde de yaşamıştım.
Bu sefer durum biraz daha farklı. Özellikle ACM firmasındaki koçların danışmanlıkları ve eğitimleri çok profesyonel. Koçlarımızı dinlediğim her fırsatta yeni bir şeyler öğreniyorum. Hele ki eğitimlerden…
Kültür dönüşümünün önemli bir parçası da DevOps’a geçilmesi. Tahmin edileceği üzere bu da kolay bir iş değil. Manuel olarak yürüyen çok fazla şey var. Operasyon ile geliştiriciler arasındaki bariyerler zaman içerisinde oldukça kalınlaşmış. Her production geçişi korkulu rüyalar görmemize sebep olabiliyor. Sistem bir şekilde yaşıyor ama bakım maliyetleri artıyor. Ayrıca legacy sınıfına girmiş 2002 doğumlu olan önemli bir ERP sistemi mevcut. Neredeyse her türden Anti-Pattern’i bünyesinde barındırıyor. Her ne kadar ürün modül modül yeni nesil teknolojilere geçirilmeye başlanmış olsa da bu tek başına yeterli değil. Artık uçtan uca otomatize edilmiş, hataların önceden bertaraf edilebileceği, sürekli değer yaratan iş parçalarının müşteriye sunulabileceği, değişimin bir parçası olan tutarlı ve güvenilir bir hattın tesis edilmesi lazım.
Dolayısıyla DevOps felsefesinin benimsenmesi ve kullanılır hale getirilmesi de büyük önem kazanmış durumda. Hatta şimdi çevik olmanın anlamı bir kat daha artıyor. Çünkü çevik metodolojier, DevOps’u destekleyen önemli enstrümanlardan birisi. Nerden mi biliyorum? Değerli Umut Arısoy’un eğitimde anlattıklarından. Kısa bir süre önce DevOps’un ne olduğunu anlatan güzel bir eğitim aldık kendisinden. Ben her eğitimde olduğu gibi alabildiğim kadar not almaya çalıştım. Sonra bunları temize çektim ve paylaşmanın güzel olabileceğine karar verdim. İşte eğitimden hatırımda kalan kısa kısa notlar.
Bir Girizgah Yaptık
DevOps bir süreç değildir, süreç ve araçlardan yararlanan bir felsefedir. Çevik(Agile) metodolojiler DevOps’ u destekler türdendir. DevOps’ da amaç geliştiriciler ile operasyon arasındaki bariyerleri kaldırmaktır. Bu nedenle iletişim(Communication) ve işbirliği(Collaboration) çok önemlidir.
firmasında bir dönem çalışanlardan sonraki 24 saat boyunca planda olan işlerle uğraşmak yerine başka işlere bakmaları söylemiş. Çalışanlar bir şeyleri düzeltmek için kenara bırakmak zorunda kaldıkları işlerle uğraşmış ve bir çok problemin düzeldiği görülmüş. Nitekim insanlar düzeltmeyi planladıkları ama dönüp bakamadıkları işlerle ilgilenme fırsatı bulmuşlar.(Umut Arısoy aralara çok güzel firma hikayeleri de kattı)
DevOps çok çalışma ve önemli bir kültür değişimi gerektiriyor. Yani “benim işim budur bundan sonrası sende” yaklaşımını değiştirmeyi öğütlüyor. Korkutucu görünebilir ama küçük başlayıp(Start Small) sonrasında ise Build Trust, Celebrate Success gibi tesis edilmesi zor adımlarına geçilir. DevOps felsefesi oturdukça hız, kalite ve sağlamlık gibi olgular oluşmaya başlar. Buna göre build, test ve release gibi bir ürünün sunulmasında önem arz eden ana çarklar düzgün bir şekilde işlemeye başlar.
DevOps maliyetleri düşürmeye, riski azaltmaya, sürekli pazara çıkabilmeye, küçük ve sık sürümleri yayınlayabilmeye, kod ve dağıtım kalitesini arttırmaya çalışan bir kültür yaratmaya çalışır.
Bir şirketin yaşam felsefesini değiştirmek, kültürünü güncellemek her zaman için en zor olan şeydir.
DevOps’un Amaçlarına Baktık
DevOps’ un hedefleri genel olarak aşağıdaki gibidir.
- Data Driven Decision : Verilere göre karar verebilmek, veri odaklı otomatize işler planlayabilmek.
- Intelligent Risk Taking : Riskleri akıllıca karşılayabilmek
- Collaboration : Özellikle takım olarak iş birliğinde olmak. Operasyon ve geliştirme arasındaki kalın duvarları yıkmak.
- Open honest two way communication : İletişimin dürüst ve güvenilir olmasını iki taraflı sağlayabilmek.
- Learning & Practicining : Öğrenmek ve pratiğe dökebilmek
- Trust : Güvenilir bir hat oluşturabilmek
- Transparency : Sistemin her noktasında, takımların yaptığı her işte açık olabilmek, şeffaflığı sağlamak.
- Shared Vision : Ortak bir vizyonda buluşmak.
- Continuous Improvements : Sürekli iyileştirmek
- Continuous Experimentation : Sürekli deneyimlemek.
Amazon,
firması günde 23 bin Deployment yapabiliyormuş. Neredeyse her 4 saniyede bir. Bu, başarılı bir şekilde oturttukları DevOps kültürünün bir sonucu. Özellikle Push butonunu ortadan kaldırıp Continuous Delivery’ den Continuous Deployment’ a geçmiş olmaları bunun bir sebebi olarak ifade ediliyor.
2011 yılı istatistiklerine göre 11,6 saniyede bir üretime dağıtım yapıyormuş. Bu en yoğun saatte 1079 dağıtım anlamına gelmekte.
DevOps’u bu anlamda düşündüğümüzde çok başarılı uygulayan bir çok şirket de var. NASA, Amazon, Netflix bunlardan bazıları. Şuradaki gibi güncel yazılara bakmakta yarar var.
Araçlara Değindik
DevOps bir felsefe olmakla birlikte çok geniş bir araç yelpazesine de sahiptir. Fikrin geliştirilmesinden, testlerine, dağıtım planlamasından, log stratejilerinin inşasına kadar bir çok araç işin içerisine girer. Benzer amaçlara hizmet eden, açık kaynak olarak sunulan veya ücrete tabii olan bir çok enstrümandan bahsediyoruz. Yıllar öncesinden gördüğüm o meşhur DevOps Periyodik tablosu da eğitimin bir parçası olarak karşımıza çıkmıştı.
Ürün Geliştirme Hiyakesinden Bahsettik
Genel olarak ürün geliştirmede şöyle bir akış vardır; Business’ bir fikir(idea) tanımlar ve bunun üretilmesi için geliştirme ekiplerine verir. Development safhasında kodlanan ürün operasyon birimleri tarafından ürün olmak üzere ilgili ortamlara taşınır. Son adımda ürün müşteri ile buluşmuş olur. Dolayısıyla iş biriminden gelen fikirlerin müşteriye ulaştırılması en önemli amaçtır. DevOps soldan sağa doğru ilerleyen bu hattı iyileştirmeye ve hızlandırmaya çalışılır.
DevOps’un müşteriye ürün ulaştırılmasındaki katkısını anlamak için aşağıdaki şekil bize yardımcı olabilir.
İlk model analiz sonrası sıkışık development sürecini yansıtmaktadır. İkinci modelde geliştirme kültürü Scrum ile desteklenir ve takımların daha fazla değer oluşturmasına olanak sağlanır. Ancak yine operasyon kısmında darboğazlar oluşabilir. Üçüncü modele göre DevOps kültürü de işin içerisine katılır. Ancak bu da tek başına yeterli değildir. DevOps sürekli tecrübe edinmek ve öğrenme üzerine kurgulanmış bir sistemdir. Bu nedenle sağdan sola doğru geri bildirimlerin akması çok önemlidir. Yapılan her şeyle ilgili geri bildirim almak, sonraki iterasyonlarda yanlış giden bir şeyleri düzeltmek anlamına gelir. Bu da iyileştirmek demektir. Yani sürekli olarak iyileştirme yoluna gidilirek hattın sorunları azaltılmaya çalışılır.
Netflix’in,
başarısının arkasında Uptime süreleri vardır. Lakin bunu gerçekleştirmek için önemli bir DevOps kültürünü benimsemişlerdir. Netflix vakti zamanında Simian Army isimli bir yapı kurgulamış. Simian Army içerisinde çeşitli botlar barındıran bir çatı gibi düşünülebilir.
Örneğin Chaos Monkey isimli bot, yerel sunucularda rastgele ateş açarak sorunlar oluşturur. Network’ü engeller, sanal makineleri uçurur, veritabanında bozukluklar yapar(Burada deneyimlemek istenen şey Chaos Engineering) vb. Ya da Chaos Kong, bölgesel zararlar verir. Örneğin bölgesel olarak ağı çökertip videoların oynatılmasını engeller. Janitor Monkey, sistemde kullanılmayan ne varsa kaldıran bir robot yazılımdır. Bunlara ek olarak Chaos Gorilla, Docker Monkey, Compliance Monkey, Letency Monkey, Security Monkey gibi diğer maymun botların yaptığı sorunları engellemeye çalışan bot’ lar da varmış.
Burada amaç sistemin Uptime sürelerini mümkün olduğunca yukarı çıkartabilecek iyileştirmeleri yapmak ve müşterinin hizmetinin aksamasını engellemek. Öğrendiğimiz kadarıyla Simian Army bir süre önce emekli edilmiş.
Takım Yapılarına Baktık
Aslında sorunların önemli bir kısmı çalışmakta olduğumuz takımların yapılarından ve çalışma stillerinden kaynaklanıyor. Dünya üzerindeki takım yapıları genel olarak üç farklı türdedir.
- Yüzde seksinimiz(%80) Survival Mode da çalışıyoruz.
- Learning Mode (Bu kısmı kaçırdım)
- Yüzde bir (%1) kadarımız Self-Organizing/Self-Sufficient modda çalışıyor. Bu çok düşük bir oran ancak en etkili ve verimli mod diyebiliriz. Nitekim çevik süreçlerde olduğu gibi takım kendi kendine organize olup sorunları hızlı bir şekilde çözümleyebiliyor.
Derken Continuous Cephesine Uğradık
Gelelim Continuous Integration, Continuous Delivery ve Continuous Deployment konularına. Genel olarak kodun DevOps süreçlerine dahil edilerek Release noktasına gelme adımları genel olarak aşağıdaki şekilde görüldüğü gibi gerçekleşiyor.
Kod check-in’lendikten sonra Version Control’ a atılır. Version Control sistemi CI Server’ı tetikler. Burada bir dizi otomatize edilmiş test çalıştırılır ve build işlemi gerçekleştirilir. Eğer hata varsa geri bildirim yapılır. Kod tekrardan düzenlenir, hataları giderilir ve yeniden check-in’lenip Version Control üzerinden bir kez daha CI Server(Jenkins , VSTS gibi sunucular olarak düşünülebilir) a gelir ve tekrardan test/build işlemleri yapılır. Sorun yoksa otomatize edilmiş kabul testleri tetiklenir. Sorun oluşursa yeniden geliştirme adımına dönülür. Aynı süreç bu noktaya kadar devam eder. Sorun yoksa UAT adımı işler ve Release’ a kadar gelinir.
Aslında Continuous Integration, Continuous Delivery ve Continuous Deployment’ın yazılım geliştirme hattındaki farklarını aşağıdaki şekil ile daha net görebiliriz.
Dikkat edileceği üzere Continuous Delivery’ de manuel olarak yürüyen dağıtım adımları Continuous Deployment’ta otomatik olarak gerçekleşir. Amazon’un en büyük sırrı da budur.
Bu yaşam döngüsünde testlerin önemli bir yeri var. Geliştiriciler açısından düşünürsek Test Driven Development’a uygun hareket etmek lazım(Red Green Blue; Önce hatalı sonlandır, sonra doğru çalıştır ve en sonunda kodunu toparla) Testin DevOps içerisindeki önemini aşağıdaki grafikler ile açıklamak da mümkün.
İlk grafik proje boyutuna göre zaman maliyetini gösteriyor. TDD ilk başta geliştiricilere çok zaman kaybettiriyor gibi görünebilir ki öyle de oluyor. Ancak işi garanti etmek uzun vadede avantaj yaratıyor. Proje’nin çapı genişledikçe yeni özelliklerin eklenmesi için harcanan zaman TDD dışı uygulanan süreçte giderek artıyor. Benzer durum bug fix senaryoları içinde geçerli. TDD ile birlikte kodun tamamının gözden geçirilmesi(%100 code coverage) bug-fix düzeltmeleri için harcanan sürenin belirgin ölçüde azalması demek. Son grafik değişim maliyetlerini göstermekte. Değişim, Waterfall gibi süreçlerde zaman ilerledikçe gittikçe zorlaşmakta. TDD ile başlanıldığında ise kabul edilebilir maliyetler dahilinde değişime ayak uydurulması mümkün.
İşin içerisinde TDD varsa geliştiricinin yapması gereken önemli pratiklerden birisi de Code Kata’dır.
Tabii testlerin önemini bu kadar çok vurgularken tercih edilmediği durumlar olabileceğini de ifade etmek gerekiyor. Örneğin bir startup’ı göz önüne alalım. Çoğunlukla düşük bütçeli ve küçük bir geliştirme ekibi vardır ve mümkün olan en kısa sürede(as soon as posible) pazara çıkılmak istenir. Üstelik gereksinimler(Requirements) çoğunlukla iyi tanımlanmamıştır. Bu tip bir yapıda otomatize edilmiş testler önemli olmakla birlikte esasen zorunlu değildir. Diğer yandan yüksek bütçeli, pazara orta veya uzun vadede sokulması planlanan, orta veya büyük ölçekli geliştirme takımı bulunan ve iş birimince gereksinimlerinin net olarak ifade edildiği bir ürün söz konusuysa otomatize testlerin(Automated Tests) kullanılması şiddetle önerilmektedir.
TDD denildiğinde genellikle aklımıza gelen ilk şey birim testtir(Unit Test) Oysa ki TDD, Integration Tests, User Acceptance Tests gibi temel test konularını da içerir. Hatta Smoke Testing, Penetration Testing, Stress Testing, A/B testing, Fuzz Testing ve Boundary Testing gibi konular da vardır(TDD başlı başına büyük bir konu ama DevOps felsefesinin olmazsa olmaz yapıtaşlarından da birisi)
O Zaman Dağıtım(Deployment) Stratejilerine’de Bakalım Dedik
Dağıtım tabii ki DevOps’un en önemli parçalarından birisi. Düğmeye basınca Facebook’u production’a almak öyle sanıldığı kadar kolay değil. Sonuçta en ufak hatayı dahi affetmeyecek bir müşteri kitlesi var. Bu nedenle duruma göre tercih edilebilecek farklı dağıtım stratejileri mevcut.
- Highlander Deployment: Bir uygulamanın versiyonu doğrudan yeni versiyona çekilir. Klasik bir yöntemdir. Riskleri fazladır. Deployment sırasında sistem kapalı kalır(Bu bizim de bir üründe mecburen kullanmakta olduğumuz bir model. Dağıtım sırasında söz konusu uygulama 1 saate yakın süre kapalı kalıyor :| Ama bu durum değişecek (: Hatta yeni nesil ürünlerimizden birisi VSTS pipeline’ı üzerinde ve Continuous Delivery’yi destekler durumda)
- Rolling Deployment: Versiyonlar kademeli olarak geçirilir. Bir ortam geçtikten sonra diğeri, sonra diğeri gibi. Gelişmiş deployment araçları gerektirir. Bankaların kullandığı tekniklerdendir.
- Blue/Green Deployment: Downtime ve riski düşürmek için Blue ve Green isimli ortamlar söz konusudur. T anında bunlardan sadece birisine deployment yapılır. Dolayısıyla ortamlardan birinde canlı test gerçekleşir. Ortamlardan biri aktifken diğeri idle pozisyonda kalır. Eğer aktif ortamda sorunlar varsa trafik diğer ortama yönlendirilir.
- Phoenix Deployment: Bunu not alamadım, sonra da araştıramadım. Üzgünüm :( Bilen birileri iki kelam ederse harika olur.
- Canary Release Deployment: Bu, oldukça değişik bir model. Örneğin Facebook kullanıyor. Bir Release çıkarken kullanıcılarının sadece %2’sine bunu çıkıp geri bildirimleri takip ediyormuş. Eğer bir problem varsa yapılan değişiklikler otomatik olarak geri alınıyormuş(Şunu bir düşünün. Production’a yeni bir sürüm aldınız ve beklemediğiniz bir sorunla karşılaştınız. Geri alma planınız var mı? Peki ya manuel mi yürüyor? Otomatikleştirebilir misiniz? Nasıl? Çözüm DevOps felsefesinde var)
Stratejiler ile ilgili olarak şurada güzel bilgiler yer alıyor.
Aralarda Bir Takım Özlü Sözler’de Yakaladım
- Microservices -> Correct version of the SOA :)
- TDD(Test Driven Development) geliştirme süresini uzatsa da uzun vadede çok daha az defact çıkmasını sağlar.
- Continuous Deployment, Continuous Delivery’ nin Push düğmesi kaldırılmış versiyonudur.
- Continuous Integration = Automated Build+Validated by Unit, Integration and Acceptance Tests+Code Standards
- Şirketler için kalite ve risk yönetimi en az hız kadar önemlidir.
Eğitim Sonrası Kendime Araştıracak Belli Başlı Konular da Çıkarttım
- CALMS nedir? (Culture Automation Lean Measurement Sharing)
- Futurist Gerd Leonhard
- Nokia Optimized TCO
- Jesus Driven Development :D
- Jenkins (CI Server)
- DevSecOps
- Phoenix Deployment
Ve sonunda bu giriş eğitimini tamamlamış olduk. Ben eğitim sonrası Pluralsight’tan konu ile ilgili eğitimleri izlemeye başladım. İçinde yaşamaya başladığımız bu felsefe ile ilgili detayları öğrenmeye devam ediyorum. Başarılı olacağımıza ve bir şeylerin iyiye gideceğine inancımız tam. Scrum Master’dan, Product Owner’a, Development Team’den, Stakeholder’lara…
