Power Platform PAYG: Kredi Hatası Kendiliğinden Düzeldi

Bir Power Platform ortamında kullandıkça öde (pay-as-you-go) planı açıkken, beklenmedik bir kredi yetersizliği hatası çıktı. Yapılandırmaya dokunulmadı, faturalama planı değiştirilmedi, abonelik tarafında bir işlem yapılmadı. Bir süre sonra hata kendiliğinden kayboldu ve servis normal çalışmaya devam etti.

Microsoft desteğine açılan bilette sorulan soru sadeydi: PAYG yapılandırmasında ya da faturalama modelinde beklenmedik bir değişiklik oldu mu? Gelen yanıt kibar, teknik olarak doğru ve tam da bu yazının konusu olan anlamda eksikti. Özetle üç şey söylüyordu: kendi taraflarından bakıldığında yapılandırmanın değiştiğine dair bir işaret yok; sorun bir değişiklik yapılmadan çözüldüğüne göre servis muhtemelen arka planda ek bir senkronizasyon ya da yetki yayılımı bekliyordu; Azure faturalama kayıtlarına doğrudan görüşleri olmadığı için doğrulamayı müşterinin kendi tarafından yapması gerekiyor.

Bu yanıtın her cümlesi savunulabilir. Yine de ortada şu gerçek duruyor: kendiliğinden düzelen bir hata, teşhis edilmiş bir hata değildir. Kapanan şey bilettir, dosya değil. Ve Power Platform PAYG’nin mimarisi, bu tür hataların neden çıktığını ve neden kendiliğinden kaybolduğunu aslında oldukça iyi açıklıyor.

Hatanın Kaynağı: PAYG Yetkilendirme Davranışını Değiştirir

Kullandıkça öde planını bir ödeme yöntemi değişikliği gibi düşünmek yaygın bir hata. Gerçekte yaptığı şey daha derin: bir ortamın yetkilendirme davranışını değiştirir.

Normal bir ortamda kullanıcı lisansı yoksa erişim engellenir, günlük istek hakkı aşılırsa kısıtlama devreye girer. PAYG açıldığında bu mantık tersine döner. Microsoft’un kendi dokümantasyonu bunu açıkça yazıyor: kullandıkça öde açık olan bir ortamda yüksek kullanım kısıtlaması kaldırılır ve günlük hak edişi aşan kullanım, kısıtlanmak yerine Azure aboneliğine fatura edilir. Lisanssız kullanıcı da aynı şekilde engellenmez, sayaca yazılır.

Buradan sonrası mantık yürütmeyle geliyor. Eğer bir ortam PAYG olarak işaretlenmişse ama bu bilgi henüz yetkilendirme katmanına tam olarak ulaşmamışsa, sistem o ortamı hâlâ eski kurallarla değerlendirir: lisans yok, kredi yok, erişim yok. Kullanıcı tarafında görünen şey bir kredi ya da lisans hatasıdır. Yapılandırma doğrudur, sadece henüz her yere ulaşmamıştır.

Destek mühendisinin yetki yayılımı hipotezi tam olarak bunu tarif ediyor. Bu bir savuşturma değil, sistemin bilinen bir davranış biçimi. Sorun hipotezde değil, hipotezin doğrulanmadan biletin kapanmasında.

PAYG Aslında Nasıl Çalışır: İki Kontrol Düzlemi

Kullandıkça öde planının tek bir sistem gibi görünmesi yanıltıcı. Aslında birbirinden bağımsız iki kontrol düzlemi ve aralarında bir köprü var.

Birinci düzlem Power Platform tarafı: kiracı, ortam ve o ortamdaki uygulamalar, akışlar, Dataverse verisi. İkinci düzlem Azure tarafı: abonelik, kaynak grubu ve faturalama planı oluşturulduğunda otomatik yaratılan Power Platform account kaynağı. İkisini birbirine bağlayan şey faturalama planıdır.

Bu bağlantının üç yapısal özelliği var ve üçü de sorun çıkarabilir. İlki, bir ortam aynı anda yalnızca tek bir faturalama planına bağlı olabilir. İkincisi, plan yalnızca Production ve Sandbox ortamlarında kurulabilir; Default, Developer, Trial ve Teams ortamları desteklenmez. Üçüncüsü, Azure aboneliği aynı kiracıda olmak zorundadır.

Ve en sinsi ayrıntı: Azure tarafında yaratılan Power Platform account kaynağı portalda varsayılan olarak görünmez. Gizli tip olarak işaretlidir; kaynak listesinde gizli türleri göster filtresini açmadan bulunamaz. Faturalama planını Power Platform tarafından sildiğinizde de bu kaynak otomatik silinmez, aboneliğin içinde öylece kalır.

