DevOps Nedir? Kültür, Süreç ve Araçlar İçin Başlangıç Rehberi

DevOps nedir?

DevOps, yazılım geliştirme (Dev) ve operasyon (Ops) ekiplerinin ortak sorumluluk, otomasyon ve sürekli geri bildirimle yazılımı daha sık, daha küçük parçalarla ve daha güvenli yayınlamasını hedefleyen kültür ve uygulamalar bütünüdür. Bir araç ya da bir unvan değil, bir çalışma biçimidir.

Gündelik bir benzetme yapalım. Bir restoranda aşçılar yemeği pişirir, garsonlar servis eder. Aşçılar ile garsonlar birbirini hiç görmezse, soğumuş tabaklar ve yanlış siparişler kaçınılmaz olur. DevOps, mutfak ile salonu aynı hedef etrafında buluşturur. Böylece yemek hem hızlı hem doğru gelir.

Yazılımda mutfak, kodu yazan geliştirme ekibidir. Salon ise o kodu gerçek kullanıcıya ulaştıran ve ayakta tutan operasyon tarafıdır. Bu yazıda DevOps nedir sorusunu kültür, yaşam döngüsü ve ölçütler üzerinden yanıtlıyoruz. DevOps kültürünü, yaşam döngüsünü, temel uygulamalarını ve ölçütlerini sade bir dille anlatıyoruz. Ayrıca küçük bir ekip için başlangıç yol haritası ve kontrol listesi de veriyoruz.

DevOps neden ortaya çıktı ve eski duvar modelinden farkı ne?

Eski modelde geliştiriciler yeni özellik üretmekle ödüllendirilirdi. Operasyon ekibi ise sistemin ayakta kalmasıyla ölçülürdü. Bu iki hedef doğal olarak çatışır. Çünkü her yeni değişiklik, çalışan sistem için bir risktir.

Sonuçta ortaya "duvar" modeli çıktı. Geliştirici kodu hazırlar, duvarın üzerinden operasyona atar ve işi bitmiş sayardı. Operasyon ekibi ise kodu nasıl çalıştıracağını çoğu zaman bilmeden devralırdı. Bir sorun çıkınca iki taraf birbirini suçlardı.

DevOps bu duvarı kaldırmayı hedefler. Aynı ekip, kodun yazılmasından üretimde çalışmasına kadar sorumluluk taşır. Dolayısıyla "benim tarafımda çalışıyordu" cümlesi anlamını kaybeder.

• Duvar modelinde yayınlar nadir, büyük ve riskli olur.
• DevOps modelinde yayınlar sık, küçük ve geri alınabilir olur.
• Duvar modelinde bir hata çıkınca ekipler suçlu arar.
• DevOps modelinde bir hata çıkınca ekipler süreci düzeltir.

Bu fark, günlük işleyişte büyük bir rahatlama yaratır. Ancak bu rahatlama yalnızca araç kurarak gelmez. Önce bakış açısı değişir, ardından araçlar bu yeni bakış açısını destekler.

DevOps nedir sorusunun temelinde hangi ilkeler yatar? CALMS kavramı

DevOps ilkelerini hatırlamak için sık kullanılan bir çerçeve CALMS kısaltmasıdır. Beş kelimenin baş harflerinden oluşur: Culture (kültür), Automation (otomasyon), Lean (yalın düşünce), Measurement (ölçüm) ve Sharing (paylaşım). Bu çerçeve resmi bir standart değildir, ancak sahada işe yarayan bir hatırlatma listesidir.

1. Kültür: Ekipler hata yapmaktan korkmaz. Sorun çıktığında kişiyi değil, süreci incelerler.
2. Otomasyon: Tekrar eden işleri, yani derleme, test ve yayını, makineye bırakırsınız.
3. Yalın düşünce: İşi küçük parçalara bölersiniz. Bekleme ve gereksiz adımları azaltırsınız.
4. Ölçüm: Hissederek değil, veriyle karar verirsiniz. Yayın sıklığı ve hata oranı gibi ölçütleri izlersiniz.
5. Paylaşım: Ekipler bilgiyi, sorumluluğu ve ortak hedefleri açıkça paylaşır.

Bu beş ilke birbirine bağlıdır. Örneğin ölçüm olmadan otomasyonun işe yarayıp yaramadığını bilemezsiniz. Kültür olmadan da paylaşım kâğıt üzerinde kalır.

