AI API Ağ Geçitleri için Kontrol Düzlemi Mutabakatı

Bir AI API ağ geçidi, yukarı akış sağlayıcı kontrol düzlemleri sürüklenmeye devam ederken çalışma zamanı erişiminin birleşik görünmesini sağlayabilir. Ekipler genellikle çıkarım çağrılarını, faturalandırmayı, API anahtarı yönetimini ve kullanım analizlerini ağ geçidinde merkezileştirir ve ardından OpenAI projelerini, Anthropic çalışma alanlarını, Google Cloud projelerini, Gemini anahtarlarını, hizmet hesaplarını, bütçeleri ve raporlama kapsamlarını manuel olarak yapılandırılacak şekilde bırakır. Bu, sessiz bir hata modu yaratır: Ağ geçidi, bir kiracı politikasının mevcut olduğunu söyler ancak sağlayıcı hesabı başka bir şeyi uygular veya bildirir.

Pratik model, kontrol düzlemi mutabakatıdır. Yukarı akış sağlayıcının yönetim nesnelerine envanter olarak davranın. Gözlemlenen envanteri ağ geçidindeki istenen kiracı politikasıyla karşılaştırın. Sapma bulguları üretin, düzeltmeleri onaylar yoluyla yönlendirin ve açıkça yüksek riskli durumlar için otomatik eylem ayırın.

Bu makalede gerçekler, öneriler ve tahminler birbirinden ayrılmıştır. Gerçekler, bugün belgelenen sağlayıcı davranışlarıdır. Öneriler, bir ağ geçidi operatörü için mimari tercihleridir. Çok sağlayıcılı yapay zeka yığınları olgunlaştıkça tahminler muhtemelen operasyonel baskılar oluşturacaktır.

Ağ Geçidinin Benimsenmesinden Sonra Kayma Nasıl Görünüyor?

Çalışma zamanı ağ geçitleri sorunun bir katmanını çözer: uygulamalar istekleri ortak bir uç noktaya gönderir, kiracılar kapsamı belirlenmiş ağ geçidi anahtarlarını alır ve kullanım tek bir deftere kaydedilir. Ancak yukarı akış sağlayıcı nesneleri hala önemlidir. Hangi projenin veya çalışma alanının bir anahtara sahip olduğuna, hangi raporların harcamayı içerdiğine, hangi oran ve kaynak sınırlarının uygulanacağına ve hangi acil durum kontrollerinin mevcut olduğuna karar verirler.

Yaygın sapma örnekleri şunları içerir:

• Bir kiracı, ağ geçidinde bir OpenAI projesiyle eşlenir, ancak bir çalışma zamanı anahtarı hala paylaşılan bir varsayılan projeye aittir.
• Anthropic API anahtarı yanlış çalışma alanında oluşturuldu ve amaçlanan alana taşınamaz.
• Dışarıda bir Google API anahtarı oluşturuldu konsol akışına aktarılır ve kısıtlamalar hiçbir zaman açık bir şekilde ayarlanmadığı için sınırsız kalır.
• Sağlayıcı harcama eşiği, ağ geçidi kiracı bütçesinden düşüktür ve ağ geçidi onları beklemeden sağlayıcı tarafında hatalara neden olur.
• Sağlayıcı harcama eşiği, ağ geçidi politikasından daha yüksek olduğundan, sağlayıcı hesabını zayıf bir destek noktası olarak bırakır.
• Kullanım raporları boş veya devralınan çalışma alanı alanları içerir, bu nedenle finans, sağlayıcı maliyetini ağ geçidi kiracılarıyla net bir şekilde uzlaştıramaz.
• Bir hizmet hesabı, çalışanın hayatta kalmasını sağlar. ağ geçidi sahiplik modeline bağlı olmadığı için işten çıkarılıyor.

Risk yalnızca güvenlik değildir. Drift kesintileri ilişkilendirme, acil durum müdahalesi, maliyet kontrolü ve denetlenebilirlik.

Tasarımda Korunması Gereken Gerçekler

Sağlayıcı kontrol düzlemleri birbirinin yerine kullanılamaz. Bir uzlaştırıcı, operatörlerin verimli bir şekilde çalışabilmesi için yeterli veriyi normalleştirmeli ancak sağlayıcıya özgü semantiği korumalıdır.

OpenAI Projeleri

