Devops’u yanlış yaptığınızın 7 işareti

Yanlış anlamalar ve hatalı uygulamalar devops’un gerçek faydalarını kaçırmanıza neden olabilir

Devops pek çok firmanın fayda sağlamak için uygulamaya koyduğu kültürel bir dönüşümdür. Kültürle bağlantılı her şey gibi, bir kaç araç kurup yeni süreçlerin içine serpiştirerek kendini devops uygulayan bir organizasyon olarak tanıtmak oldukça mümkün. Son günlerde firmaların devops takımları kurduklarını ve düzenli olarak devops tekniklerini uyguladığını söylemeleri de son derece popüler ve bu söylemi iyi yetenekleri takımlarına çekmek için iyi bir tanıtım olarak görüyor olabilirler. Ama gerçekte, devops’a bağlılıklarını ilan eden pek çok firma – ve teknik işe alım uzmanı –“gerçek” devops organizasyonları değildir.

Bu yazıda bazı çok genel yanlış anlamalara ve hatalı devops uygulamalarına göz atacağız. Belki sizin firmanız da bunlardan  bir veya bir kaçına yakalanmıştır. Bu kesinlike devops uygulamadığınız anlamına gelmez. Bu sadece firmanızın bu yolda kat etmesi gereken biraz daha mesafe var demektir. Devops elde edebileceğiniz bir ödül veya ünvan değildir, bir felsefedir, kültürdür ve yazılım geliştirme işine bir yaklaşım şeklidir.

Arkanıza yaslanıp okuyun ve firmanızın devops’u ne kadar doğru yaptığını kendiniz değerlendirin. Takımınıza doğru yönde rehberlik etmek için değerlendirmenizde samimiyet ve dürüstlüğü esas alın.

İşaret #1: “Devops”u alma ihtiyacı duyuyorsunuz

BT departmanları işletmek için bazı “şey”lere ihtiyaç duyarlar. Donanıma ihtaç duyarlar: bilgisayarlar, sunucular, rack’ler, network switch’leri, router’lar, yük dengeleyiciler… Ayrıca yazılımlara ihtiyaç duyarlar: işletim sistemleri, antivirüsler, verimlilik uygulamaları, proje yönetim çözümleri, çeşitli iş birimi yazılımları ve donanım ile yazılımın sağlığını ve performansını izlemek için monitoring uygulamaları gibi.

BT departmanları var oldukları günden beri bir “şey”ler satın almışlardır. İlk firma iş uygulamalarının bir parçası olarak bilgisayar kullanmaya karar verdiğinden beri “satın alma” BT’nin can damarı olarak ortaya çıkmıştır. BT uzmanlarının iş birimlerine yardım etmelerini kolaylaştıracak bir sonraki büyük şeyi satın alabileceklerini düşünmesi doğaldır. Bazı firmaların “devops”u satın alabilecekleri gibi yanlış bir izlenime kapılmış olmaları da bu sebeptendir.

Elbette kötü niyetlerinden değil ama devops konferanslarına katılan ya da devops dostu CIO’larla devops hakkında sohbet eden pek çok CIO, devops’un firmaları için neler yapabileceğini görmeye başladılar. Bazıları “devops”u istediklerine karar verdiler, hem de hemen istediklerine! Anlamadıkları nokta ise devops’un satın alabilecekleri bir ürün veya hizmet olmadığıydı. Devops bir kafa yapısı, bir çalışma şeklidir.

Bu devops prensiplerini öğrenmek için danışmanlardan destek alamayacağınız anlamına gelmez, ama bunu yaparak sonuçta devops’u değil uygulamak için sıkı bir çalışma gerektiren bilgiyi satın almış olursunuz. Takımınız öğretilenleri özümsemelidir ve ancak ondan sonra devops uygulamaları kök salmaya başlayacaktır.

“Devops” basit bir kontrol veya ufak bir eğitimle bir gecede elde edilemez. Devops ana süreçlerinize dönüşümsel bir yaklaşımdır ve zaman alır, uzmanlaşma ister ve özellikle ezber bozan devops pratiklerini uygulayabilecek bir takım ister.