DevOps kültürünü günlük işte nasıl fark edersiniz?

Kültür soyut bir kelime gibi durur. Oysa günlük işte somut izler bırakır. Bir ekibin DevOps kültürüne sahip olup olmadığını birkaç basit işaretten anlayabilirsiniz.

Birincisi, geliştiriciler üretimde ne olduğunu görebilir. İzleme panolarına erişimleri vardır ve kendi kodlarının sahadaki davranışını takip ederler. İkincisi, operasyon uzmanları planlama toplantısında yer alır. Böylece ekip, bir özelliği daha tasarım aşamasında işletme açısından da tartar.

Üçüncüsü, hata sonrası toplantılar suçlama içermez. Ekip "kim yaptı" yerine "sistem bunu nasıl mümkün kıldı" sorusunu sorar. Dördüncüsü, ekip nöbet yükünü birlikte taşır. Gece gelen alarm yalnızca bir kişinin değil, sistemi yazan herkesin meselesidir.

Bu davranışlar bir gecede oluşmaz. Üstelik yalnızca yönetici talimatıyla da yerleşmez. Küçük bir ekipte bile her hafta tekrarlanan kısa bir değerlendirme toplantısı, kültürü yavaş yavaş değiştirir.

DevOps yaşam döngüsü hangi aşamalardan oluşur?

Çoğu kaynak DevOps yaşam döngüsünü sonsuzluk işaretine benzeyen bir döngü olarak gösterir. Çünkü iş bir noktada bitmez, çıktıdan elde edilen bilgi yeni planlamaya girdi olur. Kaynaklara göre aşama isimleri biraz değişir, ancak mantık aynıdır.

Bu yazıda yedi aşamayı kullanıyoruz: planla, kodla, derle, test et, yayınla, işlet ve izle. Microsoft Learn belgeleri aynı döngüyü planlama, geliştirme, teslim ve operasyon olarak dört ana evrede toplar. İki anlatım da aynı fikri taşır.

Her aşama bir sonrakini besler. Özellikle son aşama kritiktir, çünkü izlemeden gelen bilgi döngüyü yeniden başlatır.

Planlama ve kodlama aşamasında neler olur?

Planlama aşamasında ekip, bir değişikliği küçük ve ölçülebilir parçalara böler. Büyük bir özelliği tek seferde yayınlamak yerine, birkaç küçük adıma ayırırsınız. Böylece her adımı ayrı ayrı test eder, gerekirse geri alırsınız. Agile ve Scrum yöntemleri bu aşamada devreye girer; bu konuyu Agile, Scrum ve Kanban rehberimizde ayrıca ele aldık.

Kodlama aşamasının merkezinde sürüm kontrol sistemi vardır. Her değişikliği kayda geçirir, bir ekip arkadaşınıza inceletir ve ancak sonra ana koda katarsınız. Sürüm kontrolü, DevOps'un neredeyse tüm diğer uygulamalarının temelidir. Çünkü otomatik derleme, test ve altyapı tanımı da aynı depoyu kullanır.

Bu aşamada ekip, "çalışan tek bir doğru sürüm" kavramını korur. Dallanmaları kısa tutar, değişiklikleri sık birleştirir. Uzun süre ayrı yaşayan dallar, birleştirme anında büyük sürprizler çıkarır. Dolayısıyla küçük ve sık birleştirme, DevOps'un en sade alışkanlıklarından biridir.

Derleme, test ve yayın aşamasında neler olur?

Derleme aşaması, yazılan kodun çalıştırılabilir bir pakete dönüşmesidir. Bu işi elle yaparsanız her seferinde küçük farklar ortaya çıkar. Otomatik derleme ise her seferinde aynı adımları aynı sırayla izler. Yani "bende çalışıyordu" sorunu büyük ölçüde ortadan kalkar.

Test aşamasında otomatik testler devreye girer. Birim testleri küçük kod parçalarını, entegrasyon testleri ise parçaların birlikte çalışmasını kontrol eder. Test ne kadar erken çalışırsa hata o kadar ucuza düzelir. Güvenlik taramaları da bu aşamaya eklenebilir.