Gerçek: OpenAI Projeleri, kuruluşların işleri organize etmesine, erişimi ve sınırları yönetmesine, hizmet hesaplarını sağlamasına ve bir proje kapsamındaki kullanımı izlemesine olanak tanır. Kullanım projeye göre ayrılabilir ve proje başına harcama sınırları belirlenebilir.

Gerçek: OpenAI proje hizmeti hesapları, oluşturuldukları projeye özeldir. Oluşturulan gizli anahtar bir kez gösterilir ve onu kaybetmek için yeni bir anahtar oluşturulması gerekir.

Gerçek: OpenAI API anahtarları Tümü, Kısıtlı ve Salt Okunur gibi izin düzeylerini destekler. Hizmet hesabı API anahtarı izinleri, değiştirilmediği sürece varsayılan olarak tüm proje API kaynaklarına okuma ve yazma erişimi şeklindedir.

Gerçek: OpenAI belgeleri, bir yardım makalesinde proje aylık harcama sınırlarını yumuşak eşikler olarak tanımlarken, sorun giderme materyali ayrıca project_spend_limit_exceeded gibi kesin sınır hatalarını da belgelemektedir. Bir ağ geçidi, yapılandırılmış her sağlayıcı harcama sınırının, her hesap yapılandırmasında eşzamanlı sabit sınır gibi davrandığını varsaymamalıdır.

Antropik Çalışma Alanları

Gerçek: Antropik Çalışma Alanları, API anahtarlarını, ekip erişimini ve maliyetleri düzenler. Ek çalışma alanları; üyeleri, hizmet hesaplarını, API anahtarlarını ve kaynak sınırlarını içerebilir.

Gerçek: API anahtarları, oluşturuldukları çalışma alanına bağlıdır ve çalışma alanları arasında taşınamaz. Anthropic, her istekte geçerli çalışma alanını ve organizasyon sınırlayıcılarını değerlendirir.

Gerçek: Varsayılan Çalışma Alanının özel raporlama davranışı vardır. Kullanım ve maliyet raporları, boş bir çalışma alanı_kimliği gösterebilir ve bu, bir ağ geçidi, sağlayıcı raporlarını kiracılarla eşleştirmeye çalıştığında önemli olur.

Gerçek: Antropik Yönetici ve Analytics API'leri, organizasyon ve çalışma alanı yönetimini, API anahtarlarını, kullanım raporlarını, maliyet raporlarını ve ilgili analizleri kapsar, ancak erişim, yönetici anahtarlarına ve hesap veya rol uygunluğuna bağlıdır.

Google Cloud ve Gemini Anahtarları

Gerçek: Google Cloud API anahtar kılavuzu, sınırsız API anahtarlarının güvenli olmadığını söylüyor. API kısıtlamaları hangi API'lerin çağrılabileceğini, uygulama kısıtlamaları ise bir anahtarın nerede kullanılabileceğini sınırlar.Google, uygun olduğu durumlarda her ikisinin de ayarlanmasını önerir.

Gerçek: Google Cloud belgeleri, konsol aracılığıyla oluşturulan API anahtarlarının en az bir API kısıtlaması gerektirdiğini, gcloud veya REST aracılığıyla oluşturulan anahtarların ise kısıtlamalar açıkça belirtilmediği sürece sınırsız olduğunu söylüyor.

Gerçek: Geliştiriciler için Google AI belgeleri, Gemini API'nin standart anahtarlardan yetkilendirme anahtarlarına geçtiğini, kısıtlanmamış standart anahtarların reddedildiğini ve hizmetten kaçınmak için standart anahtarların Eylül 2026'dan önce yetkilendirme anahtarlarına taşınması gerektiğini söylüyor. kesinti.

Gerçek: Uyarı içeren Google Cloud Faturalandırma bütçeleri harcamayı otomatik olarak sınırlamaz. Programatik Pub/Sub bildirimleri, maliyet kontrolü yanıtlarını otomatikleştirebilir ancak Pub/Sub teslimatı en az bir kez yapılır ve mesajlar sıra dışı olarak gelebilir.

Referans Mimarisi

Öneri: Mutabakatı, sıcak istek yolunun içinde değil, çalışma zamanı ağ geçidinin yanında bir kontrol düzlemi hizmeti olarak oluşturun. Sağlayıcı yönetici yüzeylerini okumalı, bunları ağ geçidi kiracı politikasıyla karşılaştırmalı ve sürüklenme olaylarını yaymalıdır.