Eğer firmanızın bir devops satın alma bütçesi varsa, devops’u yanlış yapıyorsunuz.

İşaret #2: Yazılım ve araçları devops’a eşit tutuyorsunuz

Bu yanlış devops uygulaması birinci işaret ile paralellik arzeder. BT firmaları işlerini daha etkili yapmak için araçlar edinir. Bu işin doğasında vardır. BT firmalarının depolama, işlem ve ağ kaynakları için olduğu gibi istemcileri ve sunucuları da yönetmek için araçları vardır. Ama iş araçlar ve devops’a gelince genelde firmaların kafası karışır. Doğrusu araçlar olmadan devops geçişinin altından kalkmak imkansızdır. Ama firmalar devops’un diğer alanlarını görmezden gelip sadece araçlara odaklandıklarında problemler ortaya çıkar. Araçlar önemli olabilirler ama onlar sadece buzdağının görünen kısmıdır.

Devops’la ilişkili çeşitli konfigürasyon yönetimi ürünleri kesinlikle bir devops kültürü inşa etmenize yardımcı olur. Onlar olmadan şüphesiz devops uyguluyor olamazsız. Yazılım testi, aktarım, derleme gibi önceden elle yapılan işlemlerinizi otomatikleştirmek için kendi araçlarınızı geliştiriyor veya bu işleri hızlandırmak için araçlar satın alıyor olabilirsiniz; öyle ya da böyle otomasyon devops’un büyük bir parçasıdır. Araçlar olmasaydı hala test sunucularımızı kılavuzları takip edip kontrol listelerine tik atarak elle ayağa kaldırıyor olurduk.

Ama devops konfigurasyon yönetiminin ötesinde bir dizi alanı daha kapsar; sırf bir çözümü mevcut olduğu için bir alana odaklanmayın. Eğer devops ninja olma yolunda sizin için biçilmiş bir kaftan ararsanız hata edersiniz.

Eğer firmanız tüm devops ihtiyaçlarınıza deva olacağını düşünerek Chef veya Puppet satın aldıysa, devops’u yanlış yapıyorsunuz.

İşaret #3: Dağıtımları yönetmek için kontrol listeleri veya kılavuzlar kullanıyorsunuz

Devops’un püf noktasının otomasyon olduğunun altını çizmek gerekir. Otomasyon, organizasyonel devops kültüründe büyük önem taşır. Devops uygulayan şirketler mümkün olan herşeyi otomatize etmeyi arzu ederler. Otomasyon insan hatalarının önüne geçme ve tüm yazılım geliştirme yaşam döngüsü boyunca süreçleri standartlaştırmaya imkan tanır.

İşletmeler otomasyonun, tutarlı ve rutin kod dağıtımı gibi devops prinsiplerinin tohumlarını ekmek olduğunu bilirler. Özellikle güvenilir kod dağıtımları yapmak otomasyon olmadan mümkün değildir. Otomasyon devops yolculuğunuzda lokomotifiniz olacaktır.

Eğer kendinizi “Otomasyon için yeterli zamanımız yok.” veya “Bu seferlik elle yapsak? Daha hızlı olur.” gibi konuşmaların içinde buluyorsanız, devops’u yanlış yapıyorsunuz. Eğer yeni bir projeye giriştiğinizde aklınıza gelen ilk düşünce her şeyi otomatikleştirmenin mümkün olduğu değilse muhtemelen henüz devops konusunda yeterince uzmanlaşmadınız demektir.

Devops ağır kültürler otomasyon için harcanacak süre katbekat fazla bile olsa da gelecekte daha güvenilir ve daha hızlı kod dağıtımları ile harcanan emeğin karşılığını alacaklarını bilirler. Firmanız yazılım geliştirme sürecindeki neredeyse her şeyin otomatikleştirilebileceğini kavramalıdır. Dağıtımlar, testler, kod değişikliği politikaları, sunucular, derlemeler… Neredeyse her şey.

Eğer firmanız kod değişikliklerinin dağıtıma hazır olduğuna emin olmak için kontrol listeleri üzerinde saatler harcıyorsa, devops’u yanlış yapıyorsunuz.