Yayın aşamasında paketi hazırlık ve üretim ortamlarına aşama aşama ulaştırırsınız. Bu zincirin otomatik halini CI/CD rehberimizde ayrıntılı anlattık; burada yalnızca rolünü hatırlatıyoruz. Sürekli entegrasyon değişiklikleri sık birleştirip test eder. Sürekli teslimat ise onaylı paketi güvenle yayına hazır tutar.

Yayını riskten arındırmanın bir yolu da özellik bayraklarıdır. Yeni kodu kapalı halde yayına alır, hazır olduğunda açarsınız. Bu yaklaşımı özellik bayrağı yazımızda işledik.

İşletme ve izleme aşamasında neler olur?

Yayın bittiğinde iş bitmez; asıl sorumluluk burada başlar. İşletme aşamasında ekip, sistemin kullanıcıya sürekli hizmet vermesini sağlar. Kapasite, yedekleme, güvenlik yamaları ve olay yönetimi bu aşamanın konularıdır. Yayının nerede çalıştığı, yani kendi sunucunuz mu yoksa bir bulut hizmeti mi olduğu, işletme yükünü belirler. Bu ayrımı IaaS, PaaS ve SaaS rehberimizde anlattık.

İzleme ise sistemin gerçek davranışını gözlemlemektir. Günlük kayıtları, metrikler ve izler (trace) bu gözlemin ham maddesidir. Alarmlar yalnızca gerçekten müdahale gerektiren durumlar için çalmalıdır. Aksi halde ekip alarm yorgunluğuna düşer ve önemli uyarıyı kaçırır.

İzleme verisi, yeni plana girdi olur. Örneğin bir sayfanın yavaş açıldığını görürseniz, bir sonraki döngüde onu iyileştirmeyi planlarsınız. Konunun derin tarafını gözlemlenebilirlik ve OpenTelemetry yazımızda anlattık.

DevOps nedir sorusunun cevabında hangi temel uygulamalar yer alır?

DevOps tek bir uygulama değil, birbirini tamamlayan uygulamalar demetidir. AWS ve Microsoft'un resmi belgeleri de benzer bir liste verir: sürekli entegrasyon ve teslimat, kod olarak altyapı, yapılandırma yönetimi, mikroservisler, izleme ve günlükleme, iletişim ve iş birliği. Her birini burada kısaca tanıtıyoruz; ayrıntı için ilgili yazılara bağlantı veriyoruz.

• CI/CD: Değişiklikleri otomatik derler, test eder ve yayına hazırlar. Ayrıntısı için CI/CD nedir yazımıza bakın.
• Kod olarak altyapı: Sunucu ve ağ kaynaklarını elle değil, sürüm kontrolündeki tanım dosyalarıyla kurarsınız. Bunu Infrastructure as Code rehberimizde işledik.
• Konteyner: Uygulamayı bağımlılıklarıyla birlikte paketler, her ortamda aynı çalışmasını sağlar. Başlangıç için Docker ve konteyner rehberimiz uygundur.
• Gözlemlenebilirlik: Sistemin içinde ne olduğunu dışarıdan anlamanızı sağlar.
• Mikroservis: Büyük uygulamayı bağımsız yayınlanabilen küçük servislere böler. Artıları ve eksileri için mikroservis ve monolit karşılaştırmamıza göz atın.

Bu uygulamaların hepsini aynı anda kurmanız gerekmez. Çoğu ekip sürüm kontrolü ve otomatik testle başlar, sonra CI/CD ve izleme ekler.

DORA ölçütleri nedir ve DevOps başarısını nasıl gösterir?

DORA (DevOps Research and Assessment), yazılım teslim performansını yıllardır araştıran bir programdır ve Google Cloud bünyesinde yürür. Araştırmanın en bilinen çıktısı, ekibin teslim performansını gösteren az sayıda ölçüttür. Bu ölçütleri iki gruba bölebilirsiniz: hız (throughput) ve kararlılık (stability).

DORA'nın resmi rehberine göre hız tarafında üç ölçüt vardır: değişiklik teslim süresi, yayın sıklığı ve başarısız yayından geri dönüş süresi. Kararlılık tarafında ise değişiklik başarısızlık oranı ile yeniden iş (rework) oranı yer alır. Geçmişte "dört ölçüt" diye bilinen liste zamanla genişledi. Bu nedenle güncel adları ve tanımları DORA'nın resmi ölçüt sayfasından kontrol etmenizi öneririz.

