🚨 Yaygın Azure Hataları

Yaygın Azure Hataları: Azure hataları, Java'nın checked exception modelini yansıtan bir kalıba sahiptir: hata adları açıklayıcıdır, ama API'nin neyi reddettiğini anlatır — niyeti

Azure hataları, Java'nın checked exception modelini yansıtan bir kalıba sahiptir: hata adları açıklayıcıdır, ama API'nin neyi reddettiğini anlatır — niyetinin neden başarısız olduğunu değil. `AuthorizationFailed`, Azure'un `AccessControlException`'ıdır: RBAC rol sistemi kimliğinin bu hakka sahip olmadığını söyledi, ve bu neredeyse hiçbir zaman kimliğin kendisiyle değil, hangi rolün hangi kapsama atandığıyla ilgilidir. `StorageAccountAlreadyTaken` ise Azure'un `IllegalArgumentException`'ıdır: kısıtlama (global olarak benzersiz ad) platform seviyesinde var ve müzakere edilemez. Ama anlayışı derinleştiren soru şudur: Azure neden basit kullanıcı başına izinler yerine resource group kapsamlarında RBAC rolleri kullanır? Çünkü sabah QA pipeline'ınızı çalıştıran Service Principal'in öğleden sonra production veritabanlarını silebilmemesi gerekir — RBAC kapsam sınırları bu ayrımı uygulama seviyesinde değil platform seviyesinde uygular. Java analojisi: RBAC kapsamları, Java modül sistemi sınırları gibidir (`module-info.java`) — JVM'e sahip olsan bile açıkça export edilmeyen şeye erişemezsin. Bu hataları yanlış okumanın QA olayı tutarlı biçimde aynıdır: bir pipeline gece 11'de sürümden önce `AuthorizationFailed` ile başarısız olur, on-call mühendisi "sadece çalıştırmak için" subscription seviyesinde `Contributor` rolü ekler ve ertesi sabah QA pipeline'ının hiç erişmemesi gereken production ortamına yazma yetkisi vardır.

Azure kimliğinin (kullanıcı veya service principal) gerekli RBAC rolü yok. Azure, Role-Based Access Control kullanır — bir resource group'un Owner'ı bile başka bir resource group'a erişemez.

Azure storage account adları global olarak benzersiz olmak zorundadır (3-24 küçük harf alfanümerik karakter). Dünya genelinde herhangi bir Azure tenant'taki biri "mytestreports"u zaten almış.

Azure DevOps, yeni özel projeler için politikasını değiştirdi: ücretsiz Microsoft hosted agent paralelliği manuel onay gerektirir. Bu, özel repo çalıştıran yeni oluşturulan organizasyonları etkiler.

Seçilen VM boyutu, seçilen region'da mevcut kapasiteye sahip değil. Azure, region ve boyuta göre değişen kapasiteye sahiptir. Bu, GPU instance'ları ve yoğun region'lardaki belirli VM boyutlarında yaygındır.

Azure AD tenant'ı MFA gerektiren Conditional Access policy'lerine sahip. "az login" interactive modu MFA tetikler, ancak gözetimsiz script'ler MFA'yı interaktif olarak tamamlayamaz.

Azure Container Instance belleği tükendi. Chrome/Selenium browser'lar bellek yoğundur. 1GB RAM'li container, 2-3'ten fazla paralel browser session için yetersizdir.

Pipeline, AzureCLI@2 task kullanıyor ancak script daha yeni bir versiyonun sözdizimini kullanıyor. Ya da self-hosted agent'ta Azure CLI yüklü değil. Microsoft hosted agent'lar CLI versiyonlarını periyodik olarak günceller.

Shared Access Signature (SAS) token veya access key süresi dolmuş, yetersiz izinlere sahip veya istek IP'si izin verilen IP aralığında değil. Ayrıca storage account güvenlik duvarı erişimi engellediğinde de olur.

AKS cluster'ı test pod'unu schedule edecek yeterli CPU veya belleğe sahip değil. Tüm mevcut node'lar çalışan test container'larıyla tamamen kullanılmış.

🎬 AuthorizationFailed: 11'de Panik, Sabah Felaket

Release Öncesi Pipeline

Nöbetçi Mühendis (11pm)

Contributor @ Subscription (aşırı geniş)