DevOps kelimesi son on yılda o kadar çok iş ilanına girdi ki asıl anlamı kayboldu. Bugün çoğu yerde "DevOps mühendisi" denince Jenkins bakan, Kubernetes kuran ve sunucuya SSH atan kişi anlaşılıyor. Oysa DevOps bir unvan ya da araç seti değil, geliştirme ile operasyonun aynı sonuçtan sorumlu olduğu bir çalışma biçimidir. Araçlar bu biçimi mümkün kılar ama tek başına hiçbir araç DevOps yapmaz.
Bu rehberde DevOps'un ne olduğunu ve sıkça karıştırıldığı şeylerden nasıl ayrıldığını, kültür dediğimiz soyut kavramın günlük işteki somut karşılığını, sürekli entegrasyon ve teslimatın gerçekte neyi değiştirdiğini, altyapıyı kod olarak yönetmenin yerini, gözlemlenebilirliğin üç ayağını ve ekibinin nerede durduğunu ölçmene yarayan DORA metriklerini anlatacağım. Ayrıca sahada en sık gördüğüm, iyi niyetle başlayıp işi zorlaştıran uygulamalara da değineceğim.
DevOps Nedir, Ne Değildir#
DevOps'un çıkış noktası çok somut bir sorundur: geliştirici ekip hızlı değişiklik ister, operasyon ekibi kararlılık ister ve bu iki hedef birbirine karşı kurgulanmışsa taraflar birbirini yavaşlatır. Geliştirici kodu "duvarın üzerinden atar", operasyon kodu tanımadan çalıştırmaya çalışır, bir şey bozulduğunda ise kimin sorumlu olduğu tartışılır. DevOps bu duvarı kaldırıp iki tarafı da aynı sonuçtan — çalışan, güvenilir ve sık güncellenebilen bir sistemden — sorumlu tutar.
Neyin DevOps olmadığını netleştirmek, ne olduğunu anlatmaktan daha faydalıdır:
| Yaygın algı | Gerçek |
|---|---|
| Bir unvan / pozisyon | Ekiplerin çalışma biçimi |
| Belirli araçları kurmak | Araçlar sonuçtur, sebep değil |
| Operasyon ekibinin yeni adı | Sorumluluğun paylaşılması |
| Sadece otomasyon | Otomasyon önemli ama tek bileşen değil |
| Yalnızca büyük şirketlere uygun | Üç kişilik ekipte de anlamlıdır |
En yanıltıcı satır sonuncusudur. Üç kişilik bir ekipte de kodu yazan kişi onun canlıda nasıl davrandığını görmüyorsa, ölçemediği bir sistemi geliştiriyor demektir. Ölçek büyüdükçe araçlar değişir ama ilke aynı kalır.
Kültürün Somut Karşılığı#
"Kültür" kelimesi kulağa muğlak gelir; oysa DevOps kültürünün ölçülebilir, gözle görülür göstergeleri vardır. Bir ekibin bu kültüre sahip olup olmadığını birkaç soruyla anlarsın.
- Kodu yazan kişi onun canlıdaki davranışını görebiliyor mu? Loglara, metriklere ve hata izlerine erişimi var mı, yoksa her seferinde başkasından mı istiyor?
- Bir olaydan sonra suçlu mu aranıyor, sistem mi düzeltiliyor? Suçlamayan (blameless) bir olay sonrası incelemesi kültürün en net göstergesidir.
- Yayın yapmak korkulan bir olay mı, sıradan bir işlem mi? Cuma günü yayın yapmaktan çekiniyorsan, sorun cuma değil geri dönüş mekanizmanın zayıflığıdır.
- Operasyonel yük görünür mü? Nöbet, alarm ve elle yapılan işler ölçülüp azaltılıyor mu, yoksa "zaten hep böyleydi" mi deniyor?
- Küçük ve sık mı değişiyor, büyük ve seyrek mi? Değişiklik boyutu, riskin en güçlü belirleyicisidir.
Suçlamayan olay incelemesi özellikle önemlidir çünkü doğrudan bilgi akışını etkiler. Bir hatanın sebebi "Ahmet yanlış komutu çalıştırdı" olarak yazılırsa, sonraki kişi hata yaptığında bunu saklamaya çalışır. Aynı olay "üretim veritabanında yıkıcı komutu onaysız çalıştırmayı engelleyen bir korumamız yoktu" diye yazılırsa, çıktısı bir sistem iyileştirmesi olur. İkisi arasındaki fark, ekibin bir yıl sonra daha güvenli mi yoksa daha sessiz mi olacağını belirler.
Sürekli Entegrasyon ve Sürekli Teslimat#
CI/CD, DevOps'un en somut pratiğidir ve iki ayrı fikirden oluşur. Sürekli entegrasyon (CI), herkesin değişikliğini günde en az bir kez ana dala birleştirmesi ve her birleştirmenin otomatik olarak derlenip test edilmesidir. Amacı, entegrasyon acısını haftalara yayılmış tek bir kavgadan günlük küçük dokunuşlara indirmektir. Sürekli teslimat (CD) ise ana daldaki her sürümün her an yayınlanabilir durumda olmasıdır; yayın kararı teknik değil ticari bir karara dönüşür.
Basit ama gerçek bir hat şöyle görünür:
# .github/workflows/ci.yml
name: ci
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
with:
node-version: 22
cache: npm
- run: npm ci # kilit dosyasıyla birebir kurulum
- run: npm run lint
- run: npm test
- run: npm run build
image:
needs: test # testler geçmeden imaj üretilmez
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- name: İmajı değişmez etiketle üret
run: |
ETIKET="1.0.${GITHUB_RUN_NUMBER}-$(git rev-parse --short HEAD)"
docker build -t registry.firmaniz.com/api:${ETIKET} .
docker push registry.firmaniz.com/api:${ETIKET}
Buradaki iki ayrıntı, hattın işe yarayıp yaramamasını belirler. Birincisi npm ci kullanımıdır: kilit dosyasıyla package.json uyuşmazsa komut hata verir, yani CI'nin kurduğu bağımlılıklar geliştiricinin makinesindekiyle birebir aynı olur. İkincisi, imajın değişmez bir etiketle üretilmesidir; latest etiketiyle çalışan bir hatta hangi kodun canlıda olduğunu kimse kesin bilemez ve geri dönüş yapılamaz.
Hattın hızlı olması da bir kültür meselesidir. Yirmi dakika süren bir CI, geliştiricileri sonucu beklemeden başka işe geçmeye ve hatayı saatler sonra öğrenmeye iter. Beş dakikanın altındaki bir hat, hatayı hâlâ bağlam aklındayken bulmanı sağlar.
Altyapıyı Kod Olarak Yönetmek#
Sunucuyu elle kurmak, o sunucunun nasıl kurulduğunu yalnızca kuran kişinin hafızasında tutmak demektir. Altı ay sonra ikinci bir sunucu kurmak gerektiğinde ortaya çıkan farklar, hata ayıklaması en zor sorun türünü doğurur: "test ortamında çalışıyor, canlıda çalışmıyor." Altyapıyı kod olarak yönetmek bu belirsizliği ortadan kaldırır; sunucunun durumu bir depoda, sürüm kontrolü altında ve gözden geçirilebilir biçimde durur.
Basit bir Ansible görevi bile bu farkı yaratır:
- name: Web sunucusu temel yapılandırması
hosts: web
become: true
tasks:
- name: Nginx kurulu olsun
ansible.builtin.package:
name: nginx
state: present
- name: Yapılandırma şablondan üretilsin
ansible.builtin.template:
src: templates/site.conf.j2
dest: /etc/nginx/conf.d/firmaniz.conf
owner: root
mode: "0644"
notify: nginx reload # yalnızca dosya değiştiyse tetiklenir
handlers:
- name: nginx reload
ansible.builtin.service:
name: nginx
state: reloaded
Bu yaklaşımın kazandırdığı en büyük şey tekrar edilebilirliktir: aynı playbook'u çalıştırdığında aynı sonucu alırsın ve sunucu kaybolduğunda yenisini dakikalar içinde ayağa kaldırırsın. Konu yeterince geniş olduğu için ayrı bir yazıda ele aldım; Infrastructure as Code nedir yazısında bildirimsel ve emirsel yaklaşım farkını, durum dosyası yönetimini ve yapılandırma kaymasını ayrıntılı anlattım. Konteyner tarafında aynı ilkenin karşılığı Dockerfile ve compose dosyalarıdır; Docker Compose kullanımı yazısı buraya iyi bir giriş sağlar.
Gözlemlenebilirlik: Log, Metrik ve İz#
Bir sistemi hızlı değiştirebilmenin ön koşulu, değiştirdikten sonra ne olduğunu görebilmektir. Gözlemlenebilirlik üç veri türüne dayanır ve üçü birbirinin yerine geçmez:
| Veri türü | Cevapladığı soru | Tipik maliyet |
|---|---|---|
| Metrik | Ne oluyor? Hata oranı, gecikme, kaynak kullanımı | Düşük, uzun süre saklanabilir |
| Log | Tam olarak ne oldu? Olayın ayrıntısı | Orta – yüksek, hacimle büyür |
| İz (trace) | Nerede yavaşladı? İstek hangi servislerde ne kadar durdu | Yüksek, örnekleme gerekir |
Metrikle başlarsın: hata oranı yükseldi mi, gecikme arttı mı? Sonra logla o zaman aralığındaki ayrıntıya inersin. Servis sayısı arttıkça izler devreye girer, çünkü bir isteğin hangi adımda yavaşladığını yalnızca uçtan uca izleme gösterir. Log yazarken tek bir kural bile büyük fark yaratır: yapılandırılmış log yaz. Serbest metin yerine JSON satırları üret ki sorgulanabilsin.
# Yapılandırılmış logda hata oranını hızlıca çıkar
jq -r 'select(.level=="error") | .path' /var/log/uygulama.jsonl \
| sort | uniq -c | sort -rn | head -10
# Konteyner tarafında son 15 dakikanın hataları
docker logs --since 15m api 2>&1 | grep -c '"level":"error"'
Konteyner loglarını okuma ve hata ayıklama pratiğini ayrıntılı görmek istersen Docker konteyner loglarını okuma yazısı bu konuya odaklanıyor.
DORA Metrikleri ile Kendini Ölçmek#
"Biz DevOps yapıyor muyuz?" sorusunun cevabı fikir değil ölçü olmalıdır. Yıllara yayılan araştırmalar, yazılım teslim performansını dört metriğin oldukça iyi özetlediğini gösterdi. Bu dördü DORA metrikleri olarak bilinir ve güzel yanı, hepsinin var olan araçlardan üretilebilmesidir.
| Metrik | Ne ölçer | İyi yön |
|---|---|---|
| Yayın sıklığı | Ne kadar sık canlıya çıkıyorsun | Yüksek |
| Değişiklik öncü süresi | Commit'ten canlıya kadar geçen süre | Düşük |
| Değişiklik başarısızlık oranı | Yayınların yüzde kaçı sorun çıkarıyor | Düşük |
| Kurtarma süresi | Bozulduktan sonra ne kadar sürede düzeliyor | Düşük |
İlk iki metrik hızı, son ikisi kararlılığı ölçer ve asıl bulgu şudur: bunlar birbirinin zıddı değildir. Sık ve küçük yayın yapan ekipler, seyrek ve büyük yayın yapanlardan hem daha hızlı hem de daha kararlıdır; çünkü küçük değişikliğin nesi bozduğunu bulmak kolaydır ve geri almak ucuzdur. Öncü süreyi ölçmek için karmaşık bir araca da gerek yok:
# Son 20 yayın etiketinin commit'ten etiketlenmeye kadar geçen süresi
git for-each-ref --sort=-creatordate --count=20 \
--format='%(refname:short) %(creatordate:unix)' refs/tags | \
while read etiket t_etiket; do
t_commit=$(git log -1 --format=%ct "${etiket}^{commit}")
echo "$etiket $(( (t_etiket - t_commit) / 3600 )) saat"
done
Bu dört metriği ölçmeye başladığın an tartışmalar fikirden veriye kayar. "Yayın yapmak riskli" cümlesi, "değişiklik başarısızlık oranımız yüzde otuz ve kurtarma süremiz iki saat" cümlesine dönüştüğünde ne üzerinde çalışacağın da netleşir. Güvenilirlik hedeflerini sayısal olarak tanımlamak istersen SRE, SLO ve error budget yazısı bir sonraki adımdır.
Sık Görülen DevOps Yanlışları#
Araçla başlamak. Kubernetes kurup sonra "artık DevOps yapıyoruz" demek en yaygın hatadır. Üç servisi olan bir ekip için Kubernetes çoğu zaman çözdüğünden fazla sorun yaratır. Önce sorunu tanımla — yayın mı yavaş, geri dönüş mü zor, ortamlar mı tutarsız — sonra o soruna uygun en basit aracı seç.
"DevOps ekibi" kurmak. Geliştirme ile operasyon arasındaki duvarı kaldırmak için kurulan yeni takım, pratikte üçüncü bir duvar olur. Doğru yaklaşım, altyapı ekibini bir hizmet sağlayıcı ve platform kurucusu gibi konumlandırmak, sorumluluğu ürün ekiplerinde tutmaktır.
Otomasyonu belgelemeden bırakmak. Yalnızca bir kişinin nasıl çalıştırdığını bildiği bir dağıtım betiği, elle yapılan işten daha risklidir; çünkü elle yapılan iş en azından görünürdür.
Test etmeden otomatikleştirmek. Bozuk bir süreci otomatikleştirmek, onu daha hızlı bozar. Önce süreci düzelt, sonra otomatikleştir.
Güvenliği en sona bırakmak. Bağımlılık taraması, gizli anahtar sızıntısı kontrolü ve imaj taraması hattın parçası olmalıdır. Depoya kazara giren bir .env dosyasının nelere yol açtığını .git klasörü ve .env dosyası ifşası yazısında somut örnekleriyle anlattım.
Sıkça Sorulan Sorular#
DevOps mühendisi diye bir pozisyon var mı#
Piyasada bu unvanla çok sayıda ilan var ve pratikte genellikle CI/CD hatları, altyapı otomasyonu ve gözlemlenebilirlik kuran kişiyi tanımlıyor. Ancak DevOps kavramının kendisi bir rolü değil, ekiplerin çalışma biçimini anlatır. Bu unvanın tek kişiye yüklenip diğerlerinin sorumluluk almadığı bir yapı, adı DevOps olsa da eski duvarı yeniden kurar.
Küçük bir ekipte DevOps uygulamak mantıklı mı#
Evet, hatta getirisi daha hızlı görünür. Üç kişilik bir ekipte bile otomatik test çalıştıran bir CI hattı, tek komutla yapılan bir yayın ve temel metrik grafikleri birkaç günde kurulur ve haftalarca zaman kazandırır. Küçük ekipte fark, araçların daha sade seçilmesidir; karmaşık orkestrasyon yerine tek sunucuda Docker Compose çoğu zaman doğru cevaptır.
DevOps ile SRE arasındaki fark nedir#
DevOps bir felsefe ve çalışma biçimidir, nasıl uygulanacağını size bırakır. SRE ise bu felsefenin belirli bir uygulamasıdır ve somut araçlar getirir: SLI, SLO, hata bütçesi, toil ölçümü, olay müdahale süreçleri. Kabaca "SRE, DevOps'un ölçülebilir hale getirilmiş halidir" demek yanlış olmaz; ikisi birbirinin alternatifi değildir.
CI/CD kurmak ne kadar sürer#
Basit bir uygulama için çalışan bir CI hattı birkaç saatte kurulur: kod çekme, bağımlılık kurma, test çalıştırma ve imaj üretme adımları hazır şablonlarla gelir. Asıl zaman testlerin yazılmasında ve dağıtım adımının güvenli hale getirilmesinde geçer. Gerçekçi bir plan, ilk hafta CI'yi, sonraki haftalarda kademeli olarak otomatik dağıtımı devreye almaktır.
DevOps için hangi araçları öğrenmeliyim#
Önce temeller: Linux komut satırı, Git, bir betik dili ve HTTP ile ağ temelleri. Sonra konteyner (Docker), bir CI aracı ve bir altyapı otomasyon aracı. Orkestrasyona ancak servis sayısı ve ekip büyüklüğü gerektirdiğinde geç. Araç listesi moda gibi değişir ama temeller değişmez; temelleri olan biri yeni aracı bir haftada öğrenir.
Yayın sıklığını artırmak riski büyütmez mi#
Sezgiye ters gelir ama tam tersi olur. Küçük ve sık yayınlar, her seferinde az sayıda değişiklik taşıdığı için bir sorun çıktığında nedenini bulmak kolaydır ve geri dönüş ucuzdur. Riski büyüten şey, aylarca biriktirilip tek seferde yayınlanan yüzlerce değişikliktir; orada bir şey bozulduğunda hangisinin bozduğunu bulmak günler alır.
Kapanış#
DevOps'u araç listesi olarak değil, birkaç alışkanlığın toplamı olarak düşün: değişikliği küçük ve sık tut, her değişikliği otomatik olarak test et, altyapıyı hafızada değil depoda sakla, canlıdaki davranışı kodu yazan kişinin de görebildiği biçimde ölç ve olaylardan sonra insan değil sistem düzelt. Bu beşini kurduğunda hangi aracı seçtiğin ikinci derecede bir ayrıntıya dönüşür.
Bu pratikleri uygulayacağın esnek bir ortama ihtiyacın olursa tam root erişimli VDS ve bulut sunucu paketlerimizle kendi CI çalıştırıcını, kayıt defterini ve izleme yığınını kurabilirsin. İşletim sistemi bakımı, güvenlik yamaları ve izleme kurulumunu bize bırakmak istersen sunucu yönetimi hizmetimiz devreye girer; düzenli yedek ve geri dönüş noktaları için de yedekleme çözümlerimize göz atabilirsin.