Bu ölçütlerin gücü, hız ile kararlılığı birlikte göstermesidir. Hızlı yayın yapıp sürekli bozulan bir sistem başarılı değildir. Tersine, hiç bozulmayan ama yılda bir kez yayınlanan bir sistem de çevikliğini kaybetmiştir. Dolayısıyla iki grubu birlikte izlersiniz.

Not: Bu yazıda bilerek eşik ya da hedef rakam vermiyoruz. Her ekibin bağlamı farklıdır. Önce kendi başlangıç noktanızı ölçün, sonra kendi geçmişinizle kıyaslayın. Ölçütleri ekipler arası yarış aracı yapmak, kültürü bozar.

DevOps nedir, DevSecOps ve SRE ile farkı ne?

İnsanlar komşu kavramları sık birbirine karıştırır. DevSecOps, güvenliği sürecin sonuna bırakmak yerine her aşamaya yayma fikridir. SRE (Site Reliability Engineering) ise Google'ın, operasyon işine yazılım mühendisliği yaklaşımıyla bakan disiplinidir. Google'ın SRE kitabı, iki yaklaşımı birbirinin rakibi değil, ortak ilkeleri paylaşan akrabalar olarak anlatır.

Tablodan çıkan sonuç şudur: Bu kavramlar birbirinin yerine geçmez, birbirini tamamlar. DevSecOps güvenlik odaklı bir genişlemedir. Güvenlik tarafının somut zafiyet listesi için OWASP Top 10 rehberimize bakabilirsiniz. SRE ise güvenilirliği ölçülebilir hedeflerle yöneten ayrı bir disiplindir. Google'ın SRE kitabındaki giriş bölümü bu farkı anlatır.

DevOps ile Agile aynı şey mi?

Hayır, ancak yakın akrabadırlar. DevOps nedir sorusunu Agile ile birlikte düşünmek bu yüzden faydalıdır. Agile, yazılımı nasıl planlayıp geliştireceğinize bakar. Kısa döngüler, müşteri geri bildirimi ve değişime uyum başlıca fikirlerdir. DevOps ise o yazılımın üretime nasıl ulaştığına ve orada nasıl yaşadığına bakar.

Bir benzetme düşünün. Agile, yemeği küçük porsiyonlarla ve müşteri tadına bakarak hazırlamaktır. DevOps ise o porsiyonların mutfaktan masaya hızlı, sıcak ve sorunsuz ulaşmasıdır. İkisi birlikte çalışınca ekip hem doğru ürünü üretir hem de zamanında teslim eder.

Microsoft Learn belgeleri de Agile'ı DevOps uygulamaları arasında sayar. Yani çoğu ekipte Agile, DevOps'un planlama ayağıdır. Agile yapmayan bir ekip DevOps'tan yine yararlanabilir. Ancak ikisini birlikte kullanan ekip, değer akışını baştan sona iyileştirmiş olur.

DevOps mühendisi ne yapar?

DevOps mühendisi, geliştirme ve operasyon arasındaki boşluğu kapatan kişidir. Sektör bu unvanı çok farklı anlamlarda kullanıyor. Bazı şirketlerde bu kişi yayın hattını kurar. Bazılarında bulut altyapısını yönetir. Bazılarında ise ekiplere araç ve eğitim sağlayan bir platform rolü üstlenir.

Genel olarak bu rolün sık görülen görevleri şunlardır:

• Derleme, test ve yayın hatlarını kurmak ve bakımını yapmak.
• Altyapıyı kod olarak tanımlamak ve ortamları tekrar üretilebilir kılmak.
• İzleme, günlükleme ve alarm düzenini oluşturmak.
• Güvenlik taramalarını yayın hattına entegre etmek.
• Olay anında ekiplerle birlikte sorunu çözmek ve sonrasında süreci iyileştirmek.

Önemli bir uyarı: DevOps tek kişinin işi değildir. Bir kişiye "DevOps mühendisi" unvanı vermek, ekibin geri kalanını sorumluluktan kurtarmaz. Aksi halde yeni bir duvar örersiniz. Bu yazıda maaş ya da piyasa değeri üzerine bir bilgi vermiyoruz; çünkü bu rakamlar bölgeye ve döneme göre çok değişir.

