1. GİRİŞ

Ölçebildiğiniz şeyi yönetirsiniz. DevOps ve platform mühendisliği disiplinlerinde bu prensip, metrik odaklı karar alma süreçlerinin temelini oluşturur. "DevOps metrikleri" terimi, yazılım geliştirme ve operasyon süreçlerinin performansını, güvenilirliğini ve verimliliğini nicel olarak ifade eden göstergeleri kapsar. Günümüzde mikroservisler, CI/CD pipeline'ları, dağıtık sistemler ve site reliability engineering (SRE) yaklaşımları yaygınlaştıkça, doğru metrikleri seçmek ve kullandığı veriyi aksiyonla bağlamak organizasyonlar için hayati önem taşır.

Neden bugün önemli?

• Hız ve güvenilirlik arasında doğru dengeyi kurmak için ölçümlere ihtiyaç var.
• Bulut maliyetleri, incident sıklığı ve kullanıcı memnuniyeti gibi alanlarda veri‑temelli iyileştirme gereksinimi artıyor.
• DORA, RED, SLI/SLO gibi standartlar endüstri tarafından kabul edilerek operasyonel mükemmellik için yol gösteriyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri — servis güvenilirliğini maddesel hedeflerle yönetmek isteyenler.
• Geliştirici ekip liderleri ve CTO'lar — teslim hızını, kaliteyi ve maliyeti dengelemek isteyenler.
• DevOps mühendisleri ve release yöneticileri — pipeline performansını ve deploy riskini ölçmek isteyenler.

Hangi problemleri çözüyor?

• Belirgin hedefler (SLO) ile incident yönetimini süreçlere bağlama.
• Performans darboğazlarını belirleme ve önceliklendirme için veri sağlama.
• Organizasyonel iyileştirmeleri ölçülebilir hale getirme (ör. DORA metrikleri ile sürekli teslimat kapasitesi ölçümü).

2. KAVRAMSAL TEMELLER

2.1 Temel terimler ve açıklamalar

SLI (Service Level Indicator)

Bir servisin performans veya güvenilirlik özelliklerini nicel olarak gösteren ham metrik (örn. başarı oranı, latency, throughput).

SLO (Service Level Objective)

SLI üzerinde tanımlı hedef; ör. "%99.9 istek başarı oranı" gibi kabul edilebilir seviyeyi belirtir.

SLA (Service Level Agreement)

Genelde müşteri veya iş birimi ile yapılan resmi anlaşma; SLO'ların ticari/hukuki karşılığıdır.

RED

Request rate, Error rate, Duration (latency) — hizmetin üretim performansını özetleyen SRE odaklı metrik seti.

DORA metrikleri

Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), Change Failure Rate — yazılım teslimat performansını ölçen dört ana gösterge.

2.2 Neden doğru metrik seçimi kritik?

Yanlış metrikler takibi yanıltıcı sonuçlara yol açar: örneğin yalnızca deploy sayısına bakmak üretkenlik artışı olarak yorumlanabilir, fakat değişiklik kalitesi veya kullanıcı deneyimi kötüleşiyorsa asıl problem gizlenir. İyi metrikler, aksiyonla bağlanabilir, manipülasyona açık değildir ve sistem davranışının altında yatan gerçek koşulları yansıtır.

3. NASIL ÇALIŞIR? — TEKNİK YAKLAŞIM VE VERİ AKIŞI

3.1 Telemetri kaynakları

• Application metrics: Prometheus gibi sistemlerden toplanan histogramlar, counters ve gauges.
• Tracing: OpenTelemetry/Jaeger/Zipkin ile dağıtık izleme (spans, traces).
• Logging: Structured logs ve log shipper'lar (Fluentd, Logstash) — olay korelasyonu için gereklidir.
• CI/CD pipeline metrikleri: pipeline süreleri, queue time, build success/failure oranları.
• Business metrics: kullanıcı etkinliği, ödeme işlemleri, conversion rate gibi iş odaklı göstergeler.

3.2 Veri hattı (Telemetry pipeline)

Telemetri verileri ham halde toplanır, işlenir ve uzun dönem saklama için uygun yerlere (metrics store, trace backend, log store) yönlendirilir. Bu pipeline tipik olarak şu adımları içerir:

1. Instrumentasyon: SDK veya otomatize agent ile uygulamaya metrik/trace/log eklenmesi.
2. Aggregation & sampling: yüksek hacimli verilerin yönetimi için histogram agregasyonu ve tracing sample stratejisi uygulanması.
3. Export & storage: Prometheus, Cortex, Thanos, OTLP/Jaeger backends, ELK gibi depolara gönderim.
4. Alerting & dashboards: Grafana/Alertmanager veya Managed APM ile SLO bazlı uyarı kuralları ve dashboard'lar oluşturma.

3.3 SLO tanımı ve uyarı stratejisi

