Bir kontrol paneli, bütçenin aşılmasını kusursuz bir şekilde raporlayabilir, ancak bunu önlemek için hiçbir şey yapmaz. Uygulama için, maliyetli çalışmalar başlamadan önce bir karar alınması gerekir ve bu karar, aynı anda birden fazla talep geldiğinde de geçerliliğini korumalıdır.
Bu durumu gözden kaçırmak çok kolaydır: İki istek de kalan kotayı aynı şekilde okur, her ikisi de devam edebileceğine karar verir ve birlikte kiracının limitini aşar. Basit bir “bakiyeyi kontrol et, sonra modeli çağır” sıralaması bu sorunu çözmez.
Rezerv kapasitesini atomik düzeyde ayarla
Harcanabilir kotayı, limitten ödenmiş kullanım ve aktif rezervasyonların çıkarılmasıyla hesaplıyorum. Bir istek, faturalandırılabilir işlere başlamadan önce tek bir işlemle yeterli kapasiteyi rezerve etmelidir.
Sınırlı bir metin oluşturma isteği söz konusu olduğunda, rezervasyon, tahmini girdi maliyetini ve yapılandırılmış maksimum çıktı miktarını hesaba katabilir. Görüntü işleme veya ek araç adımları gibi diğer ücretlendirilebilir unsurlar için ise ayrı ve açık bir şekilde ele alınması gerekir.
Rezervasyon, bir uygulama politikasıdır; her hizmet sağlayıcının faturalandırma davranışına ilişkin bir garanti değildir. Sıkı kontroller, sınırlı aramalara, bilinen fiyatlandırmaya ve belirsizliğe yönelik bir politikaya dayanır. Bir arama, sınırsız bir iş yükü yaratabiliyorsa, hiçbir ilk tahmin bunu güvenli hale getiremez.
Kabul ve yerleşim işlemlerini birbirinden ayrı tutun
"Admission" işlemi, bir talebin başlatılıp başlatılamayacağına karar verir. "Settlement" işlemi ise fiilen tüketilen miktarı kaydeder ve kullanılmayan rezervasyonları serbest bırakır. Her iki işlem de, yeniden denemeler sırasında aynı miktarın iki kez tahsil edilmesini veya serbest bırakılmasını önlemek için sabit tanımlayıcılara ihtiyaç duyar.
Basitleştirilmiş bir kabul kuralı şöyledir:
kullanılabilir = limit - gerçekleşen_kullanım - aktif_rezervasyonlar
atomik olarak:
eğer talep edilen_rezervasyon > kullanılabilir ise:
reject_or_degrade()
aksi takdirde:
create_reservation(istek_id, talep edilen_rezervasyon)Bu sözde kod, değişmezliği ifade etmektedir. Uygulamanın hayata geçirilmesi için hâlâ işlem tabanlı güncellemeler, geçerlilik süresi yönetimi, para birimi hassasiyeti ve kalıcı bir istek defteri gereklidir.
Yarı kesilen ve belirsiz aramaları yönetme
Bağlantısı kesilen bir istemci, sağlayıcının hesaplama işlemini durdurduğunu kanıtlamaz. Zaman aşımı, çağrının boş olduğunu kanıtlamaz. Bağlantı hatası durumunda her türlü rezervasyonu derhal serbest bırakmak, yeniden denenme olasılığı en yüksek olan işlerin sayısının eksik hesaplanmasına yol açabilir.
Belirsiz kullanımları mutabakat durumunda tutuyorum. Sağlayıcının kullanım kayıtları mevcutsa, bu kullanımlar daha sonra mutabakat altına alınabilir. Aksi takdirde, ürün için ihtiyatlı bir muhasebe kuralı ve tahmini kullanım miktarının net bir şekilde görülebilmesi gerekir.
Rezervasyonlar için de çökmüş iş parçacıklarıyla ilgili kurtarma kuralları gereklidir. Bir rezervasyonun süresinin dolması durumunda, harici işin hâlâ çalışıyor olup olmadığı göz önünde bulundurulmalıdır; yalnızca kiralama zaman aşımı, sağlayıcı çağrısının sona erdiğinin kanıtı değildir.
Sürüm fiyatları ve bütçe politikası
Bir kullanım kaydı, modeli, faturalandırılabilir miktarları, fiyatlandırma sürümünü, talep kimliğini, kiracıyı ve görevi içermelidir. Eski kullanım verilerini günümüzün fiyat tablosuna göre yeniden hesaplamak, geçmiş raporların güvenilirliğini bozar.
Bilinen olmayan bir modeli sıfır maliyetli olarak değerlendirmekten kaçınırım. Ürüne bağlı olarak, fiyatı belirlenmemiş bir model, fiyatlandırması yapılandırılana kadar satışa sunulmamalı ya da ihtiyatlı bir rezervasyon almalıdır. Eksik yapılandırma, harcama iznini hiçbir şekilde sessizce genişletmemelidir.
Politika ayrıca, bir müşteri limitinin sağlayıcı maliyetine, ticari kredi bakiyesine mi yoksa başka bir kullanım birimine mi uygulandığını da tanımlamalıdır. Bunlar farklı kavramlardır ve yanıltıcı bir “bakiye” etiketini paylaşmamalıdır.
Müşteriye öngörülebilir bir yedek yol sunun
Bir uyarı eşiği, kiracının sınıra ulaşmadan önce harekete geçmesine yardımcı olabilir. Sınıra ulaşıldığında, uygulama insan desteğini koruyabilir, açık bir uyarı gösterebilir veya politika sınırları içinde kalan daha düşük maliyetli bir görev önerebilir.
Otomatik yedekleme, aynı kabul kontrolünden geçmelidir. Başka bir sağlayıcıya geçiş, kiracının bütçesini sıfırlamamalı veya bağımsız bir ödenek oluşturmamalıdır.
Eşzamanlı girişleri, yinelenen ödemeleri, işçi çökmelerini ve bilinmeyen fiyatlandırmaları test ediyorum. Önemli olan nokta, harcama kuralının yalnızca tek bir başarılı istek sırasında değil, bu koşullar altında da geçerli olmasıdır.
25 Eylül 2026 tarihinde güncellenmiştir.