FinOps FOCUS spesifikasyonu AWS, Azure ve Google Cloud fatura verilerine ortak bir şema kazandırıyor

Üç fatura için tek şema

AWS, Azure ve Google Cloud üzerinde iş yükleri çalıştıran herkes, muhtemelen üç sağlayıcının faturalarını uzlaştırmak için bir电子表格 tablosu ya da SQL betiği hazırlamış — sonra bir alanın adı değiştiği anda bunun nasıl çöktüğünü izlemiştir. CloudSkill Consulting'in dev.to üzerinde yayımladığı pratik bir kılavuz, FinOps Open Cost and Usage Specification'ın (FOCUS) sorunu kaynağında çözdüğünü savunuyor: bu, fatura verileri için açık bir standart ve üç büyük bulut sağlayıcısının tamamı artık maliyet verilerini bu biçimde dışa aktarabiliyor.

Çeviri katmanları neden bozuluyor

dev.to'daki yazıya göre her sağlayıcı faturasını farklı biçimde yazıyor. Aynı kavram için sütun adları, tarih alanları ve terminoloji birbirinden farklılaşıyor; dolayısıyla finansın basit bir sorusu — geçen ay toplam compute harcaması — bile önce üç ayrı dosyayı birbiriyle eşleştirmeyi gerektiriyor. Bu iş yavaş ve hataya açık. Ortak bir şema eşleştirme adımını tamamen ortadan kaldırıyor: her fatura özdeş anlamlara sahip özdeş sütun adları kullandığında, tek bir sorgu üç bulutun tamamı için yanıt verebiliyor.

Spesifikasyon neyi tanımlıyor

FOCUS, maliyet ve kullanım verileri için sütun adlarını ve anlamlarını standartlaştırıyor. dev.to kılavuzu en sık kullanılan sütunları öne çıkarıyor: ProviderName bir ücretlendirmenin hangi buluttan geldiğini tanımlıyor, ServiceName hizmeti sağlayıcının kendi terimleriyle adlandırıyor, SubAccountId bir AWS hesabıyla, Azure aboneliğiyle veya Google Cloud projesiyle eşleşiyor, ChargePeriodStart ücretlendirmenin geçerli olduğu zamanı kaydediyor, ChargeCategory ise kullanımı satın alımlardan, vergilerden, kredilerden ve düzeltmelerden ayırıyor. İki maliyet sütunu var: faturada görüneni yansıtan BilledCost ve indirimleri ile ön ödemeli taahhütleri kapsadıkları kullanıma yayan EffectiveCost. Bir Tags sütunu ise ekip, uygulama veya ortam gibi sahiplik bilgilerini taşıyor.

Sağlayıcılar kendi sütunlarını ekleyebilir ama bunların x_ önekiyle başlaması gerekiyor. Örneğin AWS, x_ServiceCode, x_UsageType ve x_Operation sütunlarını ekliyor. Kılavuz, bu tür sütunların bulutlar arası sorguların dışında tutulmasını öneriyor. Ayrıca bir sürüm uyarısına da değiniyor: anlattığı sütun adları FOCUS 1.0'a dayanırken AWS zaten FOCUS 1.2 tablosu sunuyor ve yeni revizyonlar sütun ekleyip değerleri değiştiriyor — bu nedenle ekipler herhangi bir şeyi sabit kodlamadan önce her dışa aktarımın hangi sürümü kullandığını doğrulamalı.

Dışa aktarımları etkinleştirmek

dev.to'da anlatıldığı gibi kurulum sağlayıcıya göre değişiyor. AWS'de Billing and Cost Management altında bir Data Export oluşturup S3'e düşen FOCUS tablosunu (1.0 veya 1.2) seçiyorsunuz. Azure'da Cost Management içinde Cost and usage details (FOCUS) veri setini kullanarak, bir storage account'a yazılan bir export oluşturuyorsunuz. Google Cloud'da Billing export sayfasında bir FOCUS dışa aktarımını etkinleştirme seçeneği var; bu, gcp_billing_immutable_ önekiyle, ardından faturalandırma hesabı kimliği ve konumla adlandırılan, salt okunur bağlı bir BigQuery veri seti üretiyor ve bu veri seti gcp_billing_export_focus_ adlı artı faturalandırma hesabı kimliğinden oluşan bir tablo içeriyor. Google'ın dışa aktarımı Pre-GA Offerings Terms kapsamında hâlâ Preview durumunda; yani destek sınırlı olabilir ve Google, gelecekteki şema değişikliklerinin sorguları bozmaması için bir view üzerinden sorgulama yapılmasını öneriyor — yazar bu öneriyi üç bulutun tamamına genişletiyor.

Yazı ayrıca operasyonel hijyene de değiniyor: her dışa aktarımı halihazırda işlettiğiniz tek bir veri ambarına indirin (BigQuery, Amazon Athena veya Azure Synapse örnek gösteriliyor), her dışa aktarıma kendi tablosunu verin ve fatura verileri hesap adlarını ve etiketleri ortaya çıkardığı için okuma erişimini kısıtlayın. Yeni dışa aktarımlar genellikle içinde bulunulan ayla başlıyor, ancak bazı sağlayıcılar daha eski geçmişi talep etmenize izin veriyor.

Üç dışa aktarım üzerinde tek view

Yüklendikten sonra, ince bir view üç dışa aktarım tablosunu birleştiriyor ve yalnızca ortak sütunları adlarıyla seçiyor, SELECT * kullanmıyor; böylece sağlayıcıların eklediği x_ sütunları view'ı asla bozmuyor. Örnek bir sorgu ProviderName ve aya göre grupluyor, ChargeCategory'yi usage olarak filtreliyor ve bulut başına aylık maliyet rakamı için EffectiveCost'u topluyor. Bir sağlayıcı dışa aktarımını değiştirdiğinde view'ı bir kez düzeltmek tüm aşağı akış raporlarının çalışmaya devam etmesini sağlıyor.

Kılavuz yaygın bir tuzağa da dikkat çekerek kapanıyor: BilledCost finansla fatura uzlaştırmasına, EffectiveCost ise showback, birim maliyetler ve eğilimlere uygundur — ve bu ikisi asla toplanmamalıdır.

Neden önemli

Çok bulutlu maliyet raporlama tarihsel olarak kırılgan, elle kurulmuş çeviri katmanlarına bağlıydı. Üç hyperscaler tarafından yerel olarak desteklenen, sağlayıcıdan bağımsız açık bir şema, bu işi tek bir view'a indiriyor ve showback ile chargeback gibi pratikleri özel yapıştırma kodu olmadan erişilebilir kılıyor. Uyarılar gerçek — spesifikasyon sürümleri şimdiden farklılaşıyor ve Google'ın dışa aktarımı pre-GA durumunda — ama yön net: standartlaştırılmış fatura verisi FinOps çalışmaları için temel gereklilik haline geliyor.