Buluta geçiş ilk aşamada hız ve esneklik sağlar. Ancak birkaç ay sonra faturalar detaylı incelendiğinde tablo değişebilir. Geliştirme ortamları 7/24 açık kalır, kullanılmayan diskler birikir, veri çıkış maliyetleri fark edilmez, ekipler farklı servisleri paralel şekilde kullanır. Ortaya çıkan sonuç ise, tahmin edilenden daha yüksek bir aylık gider olur. Tam da bu noktada bulut maliyet optimizasyonu, yalnızca teknik bir iyileştirme değil; finans ve operasyon açısından da bir disiplindir.

FinOps yaklaşımı, bulut harcamalarını yalnızca “daha az kaynak kullan” seviyesinde ele almaz. Buradaki asıl amaç, iş değeri ile maliyeti aynı çerçevede yönetmektir. Örneğin aylık 100.000 TL bulut harcaması olan bir şirkette tek başına %10 tasarruf, yılda 120.000 TL eder. Daha da önemlisi, hangi ürünün, hangi ekibin, hangi müşteri segmentinin ne kadar altyapı tükettiği görünür hale gelir. Bu görünürlük olmadan yapılan kesintiler ise çoğu zaman performans sorunlarına ya da gizli kapasite risklerine dönüşür.

Bu rehberde KOBİ’ler ve kurumsal firmalar için uygulanabilir bir çerçeve sunacağız. Genel tavsiyeler vermek yerine; etiketleme standardı, kullanım metrikleri, rezervasyon stratejileri, otomasyon örnekleri ve yönetim modeli üzerinde duracağız.

Bulut faturası neden kontrolden çıkar?

Bulut maliyetleri tek bir nedenle artmaz. Çoğu şirkette 4 ila 6 küçük kararın birleşimi faturayı büyütür. En sık karşılaşılan durumlardan biri, kaynakların iş yüküne göre değil, “en kötü senaryo” varsayımıyla seçilmesidir. 2 vCPU ve 8 GB RAM ile rahat çalışan bir servis için 8 vCPU’lu sanal makine tahsis etmek oldukça yaygındır. Bu fark tek bir sunucuda küçük görünebilir; ancak 20 ortamda çarpan etkisi yaratır.

Bir diğer alan depolamadır. Eski snapshot’lar, yedekler, log arşivleri ve kullanılmayan blok diskler düzenli olarak temizlenmezse aylar içinde sessizce birikir. Özellikle 30, 60, 90 gün saklama politikası tanımlanmamış sistemlerde gereksiz depolama maliyetleri oluşur.

Veri transferi de birçok ekipte gözden kaçar. Aynı bulut sağlayıcısında bile bölgeler arası trafik, internet çıkışı ya da yönetilen servisler arasındaki transfer ücretli olabilir. Ay sonunda faturada görülen “egress” kalemi, uygulama sunucusundan daha hızlı büyüyebilir.

Kurumsal yapılarda öne çıkan bir başka sorun ise sahiplik eksikliğidir. Kaynak açılır, fakat sahibi tanımlanmaz. “test-api-3”, “new-db-final”, “temp-v2” gibi isimlerle yaşayan altyapılar aylar boyunca faturaya yansır. Bunların kapatılması, teknik bir konudan çok yönetişim meselesidir.

FinOps yaklaşımı: sadece tasarruf değil, karar disiplini

FinOps, finans, teknoloji ve iş birimlerini aynı veri seti etrafında buluşturan bir çalışma modelidir. Buradaki temel soru şudur: “Bu harcama iş için ne üretiyor?” Aylık 50.000 TL tutan bir analitik iş yükü, satış ekibine anlamlı veri sağlıyorsa değerlidir. Aynı iş yükü kullanılmayan bir dashboard üretip bütçe tüketiyorsa, burada optimizasyon gerekir.

KOBİ’lerde bu model daha yalın ilerleyebilir. Örneğin haftada 30 dakikalık bir maliyet gözden geçirme toplantısı yeterli olabilir. Katılımcılar genellikle teknik lider, operasyon sorumlusu ve bütçe sahibidir. Kurumsal firmalarda ise maliyet merkezi, ürün bazlı raporlama, showback ya da chargeback gibi yöntemler devreye girer.

