背景
約1年半前に、私たちの課金システム（誰かが書いたことがあり、ローカルカウンターでサポートされていたが、著者はもういなかった）が割り当てられたタスクに対処できないという問題に直面しました。
タスクに合わせて新しいシステムの開発を注文するのは、費用がかかり、長すぎます。 したがって、タスクが発生しました-適切なソリューションを見つけること。 最終的に選択はBGBillingにかかった。 その結果、私たちは1年間このシステムを使用しており、一般的にすべてに満足しています。 システムを選択した理由と良い理由（マイナスも強調します）以下で詳細に説明します。
はじめに
それでは、この投稿の主な目的は誰ですか？ 1年半前の私のような人々にとって、リーダーシップに困惑し、適切な解決策を探し、さまざまなシステムの説明を探して、テストを開始しますもっと信じます）。 また、急速な成長を経験している/新しいニッチに参入しており、新しいプラットフォームにアップグレード/移行する必要性を感じている人にとっても興味深いと思います。
始めましょう。
システムについて
システムはロシア語です。 ウェブサイト-bgbilling.ru
私が理解したように、このシステムはUfaNetネットワーク用に作成され、その後別の製品に成長しました。 2003年以降、どこかで開発が行われています。 現在のバージョンは5.0です（4.6があり、実際には現在のバージョンとの違いはありません。新しいバージョンは証明書の有効期限によるものです）。バージョン5.1は開発中です。
システムアーキテクチャ-サーバー部分はJavaで記述されています。 最初は、このようなシステムのパフォーマンスと安定性が気になりました。 1年後、パフォーマンスと安定性に問題はないと言うことができます。 しかし、1つだけあります。 サーバーには最新のJavaが必要であり、FreeBSDでは特定の問題があります。 したがって、このシステムはサポートされるリストにありません。 しかし、Windows、Linuxがあります。 具体的には、Fedora 10があります。Macはサポート対象プラットフォームとして宣言されていませんが、一般に、ラップトップでサーバーとクライアントを起動することを妨げるものはありません。 DBMS-MySQL。
データベースのドキュメントは素晴らしいです。 私たちはサイトdbinfo.bitel.ruに行き、調べて、何がどのように、何がどのパラメーターに接続できるのかを調べます。 正直なところ、私にとって、データベースの文書化は決定的な要因の1つでした。 私たちだけに固有の機能を自分で完成させなければならないことは明らかでした。したがって、適切なドキュメントなどのヘルプは、私が喜んでいたように、ますます楽しいものになりました。
請求オペレーターのクライアントは、別個のGUIアプリケーションです。
注意すべき点-クライアントには組み込みのSQLエディターがあり、クライアント自体からデータベースへの給与を実行し、消化可能な形式で結果を取得できます。
コスト、ライセンスなど
システムはモジュール式です。 各モジュールには、動作可能な多数のライセンス（または無限数）があります。 ライセンスが多いほど、モジュールは高価になります。 最大価格は、無制限のライセンス数です。
強調表示する価値のあるモジュールは、サブスクリプションボードの廃止モジュール、ディップアップモジュール、ipnモジュール、voiceipです。 サイトでライセンスのコストを計算できます-bgbilling.ru/price_count.shtml
誰がどんなモジュールを必要としますか？ サブスクリプションモジュールなしではどこにもありません 無限数のライセンスの最大価格（無限ライセンスは10,000ライセンスから開始）-100兆ドルです。
今、私たちは何をしていますか？ KTVオペレーターは基本的に他に何も必要としません。 プロバイダーにはネットワークモジュールもあります。 これはIPNまたはDialUPのいずれかです。どちらも最大で約100trの価値があります。
テレフォニーモジュールは最も高価なものの1つです。 約240兆
他のモジュール-voiceip、デジタルテレビモジュール-は、私の意見ではあまり人気がないので、考慮しません。 興味があれば-あなたはサイトを頼りにすることができます。
技術サポート、コミュニティ
テクニカルサポートの議論のある問題。 彼女は支払った。 ライセンスを購入する場合、テクニカルサポート契約を締結し、コールパッケージを購入することを提案します。 25trの場合、年間50件の電話を受けることができます。 9tr-15コール、1年間。 それはたくさんですか、それとも少しですか？ 私たちはその年に使用しました-5ヒット。 呼び出しのエラーメッセージはカウントされませんが、それらのメッセージには少なくとも1つの呼び出しを含むパッケージが必要です。
開発者は無料のサポートをフォーラムで提供しますが、保証期間はありません。 あなたの個人アカウントを通じて平均して数時間で回答が得られる場合、フォーラムでは1〜2日待つ必要があります。 しかし、フォーラムには、あなたと同じように、より迅速に助けを求めたり助けたりするユーザーがたくさんいます。
コミュニティとウィキベースの問題に私たちをもたらします。 私はコミュニティが本当に好きでした。 フォーラムでは、ほぼすべての問題に関するヘルプを見つけることができます。 最近、彼らは質問をしてICQで私に連絡し始めました。
パフォーマンスとFakapy
公式データは、サイトの対応するページ-bgbilling.ru/program/speed.shtmlに表示されます。 一般的に、それらは信頼できます。 APは非常に迅速に償却されます。 半径（DiapUPモジュールを使用してネットワークにアクセスする）は、負荷を保持しながら、同時に1000〜1500人のユーザーを許可します（エリア内の軽い障害、およびそれをオンにする）。 Radiusは、ネットフロー統計も計算します。 それぞれに1ギガビットのトラフィックがある6チスクのストリームに対処します。
曲がった手によって引き起こされたfakapsとは別に、2010年1月1日に1つのやや不快なfakapがありました。 毎月、残高のある新しいテーブルが自動的に作成されます。 ロジックに何らかの欠陥があるため、2010年には新しいテーブルは作成されませんでした。 そのため、APの償却時に、全員がアカウントに0を持っていました。 データベースの利点は非常によく文書化されており、グループ操作の機能があります-これはすぐに解消されました（ほとんどの加入者が二日酔いから離れてインターネットに登る前に）。
起動、既存のデータベースの転送
システムのセットアップと起動は非常に簡単で、強調することすらありません。 アーカイブを解凍し、実行可能ファイル.shを自動実行に追加し、ダンプファイルからテーブル構造をロードすると、おそらくすべてがすでに動作します=）。
興味深い瞬間。 システムの主要コンポーネント（サーバー、半径、シェダー）を異なるサーバーに分散し、設定でIPを指定すると、すべてが正常に機能し、サーバーにしがみついて負荷を分散できます。
負荷分散といえば。 すべてのタスクは、スケジューラが処理するキューに分類されます。 さらに、サーバーとの接続はほとんどありません。 つまり 統計をアップロードし、トラフィックを再計算するタスクはシェダラーをロードしますが、請求サーバー自体のパフォーマンスには影響しません。通常モードで動作し、キューにタスクを追加するとデータベース半径およびその他のモジュールにアクセスできます。
結論、他のシステムとの比較
一般的に、私は請求に満足しています。 今、インターフェイスを追加しています（データベースのドキュメントに満足しています-必要なクエリをデータベースに書くのはとても簡単です）
他のシステムと比較して、特別な機能はありませんでした。 UTM-天と地-のドキュメントとデータベースのオープン性、独自のスクリプトを追加する機能、独自のビジネスロジックを実装することで動く人々のレビューによると。
PS質問があれば、尋ねてください、私は答えようとします。