Pratik bir mimari beş bölümden oluşur:

• İstenen durum deposu: ağ geçidi kiracı politikası: kiracı, sahip, izin verilen sağlayıcılar, model profilleri, bütçe politikası, ücret politikası, izin verilen yukarı akış projeleri veya çalışma alanları, anahtar sahipliği ve acil durum durumu.
• Gözlemlenen durum envanteri: yönetici API'leri aracılığıyla keşfedilen sağlayıcı nesneleri, faturalandırma dışa aktarmaları, konsol dışa aktarmaları veya planlı taramalar.
• Sağlayıcı bağdaştırıcıları: OpenAI, Anthropic, Google Cloud ve yerel tanımlayıcıları ve semantiği koruyan diğer sağlayıcıya özel toplayıcılar.
• Drift motoru: sessizce sağlayıcı durumunu değiştirmek yerine bulgular üreten deterministik karşılaştırmalar.
• İyileştirme iş akışı: bildirimler, onaylar, sohbet uyarıları ve dar kapsamlı yüksek riskli sürüklenmeye karşı otomatik eylemler.

Ağ geçidi, kiracı faturalandırma gerçeğinin kaynağı olmaya devam ediyor. Sağlayıcı maliyet ve kullanım raporları, ödeme girdileri ve anormallik sinyalleri haline gelir. Bu ayrım önemlidir çünkü sağlayıcı raporları gecikebilir, farklı boyutlar kullanabilir veya ağ geçidi kiracılarıyla net bir şekilde eşlenmeyen raporlama alanlarını açığa çıkarabilir.

Anlamı Uzaklaştırmak Değil, Envanteri Normalleştirin

Öneri: Normalleştirilmiş bir envanter tablosu kullanın, ancak sağlayıcıya özgü alanları ekleyin. Bir OpenAI projesi, Anthropic çalışma alanı ve Google Cloud projesinin aynı nesne olduğunu iddia etmeyin.

Yararlı bir envanter modeli şunları içerir:

• provider: openai, anthropic, google, azure veya başka bir bağdaştırıcı adı.
• provider_account_id: kuruluş, faturalandırma hesabı veya bulut hesabı tanımlayıcısı.
• container_type: proje, çalışma alanı, bulut projesi, klasör veya hesap.
• container_id: sağlayıcının yerel projesi veya çalışma alanı tanımlayıcısı.
• container_name: sağlayıcının insanlar tarafından okunabilen etiketi.
• tenant_id: eşlenen ağ geçidi kiracısı veya eşlenmediğinde null.
• service_account_id: sağlayıcı hizmet hesabı veya iş yükü kimliği mevcut olduğunda.
• api_key_id: anahtar parmak izi, anahtar kimliği veya karma anahtar tanımlayıcısı. Ham sağlayıcı sırlarını bu tabloda saklamayın.
• key_scope: proje, çalışma alanı, organizasyon, uygulama kısıtlaması, API kısıtlaması veya eşdeğer sağlayıcıya özgü kapsam.
• izinler: yerel izin düzeyi, rol bağlama, kısıtlanmış yetenek listesi veya okuma/yazma durumu.
• model_allowlist: sağlayıcının bunu ortaya çıkardığı, anahtarın erişebileceği modeller veya API aileleri kontrol.
• rate_policy: gözlemlenen sağlayıcı sınırı ve desteklemesi beklenen ağ geçidi politikası.
• spend_policy: gözlemlenen sağlayıcı eşiği veya bütçesi ve ağ geçidi kiracı bütçesi politikası.
• reporting_scope: bilinen boş veya devralınan alanlar dahil olmak üzere sağlayıcı raporlarında beklenen boyutlar.
• last_seen_at: en yeni zaman damgası tarayın.
• sahip: ağ geçidi kiracısı, ekip, hizmet sahibi veya insan sahibi.
• kaynak: yönetici API'si, faturalandırmayı dışa aktarma, konsolu dışa aktarma, yapılandırmayı içe aktarma veya manuel doğrulama.

Bu tablo ekleme dostu olmalıdır. Operatörlerin geçmişe ihtiyacı vardır: bir anahtarın ilk kez ne zaman göründüğü, ne zaman görünmeyi bıraktığı, izinlerinin ne zaman değiştiği ve değişikliği hangi tarayıcının gözlemlediği.

