FinOps: Bulut Maliyet Optimizasyonu Rehberi (90 Günlük Plan)
FinOps; finans, mühendislik ve ürün ekiplerini aynı masada buluşturan bir iş disiplini.
Amaç; hızdan ödün vermeden bulut maliyetlerini görünür, tahmin edilebilir ve optimize hale getirmek. Bu rehber, ilk günden uygulanabilir pratiklerle 30/60/90 gün planını, taahhüt stratejilerini ve otomasyon tüyolarını sunar.
- FinOps Nedir? Neden Önemlidir?
- Bulut Maliyet Anatomisi
- Organizasyon ve RACI
- Görünürlük: Etiketleme (Tags) ve Muhasebeleştirme
- İlk 30 Gün: Hızlı Kazanımlar
- 60–90 Gün: Kalıcı Optimizasyonlar
- Taahhütler: RI & Savings Plan Stratejisi
- Rightsizing ve Otomasyon
- Veri Transferi (Egress) Maliyeti
- Depolama Yaşam Döngüsü
- Guardrail’ler ve Politika Tabanlı Kontroller
- KPI’lar, Dashboard ve Raporlama
- Sıkça Sorulan Sorular
FinOps Nedir? Neden Önemlidir?
FinOps, teknik ve finansal kararları gerçek kullanım verisiyle hizalar. Hedef; “daha ucuza çalıştırmak” değil, aynı bütçeyle daha fazla iş değeri üretmek.
Gerçekçi Beklenti: “Kredi kartını kapat” yaklaşımı değil; ölç–iyileştir–yinele döngüsüdür. Mimariler, yayın temposu ve SLO’lar etkilenir.
Bulut Maliyet Anatomisi
Maliyetler dört ana başlıkta toplanır: hesaplama (compute), depolama, ağ/transfer ve yönetilen servisler.
| Bileşen | Sürücü | Risk | Hızlı Çözüm |
|---|---|---|---|
| Compute | Instance tipi/ölçek | Aşırı tahsis | Rightsizing, autoscaling |
| Depolama | Katman/IOPS/Snapshot | Yetim disk/snapshot | Lifecycle, temizlik |
| Ağ/Egress | Bölge/çıkış/veri yolu | Sürpriz fatura | Yakınlık, cache, peering |
| Yönetilen Servis | Özellik/ölçek/plan | Gereğinden fazla plan | Plan düşürme, paylaşımlı |
Organizasyon ve RACI
Sahipliği net olmayan maliyet, hiçbir zaman düşmez. Aşağıdaki tablo pratik bir başlangıç RACI’sidir.
| Aktivite | R | A | C | I |
|---|---|---|---|---|
| Etiketleme standardı | Platform | CTO | Finans, Takımlar | Güvenlik |
| Taahhüt portföyü | FinOps | CFO | Takımlar | CTO |
| Rightsizing | Takımlar | Ürün Sahibi | FinOps | Finans |
Görünürlük: Etiketleme (Tags) ve Muhasebeleştirme
- Zorunlu etiketler: cost-center, owner, env, app, project
- Doğrulama: IAM/Policy ile etiketsiz kaynak açılmasın
- Raporlama: Showback → Chargeback
Örnek Etiket Standardı
- env: prod|stg|dev
- app: checkout|catalog|auth
- owner: ekip-e-posta
- cost-center: FIN-001
- data-class: public|internal|restricted
İlk 30 Gün: Hızlı Kazanımlar
- Yetim Kaynak Temizliği: EBS/disk, IP, ELB, snapshot
- Durma Zamanlaması: Dev/QA geceleri otomatik kapat
- Depolama Yaşam Döngüsü: Soğuk katmana taşı
- Plan Düşürme: Abartılı yönetilen servis planlarını küçült
- Uyarılar: Günlük eşiğe yaklaşınca bildirim
60–90 Gün: Kalıcı Optimizasyonlar
- Autoscaling politikalarını gerçek yük verisine göre ayarla
- Container node/iş yükü paketlemelerini iyileştir
- Önbellekleme/CDN ile ağ çıkışını azalt
- Veri yakınlığını gözden geçir (çok bölge → gerekli mi?)
- Taahhüt portföyünü kademeli satın al (aylık dilimler)
Taahhütler: RI & Savings Plan Stratejisi
Taahhütler; sürekli yükleri ucuza çalıştırmanın ana aracıdır. Aşırı taahhüt risktir.
| Seçenek | Esneklik | İndirim | Ne Zaman? |
|---|---|---|---|
| 1y Kısmi Ödeme | Orta | Orta | Öngörülebilir temel yük |
| 3y Tam Ödeme | Düşük | Yüksek | Stabil ve kritik servis |
| Savings Plan | Yüksek | Orta-Yüksek | Heterojen iş yükleri |
İpucu: “Önce rightsizing, sonra taahhüt.” Aksi halde gereğinden büyük kapasiteyi üç yıl kilitlemiş olursunuz.
Rightsizing ve Otomasyon
- Eşikler: CPU < 40% ve RAM < 50% ise küçültme öner
- Boyut Kütüphanesi: Uygulama türüne göre şablon boyutlar
- Otomasyon: Kapasite “schedule” + kullanım tabanlı aç/kapa
- CI/CD Entegrasyonu: Her release sonrası ölçüm
Veri Transferi (Egress) Maliyeti
Egress, sürpriz faturaların başlıca sebebidir. Mimariyi “veriyi yerinden oynatma” üzerinden düşünün.
- Aynı bölge/iç ağ önceliği, private endpoint
- CDN ve edge cache ile son kullanıcıya yakınlaş
- Analytics için örnekleme/kompresyon
- Cross-cloud trafiği minimize et
Depolama Yaşam Döngüsü
| Katman | Gecikme | Maliyet | Kullanım |
|---|---|---|---|
| Sıcak | Düşük | Yüksek | Aktif veri, DB |
| Seyrek Erişim | Orta | Orta | Log, rapor |
| Arşiv | Yüksek | Düşük | Uyumluluk/uzun saklama |
Guardrail’ler ve Politika Tabanlı Kontroller
- Bütçe Guardrail’i: Aylık üst limit ve %80 uyarı
- Kaynak Politikası: Etiketsiz kaynak oluşturmayı engelle
- Bölge Politikası: İzinli bölgeler listesi
- Boyut Politikası: Dev/QA’da maksimum instance tipi
KPI’lar, Dashboard ve Raporlama
| Metrik | Tanım | Hedef |
|---|---|---|
| Tasarruf Oranı | (Öngörülen – Gerçek) / Öngörülen | %20+ |
| Etiket Kapsamı | Etiketli kaynak / Toplam | %95+ |
| Taahhüt Kapsaması | Taahhütlü kapasite / Sürekli yük | %70–90 |
| Yetim Kaynaklar | Atıl disk/IP/LB sayısı | Aylık −%80 |
30/60/90 Gün Yol Haritası
Gün 0–30
- Etiket standardı + policy
- Temizlik ve plan düşürme
- Bütçe ve uyarılar
Gün 31–60
- Rightsizing otomasyonu
- Depolama lifecycle
- CDN/cache yaygınlaştırma
Gün 61–90
- Taahhüt portföyü (kademeli)
- Dashboard + chargeback
- DR ve çok-bölge maliyet analizi
Sıkça Sorulan Sorular
FinOps Programınızı Birlikte Kuralım
İnvekor olarak; etiket standardı, rightsizing otomasyonu, taahhüt portföyü ve dashboard’lar ile 90 günde ölçülebilir sonuçlar üretiyoruz. İş hedeflerinize uygun bir FinOps planı için bizimle iletişime geçin.