FinOps’un pratikte işlemesi için 3 temel veri gerekir: kaynak bazlı maliyet, kullanım metriği ve iş çıktısı. Yalnızca toplam faturaya bakarak doğru karar verilemez. Örneğin bir API servisinin aylık maliyeti 12.000 TL olabilir. Aynı dönemde 24 milyon istek işliyorsa, istek başına maliyet 0,0005 TL seviyesindedir. Bu hesap, kapasite düşürmenin mantıklı olup olmadığını çok daha net gösterir.

KOBİ ile kurumsal yapı arasında ne fark var?

KOBİ’lerde öncelik genellikle hızlı görünürlük kazanmak ve gereksiz kaynakları kapatmaktır. İlk 30 gün içinde kullanılmayan diskler, atıl IP’ler, çalışma saatleri dışında açık kalan test ortamları tespit edilerek hızlı sonuç alınabilir. Kurumsal tarafta ise iş daha katmanlı ilerler. Birden fazla ekip, farklı abonelikler, güvenlik politikaları ve uyumluluk gereksinimleri vardır. Buradaki hedef yalnızca maliyeti düşürmek değil, aynı zamanda maliyeti tahmin edilebilir hale getirmektir.

İlk 30 günde uygulanacak maliyet kontrol adımları

Başlangıç için karmaşık bir dönüşüme ihtiyaç yok. İlk 30 gün içinde uygulanabilecek birkaç adım, güçlü bir temel oluşturur.

1) Etiketleme standardı belirleyin

Her kaynağın en az şu alanları taşıması gerekir: ekip, ortam, uygulama, maliyet merkezi, sahip kişi. Örnek bir etiket yapısı şöyle olabilir:

team=crm
environment=prod
application=customer-api
cost_center=IT-204
owner=ayse.yilmaz

Etiketlenmemiş kaynak, raporlanamayan kaynaktır. Raporlanamayan kaynak da yönetilemez. Kurumsal ölçekte etiket uyumluluğu için %95 hedefi makuldür; %60 seviyesinde kalan bir yapıda sağlıklı showback raporu üretmek zordur.

2) Çalışma saatine göre otomasyon kurun

Geliştirme ve test ortamları çoğu zaman 7/24 açık kalır. Oysa haftada 5 gün, günde 10 saat aktif kullanılan bir ortamın teorik kullanım oranı yaklaşık %30’dur. Akşam 20:00’de kapanıp sabah 08:00’de açılan non-prod sunucular belirgin tasarruf sağlar. Buradaki kritik nokta, istisna listesi oluşturmaktır. Gece çalışan batch süreçleri varsa otomasyon buna göre tanımlanmalıdır.

3) Rightsizing yapın

CPU, RAM, disk IOPS ve ağ kullanımını en az son 14 ila 30 gün verisiyle inceleyin. Ortalama CPU kullanımı %15 olan bir sunucu, çoğu zaman büyük seçilmiştir. Yine de yalnızca ortalamaya bakmayın. P95 veya pik kullanım pencerelerini de değerlendirin. Aksi halde ay sonu raporu iyi görünür, ancak yoğun saatlerde performans düşer.

4) Eski snapshot ve diskleri temizleyin

Snapshot’ların “dursun, lazım olur” mantığıyla tutulması maliyetlidir. 90 günden eski, geri dönüş planına dahil olmayan kopyalar gözden geçirilmelidir. Saklama politikası yazılı hale getirilmeli; örneğin günlük 7, haftalık 4, aylık 3 kopya gibi iş gereksinimine göre net sınırlar belirlenmelidir.

En yüksek etkiyi yaratan optimizasyon alanları

Her kalem aynı etkiyi yaratmaz. Saha tecrübesinde en büyük etki genellikle hesaplama, depolama, veri transferi ve lisans tarafında görülür.

Hesaplama kaynakları: rezervasyon ve esnek kapasite dengesi

Sürekli çalışan iş yükleri için rezerve kapasite ya da taahhütlü kullanım modelleri değerlendirilebilir. Ancak bu karar, en az 3 ila 6 aylık kullanım verisi görülmeden verilmemelidir. Kararlı iş yükü ile geçici kampanya yükünü aynı sepete koymak hatalı olur. Örneğin çekirdek ERP servisi 12 ay boyunca benzer düzeyde çalışıyorsa rezervasyon mantıklı olabilir. Haftalık yoğunluğu değişen veri işleme hattında ise otomatik ölçeklenme daha doğru sonuç verir.

Depolama katmanları: erişim sıklığına göre sınıf seçimi

