Sağlayıcılar için faturalama sistemleri: nelerden oluşur

Abone faturalamadan tek bir satır görür: "şu tarihte şu kadar kesilecek". İçeride ise operatörün en kritik sistemidir: insanları ağa alır, tüketimi ölçer, parayı sayar ve her kuruş için muhasebeye hesap verir. Operatör site kesintisini atlatır, ama faturalama arızası binlerce abonenin ya ağsız kalması ya da ağı bedava kullanması demektir. Sektörde otomatik faturalama sistemi denen bu yapının nelerden oluştuğuna bakalım.

Abonenin faturalamadaki yolu

Abonenin yönlendiricisi bağlantı kurduğunda operatörün cihazı faturalamaya sorar: içeri alınsın mı ve hangi hızda. Bu diyaloğun klasik dili RADIUS'tur, yanıt bakiyeye ve tarifeye bağlıdır. Sonra ağ sayaçları gönderir: kaç bayt geçti, oturum ne kadar sürdü. Faturalama bunları ücrete çevirir ve kesim gününde dönemi kapatır. Panelden yapılan ödeme ters yönde gider: para yatırıldı, engel kalktı, hız geri geldi, tümü insan müdahalesi olmadan.

Modern sistemin modülleri

Çekirdeğin çevresinde genelde yan bloklar bulunur: kablo ve port envanteri, kesim bildirimleri, kapsama haritası entegrasyonu. Operatör büyüdükçe faturalama, her modülü değiştirilebilen bir yapı setine benzer.

Kutu ürün, SaaS ya da kendi geliştirmeniz

Küçük ağlar kutu sistemlerle başlar: sunucuna kur, tarifeleri gir, çalış. Artısı kontrol ve tek seferlik fiyat, eksisi güncellemelerin ve yedeklerin size ait olması. Bulut sistemler hesap başına ücret karşılığında işletmeyi üstlenir: birkaç bin aboneli bir ağ için bu çoğu zaman yönetici maaşından ucuzdur. Kendi geliştirmeyi standart dışı modeli olan operatörler seçer: sanal operatörler, günlük tarifeli sağlayıcılar, faturalamanın ürün olduğu hizmetler. En pahalı yol budur, ama başkasının mimarisinin sınırları yoktur.

Seçerken nelere bakmalı

• Cihaz desteği. Yetkilendirme ve sayaç toplama, "genel olarak" değil, sizin anahtar ve BRAS modellerinizle çalışmalıdır.
• Engelleme hızı. Sıfır bakiye ile gerçek kesinti arasında ne kadar geçer: saatlerce fark hediye edilmiş trafiktir.
• Yeniden hesaplamalar. Geriye dönük tarife değişimi, iadeler, vaat edilen ödeme: kutu ürünler en çok bu senaryolarda bozulur.
• Açık API. Panel, site ve mobil uygulama, başkasının şablonu içinde değil API üzerine kurulursa daha uzun yaşar.
• Yük payı. Bin aboneyle canlı görünen sistem, toplu kesim gününde elli binle durabilir.

Ayrı bir gider de geçiştir. Eski sistemden ayrılmak bakiye geçmişini, kapanmamış dönemleri ve vaat edilen ödemeleri peşinden sürükler. İyi yüklenici işe bu artıkları sayarak başlar, kötüsü güzel bir panel göstererek. İki sistemin en az bir fatura dönemi paralel çalışmasını planlayın: gerçek abonelerde ücret karşılaştırması hiçbir testin göstermediğini bulur.

Tipik kurulum hataları

• Ağdan sonra faturalama. Önce ağ kurulur, sonra hesaplama eklenir. Doğrusu tersidir: yetkilendirme ve kayıt tasarımı cihaz seçimini belirler.
• "Komşununki gibi" tarifeler. Sistem esnek tarifeler destekler, ama içine üç satır girilir. Sonra her kampanya elle yeniden hesaplamaya döner.
• Her şey için tek sunucu. Aynı makinedeki veritabanı, RADIUS ve panel ilk toplu kesim gününe kadar çalışır. En azından veritabanını önceden ayırın.
• Test ortamı yok. Güncellemeler doğrudan canlıya gider ve ilk tarifelendirme hatası, bir test düzeneğinin ömür boyu maliyetini aşar.
• Geri yükleme denenmemiş yedek. Yıllarca yedek alınır, ilk geri yükleme arıza anında denenir. Üç ayda bir geri yükleme provası yapın.

Bu hataların ortak paydası, faturalamayı süreç değil program sanmaktır. Abonelerin parası içinden kesintisiz geçer, bu yüzden ona site gibi değil kasa gibi davranın.

Büyüyen bir ağ için sistem seçiyorsanız, işlev listesinin ötesine bakıp iki soru sorun: kesim gününü nasıl atlatıyor ve taşınırken verileri çıkarmak ne kadar kolay. Geri kalanı eklenebilir, bu iki özelliği mimari belirler. Çevresindeki altyapıyı ayrıca yazdık: ağdaki sunucu türleri özeti, faturalamanın bu resimde nereye oturduğunu görmenize yardım eder.