Fatura patlamadı — her zaman bu kadardı

2026’da bulut hakkındaki her CFO konuşması aynı başlar: “iki yıl öncesine göre faturamız neden üç katı?” Rahatsız edici cevap, o harcamanın çoğunun görünmesinden aylar önce pişirildiği — kimsenin yeniden boyutlandırmadığı büyük instance’lar, hiç taşınmayan depolama katmanları, bir analitik hattı eşiği geçene kadar görünmez kalan egress ücretleri ve sessizce birleşen yönetimli servisler. Flexera State of the Cloud raporu ortalama israfı yıllık bulut harcamasının %27’si olarak koyuyor. FinOps pratikleri olmayan kurumlar %35-40’ta; olgun FinOps olan kurumlar %10-15’te. Bu fark — aylık $200K faturada — aylık $40K, yılda $480K. Çoğu mühendislik ekibinden büyük.

Bu yazı o faturanın dürüst anatomisi ve onu kontrole almaya giden 30-60-90 günlük yol. Gerçek kalemler nedir, israf nerede saklanır, olgun ekiplerin gerçekten çalıştırdığı %30-60 tasarruf sırası, self-host’un ne zaman yeniden mantıklı olduğu ve mimarinizin tek bir sağlayıcıya kilitlenmemesi. Satıcı sunumundan değil, yaptıklarımızdan yazıldı.

Bulut faturasının gerçek anatomisi

Çoğu ekip faturasını yanlış okur, çünkü compute’a çapa atarlar. Compute gürültülüdür — büyük EC2 ya da VM kalemlerini görmek kolay — ama 2026’nın kaçan faturasının hikâyesi daha az bariz dört satırda yaşar. Depolama imzaladığınız GB başı oran değil: 100 TB S3 Standard iş yükü kâğıt üzerinde ayda $2.304, 500 milyon GET isteği, 50 milyon PUT isteği ve 5 TB egress eklendiğinde gerçekte $3.200. Egress sessiz katildir — AWS $0.09/GB, GCP $0.08-$0.12/GB, Azure bölgeye göre değişir. Bir analitik hattı ayda 20 TB taşıyana ve çıkmak için $1.800 borçlu olana kadar küçük görünür. Yönetimli servisler de birikir: NAT geçitleri, yük dengeleyicileri, log toplama, KMS anahtarları, VPC uç noktaları. Tek tek unutulabilir, toplamda genelde faturanın %15-25’i. Gözlemlenebilirlik en yeni sessiz kalem: Datadog, New Relic, CloudWatch, Splunk. Log depolama ve host başı ajan ücretleri artık gözlemledikleri compute ile boy ölçüşüyor.

FinOps Foundation 2026’da kendi misyonunu bunu yansıtacak şekilde güncelledi — “bulutun değerini yönetmek”ten “teknolojinin değerini yönetmek”e; SaaS, AI, lisanslama ve veri merkezini açıkça ekleyerek. 2026 problemi sadece bulut israfı değil. Tüm maliyet yüzeyi.

Gerçekten çalışan 30 günlük FinOps playbook’u

Foundation’ın üç aşamalı çerçevesi Inform → Optimize → Operate’dir ve olgun ekipler onu tekrarlanabilir aylık bir döngü olarak çalıştırır. Birinci hafta Inform: her kaynakta maliyet dağıtım etiketlerini açın, Cost Explorer / Cost Management / Cloud Billing’i etkinleştirin ve sağlayıcılar arasında veriyi normalize edin (FinOps Foundation’ın FOCUS spesifikasyonu artık multi-cloud için standart). Harcamanızın %40’ından fazlası bir ekip, ürün ya da iş yüküne bağlanamıyorsa, faturanızın %40’ını optimize edemezsiniz — tavan budur. İkinci hafta hızlı kazançlı Optimize: yetim kaynakları silin (bağlanmamış diskler, terk edilmiş snapshot’lar, unutulmuş depolama hesapları), açıkça aşırı boyutlandırılmış instance’ları doğru boyutlayın (Compute Optimizer / Azure Advisor EC2 harcamanızın %20-30’unu sizin için bulur), yaşam döngüsü kurallarıyla nadir erişilen depolamayı daha ucuz katmanlara taşıyın (yalnız log kovağında %40-70 azalma). Üçüncü ve dördüncü hafta Operate: ekip ve ortam bazında bütçe uyarıları (staging haftalık bütçesini aştığında bir Slack bildirimi on dashboard’a bedeldir), taahhüt planlaması (çoğu modern iş yükü için EC2 RI’ların üstünde Compute Savings Plans, %66’ya kadar iskonto) ve Kubernetes maliyet görünürlüğü namespace bazında. Her operasyonel kazancı sonraki deploy’un devraldığı bir kural olur.

Paranın gerçekten yanlış gittiği yerler