SLO tasarımı yalnızca bir sayı belirlemek değildir — hata bütçesi (error budget) ile operasyonel kararları da etkiler. Yaygın pratik:

• SLO'yu kullanıcı odaklı bir SLI ile ilişkilendirin (örn. "%99.9 başarılı ödeme işlemi").
• Hata bütçesi tüketimi arttığında otomatik olarak önlemler alın (rate limit, feature flag geri çekme, canary rollback).
• Eşikler belirleyin: uyarı (warning) ve kritik (critical) seviyelerini ayırın; uyarılara uygun runbook'lar tanımlayın.

3.4 Metrik korelasyonu ve incident root cause

Bir incident sırasında yalnızca tek bir metrik değil, logs + traces + metrics kombinasyonu ile korelasyon yapmak gerekir. Örnek bir workflow:

1. Alert: error rate yükseldi.
2. Traces: yüksek latency olan traces sorgulanır ve gecikmeye sebep olan service identifiye edilir.
3. Logs: ilgili instance'ların hataları ve stack trace'leri incelenir.
4. CI/CD metrikleri: son deploy'lar sorgulanır — deploy sonrası hata artışı varsa rollback veya canary analizi yapılır.

4. GERÇEK DÜNYA KULLANIMLARI VE ÖRNEKLER

4.1 DORA metrikleri ile ekip olgunluğu

DORA (DevOps Research and Assessment) çalışmaları, yazılım teslimat performansını dört metrikle özetler: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), Change Failure Rate. Bu metrikler ekipleri yüksek‑performanslı (high performers) ve düşük‑performanslı (low performers) sınıflandırmak için güçlü göstergeler sunar. Örnek uygulama:

• Deployment Frequency: günlük/haftalık kaç deploy yapıldığı — otomasyon ve küçük değişikliklerle arttırılabilir.
• Lead Time: kod değişikliğinin üretime ulaşması süresi — hızlı kod incelemeleri, otomatik test ve pipeline optimizasyonu ile azaltılır.
• MTTR: incident sonrası servisin toparlanma süresi — iyi runbook ve otomatik rollback ile düşürülür.
• Change Failure Rate: değişikliklerin başarısız olma oranı — test kalitesi ve canary stratejileri ile iyileştirilir.

4.2 RED metrikleri: uygulama performans takibi

RED (Rate, Errors, Duration) metrikleri servis sağlığını anlamak için pratik bir set sunar. Örneğin bir HTTP API için:

• Rate: saniye başına gelen istek sayısı (RPS) — trafik pattern'lerini ve aşırı yük durumlarını tespit etmek için gereklidir.
• Errors: hata sayısı veya hata oranı (4xx/5xx) — regresyonları ve upstream sorunları gösterir.
• Duration: p95/p99 latency — kullanıcı deneyimindeki değişiklikleri yansıtır.

4.3 Business‑centric metrikler

Teknik metriklerin yanı sıra iş odaklı göstergeler (ör. checkout conversion rate, adım tamamlama oranı) da SLO/SLI seçiminde önemlidir. Örneğin bir e‑ticaret servisi için ödeme başarı oranı SLO olarak belirlenebilir ve teknik metrikler ile korele edilerek kök neden analizine (RCA) destek sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Veri‑temelli karar alma: tahmine dayalı değil, ölçülebilir iyileştirmeler yapılır.
• Önceliklendirme: hangi problemin daha fazla kullanıcı etkilediği açıkça görülür.
• Sürekli iyileştirme döngüsü: metrikler yol gösterir ve A/B, canary deneyleriyle test edilir.

Sınırlamalar