Konteyner ve orkestrasyon DevOps içinde nerede durur?

Konteyner, uygulamayı ve ihtiyaç duyduğu her şeyi tek bir pakete koyar. Böylece geliştiricinin bilgisayarında çalışan uygulama, test ve üretim ortamında da aynı şekilde çalışır. Bu, "bende çalışıyordu" cümlesinin en etkili çözümlerinden biridir. Temel kavramları Docker rehberimizde bulabilirsiniz.

Çok sayıda konteyner olunca, onları başlatan, izleyen ve yeniden başlatan bir yönetim katmanına ihtiyaç doğar. Buna orkestrasyon denir. En bilinen örnek Kubernetes'tir. İki kavramın farkını Kubernetes ve Docker farkı yazımızda açıkladık.

Bir uyarı yapalım. Konteyner ve orkestrasyon DevOps'un şartı değildir. Küçük bir uygulama, konteynersiz de sağlıklı biçimde yayınlanabilir. Bu araçlar, ekip ve trafik büyüdükçe karmaşıklığı yönetmenize yardım eder. Dolayısıyla ihtiyaç doğmadan karmaşıklık eklemeyin.

DevOps'ta güvenliği nasıl ele alırsınız?

Eski yaklaşımda güvenlik denetimi yayından hemen önce, son durak olarak yapılırdı. Bu geç kalmış bir kontroldür. Sorun bulunduğunda düzeltmek hem pahalı hem de yayını geciktirici olur. DevOps yaklaşımında güvenlik, süreci "sola" çeker; yani erken aşamalara taşır.

Bunun pratikte karşılığı basittir. Kod incelemesinde güvenlik sorusu sorarsınız. Bağımlılıkların bilinen zafiyetlerini hat içinde otomatik taratırsınız. Gizli anahtarları kodun içine değil, ayrı ve korumalı bir yerde saklarsınız. Erişim yetkilerini yalnızca gerekli olanla sınırlarsınız.

Bu uygulamalar topluca DevSecOps adını alır. Güvenlik uzmanı da planlama ve tasarım aşamasında masaya oturur. Böylece güvenlik, engel koyan taraf olmaktan çıkar; ekibin ortak kalite ölçütlerinden biri olur.

Not: Güvenlik ve uyum konularında bu yazı hukuki ya da denetim danışmanlığı değildir. Sektörünüze özgü yükümlülükler için yetkili bir uzmana danışın.

DevOps ekiplerinde roller ve sorumluluklar nasıl dağılır?

DevOps'ta kimse herkesin her şeyi yapmasını beklemez. Beklenen, herkesin işin tamamını görmesi ve ortak hedefe katkı vermesidir. Uzmanlık yerini korur. Değişen şey, uzmanların birbirinden kopuk çalışmamasıdır.

Geliştirici, yazdığı kodun üretimde nasıl davrandığıyla ilgilenir. Operasyon uzmanı, yayın hattının ve altyapının güvenilirliğini yönetir. Test uzmanı, otomatik test stratejisini tasarlar. Güvenlik uzmanı, kontrolleri hatta yerleştirir. Ürün sahibi ise önceliği belirler.

Bu rollerin kesiştiği alan, ortak sahiplik alanıdır. Örneğin bir alarm geldiğinde, "bu bizim servisimiz" diyen ekip çözüme başlar. Nöbet düzeni, olay sonrası değerlendirme ve ortak panolar bu ortak sahipliği besler.

Küçük ekiplerde bir kişi birkaç rolü birden üstlenebilir. Bu tamamen normaldir. Önemli olan, rollerin bilgi ve sorumluluk açısından birbirine kapalı kalmamasıdır.

Örnek senaryo: küçük bir e-ticaret ekibi DevOps'a nasıl geçer?

Bu bir örnek senaryodur, gerçek bir müşteri hikâyesi değildir. Küçük bir ekip, kendi online mağazasının yazılımını geliştiriyor olsun. Ekip yayını ayda bir kez, hafta sonu gecesi, elle yapıyor. Her yayından sonra birkaç küçük hata çıkıyor ve ekip pazartesiyi yamalarla geçiriyor.