Arka Plan Senkronizasyonu Gerçek mi? Belgelenmiş Süreler

Yetki yayılımı hipotezi kulağa belirsiz geliyor, ama köprünün diğer yönü için Microsoft somut rakamlar veriyor. Kullanım verisi Azure’a sürekli akmaz; toplu olarak, günde üç kez gönderilir.

Tablodaki son satır bu vakanın can alıcı noktası. Kullanım raporlamasının gecikmesi belgelidir, ölçülebilir ve beklenebilir. Yetkinin geç ulaşmasının ne kadar sürdüğü ise hiçbir yerde yazmaz. Destek mühendisi de zaten bunu söylüyor: muhtemelen böyle oldu, ama emin değilim.

Bu asimetri önemli. Faturanın geç görünmesi normaldir ve paniğe gerek yoktur. Yetkinin geç ulaşması ise kullanıcının yüzüne hata olarak çarpar ve ne kadar süreceği bilinmez. İkisini aynı torbaya koyup arka plan senkronizasyonu demek, sorunun bir yarısını görünmez kılar.

Kanıt Penceresi: Bilet Kapanmadan Önce Bakılmalı

Buradan somut bir operasyonel sonuç çıkıyor. Hata göründüğü anda Azure Cost Management’ta o kullanıma ait veri henüz yoktur. Bakarsanız boş görürsünüz ve bu boşluk hiçbir şey kanıtlamaz.

Olağan refleks şudur: hata görülür, bir süre beklenir, hata kaybolur, bilet kapatılır. Bu sırayla ilerlendiğinde doğrulama için gereken veri tam da bilet kapandıktan sonra oluşur. Sorun çözülmüş gibi görünür ama elde hiçbir kayıt kalmaz.

Doğru sıra ise şudur: hata görülür ve o anda ekran görüntüsü, zaman damgası, ortam kimliği kaydedilir. Hata kaybolsa bile bilet açık bırakılır. Yirmi dört saat sonra Azure tarafındaki veri kontrol edilir. Ancak ondan sonra kapatılır.

Aradaki fark tek bir soruya indirgenebilir: aynı hata iki hafta sonra tekrar ederse, elinizde önceki sefere ait ne var? İlk sırada hiçbir şey yoktur. İkinci sırada bir zaman çizelgesi, bir kullanım kaydı ve karşılaştırılabilir bir tablo vardır.

Doğrulama Reçetesi: Altı Adım

Bilet kapanmadan önce ya da hata tekrar ettiğinde yapılacaklar, en hızlıdan en yavaşa doğru:

1. Ortam tipini doğrulayın. Production veya Sandbox olmalı. Default ya da Developer ortamında PAYG zaten çalışmaz; hata yayılım gecikmesi değil, yapılandırma hatasıdır.
2. Ortamın plana bağlı olduğunu görün. Power Platform yönetim merkezinde faturalama planını açın ve ortamlar listesinde ilgili ortamın gerçekten yazdığını teyit edin. Planı oluşturup ortamı eklemeyi atlamak sık rastlanan bir adım atlamasıdır.
3. Azure tarafındaki kaynağı bulun. Abonelik ve kaynak grubunda gizli türleri göster filtresini açın. Plan adıyla aynı isimde bir Power Platform account kaynağı görmeniz gerekir.
4. Aynı kaynağı komut satırından da teyit edin. Portal filtresi unutulabilir, komut ya çıktı verir ya vermez:

az resource list \\
--subscription <ABONELİK-KİMLİĞİ> \\
--query "[?contains(type,'PowerPlatform')]" \\
--output table

5. Kullanım raporunu indirin. Yönetim merkezindeki faturalama planı sayfasından indirilebilir rapor, hangi ortamın hangi sayacı tükettiğini gösterir. Azure Cost Management bu kırılımı vermez, yalnızca toplam tutarı gösterir.
6. Yirmi dört saat sonra Cost Management’a bakın. Filtreyi plan adıyla aynı ismi taşıyan Power Platform account kaynağına kurun. Veri geldiyse köprü çalışıyor demektir.

Hangi Sayaç Neyi Ölçüyor

Kredi ya da kapasite hatası aldığınızda ilk sorulacak soru şudur: hangi sayaç devrede? Kullandıkça öde tek bir ücret değil, birbirinden bağımsız çalışan bir sayaç kümesidir ve bir ortam plana bağlandığında bunların tümü aynı anda etkinleşir. Aralık 2024’ten itibaren planı kurarken hangi ürün sayaçlarının açılacağını seçmek mümkün; Dataverse sayacı ise varsayılan olarak açık gelir.

