DevOps kültürü; geliştirme ve operasyon ekiplerinin kod commit'ten production destek'e kadar tüm yazılım yaşam döngüsünde sorumluluğu paylaştığı bir zihniyettir. Satın aldığın bir araç ya da sysadmin'leri yeniden adlandırarak oluşturduğun bir ekip değildir. Benim ortamımda asıl değişim, geliştiricilerin uptime'a önem vermeye başladığı ve ops mühendislerinin teslimat hızına kafa yorduğu anda gerçekleşiyor. Kültür kısmı, herhangi bir CI/CD pipeline'ından veya monitoring stack'inden daha fazla önem taşır. Çünkü kültür yoksa araçlar sadece mevcut siloları büyütür.
Daha önce DevOps mühendisleri neden daha fazla kazanır (https://furkanikkan.com/urun/devops-muhendisleri-neden-daha-fazla-kazaniyor-yetenek-sorumluluk-ve-risk-33) yazımda belirttiğim gibi, bu rol geniş bir yetenek yelpazesi gerektirir. Ama maaş primi var diye, kültür senden sadece ticket'ları değil sonuçları sahiplenmeni bekler.
DevOps Neden Bir Araç Seti Değil, Kültürdür
Sürekli şu hatayı görüyorum: bir yönetici DevOps hakkında bir şeyler okuyor, Jenkins satın alıyor, Kubernetes kuruyor ve dönüşüm tamam diyor. Altı ay sonra dev'lerle ops'lar arasında aynı duvar hâlâ duruyor. Geliştiriciler yine Cuma akşamı kodu duvarın öbür tarafına atıyor. Ops yine "uygulama çöktü, kodunu düzelt" diye ticket açıyor. Araç bütçesi dışında hiçbir şey değişmemiş.
Araçlar kültürü mümkün kılar ama yaratmaz. Kültür; teşvikler, ortak hedefler ve psikolojik güvenlik hakkında bir şeydir. Bir geliştirici dokunduğu her production issue için cezalandırılıyorsa, production'dan uzak durur. Operasyon yavaş release'lerden dolayı suçlanıyorsa, deployment sıklığına direnir. DevOps kültürü bu teşvikleri hizalar ki her iki taraf da aynı şeyi istesin: hızlı teslim edilen stabil yazılım.
DevOps Kültürü Dev ve Ops Arasındaki Siloları Nasıl Yıkar
Geleneksel bir düzende, organizasyon şemasının kendisi sorunu yaratır. Geliştirme ayrı bir yöneticiye, operasyon ayrı bir yöneticiye rapor verir ve KPI'ları çakışır. Geliştirme feature velocity ile ölçülür. Operasyon uptime ile ölçülür. Bu iki metrik sürekli birbiriyle savaşır.
DevOps kültürü bunu, ekiplerin tüm yaşam döngüsünü sahiplenmesini sağlayarak yazar. Sen kurarsın, sen çalıştırırsın. Kodun sabah 3'te patlarsa, incident kanalındasın. Kulağa zorlu geliyor ama işe yarıyor; çünkü geliştiriciler bunun için sayfa alacaklarını bildiklerinde daha iyi kod yazmaya başlıyorlar.
Pratikte değişen şeyler:
- Geliştiriciler sadece local log'lara değil, production metriklerine de erişebilir
- Ops mühendisleri kod yazılmadan önce mimari kararlarına dahil olur
- Olay suçlaması "kim bozdu"dan "hangi sistem bizi yanılttı"ya kayar
- Runbook'lar ve dokümantasyon operasyona özel sırlar olmaktan çıkar, paylaşılan varlıklara dönüşür
- Deployment sıklığı artarken change failure rate düşer
Ortak Sorumluluk: DevOps Kültürünün Çekirdeği
Sürekli geri döndüğüm cümle: "sen kurarsın, sen çalıştırırsın." Bu Amazon'da popülerleşti ve DevOps kültürünün en temiz açıklaması olmaya devam ediyor. Kodu yazan kişi aynı zamanda o kodun production'daki davranışından da sorumlu olduğunda, kalite çıtası doğal olarak yükselir.
Benim ortamımda bunu, geliştiricilerin kendi deployment'larını self-service pipeline'lar üzerinden yapmalarını sağlayarak destekliyorum. Onların kodunu ben deploy etmem. Platformu kurarım, CI/CD şablonlarını yazarım ve süreci dokümante ederim. Sonra deploy butonu onların olur. Bir şey kırılırsa rollback yaparlar. Ben altyapı sorunlarında yardım için oradayımım ama deployment bottleneck'i ben değilim.
Bu her iki yönde de güven gerektirir. Geliştiriciler platformun stabil olduğuna güvenir. Operasyon, geliştiricilerin yeni yetkilerini suistimal etmeyeceğine güvenir. O güven access control list'lerle değil, şeffaflık ve runbook'larla inşa edilir.
Kültürel Bir Etkinleştirici Olarak Otomasyon
Otomasyon, kültürün ve araçların buluştuğu yerdir. Her deployment'ın bir insanın sunucuya SSH çekip komutları manuel çalıştırmasını gerektirdiği bir DevOps kültürün olamaz. O model tek bir hata noktası yaratır ve siloyu güçlendirir.
Ama kültürsüz otomasyon sadece daha hızlı bir kaostur. Bozuk süreçleri otomatikleştirip DevOps diyen ekipler gördüm. 2 saat süren manuel bir deploy'u otomatikleştirmişler ve artık 10 dakikada patlıyor. Süreç zaten başından beri yanlıştı; otomasyon sadece başarısızlığı hızlandırdı.
Doğru yaklaşım, sıkıcı ve tekrar eden kısımları otomatikleştirip insanların yargı kararlarına odaklanmasını sağlamaktır:
- Altyapı sağlamak için cloud console'da tıklamak yerine
terraform apply - Her push'ta test, linting ve security scan çalıştıran CI/CD pipeline'ları
- Deployment sonrası health check'ler başarısız olduğunda otomatik rollback
- Sadece uygulama kodu değil, Infrastructure as Code review'ları da
Suçlamasız Post-Mortem'ler ve Sürekli Öğrenme
DevOps kültürünün gözden kaçan temel parçalarından biri de hatayla nasıl başa çıktığındır. Suçlama kültüründe olaylar günah keçisi üretir. DevOps kültüründe olaylar öğrenme üretir. Suçlamasız post-mortem'ler iyi olmakla ilgili değildir. Doğru bilgiyi almakla ilgilidir.
İnsanlar hatalarından dolayı cezalandırılacaklarını biliyorsa, hataları gizlerler. Amacın sistemi iyileştirmek olduğunu biliyorlarsa, olanları açıkça paylaşırlar. Bu doğrudan güvenlik kültürüyle de bağlantılıdır. Saldırganlar şirketleri nasıl ihlal eder (https://furkanikkan.com/urun/saldirganlar-sirketleri-nasil-ihlal-eder-gercek-saldiri-senaryolari-41) yazımda belirttiğim gibi, insan faktörü her zaman en zayıf halkadır. Suçlamasız bir kültür, birinin phishing tıklamasını korkudan üç gün gizlemek yerine anında raporlaması demektir.
Kullandığım post-mortem formatı basittir:
- Olay zaman çizelgesi (ne oldu, ne zaman, kim fark etti)
- Kök neden analizi (sadece teknik hata değil, süreçteki boşluk da)
- Sahipleri ve deadline'ları olan action item'lar
- Düzeltmelerin deploy edildiğini teyit etmek için follow-up review
Parmak gösterme yok. "X geliştiricisi hata yaptı" yok. Sistem o hatanın production'a ulaşmasına izin verdi. Sistemi düzelt.
Ekibinde DevOps Kültürü Oluşturmak İçin Pratik Adımlar
Ekibini DevOps kültürüne kaydırmaya çalışıyorsan, küçük başla. Tek bir çeyrekte tam bir dönüşümeye girişme. Bir acı noktası seç ve hem kültürel hem teknik bir değişiklikle ele al.
Örneğin, deployment'lar acı vericiyse ve ayda bir kez yapılıyorsa:
- Önce deployment'ları daha küçük ve daha sık yapmaya başla (teknik)
- Deploy sorumluluğunu geliştiricilere ver (kültürel)
- Pipeline'a otomatik testler ekle (teknik)
- Her deploy sonrası, başarılı olanlar dahil, suçlamasız post-mortem planla (kültürel)
Zamanla bu küçük değişiklikler birikir. Ekip, yazılımı güvenli teslim etme konusunda kas hafızası geliştirir. Production etrafındaki korku azalır. Dev ve ops arasındaki silo erir; çünkü biri org şemasını değiştirdiği için değil, günlük iş akışı doğal olarak işbirliği gerektirdiği için.
DevOps kültürü bir varış noktası değildir. Araçlar, süreçler ve işler ters gittiğinde insanlara nasıl davrandığınla ilgili her gün muhafaza ettiğin bir pratiktir. Araçlar sürekli değişecek. Kültür, araçların çalışmasını sağlayan şeydir.
İpucu: Ekibin kültürel değişime direniyorsa, monitoring ve observability ile başla. Geliştiricilere production'a görünürlük vermek, ortak sorumluluk inşa etmenin en düşük sürtünmeli yoludur. Metrikleri gördüklerinde, onları önemsemeye başlarlar.
Kapak görseli: learn_tek · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/153724200@N07/39835232960