FinOps, bulut harcamasını yalnızca finans ekibinin ya da yalnızca altyapı ekibinin değil, birlikte karar veren ekiplerin yönetmesi pratiğidir. Bulutta maliyet satın alma anında sabitlenmez. Her kaynak açıldığında, büyütüldüğünde ya da unutulduğunda yeniden oluşur. Bu yüzden maliyeti yıl sonunda bir bütçe satırı olarak değil, her gün verilen küçük kararların toplamı olarak okumak gerekir. Bu yazı yönetilen bulut servisleri ve bulut maliyet yönetimi sayfasının kavramsal girişini destekler. Fiyat, tasarruf oranı veya sonuç taahhüdü içermez.
Hızlı Özet
FinOps bir araç ya da tek seferlik bir indirim projesi değildir. Harcamayı görünür kılan, kimin neden harcadığını bağlayan ve kararları düzenli bir döngüye oturtan çalışma biçimidir. Başlamak için büyük bir platform gerekmez. Önce harcamanın kime ait olduğu bilinmelidir. Leon-X bulut altyapısının sahibi değildir. Fiyatlandırma ve indirim modelleri her sağlayıcıda ayrı olduğundan güncel koşullar sağlayıcının resmi dokümantasyonu ve sözleşmeyle doğrulanır.
İçindekiler
- FinOps Neden Ortaya Çıktı
- FinOps Ne Değildir
- Üç Aşamalı Döngü
- Kimler Neden Masada Olmalı
- İlk Kurulacak Düzen
- Küçük Ekipler İçin Başlangıç
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Wikimedia Commons, Aurora electronic calculator DT210 08. Fotoğraf Coyau tarafından çekilmiş olup CC BY-SA 3.0 lisansıyla yayımlanmıştır.
FinOps Neden Ortaya Çıktı
Geleneksel altyapıda maliyet büyük ölçüde satın alma kararıyla belirlenirdi. Sunucu alınır, amortisman yazılır, bütçe yıl başında netleşirdi. Bulutta ise kapasiteyi bir mühendis birkaç dakikada açabilir ve fatura bunu ay sonunda yansıtır. Karar veren kişi ile faturayı gören kişi artık farklıdır.
Bu ayrılık iki tipik sorun üretir. Finans ekibi kalemlerin neden arttığını anlayamaz. Mühendislik ekibi ise kaynağın maliyetini hiç görmeden karar verir. FinOps bu iki tarafı aynı veri üzerinde konuşturmak için doğmuştur. Hedef harcamayı kısmak değil, harcamanın iş değeriyle ilişkisini okunur hale getirmektir.
FinOps Ne Değildir
Kavram sık sık yanlış anlaşıldığı için sınırlarını yazmak yararlıdır.
FinOps yalnızca maliyet kesme çalışması değildir. Bazen doğru karar, daha fazla harcamak ve iş yükünü daha dayanıklı kurmaktır. Önemli olan kararın bilinçli ve sahipli olmasıdır.
FinOps tek bir yazılım değildir. Yazılım veriyi toplamaya yardım eder ama kimin hangi kararı vereceğini belirlemez.
FinOps bir kez yapılıp biten bir proje değildir. Ortam değiştikçe harcama da değişir, bu yüzden düzenli bir ritim gerektirir.
FinOps yalnızca büyük kurumların konusu da değildir. Kaynak sayısı az olsa bile sahipsiz bir kaynağın faturası aynı biçimde birikir.
Üç Aşamalı Döngü
FinOps Foundation çerçevesi çalışmayı üç aşamalı bir döngü olarak anlatır. Bu döngü bir kez değil, sürekli döner.
- Bilgilendirme. Harcamanın nereden geldiği görünür olur. Kaynaklar sahibine, projeye ve ortama bağlanır. Bu aşamada karar verilmez, önce doğru resim oluşur.
- Optimizasyon. Görünür olan harcamada fırsatlar aranır. Kullanılmayan kaynaklar, gereğinden büyük boyutlar ve uygun olmayan fiyatlandırma seçenekleri bu aşamada ele alınır.
- İşletme. Alınan kararlar süreç haline gelir. Bütçe, uyarı, gözden geçirme toplantısı ve sorumluluk dağılımı bu aşamada oturur.
Sıra önemlidir. Görünürlük olmadan optimizasyon tahmine dayanır. İşletme düzeni olmadan optimizasyon bir süre sonra eski haline döner. Çoğu kurum ilk aşamayı atlayıp doğrudan maliyet kısma arayışına girdiği için ikinci turda aynı noktaya gelir.
Kimler Neden Masada Olmalı
FinOps ortak karar gerektirdiği için en az üç rol aynı konuşmanın içinde yer alır.
Mühendislik ve operasyon ekibi, kaynakların neden o boyutta ve o sayıda olduğunu bilir. Finans ekibi bütçeyi, tahakkuku ve kalemlerin muhasebe karşılığını bilir. İş tarafı ise harcamanın hangi ürüne, müşteriye ya da hizmete bağlandığını söyler.
Bu üç taraf aynı raporu okumazsa her biri farklı bir sonuç çıkarır. Mühendislik ekibi kaynağı gerekli görür, finans ekibi kalemi gereksiz bulur. Ortak rapor, bu tartışmayı veriyle yürütmeyi sağlar. Bulutun operasyon modelini ve kimin neyi yönettiğini daha geniş okumak için yönetilen bulut sorumluluk matrisi yazısı yardımcı olur.
İlk Kurulacak Düzen
Büyük bir dönüşüm planı yerine dört küçük adım yeterlidir.
İlk adım sahiplik kaydıdır. Her bulut hesabı, abonelik ya da proje için bir sorumlu kişi yazılır. Sahibi olmayan kaynak sahipsiz harcamanın ilk kaynağıdır.
İkinci adım ortak sınıflandırmadır. Harcama ortama, uygulamaya ve ekibe göre ayrılabilmelidir. Bu sınıflandırma çoğunlukla kaynak etiketleriyle yapılır. Etiketlerin nasıl tasarlanacağı ayrı bir konudur ve ayrı bir yazıda ele alınır.
Üçüncü adım düzenli rapordur. Aynı rapor aynı ritimle ilgili kişilere ulaşır. İçeriği sade tutulur. Harcama nereden geliyor, geçen döneme göre ne değişti ve değişimin sahibi kim.
Dördüncü adım gözden geçirme toplantısıdır. Kısa ve sabit aralıklı bir toplantıda raporun işaret ettiği kalemler için karar alınır ve bir sahibe atanır. Karar kayda geçmezse bir sonraki toplantıda aynı konu yeniden açılır.
Küçük Ekipler İçin Başlangıç
Ayrı bir FinOps ekibi kurmak zorunda değilsiniz. Küçük bir şirkette bu iş bir mühendis ile bir finans temsilcisinin ortak sorumluluğu olabilir.
Başlangıç için önce tek bir sağlayıcının faturasını okumak, kalemlerin hangi hizmetten geldiğini listelemek ve en büyük birkaç kalemin sahibini bulmak yeterlidir. Çoklu bulut ya da hibrit kullanıyorsanız her sağlayıcının fatura yapısı farklıdır. Bu farkı multi-cloud ve hibrit ayrımı yazısında bulabilirsiniz. Mevcut bir bulut ortamında maliyet kaçaklarını tarayan daha uygulamalı bir plan için Azure ve Microsoft 365 maliyet optimizasyonu rehberine bakabilirsiniz.
Kaynak türüne göre maliyetin nereden oluştuğunu anlamak için sunucu modelini bilmek de işe yarar. Bu konu bulut sunucunun operasyon modeli yazısında anlatılır.
Yaygın Hatalar
Sahiplik atamadan rapor üretmek en yaygın hatadır. Rapor çıkar ama kimse kendini sorumlu görmez.
Yalnızca bir kez yapılan temizlik de sık görülür. Kullanılmayan kaynaklar silinir, düzen kurulmaz ve birkaç ay sonra aynı kaynaklar yeniden birikir.
Maliyeti tek başına teknik ekibe bırakmak ya da tek başına finans ekibine bırakmak da dengesiz sonuç verir. Biri iş bağlamını, diğeri kaynak bağlamını göremez.
Son olarak, her harcama artışını sorun saymak yanlıştır. Artış, iş hacmiyle birlikte geliyorsa beklenen bir sonuç olabilir. Rapor, artışı iş göstergesiyle birlikte okumalıdır.
Kontrol Listesi
- Her bulut hesabı ya da projesi için sorumlu kişi kayıtlı mı
- Harcama ortama, uygulamaya ve ekibe göre ayrılabiliyor mu
- Aynı rapor aynı ritimle ilgili kişilere ulaşıyor mu
- Finans, mühendislik ve iş tarafı aynı rapora bakıyor mu
- Gözden geçirme toplantısında alınan kararlar bir sahibe atanıyor mu
- Harcama artışı iş göstergesiyle birlikte okunuyor mu
- Sağlayıcı fiyat ve indirim koşulları resmi dokümantasyonla doğrulanıyor mu
Leon-X ile Sonraki Adım
Leon-X mevcut bulut ortamınızdaki hesap yapısını, sahiplik boşluklarını ve raporlama düzenini birlikte inceler. Hangi kalemlerin sahipsiz olduğunu, hangi harcamaların ortama ya da uygulamaya bağlanamadığını ve kararların kimde toplandığını listeler. Kapsam ve düzen ortamınıza göre netleşir. Sağlayıcıya ait fiyat ayrıntıları resmi dokümantasyon ve sözleşmeyle doğrulanır. Ayrıntılar bulut maliyet yönetimi ve FinOps danışmanlığı sayfasında yer alır. Keşif için iletişime geçin.
Sık Sorulan Sorular
FinOps ile bulut maliyet optimizasyonu aynı şey mi?
Hayır. Optimizasyon, FinOps döngüsünün bir aşamasıdır. FinOps ise görünürlük, optimizasyon ve işletme düzenini birlikte kapsayan daha geniş bir çalışma biçimidir.
FinOps için özel bir araç şart mı?
Hayır. Başlangıçta sağlayıcının kendi fatura ve maliyet raporları ile bir sahiplik tablosu yeterlidir. Araç, ortam büyüdüğünde veriyi toplamayı kolaylaştırır ama düzenin yerine geçmez.
FinOps hangi ekibin sorumluluğudur?
Tek bir ekibin değil. Mühendislik, finans ve iş tarafı ortak karar verir. Bir kişi koordinasyonu yürütebilir ama kararlar paylaşılır.
Küçük bir şirket FinOps uygulamalı mı?
Evet. Kaynak sayısı az olsa da sahipsiz kaynak aynı şekilde fatura üretir. Küçük bir şirkette kurulum birkaç sahiplik kaydı ve düzenli bir rapordan ibaret olabilir.
Sonuç
FinOps, bulut harcamasını görünür kılan, sahibine bağlayan ve kararları düzenli bir döngüye oturtan ortak çalışma biçimidir. Bilgilendirme, optimizasyon ve işletme sırasını korumak, görünürlükten önce kısıntı aramaktan daha kalıcı sonuç verir. Kapsam için bulut maliyet yönetimi ve FinOps danışmanlığı sayfasına bakabilirsiniz.
Kaynaklar
- FinOps Foundation, FinOps Framework (finops.org)
- Bulut sağlayıcıların resmi maliyet yönetimi ve faturalama dokümantasyonu
- Leon-X, bulut maliyet yönetimi ve FinOps danışmanlığı