İşaret #4: Kodunuzu üretim ortamına bir kaç ayda (veya yılda) bir çıkıyorsunuz

Otomayonunun önemine değindiğimize göre biraz da dağıtım sıklığının önemine bakalım. Devops’un yegâne amacı kod değişikliklerini (hata düzeltmeleri, yeni özellikler, iyileştirmeler) üretim ortamına daha hızlı çıkmaktır. Bu amaca geleneksel yöntemler ile ulaşılamaz, çevik olmak gerekir.

Çevik metodoloji özünde küçük değişiklikleri mümkün olduğunca sık bir şekilde üretim ortamına çıkmaktan oluşur. Daha projenin başındayken her küçük detayı planlamaya çalışmanın yanlış olduğunu savunur. Bu neyin “üretim ortamına hazır” olarak kabul edildiğinin tanımıyla alakalıdır. Çevik metodoloji kod değişikliğinin “üretim ortamına hazır” olmasını doğru yazıldığına itimat edilen bir dizi otomatik testin başarıyla koşulması olarak tanımlar.

Devops sürekli entegrasyon ve sürekli teslimat gibi kavramlarla eş anlamlı sayılabilir. Her iki terimdeki anahtar kelimeye dikkat: sürekli. Devops geliştiricilerin sürekli ve hızlı bir şekilde geliştirdikleri kodlar hakkında geri besleme almasını sağlamaktır ve otomatik testler bu geri bildirimlerin başlangıç çizgisidir.

Gerçek devops duayenleri için devops, kod değişikliklerinin sürekli teslimat ile tamamen otomatik bir süreçten geçip el değmeden üretim ortamına çıkılmasıdır. Eğer geliştiricilerinizin yazdığı kodlar otomatik olarak bir test süzgecinden geçerek versiyon kontrol sisteminize giriyor, ardından üretim ortamına hazır olduğuna bir dizi otomatik testler koşarak emin oluyor ve akabinde yine el değmeden üretim ortamına çıkıyorsanız zaten devops’ta kara kuşak sahibisiniz demektir.

Kod değişiklikleriniz çok küçük olsa ve bu değişiklikleri çok hızlı kodlamış olsanız bile eğer değişiklikleri ayda yılda bir üretim ortamına çıkıyorsanız, devops’u yanlış yapıyorsunuz.

İşaret #5: Hatanın kabul edilemez olduğunu düşünüyorsunuz

Kültür genellikle BT’nin olmazsa olmazları arasında sayılmaz, devops içinse daha önemli olamazdı. Firmaların devops’un vaat ettiklerine ulaşmakta genellikle hataya düştükleri nokta tam da burasıdır. Uygun araçları bir araya getirip otomasyon yapmış olabilirler, kodlarını sıklıkla güncelliyor olabilirler ama devops kültürünü tam olarak özümseyememiş olmaları onları sıkıntıya sokar.

Örneğin, sizin yaptığınız bir değişiklik üretim ortamı veritabanınızı patlattı diyelim, size ne olur? Patronunuz herkesin içinde sizi azarlar mı? Yöneticiniz sizi acilen odasına mı çağırır? Kod değişikliği yapmanızın mükafatını işinizi kaybederek ya da bir daha asla üretim ortamına değişiklik çıkamayarak mı alırsınız? Eğer öyleyse firmanız devops uygulamıyor.

Bir de şöyle olduğunu düşünün: Üretim ortamı veritabanınızın uçması bir öğrenme fırsatı olarak kabul edilir. Yöneticiniz problemin neden yaşandığını ve tekrar yaşanmaması için neler yapılabileceğini konusunda fikir alışverişi için tüm ekibi toplar. Herkes konuya samimiyetle yaklaşıp neler yapılabileceğine bakar ve kimse bütün kabahati size yüklemez. Hatanın temel sebebi belirlenir ve hatanızın etrafına yeni testler geliştirilir. Böylelikle tekrar aynı hataya düşüldüğünde kimse için diğerlerinden farklı bir gün olmaz. İşte o zaman firmanızın ne kadar değerli bir devops felsefesini benimsediğini anlarsınız.

