私はフランスのある小さな会社でVoipシステム管理者として働いていますが、ここに来たのは別の話です。
コールを受信できるエージェントの数に応じて、コールをダイヤルアップセンターに配信するためのグローバルな同等戦略を目標としたプロジェクトでのチームの作業の結果を示します。 もちろん、このフレーズは成功しました。
例では、次のようになります。
Center1 = 20エージェント
Center2 = 10エージェント
ワークロードが50％の場合、Center1には10人の無料エージェントが、Center2には5人のエージェントが必要です。 ここにそのようなパリティがあります。
コール数がフリーエージェントの数を超えると、クライアントは次々とグローバルキューに立つ必要があります。 特定の数のエージェントが空いた場合、クライアントはエージェントの優先順位に従って移動しています。
ファッショナブルなガジェットを使用して、すべてをWebインターフェースでラップする必要があります。
古いシステム：
クライアントには6つのコールセンターがあり、それらはすべて単一の着信番号で同じサービスを満たしています。 コールの数は曜日によって異なりますが、基本的には1日あたり15000〜20000です。 センター自体は、このスキームに従って機能しました。
私の前は、トリックボックス（アスタリスク）のサーバーはオープンソースサーバーなしで機能しました。システムは古風で、音質に問題がありました。 私はopenipsyを備えた2つのサーバーをインストールしました。OpenSipsはプロキシのようなもので、呼び出し専用です。指定されたルールに従ってどこにでも送信できます。 しかし、このシステムも限界を示し始めました。 オープンソースのサーバーは、 Dispatcherモジュールを使用して呼び出しを行いました。原理は簡単で、サーバーには次のデータを含むテキストファイルがありました。
1 192.168.1.1:5060＃Center1
1 192.168.1.2:5060＃Center2
1 192.168.1.3:5060＃Center3
1 192.168.1.4:5060＃Center4
1 192.168.1.5:5060＃Center5
1 192.168.1.6:5060＃Center6
コールが到着すると、openseepsは最初の行を読み取ります>センターへのコール1>リダイレクト
コールが着信すると、openseepsは2行目を読み取り>センターへのコール2>リダイレクト
ファイルの終わりに達すると、円で読み始めます。 ここで、100行あると想像してください。これは何ですか？ 100％正しい
毎朝、私は各センターのパーセンテージを受け取り、小さなルビ文字で丸めてファイルを生成しました。 これにより、効率が5％向上しました。 5％は9人で、平均給与は1700で、月あたり15300ユーロの節約になります。 エージェントの数は180人から1人まで、つまり1日を通して異なります。 しばらくして、私はいくつかの異常に気づき始め、あるセンターは実際より少ないリソースを宣言し、別のセンターはここに...それが人的要因です。 はい、そして一般的な不透明度、Trixboxesのローカルでは完全なレポートがありましたが、世界的には午前10時30分に並んでいる人の数は言えません。 グローバルな可視性がなければ、負荷を適切に予測することは単に困難であり、エージェントの数が間違っている可能性があります。 ファクターHとグローバル統計により、私の5％は衰退しました。
アイデア！ そして、それはどうだろう、それはこのようなものになるだろう...
それまでの間、openpense 1.6には興味深いLoad Balancerモジュールが搭載されていました。 この原理は興味深いもので、オープンソースは指定されたリソースの量をメモリに保持し、空きのある場所に呼び出しを送信します。 Trixboxから1分ごとにエージェントの数を取得し、データベースでそれを変更することは残っています。 ユーリカ？！
そうでもない
1：これは、エージェントの数に関して同等ではありません。つまり、最初のリソースを0、次に2番目にスコア付けします。 （この場合、最初のセンター、2番目のセンター）
2：OpenSipはオーディオを再生できません。一般的にキューはありません。これはプロキシです。
3：アルファ版。
決定
1：openseps（Bogdan）のメイン開発者に手紙を書き、彼は私たちに必要なアルゴリズムを作成しました。 ここを見ることができます
2：オーディオとキューイングにアスタリスクを使用します。
3：指に洗礼を施し、テストし、テストします。
新しいシステム：
アスタリスクは呼び出しを受け取り、openipsを介して呼び出しを試みます。リソースがあれば、それは通過し、リソースはありません、待機と言います。 すべてのクライアントが1つのキューにあるため、古いシステムに比べて不在着信の数が減ります。 リソースの量はX秒ごとに更新されます。 一般的にこれらのリソースは何ですか？ これは、Trixbochにログインしているエージェントの数です。
4台のサーバーをセットアップし、すべてを複製する必要があります。ネットワーク電源、異なるスイッチのネットワークアダプター、電源が異なる別々の格納庫にある2台のサーバー、それらの間に二重の「リング」光学部品があります。 物理的特性は次のとおりです。
Dell r410ダブルクアッドコアキセノン、ダウンロード統計：
OpenSips
top-19:05:59 35日以内、4：16、2ユーザー、平均負荷：1.10、1.24、1.21
タスク：合計192、実行中1、睡眠191、停止0、ゾンビ0
CPU（s）：9.2％us、1.3％sy、0.0％ni、89.4％id、0.2％wa、0.0％hi、0.0％si、0.0％st
メモリ：合計4043228k、使用済み3905396k、空き137832k、256656kバッファ
スワップ：合計6094840k、使用された108k、無料の6094732k、キャッシュされた3101996k
アスタリスク：
top-19:10:31 up 37 days、23:40、3 users、load average：0.04、0.05、0.12
タスク：合計175、実行中1、睡眠174、停止0、ゾンビ0
CPU（s）：0.0％us、16.7％sy、0.0％ni、83.3％id、0.0％wa、0.0％hi、0.0％si、0.0％st
メモリ：合計4037580k、使用済み2375616k、空き1661964k、156400kバッファ
スワップ：合計6094840k、使用済み168k、無料6094672k、キャッシュ1876072k
私はアスタリスクで遅刻しました。通常は平均0.5ロードです。 Openipsyでは、メモリとプロセッサを追加すると考えられますが、システムは消費しますが、最適化は役に立ちませんでした。
打ち上げ
悪夢、システムが蹴られ、昼間に止まり、クライアントが吐き出し、私たちは夜働きました。 バグがクロールしました。問題は、実際のサーバーに負荷をかけずにバグを特定することが困難であったことです。模擬テストは役に立ちませんでした。 バグを修正するのに5日かかりました。 スケジュールは面白かったです。夜は仕事をし、日中は落ちないように見ます。 私のせいで仕事をしなかった180人の人々を見ました。彼らの呪いは私の脳にまっすぐに行きました。 この5日間で、私は燃えている鍋にいることの意味を理解しました。 しかし、わずかな変更があっただけで、5日目には機能しました。 顧客は満足しています。
インターフェース
Webインターフェースはシンプルで機能的であることが判明しました。不要なフリルはありません。 法的問題のため、真実は名前をこすらなければなりませんでした。
ログイン：
デジタル形式のグローバル統計。 すべてがフランス語で説明されています。
Nombre d'appels totaux pour lajournée ：受信したコールの数。
Temps de repponseestimé ：平均待ち時間。
Appels en attente ：キューに入っている人の数（彼らはまだ答えられていません）。
Appelsreçus ：受信したコールの数。
エージェント[合計：Libre：En com] ：エージェント[すべて：無料：話す]
Appelsabandonnées ：エージェントに連絡する前に電話を切った顧客の数。
EfficacitéGlobale ：全体的なパフォーマンス、受け入れられた全体の割合。
Charge Globale ：グローバルワークロードは、10人中10人が話し、0人が待機している場合、ワークロードは100％などです。
同じですが、1つのセンターの統計：
グラフ 、2番目のグラフに注目してください。今では、エージェントの数がワークロードに迅速かつ効率的に適応します。
しかし、彼らがまだランチタイムにプッシュできることは明らかです。
スクリーンショットの残りの部分を少なく挿入しますが、それでもトピックは長くなります。 誰が彼が見えるか気にします。
レース結果
生産性を7〜10％向上これは、ダイヤルアップセンター専用で、他のタスクの時間を世界的に節約できます。 ダイヤラ管理センターによるリソースのコンパイルなど、日常的なタスクの消失。
当社のウェブサイト： www.ipbx-france.fr
Webの銃口と内部スクリプトの作業をしてくれたMaster of Codeのチームに感謝します。
ご清聴ありがとうございました。