İstenen Durumu Açıkça Tanımlayın

Öneri: Mutabakat yalnızca istenen durum somutsa işe yarar. Kiracı A'nın Anthropic'i kullanabileceği gibi bir politika çok belirsizdir.Kiracı A'nın çalışma alanı ws_123 kullanması gerekir, hizmet hesabı svc_billing_prod, insana ait çalışma zamanı anahtarı yok, model profili desteği hızlı ve ağ geçidi bütçesinin yüzde 80 ila 110'u arasındaki sağlayıcı harcama eşiği gibi bir politika eyleme dönüştürülebilir.

İstenen durum şunları içermelidir:

• Her kiracı tarafından hangi yukarı akış kapsayıcıları kullanılabilir.
• Kiracının ağ geçidine ait kimlik bilgilerini kullanıp kullanmadığı, kiracının ağ geçidine ait kimlik bilgilerini kullanıp kullanmadığı, kiracı BYOK kimlik bilgileri veya her ikisi.
• Çalışma zamanı anahtarlarının hizmet hesabına ait olması gerekip gerekmediği.
• Hangi sağlayıcı API'lerine ve modellerine izin verilir.
• Kabul edilebilir maksimum ve minimum yukarı akış harcama eşikleri.
• Yerleştirme için beklenen sağlayıcı raporlama boyutları.
• Google anahtarları için gerekli uygulama ve API kısıtlamaları.
• Her sağlayıcı ve kiracı için acil durum devre dışı bırakma davranışı.

İstenen durumu depolayın sürümlendirilmiş bir politika tablosunda. Her sapma bulgusu, karşılaştırma için kullanılan politika versiyonuna referans vermelidir. Bu, politika değişiklikleri birçok yeni bulgu oluşturduğunda incelemeleri ve geri alma işlemlerini mümkün kılar.

Operatörlerin Harekete Geçebileceği Drift Sınıflarını Uygulayın

Öneri: Yazılan drift bulgularını yayınlayın. Genel uyumsuzluk uyarılarından kaçının. Operatörler neyin bozulduğunu, neden önemli olduğunu ve hangi eyleme izin verildiğini bilmelidir.

Yararlı sürüklenme sınıfları şunları içerir:

• missing_container: kiracı politikası, var olmayan veya tarayıcı tarafından görülemeyen bir sağlayıcı projesi veya çalışma alanı bekler.
• unmapped_container: bir sağlayıcı projesi, çalışma alanı veya bulut projesi mevcuttur ancak kiracısı yoktur eşleme.
• yanlış_kapsayıcı: kiracı trafiği tarafından kullanılan bir anahtar, politikanın izin verdiğinden farklı bir projeye veya çalışma alanına aittir.
• stale_key: bir sağlayıcı anahtarı, ağ geçidi trafiğinde belirli bir süre boyunca görülmez ancak yukarı akışta etkin kalır.
• orphaned_owner: bir anahtar veya hizmet hesabı, şirketten çıkan veya eşlenmemiş bir kullanıcıya aittir. kimlik.
• excessive_permission: bir anahtar, ağ geçidi politikasının gerektirdiğinden daha geniş sağlayıcı izinlerine sahiptir.
• unrestricted_google_key: bir Google anahtarında gerekli API kısıtlamaları, uygulama kısıtlamaları veya Gemini uyumlu yetkilendirme geçiş durumu yoktur.
• limit_below_policy: sağlayıcı sınırlarının, ağ geçidi politikasından önce trafiği engelleme olasılığı yüksektir bekleniyor.
• limit_above_policy: sağlayıcı sınırları, geri durdurma işlevi göremeyecek kadar hoşgörülü.
• reporting_unreconcilable: sağlayıcı kullanımı veya maliyet raporları kiracı, anahtar, proje veya çalışma alanıyla net bir şekilde eşlenemiyor.
• scanner_blind: gerekli yönetici API'leri veya rolleri eksik, dolayısıyla uzlaştırıcı bir çözüm oluşturamıyor iddia.

Her bulgu önem derecesini, güveni, etkilenen kiracıyı, sağlayıcının yerel tanımlayıcılarını, ilk gözlem süresini, son gözlem süresini, önerilen eylemi, izin verilen otomatik eylemleri ve geri alma meta verilerini içermelidir.

Çözüm: Kuru Başlat, Dar Bir Şekilde Otomatikleştir