Eğer daha önce yaptığınız bir hatadan dolayı veya hata yapacağınız korkusuyla yaptığınız değişikliklerin üretim ortamına gitmesine müsade edilmiyorsa, devops’u yanlış yapıyorsunuz.

İşaret #6: Sistem sorunları için başkalarını suçluyorsunuz

Devops felsefesi yoğunlukla yalın metodolojiden esinlenmiştir ve “sistemsel hatalar için başkalarını suçlamamak” devops felsefesinin insani yönünü etkileyen önemli bir yaklaşımıdır. Hatalara yaklaşım biçimi gibi sistemsel sorunlar için başkalarını suçlamaktan kaçınmak da devops’u başarıyla uygulamak için gereklidir.

Gerçek devops uygulayıcılar bir şeyler yanlış gittiğinde hatanın sistemi kullananlarda değil sistemin kendisinde olduğuna inanırlar. Yazılım geliştiricilerin ve sistem operatörlerinin iyi geçinmesi için suçlu aramayan bir kültür desteklenmelidir.

Varsayalım ki bir geliştirici uygulamasını yazar, bilgisayarında test eder ve kodu operasyona devreder. Eğer operatörler kodu üretim ortamına alırken bir problem meydana gelirse, ne operatörler yazılım geliştiriciyi kalitesiz kod geliştirmekle suçlayabilir, ne de yazılım geliştirici operatörleri sunucuları doğru yönetmemekle suçlayabilir. Devops meydana gelen bu gibi sorunları çözmeye öncelikle iki test ortamındaki farklılıkları tespit ederek başlar. Fark tespit edilince, düzeltme uygulanır ve otomatik bir test yazılarak ileride bu testi kıracak bir değişikliğin üretim ortamına gitmesi önlenmiş olur.

Eğer firmanız görev ve sorumluluklarını aşmadığı halde sırf üretim ortamında kesinti yaşandı diye birini kovuyorsa, devops’u yanlış yapıyorsunuz.

İşaret #7: Yazılım geliştirme ve operasyon gruplarınız iki ayrı dünya gibi görünüyor

Devops “developer” ve “operations” kelimelerinden peyda olmuştur. Eğer geliştiricileriniz ve operatörleriniz hala aynı dili konuşmuyorlarsa, devops’u doğru yapma şansınız yok. Devops demek işbirliği demektir. Bir takım, bir bütün olarak bir araya gelerek firmaya hedeflerine ulaşması için yardım etmektir. Eğer operasyon ekipleriniz geliştiricilerle duvarın öteki tarafına iş atmanın ötesinde iletişim kurmayı reddederse, devops hayalleriniz yalan olur.

Yazılım geliştirme ve operasyon arasındaki duvarları yıkmak devops felsefesinin en önemli kısmıdır. Daha katılımdığım tüm çalışmalar bu sonuca vardı. Duvarları yıkmak elbette yazılım geliştiricilerin operatörleri birlikte yemeğe çıkmaya zorlaması veya operatörlerin yazılım geliştiricileri düğünlerine davet etmesi gerektiği anlamına gelmiyor. Bu birbirini sevmekten ziyade işletmeyi ileriye taşıyacak ürünü ortaya çıkaran profesyonel bir takım olarak çalışmak için geçmişten ders almaktır.

Eğer firmanızda yazılım geliştirme bir katta ve operasyon bir diğerinde ise ve tek iletişim kanalı değişiklik açıklamaları ise devops’u yanlış yapıyorsunuz.

Devops bir kültür işidir

Devops her firma için değildir. Kod yönetimine daha titiz bir yaklaşımın garantilenmesi gerektiği durumlar vardır. Şirketiniz tam bir devops kültürü geliştirmemeye karar vermiş olsa bile devops felsefesinin sizin pratiklerine uygulanabilecek çokca faydası vardır.

Hepsinden öte, devops kültürel bir felsefedir. Sabır, sıkı çalışma, anlayışlı insanlar ve gerçekten gelişmesini destekleyecek bir işletme ister.

‘ın 7 signs you’re doing devops wrong başlıklı yazısından çevrilmiştir.

Çeviren: Mehmet Ali Aydın