Fiyatlar Microsoft’un liste değerleridir; kurumsal sözleşmelere göre farklılaşır. Tablodaki asıl bilgi rakamlar değil, kimin sayılmadığıdır. Kullanıcı başına Power Apps lisansı olan biri uygulama sayacına hiç girmez. Microsoft 365 lisansıyla yalnızca standart bağlayıcı kullanan biri de sayılmaz; aynı kişi premium bağlayıcıya dokunduğu anda sayılmaya başlar. Yani bir ortamda PAYG açık olması, oradaki herkesin ücretlendirileceği anlamına gelmez.

Bunun teşhis açısından sonucu şu: beklenmedik bir kredi hatası gördüğünüzde, hatayı alan kullanıcının lisans durumunu da not edin. Lisanslı bir kullanıcının sayaca düşmemesi gerekirken düşüyorsa sorun yayılım gecikmesinden farklı bir yerdedir.

Yol Boyunca Çıkabilecek Tuzaklar

Doğrulama sırasında karşılaşılabilecek, çoğu belgelenmiş ama az bilinen davranışlar:

Bu listedeki ilk madde özellikle can sıkıcı. Bir sorunu doğrularken bastığınız zeminin kendisi kaygansa, doğrulama da güvenilmez hale gelir. Hak ediş değerinin sıfır görünmesi gerçek bir sorun değil, raporlama hatasıdır; bunu bilmeden bakan biri olmayan bir problemi kovalamaya başlar.

Destek Yanıtını Okumak

Son olarak, bu vakanın teknik olmayan tarafı. Kurumsal destek yanıtları belirli bir dil kullanır ve bu dili doğru okumak, yanıtın kendisinden daha faydalıdır.

Bizim tarafımızdan bakıldığında bir işaret görünmüyor cümlesi, değişiklik olmadı demek değildir. Görünürlüğün sınırını tarif eder. Muhtemelen şu olmuştur ifadesi bir bulgu değil, bir hipotezdir ve doğrulanmamıştır. Kendi tarafınızdan doğrulamanızı öneririm cümlesi ise kanıt yükünün size geçtiği andır.

Bunların hiçbiri kötü niyet değil. Destek mühendisi gerçekten de Azure faturalama kayıtlarınızı göremez ve görmediği bir şey hakkında kesin konuşmaması doğru davranıştır. Sorun, bu cümlelerin çözüldü olarak okunmasında. Bilet kapanır, kayıt kalmaz, aynı hata üç hafta sonra tekrar eder ve her şey baştan başlar.

Pratik kural sade: kendiliğinden düzelen her olayın bir kapanış notu olsun. Ne zaman başladı, ne zaman bitti, o sırada hangi veri mevcuttu, yirmi dört saat sonra ne göründü. Dört satırlık bir not, bir sonraki sefer bir saatlik araştırmayı ortadan kaldırır.

Kaynaklar

Bu yazıdaki süreler, sayaç birimleri ve kısıtlama davranışı Microsoft’un resmî dokümantasyonundan alındı. Dördü de zaman zaman güncelleniyor; özellikle önizleme aşamasındaki sayaçların durumu değişebiliyor, bu yüzden kritik bir karar öncesinde tarihlerine bakmakta fayda var.

• Set up a pay-as-you-go plan — Planı kimin kurabileceği, ortamın plana nasıl bağlandığı ve Azure tarafındaki gizli tip kaynağının nasıl görüneceği burada anlatılıyor.
• View usage and billing for pay-as-you-go plan — Yazının omurgasını oluşturan iki cümle burada: kullanımın günde üç kez raporlanması ve maliyet ekranında görünmesinin yirmi dört saati bulabilmesi.
• Pay-as-you-go meters — Sayaç tablosunun kaynağı. Hangi lisansın hangi sayacı devre dışı bıraktığını örneklerle veriyor.
• Issues and FAQs about pay-as-you-go plans — Bilinen sorunlar listesi. Hak edişin sıfır görünmesi ve kısıtlamanın kalkması maddeleri buradan.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Copilot Bütçe Artış Talepleri Nasıl Yönetilir?16 Eyl 2026

GPT-6 Astra GitHub Copilot’ta Kullanıma Sunuldu4 Eyl 2026

Teams için Ajan Tasarımı: Grup Sohbetinde Gürültüyü Yönetmek13 Ağu 2026

Microsoft Graph PowerShell 5.1 Desteği Ne Değişti?16 Eyl 2026