Her veriyi hızlı disk üzerinde tutmak gerekmez. Son 7 günde sık erişilen operasyonel veri ile 1 yıldır açılmamış arşiv dosyasını aynı katmanda saklamak, bütçeyi gereksiz yere büyütür. Yaşam döngüsü kuralları burada kritik rol oynar. Örneğin 30 gün sonra daha düşük maliyetli katmana, 180 gün sonra arşive taşıma gibi kurallar operasyonu bozmadan maliyeti düşürür.

Veri çıkış maliyetleri: görünmeyen fatura kalemi

CDN kullanılmayan medya servisleri, bölgeler arası replikasyon, dış sistemlere yoğun veri akışı ve gereksiz log transferleri veri çıkış maliyetini artırır. Burada incelenmesi gereken metrik sadece GB değil, aynı zamanda yön bilgisidir: veri nereden nereye çıkıyor, hangi servisi besliyor, gerçekten gerekli mi? Özellikle çok bölgeli mimarilerde ağ topolojisi yeniden tasarlanarak kayda değer fark yaratılabilir.

Yönetişim olmadan optimizasyon kalıcı olmaz

Bir defalık temizlik faydalıdır, ancak kalıcı değildir. 60 gün sonra benzer sorunlar yeniden ortaya çıkar. Bunu önlemek için politika ve otomasyon birlikte çalışmalıdır.

Örneğin şu kurallar net biçimde yazılabilir: etiketsiz kaynak oluşturulamaz, non-prod ortamlar mesai dışında kapanır, 45 gün erişilmeyen diskler incelemeye düşer, maliyet artışı haftalık bazda %15’i aşarsa alarm üretilir. Bu eşikler şirketten şirkete değişebilir; önemli olan rastgele değil, ölçülebilir olmalarıdır.

Kurumsal ekiplerde bütçe eşikleri ürün bazında tanımlanabilir. Birim maliyet takibi burada öne çıkar. Sipariş başına maliyet, aktif kullanıcı başına maliyet, işlenen belge başına maliyet gibi göstergeler üst yönetime çok daha anlamlı veri sunar. Yalnızca “bu ay fatura arttı” demek çoğu durumda yetersiz kalır.

Raporlama: CFO ve teknik ekip aynı tabloya bakmalı

Maliyet optimizasyonu raporu iki seviyede hazırlanmalıdır. İlki yönetim özetidir. Burada aylık toplam harcama, bütçe sapması, en büyük 5 maliyet kalemi ve birim maliyet trendi yer alır. İkincisi ise teknik detay raporudur. Kaynak bazlı tüketim, etiket uyumu, atıl kaynak listesi, büyüyen servisler ve önerilen aksiyonlar bu bölümde bulunur.

Aylık raporlama çoğu zaman yeterli görülür, ancak yüksek hacimli sistemlerde haftalık takip daha güvenlidir. Özellikle kampanya dönemlerinde 7 günlük pencere kritik olabilir. 1 haftada %20 artan bir veri çıkışı, ay sonuna kadar beklenirse ciddi bütçe kaymasına dönüşebilir.

Ne zaman dış destek alınmalı?

Eğer şirketinizde birden fazla bulut hesabı varsa, ekipler kaynakları farklı standartlarla açıyorsa, aylık faturada ana artış nedeni net biçimde görülemiyorsa ya da optimizasyon denemeleri performans sorunlarına yol açıyorsa dış destek anlamlı olabilir. İyi bir FinOps yaklaşımı yalnızca rapor üretmez; mimariyi, otomasyonu, gözlemlemeyi ve yönetişimi birlikte ele alır.

devofis.net olarak bulut tabanlı özel yazılım projelerinde maliyet görünürlüğünü, etiket standardını, kullanım analizini ve otomasyon senaryolarını iş hedefleriyle birlikte kurguluyoruz. Amaç, faturayı kör biçimde kısmak değil; ölçeklenebilir ve denetlenebilir bir yapı kurmaktır. Sağlıklı bir bulut maliyet optimizasyonu çalışması, teknik borcu azaltır, bütçe sürprizlerini önler ve büyüme dönemlerinde daha güvenli karar almanızı sağlar.

Kısacası mesele, daha az sunucu çalıştırmak değildir. Önemli olan doğru kaynağı, doğru süre boyunca, doğru iş yükü için kullanmaktır. FinOps disiplini de tam olarak bunu mümkün kılar.