Önce ekip tüm kodu sürüm kontrolüne alıyor ve her değişikliği karşılıklı inceliyor. Ardından en kritik akışlar için otomatik testler yazıyor. Örneğin sepete ekleme ve ödeme adımını artık her değişiklikte otomatik deniyor.

Üçüncü adımda yayını tek bir komuta bağlıyor ve geri alma yolunu deniyor. Yayınlar haftalık, sonra günlük hale geliyor. Her yayın küçüldüğü için hata çıksa bile ekip nedeni kolayca buluyor. Son olarak izleme kuruyor ve ödeme hatası oranı için bir alarm tanımlıyor.

Sonuçta ekip hafta sonu yayınından vazgeçiyor. Bu senaryodaki hiçbir adım pahalı bir araç gerektirmiyor. Çoğu, alışkanlık ve sıralama meselesi. Sayısal bir kazanç iddiası yapmıyoruz, çünkü sonuç her ekipte farklı çıkar.

DevOps hangi durumlarda işe yarar, sınırları nelerdir?

DevOps, sık değişen ve kullanıcıya sürekli hizmet veren yazılımlarda en çok değer üretir. Web uygulamaları, mobil uygulama arka uçları ve SaaS ürünleri tipik örneklerdir. Değişiklik ne kadar sıksa, otomasyonun kazancı o kadar büyür.

Öte yandan sınırları da vardır. Yılda bir kez güncellenen küçük bir kurumsal site için tam kapsamlı bir yayın hattı gereksiz yük olabilir. Yine de sürüm kontrolü, yedekleme ve temel izleme bu sitelerde bile faydalıdır. Yani DevOps'u "hep ya da hiç" diye düşünmeyin.

Düzenlemeye tabi alanlarda, örneğin kişisel veri işleyen sistemlerde, ekip onay ve denetim adımlarını yayın hattının içine yerleştirir. Bu durum DevOps'la çelişmez; tersine otomasyon, denetim kaydını daha sağlam kılar. Hukuki uyum konularında ise yetkili bir danışmandan destek almalısınız.

Son olarak, DevOps bir kısa yol değildir. Kusurlu bir sistemi otomatikleştirmek, sorunları yalnızca daha hızlı üretmenizi sağlar. Önce süreci anlayın, sonra otomatikleştirin.

Küçük bir ekip için DevOps yol haritası nasıl olur?

Küçük ekiplerin en büyük avantajı, duvarın zaten ince olmasıdır. Aşağıdaki yol haritası, ağır bir dönüşüm projesi olmadan başlamak isteyenler içindir. Her adım bir öncekinin üzerine oturur.

1. Tüm kodu ve yapılandırma dosyalarını tek bir sürüm kontrol sisteminde toplayın.
2. Her değişiklik için kısa bir kod inceleme alışkanlığı edinin.
3. Derleme ve temel testleri otomatik çalıştırın.
4. Hazırlık (staging) ortamını üretime olabildiğince benzer kurun.
5. Yayını tek bir komutla ya da tek bir düğmeyle yapabilir hale getirin.
6. Geri alma yolunu yayından önce deneyin.
7. İzleme ve alarmları kurun; yalnızca gerçekten önemli olanları açık bırakın.
8. Her olaydan sonra suçlamasız kısa bir değerlendirme yapın.

Bu sırayı değiştirmeyin. Test olmadan otomatik yayın kurarsanız, hataları da otomatik yayınlarsınız. Geri alma yolu olmadan sık yayın yapmak ise ekibi korkutur.

Altyapıyı kod olarak tanımlamak ve konteyner kullanmak sonraki aşamadır. Bunlara ihtiyaç doğduğunda geçin. Hepsini baştan kurmaya çalışmak ekibi yorar.

DevOps nedir diye soran ekip için başlangıç kontrol listesi nasıl olur?

Aşağıdaki liste, ekibinizin bugünkü durumunu hızlıca görmenize yardımcı olur. Her maddeye "evet", "kısmen" veya "hayır" diye yanıt verin. "Hayır" yanıtlarını bir sonraki iyileştirme adayı olarak not edin.