Öneri: Mutasyondan önce bulguları varsayılan olarak prova yapın. Sağlayıcı yönetici kimlik bilgileri güçlüdür. Kötü bir eşleme, üretim iş yüklerini devre dışı bırakabilir, ilişkilendirmeyi silebilir veya pahalı bir kesinti oluşturabilir.

İki aşamalı bir model iyi çalışır:

• Bildirim ve bildirim: eksik sahip etiketleri, eşlenmemiş raporlama alanları veya harcama eşiklerinin politikanın biraz dışında olması gibi düşük riskli veya belirsiz sapmalar için.
• Önceden onaylanmış otomatik eylem: sızdırılmış anahtarlar, sahip olunan anahtarlar gibi dar yüksek riskli durumlar için devre dışı bırakılmış kullanıcılar, sınırsız Gemini özellikli anahtarlar veya ağ geçidinde zaten devre dışı bırakılmış kiracılara bağlı anahtarlar.

Otomasyon mümkün olduğunda geri döndürülebilir olmalıdır. Örneğin, bir ağ geçidi anahtarının devre dışı bırakılmasının tersine çevrilmesi, bir yukarı akış anahtarının silinmesinden daha kolaydır. Kullanıma sunulduktan sonra bir yukarı akış sağlayıcı anahtarının döndürülmesi gerekli olabilir, ancak bu, aşağı yönde dağıtım koordinasyonunu gerektirir. Ağ geçidi bütçesinin sıfıra düşürülmesi anında gerçekleşir ve denetlenebilirken, sağlayıcı bütçesi uyarıları gecikebilir veya eşzamansız davranabilir.

Acil Durum Kapatma Çalıştırma Kitabı

Öneri: Acil durum sağlayıcı kapatma çalıştırma kitabını ihtiyaç duyulmadan önce yazın.Hem ağ geçidi denetimlerini hem de sağlayıcı denetimlerini kapsamalıdır.

Pratik bir sıralama şu şekildedir:

1. Yeni çalışma zamanı isteklerinin ağ geçidinde durması için etkilenen ağ geçidi anahtarlarını devre dışı olarak işaretleyin.
2. Kiracı ağ geçidi bütçesini veya rezervasyon harcama sınırını sıfıra ayarlayın.
3. Kiracının etkilenen sağlayıcıya veya model profiline yönlendirmesini engelleyin.
4. Desteklendiğinde yukarı akış sağlayıcı anahtarlarını iptal edin, devre dışı bırakın veya döndürün.
5. Varsa sağlayıcı tarafı eşiklerini azaltın. ve hesap yapılandırması için kullanışlıdır.
6. Her eylemi aktör, zaman damgası, neden, sağlayıcı nesnesi ve geri alma talimatıyla birlikte kaydedin.
7. Yayılma gecikmelerini bildirdikten sonra sağlayıcı tarafı kullanımı ve maliyeti uzlaştırın.
8. Olay sonrası sürüklenme incelemesini açın: nesne nasıl yönetilmez hale geldi ve hangi politika kontrolünün onu daha önce yakalaması gerekirdi?

Bu sıra, ağ geçidindeki trafiği ilk olarak kasıtlı olarak durdurur. Sağlayıcı kontrolleri hala önemlidir ancak hız, kullanılabilirlik ve yaptırım anlambilimi açısından farklılık gösterebilir.

Ödünleşmeler

Otomatik mutabakat sapmayı azaltır ancak yönetici kimlik bilgileri gerektirir. Öneri: Yönetici kimlik bilgilerini çalışma zamanı kimlik bilgilerinden ayırın, bunları ayrı bir kasa yolunda saklayın, mutasyon ayrıcalıklarını kısıtlayın ve her okuma ve yazmayı denetleyin.

Kiracı başına bir yukarı akış projesi veya çalışma alanı, ilişkilendirmeyi ve patlama yarıçapı kontrolünü iyileştirir. Takas; nesne yayılımı, sağlayıcı sınırları, operasyonel ek yük ve paylaşılan önbellek, sağlanan kapasite veya havuzlanmış aktarım hızı stratejilerine ilişkin zorluklardır.

Sağlayıcı sınırları yararlı bir destek sağlar ancak ağ geçidi tarafı bütçe rezervasyonunun yerini almaz. Sağlayıcı sınırları esnek, eşzamansız, plana bağlı olabilir veya istekler ve raporlarda farklı şekilde değerlendirilebilir.