• Metrik spam'ı: çok fazla gösterge takip etmek anlam kaybına yol açar. "One metric to rule them" yok — fakat az ve etkili metrik tercih edilmelidir.
• Veri doğruluğu: eksik veya yanlış instrumentasyon hatalı sonuçlar üretir.
• Manipülasyon riski: ekiplerin kötü seçilmiş metrikleri optimize edip kullanıcı deneyimini bozması (Goodhart's law).

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• İlk etapta kritik SLO'ları seçin: kullanıcı deneyimini doğrudan etkileyen 1–3 SLO ile başlayın.
• Hata bütçesini (error budget) operasyonel kararlar için kullanın; ör. hata bütçesi tükeniyorsa feature rollout durdurulabilir.
• SLO'ları ve metrikleri versiyonlayın ve değişiklikleri PR ile yönetin.

Performans optimizasyonu

• Histogram ve percentile metriklerini kullanın; ortalama (mean) yanıltıcı olabilir.
• Tracing ile hot‑path'leri tespit edin ve optimizasyonu hedefleyin (p95/p99 azaltımı).

Güvenlik ve veri yönetimi

• Telemetry verilerinin gizliliğine dikkat edin: PII içerebilecek loglar maskelenmeli veya ayrılmalıdır.
• Monitoring altyapısını da SLO ile yönetin — koleksiyonun kendisi yüksek maliyet veya yük getirmemeli.

Ölçeklenebilirlik

• Metrics ingestion için scalable backends (Cortex, Thanos) kullanın; retention politikalarını belirleyin.
• Tracing sampling stratejileri uygulayın: head‑based veya tail‑based sampling ile maliyet/yarar dengesi kurun.

8. SIK YAPILAN HATALAR

• Çok fazla gösterge takip etmek — ekiplerin hangi metriğe odaklanacağı belirsizleşir.
• SLO'ları teknik ekip hedefi olarak belirlemek — SLO'lar iş odaklı olmalı ve kullanıcı deneyimiyle hizalanmalıdır.
• Veriyi aksiyonla ilişkilendirmemek — metrikler sadece rapor üretirse değersizleşir.
• Tracing/logging eksikliği — metric alert'leri geldiğinde root cause analysis yapılamaz.

9. GELECEK TRENDLER

1. AI destekli anomaly detection: Telemetry akışı içindeki anomali tespitinde ML yöntemleri daha yaygın kullanılacak; false positive azaltılacak.
2. Platform as Data: Telemetry verileri ML modelleriyle performans ve kapasite optimizasyonu için kullanılacak.
3. Distributed tracing standardizasyonu: OpenTelemetry olgunlaştıkça, end‑to‑end korelasyon ve storage optimizasyonları artacak.
4. Edge ve IoT metrikleri: Merkezi olmayan mimariler için veri toplama ve SLO yönetimi daha karmaşık ama gerekli hale gelecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi metrikler öncelikli olmalı?

   Öncelik kullanıcıyı etkileyen SLO'lar olmalıdır (ör. ödeme başarı oranı, ana sayfa yüklenme süresi). Teknik metrikler (RED) ve DORA metrikleri bu SLO'ları destekleyecek şekilde kullanılmalıdır.

2. 2. SLO ile alert arasındaki fark nedir?

   SLO hedeftir; alert ise genelde SLO'ya ulaşma riskine işaret eden kısa vadeli uyarıdır. Error budget tüketimi uyarılarına dayalı farklı seviyeler tanımlanmalıdır.

3. 3. DORA metriklerini nasıl hesaplarım?

   CI/CD sisteminizden deploy timestamp'leri, commit ile production arasındaki süreleri, incident kayıtlarını ve değişiklik başarısızlık oranlarını toplayarak hesaplanır. Birçok araç bu metrikleri otomatik çıkarır.

4. 4. Tracing tüm sorunları çözer mi?

   Tracing çok değerli içgörüler sağlar ama tek başına yetersizdir. Logs ve metrics ile birlikte korelasyon yapılmalıdır.

5. 5. SLO koymak zor mu?

   Doğru SLO belirlemek başlangıçta zordur; kullanıcı etkisini ölçen basit SLO'larla başlamak ve zamanla rafine etmek en iyi yaklaşımdır.

6. 6. Metriklerin depolanma maliyetini nasıl kontrol ederim?

   Retention politikaları, aggregation (histogram buckets), sampling ve cold/hot storage stratejileri ile maliyet kontrolü sağlanır.

7. 7. Hangi araçlarla başlamalıyım?

   Prometheus + Grafana + OpenTelemetry başlangıç için iyi bir kombinasyondur. Büyük ölçek için Cortex/Thanos/Tempo gibi scalable backends değerlendirilmeli.

8. 8. Metrikleri organizasyonel olarak nasıl yayarım?

   SLO sahipliği ekip bazında atanmalı, dashboard'lar ve error budget review'lar düzenli yapılmalıdır. Yönetim raporları DORA ve business metrikleri içermelidir.

Anahtar Kavramlar

SLI

Hizmet seviyesini gösteren ham gösterge (ör. latency, success rate).

SLO

SLI için konulan hedef; organizasyonel kabul edilebilirlik sınırı.

DORA

Yazılım teslimat performansını ölçen dört ana metrik seti.

RED

Runtime servis sağlığını özetleyen Request Rate, Error Rate ve Duration metrikleri.

Error Budget

SLO hedefi ile izin verilen hata farkı; operasyonel kararlarda kullanılır.

Öğrenme Yol Haritası

1. 0–1 ay: Prometheus, Grafana ve temel metrik kavramlarını öğrenin; uygulamaya basit RED metrikleri ekleyin.
2. 1–3 ay: OpenTelemetry ile tracing entegre edin; basit SLI/SLO tanımları yapıp dashboard oluşturun.
3. 3–6 ay: DORA metriklerini hesaplayın, error budget review süreçleri kurun ve CI/CD metriklerini toplamaya başlayın.
4. 6–12 ay: Scalable telemetry backends (Cortex/Thanos/Tempo), AI destekli anomaly detection ve platform as data yaklaşımlarını deneyin.