• Tüm kod ve yapılandırma sürüm kontrolünde mi?
• Başka biri her değişikliği gözden geçiriyor mu?
• Derleme ve testler elle değil, otomatik çalışıyor mu?
• Yayın adımları yazılı ve tekrarlanabilir mi?
• Bir yayını kısa sürede geri alabiliyor musunuz?
• Üretimde neler olduğunu görebileceğiniz bir izleme düzeniniz var mı?
• Alarmlar anlamlı mı, yoksa sürekli gürültü mü üretiyor?
• Olaylardan sonra süreç iyileştirmesi yapıyor musunuz?
• Yayın sıklığınızı ve hata oranınızı biliyor musunuz?
• Güvenlik kontrolleri yayın hattının içinde mi?

Yedi veya daha fazla "evet" iyi bir başlangıç işaretidir. Ancak bu bir puanlama sistemi değil, sohbet başlatıcıdır. Önemli olan, listeyi ekiple birlikte doldurmanızdır.

DevOps uygulamalarında sık yapılan hatalar nelerdir?

Birçok ekip DevOps yolunda aynı yerlerde tökezler. Hataları bilmek, onlardan kaçınmanın ilk adımıdır.

• Araç odaklı başlamak: Önce bir araç satın alıp sonra sürecin ona uymasını beklemek.
• Yeni bir silo yaratmak: DevOps ekibi kurup geri kalan herkesi sorumluluktan çıkarmak.
• Ölçmemek: İyileşme olup olmadığını bilmeden değişiklik yapmak.
• Güvenliği sona bırakmak: Taramaları yayından hemen önce, tek seferde yapmak.
• Her şeyi aynı anda dönüştürmek: Küçük bir pilot proje yerine tüm şirkette birden değişim ilan etmek.
• Suçlama kültürünü korumak: Olay sonrası kişiyi arayıp süreci görmezden gelmek.

Bu hataların ortak noktası, kültürün atlanmasıdır. Aracı kolayca satın alırsınız. Alışkanlık ise zamanla ve örnekle yerleşir.

Yazılım projenizde DevOps için nereden destek alabilirsiniz?

Kendi ekibiniz varsa, önce yukarıdaki kontrol listesiyle bugünkü durumunuzu çıkarın. Ardından en çok zaman kaybettiren tek adımı otomatikleştirin. Genellikle bu, elle yapılan yayın ya da elle çalıştırılan testlerdir.

Elinizde hazır bir ekip yoksa ve özel bir yazılıma ihtiyaç duyuyorsanız, Talha Aslan ve ekibi olarak özel yazılım geliştirme hizmetimizde yayın sürecini projenin başından düşünüyoruz. Mimari, sürüm kontrolü, test ve yayın akışı birlikte planlanınca sonradan eklenen yamalara gerek kalmıyor. Yine de her projenin ihtiyacı farklıdır; bu nedenle önce ihtiyacı dinleriz.

Servisler arası iletişim de yayın sürecini etkiler. Bir servisin sunduğu arayüzü değiştirdiğinizde, onu kullanan diğer servisler bozulabilir. API kavramını API nedir yazımızda anlattık. Veri katmanındaki değişiklikler de benzer risk taşır; bu seçimleri NoSQL ve SQL karşılaştırmamızda ele aldık.

DevOps nedir sorusunun kısa özeti ne?

DevOps, geliştirme ve operasyonu ortak sorumlulukla birleştiren bir çalışma biçimidir. Temelinde kültür, otomasyon, ölçüm ve paylaşım vardır. Yaşam döngüsü planlamadan izlemeye uzanır ve izlemeden gelen bilgi yeni planı besler.

Uygulama tarafında sürüm kontrolü, CI/CD, kod olarak altyapı, konteyner ve gözlemlenebilirlik öne çıkar. Başarıyı ise hız ile kararlılığı birlikte gösteren DORA ölçütleriyle takip edersiniz. DevSecOps güvenliği, SRE güvenilirliği derinleştirir; ikisi de DevOps'un yerine değil, yanına geçer.

Kısacası DevOps nedir sorusunun pratik cevabı, küçük ve sık adımlarla ilerlemektir. Yola küçük başlayın: sürüm kontrolü, otomatik test ve tek adımlı yayın. Ardından ölçün, öğrenin ve genişletin. Önemli olan, araçların değil, birlikte çalışma alışkanlığının yerleşmesidir. Kaynak olarak AWS'nin DevOps tanımını ve Microsoft Learn'ün DevOps belgesini okuyabilirsiniz. İki kaynak da tarafsız bir giriş sunar.