Doğru boyutlandırma: çoğu iş yükü %20-40 CPU kullanımıyla çalışır çünkü biri bir zaman “performans sorunundan kaçınmak için” aşırı boyutlandırmıştı. Compute Optimizer çoğu denetimde EC2 harcamasının %20-30’unu yeniden boyutlandırılabilir olarak işaretler. Boş altyapı: hafta sonları çalışan dev ortamları, ekibinden daha uzun yaşayan dashboard’lar, emekliye ayrılmış servislere yönlendirilmiş yük dengeleyicileri — tipik olarak sevgisiz köşelerde faturanın %5-15’i. Egress ve çapraz-bulut transferi: çoğu CTO’nun “kilitlenmeden kaçınmak için” anlattığı multi-cloud hikâyesi genellikle tek bulut kurulumundan 2x pahalıya patlar — çünkü veri aralarında internet egress oranlarıyla taşınır. Zombi multi-cloud: yarı yolda taklılan bir göç aynı iş yükünü iki bulutta çalıştırır bırakır; bir servisi iki kez ödersiniz. Kubernetes: 2026’nın en büyük tek gizli kalemi. Boş node’lar, aşırı ayrılmış container istekleri, kötü ayarlanmış autoscaler’lar. Container verimsizlikleri CNCF’nin yükselen faturalara en büyük katkıları arasında. Depolama katmanı uyumsuzluğu: soğuk veri Hot katmanda oturur ya da sıcak veri Cold katmanda ve işlem ücretleri depolama oranının biriktirdiği her doları yer.

Altı kalemin arkasında aynı desen: biri kaynağı kurduğunda makul bir karar verdi ve kimse onu tekrar değerlendirmekten sorumlu değildi. FinOps cımrılık değildir. O tekrar değerlendirmeyi birinin işi haline getirmektir.

Self-host ne zaman yeniden mantıklı

Sarkacak çok uzağa savruldu. 2024-25 civarında küçük ama gerçek bir ekip dalgası belirli iş yüklerini buluttan geri taşımaya başladı — bulut çalışmayı bıraktığı için değil, ölçekte bazı iş yükleri sahip olduğunuz donanımda dramatik olarak daha ucuz olduğu için. Matematiğin üç kontrol noktası var. Compute faturanız öngörülebilir, sürdürülen yük tarafından baskın oluyorsa (24/7 %60+ kullanımda çalışan veritabanları), self-host ya da on-prem-eşdeğer reserved nadiren kaybeder. Fatura egress ise (terabyte sevkiyatı yapan analitik hatları, ML eğitim verisi, video), yer sağlama ya da bare metal hem maliyette hem gecikmede kazanır. Bir sağlayıcının bölgelerinde veri konumunu acılı kılan uyum gereksinimleriniz varsa, self-host sıklıkla ayrılmış bölgeler için pazarlık etmekten daha basit. Taşınma sinyali ideoloji değil — bulut priminin (2-4x altyapı maliyeti) artık gerçekte kullanılan esneklikle haklı gösterilmediği bir iş yükü.

Gün bir’den kilitlenme olmadan kurma

Kilitlenme sadece bir satıcı problemi değil. Bir mimari problemi. Seçenekleri açık tutan ekipler gün bir’den küçük bir kural setine uyar. Bulut neredeyse aynı yönetimli versiyonu sunduğu yerlerde taşınabilir açık kaynak ilkelleri kullanın (Aurora özellikleri özellikle gerekmedikçe Aurora yerine Postgres; ECS entegrasyonu belirleyici olmadıkça ECS yerine Kubernetes). Uygulama kodunu farklı bir sağlayıcıyla konuşabilecek bir soyutlamanın arkasında tutun — blob depolama API’leri, mesaj kuyrukları, secret depoları standartlaştırması en kolay olanlardır. Derin özel servisleri (DynamoDB, Cosmos DB, Firestore) iş yükü onlara gerçekten ihtiyaç duymadıkça ve açık bir alternatiften değerin %80’ini alamadıkça kullanmayın. Multi-cloud cevap değil — aynı iş yükünü iki bulutta çalıştırmak genelde tasarruf ettirdiğinden fazlaya patlar — ama taşınabilir cevap. Taşınabilir, gerekirse taşınabilirsiniz demektir. Bu tek seçenek bile yenilemede birincil sağlayıcınızdan tipik olarak %10-20 iskonto getirir.

Müşterilerimize söylediğimiz

DZDSoft finansal hizmetler, inşaat ve endüstri boyunca müşteriler için bulut iş yükleri çalıştırır ve her gerçek angajman aynı üç soruyla başlar: faturanız gerçekte nasıl görünüyor, her kaynağı doğru etiketleseniz ne değişirdi ve bugün bunu yeniden tasarlasanız ne self-host ederdiniz. Çoğu zaman ilk ayda hiçbir şeyi kırmadan %20-40 israf buluruz. Sonra disiplin kısmı başlar: bütçeler, taahhüt planlaması, doğru boyutlandırma otomasyonu, taşınabilir mimari incelemeleri. FinOps tek seferlik bir danışmanlık angajmanı değil. Mühendislik olgunluğu — maliyeti performans, güvenilirlik ve güvenlik ile birlikte birinci sınıf bir boyut olarak ele alma disiplini. Kontrol altında kalan faturalar, birinin işi onları okumayı kapsayan faturalardır.