Sık yapılan taramalar sapmayı daha hızlı tespit eder ancak yönetici API kullanımını, kota basıncını ve uyarı hacmini artırır. Daha iyi bir model, mümkün olduğu durumlarda olaya dayalı güncellemeler ve eksiksizlik için planlanmış mutabakattır.

Normalleştirme, kontrol panellerini kullanılabilir hale getirir ancak aşırı normalleştirme, önemli farklılıkları gizler. Yerel sağlayıcı alanlarını bulgular ve raporlarda görünür tutun.

Tahminler

Tahmin: AI API ağ geçidi operatörleri, sağlayıcı yönetici nesnelerini, bulut IAM ve faturalandırma hesabı yapılandırmasına benzer şekilde, giderek daha fazla düzenlenmiş yapılandırma olarak ele alacak. Çalışma zamanı proxy'si tek başına finans, güvenlik veya platform ekiplerini birçok kiracı genelinde harcama yapıp ölçeğe eriştikten sonra tatmin etmeyecek.

Tahmin: Temel modeller değişmeye devam edecek. Gemini'nin standart anahtarlardan yetkilendirme anahtarlarına geçişi gözle görülür bir örnektir. Sağlayıcının yerel nesne türünü, geçiş durumunu ve son görülen kaynağı depolayan mutabakat sistemleri, bu değişiklikleri yalnızca ham bir gizli kod ve sağlayıcı adını depolayan sistemlerden daha iyi işleyecektir.

Tahmin: Sağlayıcı raporları, uzlaşma için yararlı olmaya devam edecek ancak gerçek zamanlı uygulama için eşit olmayan bir şekilde kalacaktır. Kendi istek defterini, rezervasyon modelini ve kiracı ilişkilendirmesini tutan ağ geçitleri, sağlayıcı faturalarının dışa aktarılmasını bekleyen ağ geçitlerinden daha öngörülebilir olacaktır.

Uygulama Kontrol Listesi

• Kiracı-sağlayıcı eşlemeleri için istenilen durum politikası tablosu oluşturun.
• Sağlayıcıya özgü tanımlayıcılar ve karma anahtar kimlikleri ile gözlemlenen bir envanter tablosu oluşturun.
• Salt okunur sağlayıcı oluşturun önce bağdaştırıcılar.
• Tarayıcı arızalarını gizlemek yerine bulgu olarak sınıflandırın.
• Yazılan sürüklenme olaylarını ciddiyet ve güvenle yayınlayın.
• Bulguları destek bildirimlerine, uyarılara veya onay kuyruklarına yönlendirin.
• Otomatik eylemi yalnızca dar, önceden onaylanmış yüksek riskli sınıflar için etkinleştirin.
• Yönetici kimlik bilgilerini çalışma zamanı kimlik bilgilerinden ayrı tutun.
• Ağ geçidi defter kayıtlarını çözümleme ve anormallik için sağlayıcı raporlarına ekleyin.
• Güvenmeden önce, üretim dışı bir kiracıda acil durum kapatmayı test edin.

Uygulamaya Uygulanabilir Sonuç

Çıkarım çağrılarını ortak bir uç nokta üzerinden yönlendirmekle yetinmeyin. Yukarı yöndeki kontrol düzlemleri sürüklenirse, ağ geçidi yine de ilişkilendirmeyi kaybedebilir, eski anahtarları kaçırabilir, sağlayıcı harcama davranışını yanlış okuyabilir veya acil bir durumda başarısız olabilir.

En güçlü model basittir: ağ geçidine istenen kiracı politikasını yazın, gözlemlenen sağlayıcı nesnelerini tarayın, sağlayıcıya özgü anlamı koruyun, yazılan sapma bulgularını yayınlayın ve kontrollü bir iş akışı aracılığıyla sorunu düzeltin. Salt okunur olarak başlayın. Envanteri kanıtlayın.Ardından yalnızca riski düzelttikleri sapmadan daha düşük olan eylemleri otomatikleştirin.

İlgili okuma

• ayrı çalışma zamanı, yönetici, faturalandırma ve BYOK kimlik bilgileri
• ağ geçidi tarafı faturalandırma defteri ve bütçe rezervasyonu
• ayrılma ve hizmet hesabı sahiplik kuralları