実際の負荷の下でのアスタリスク-500人を超えるオペレータ向けの分散フェールセーフコールセンター

4か国の約600のオペレーターが、アメリカ（およびロシア語）の番号への顧客からの電話を処理しています。

ピーク時に約200の同時通話。

1日あたり約15,000回の呼び出し。

このソリューションを数分で数回拡張する機能（推定によると、問題が始まるまでに最大1000件の同時通話）。



そしてもちろん、内部システムとの緊密な統合（CRM、ショッピングサポート、オペレーターと顧客の優先順位、その他多くの多くの利点）。



これがどのように機能し、なぜそうなのか誰が気にしますか-ようこそ



この構造全体が、絶えず変化するビジネスニーズと並行して6年間で成長および発展したことをすぐに言わなければなりません。今すぐ構築を開始した場合、すべてが異なる方法で行われる可能性がありますが、それはそれであり、機能します。



まず、一般的なスキーム：





SIPテレフォニープロバイダーは、サーバーを呼び出します。 現時点では、サーバーはAmazon上にありますが、あまり接続されていません。いくつかの問題を簡単かつエレガントに解決するのに役立つ便利な機能がいくつかあります。 テレフォニープロバイダー側​​では、フェールオーバーが構成されます。1つのサーバーが応答しなかった場合、コールは自動的に別のサーバーに移動し、次に3番目のサーバーに接続されます（実際には4つのIPが登録され、現在2つのIPが使用されていますが、その場合、すぐに上げることが可能です） IP-shkamiでシャーマニズムのない新しいメインノードとプロバイダーとの通信）。



呼び出しを受信したサーバー（メインサーバーの1つ）は、現在利用可能なサーバーとその時点での負荷を調べ、呼び出し自体を処理するか、SIPリダイレクトプロバイダーを他のサーバーにスローして、この呼び出しを行う必要があります。 現在のサーバーの合計2 + N：

2-これらは、負荷を分散する方法を知っている2つの完全に交換可能なメインサーバーであり、すべてのノードで同一のファイルの分散ファイルシステム（glusterfs）、ロックのmemcacheなどの追加サービスをサポートしますつまらない。 これら2つのノードは常に実行されています。 N-残りのノード。必要に応じて（同時呼び出しの数が特定のしきい値に達すると）起動されますが、現時点では2つあります。



他のサーバーとは完全に独立してコールを受信した各サーバーは、さまざまな要因に応じて必要に応じてIVRを通過し、異なるキューを実行し、ボイスメール（留守番電話）またはオフィスの1人の特定の人（オペレーター）にコールをスローします、その後、彼はこの呼び出しを保持し、ログと統計を書き込みます。許可されている場合、会話自体も書き込みます。 通常、ビジネスロジック全体で実行されます。これは、一部はMySQL構成に、一部はagiインターフェイスを介したスクリプト（一部はMySQLで表示）、一部はcurlクエリに実装されます。



各サーバーの呼び出しのリストは異なりますが、IVRとキュー（およびキューで呼び出しを待機しているオペレーター）はすべてのサーバーで複製されます。 したがって、呼び出しをキューから無料のオペレーターに転送するなどの一部のアクションでは、サーバーはまず、memcacheを使用した単純なスクリプトが応答する特定の内部URLへのcurlリクエストによって、（このオペレーターの）対応するオブジェクトのロックをハングさせます。 OKが返され、このアクションが実行されます。 したがって、たとえば、オペレーターは異なるサーバーから同時に複数の新しい呼び出しをキューから受信することはできませんが、マシン間ですべての状態を完全に同期する必要はありません。



オペレータは、自分の机の上にVoIP電話とソフトフォンを持っていますが、これは歓迎されません。 ソフトフォンを使用すると、品質が低下し、通常の通話ができなくなり、エージェントがヘッドフォンを取り外して画面から離れると（お茶を飲む）、電話に出られなくなる可能性があります。 さらに、エージェントコンピューターにはより高価なハードウェアが必要になり（現在はubuntuに基づくローエンドのディスクレスステーションで、1セットあたり300ドル）、サポートははるかに複雑になります（したがって、より高価になります）。 ソフトフォンは、ソフトフォンとは異なり、DHCPを介してIPアドレスと設定へのリンクを取得するため、ソフトフォンのサポートはより高価です。 Amazon上のすべての同じサーバーが構成を提供し、その後、電話はLAN内のVoIPプロキシを介して、完全に独立してサーバーに登録します。 つまり、手動設定作業がほぼゼロになります（プロビジョニングのおかげで、使用するすべての電話でサポートされます）。 ほとんどすべてのサポートは、電話交換にすぎません。 ソフトウェア電話は、実践で示したように、ユーザーへのコンサルティング、インストールと設定、サウンドまたはその他の問題の解決に全社規模で非常に多くの時間を消費します。一般的に、600人のユーザーがツールを提供すると、無限の問題が発生しますそれらを作成するには... :)



電話機と外部との間のすべての通信は、VoIPプロキシ（+設定を受信するための透過HTTPプロキシ）のみを介して行われます。 ただし、VoIPプロキシはすでにAmazon上のサーバーと通信し、Amazonはサーバー上で事前に登録されたプロキシのリストとのみ通信し、プロバイダーと通信します。他のサーバーとは通信しません。



VoIPプロキシは同じアスタリスクであり、最も単純化された構成のみです：最大限に単純化して破棄できるものはすべて、電話とサーバー間のトラフィックをそれ自体に通過させ、ジッターバッファーを通過させるだけです（トラフィックが通過する際の品質が著しく向上します）ハーフグローブ）、ローカルで電話と通信するときにサーバー（およびトラフィック）の負荷の一部を削除し、あらゆる種類のテストに答えて問題をキャッチします。 これは、自宅で作業するオペレーターのエントリポイントです（原則として、Amazonへのホームユーザーリンクは、当社のオフィスよりも著しく不安定で高速ですが、通常、最寄りのオフィスへのリンクは同じ国内にあり、通常非常に良好です）。スキーム（すべての電話はプロキシ経由のみ）。 さらに、それは「防御の最前線」でもあります。 近い将来、そのようなユーザーのVPN接続に切り替える可能性がありますが、ハードウェアの面では5年前ほどのメリットはありません。



電話機自体は完全に交換可能で、実際には手動設定は不要です。IPを割り当ててDHCPを入力するだけで、その後すべてが自動的に行われます。電話機はIPと設定へのリンクを受信し、ダウンロードしてから、プロキシを介して登録します。サーバー。 同時に、新しい電話は特定の新しい内部番号を自動的に受け取ります（拡張機能）。 この番号からの電話はかけられず、彼への電話も受けられません。彼は、彼に加入しているオペレーターが自分の電話番号でこのデバイスにログインする可能性を含む、いくつかの非常に基本的なことしかできません。その後、このオペレーターの番号の呼び出しが送信され始めますこのデバイスは、以前の場所に移動しなくなります（オペレータがどこにもログインしていない場合、通話はボイスメールに送信されます）。 ネットワークテクノロジーとの類推で、電話の範囲がMACアドレスのようなものであり、オペレーターのログイン後にIPアドレスのようなものがハングアップした場合-オペレーターの個人的な範囲。 このように、コールセンターの作業のロジックは、その物理的なコンポーネントから切り離されています。すべてのビジネスロジック、レポート、優先順位などは、オペレーターの拡張（本質的に物理ではなく、むしろ論理オブジェクト）、デバイス自体の拡張で行われます-これは、このオペレーターが現在ログインしているポイントです。



フォールトトレランスに関するいくつかの言葉。



既に説明したように、テレフォニープロバイダーとの通信には、フェールオーバーメカニズムがあります。 残念ながら、オペレーター自体に関してはフェイルオーバーはありません。 まず、私たちが必要とするすべてを高品質でサポートし、さらにはリーズナブルな価格で提供できるオペレーターはそれほど多くありません。 第二に、テレフォニーでは、IPネットワークとは異なり、ルーターを1回動かすだけで別のプロバイダーに切り替えることはできません。 番号を別のプロバイダーに転送するのは時間とお金であり、それほど多くはありませんが、約1,500の番号では既に数日であり、各スイッチにはかなりの金額がかかります。問題が解決するまで待つ方が安くなります。 幸いなことに（電話事業者に敬意を表して）、中断はごくまれに、非常に短時間しか発生しません。 したがって、米国とロシアに1つずつ、着信コールのプロバイダーは2つしかありません。

サーバー（アスタリスク）、可能なすべての（および残りの少し）構成は、MySQLとの間で「リアルタイム」として送受信されます。 他のサーバーおよびWebインターフェースを介して行われた変更を確認するため。 最初は少しバグが多く、アスタリスクは数時間ごとに落ちていましたが、いくつかのパッチを適用して、多少安定させました。 したがって、どのノードでも、どのように構成を変更しても、次のアクションは、構成のこの場所に応じて、すべてのノードがすでに変更を認識しています。

数秒ごとに、すべてのノードが状態（呼び出しの数、平均負荷、アクティブなサービスなど）をMySQLに書き込みます。 したがって、これらのデータに基づいて呼び出しを配信するノードは、どのサーバーがオンラインで、誰が呼び出しを行う方がよいかを決定します（そして負荷は非常にスムーズに変化します）。 したがって、mysqlが稼働しており、メインノードの少なくとも1つが呼び出されている間、呼び出しが行われ、すべてが機能し、利用可能なマシン間で負荷がほぼ均等に分散されます（±小さなピークですが、常にある程度のマージンがあります）。 何らかの理由でノードの負荷が特定の合理的な制限を超え始めると、ノード自体は（単純なスクリプトを介して）コール自体の品質と安定性の損失を防ぐために、それ自体で重要度の低いサービスを停止またはブロックし始めます。 そのため、たとえば、あらゆる種類の重いレポートが最初にアクセスできなくなります。

MySQLとして、マルチアベイラビリティゾーンを有効にしたAmazonian RDSがあります。 そしてもちろん、あなた自身のオフサイトバックアップ。 理論的には、RDSインスタンスが停止した場合、参加せずにすべてを切り替える必要があります。 これが実際に起こったかどうかはわかりません。彼らは通知を受け取りませんでしたが、今のところすべてが時計のように機能します。 ただし、RDSが完全に停止した場合でも、30分以内に最も近いバックアップからすべてを再起動できます。 統計情報とログ（テラバイト）は存在しないため、レポートの一部は不正確になりますが、構成全体は1時間半より古いものではありません（非常にコンパクトなので）。

オフィスのVoIPプロキシは、Linuxのルーター上にあります。 各オフィスには2つのルーターがあり、それらの間でハートビートが実行されています。 1つが停止すると、すべてのサービス（VoIPプロキシを含む）が同じIPを持つ2番目のルーターですぐに動作を開始します。

また、各オフィスに2つのプロバイダーがあります。 1つが死んだり、グリッチが発生した場合は、2番目に進みます。 これは、電話の登録に関する問題が始まる場所です-IPは変化しています（サーバーは、呼び出しを送信するIPを知っている必要があります）。 これを行うには、すべてのプロキシが1分に1回、Web管理パネルの特別なURLにあるAmazonのサーバーにアクセスし、「現在のIPはそのようなものです」と言います。 一方、スクリプトはこの値をデータベース内の値と比較し、突然変更された場合は、データベース内のそれに関連するすべて（たとえば、現在の電話登録）を更新します。 ほとんどのリアルタイム構成（多くのオブジェクトに対する次のアクションは正しいIPで動作するため）から、このオフィスへの/からの呼び出しが再び行われます。

この設計全体（すべてのソフトウェア、voip-proxyなどを備えたサーバー）は、インストールスクリプトを使用してsvnで設計され、svn checkout ... && ./install.shメソッドを使用して、新しくクリーンなLinuxにデプロイされます。ある程度の構成が必要ですが、非常に小さいです。Amazonのサーバーの場合、+ 1プライマリまたはセカンダリサーバーをすばやく展開できる最新のスナップショットもあります。

各ノードにはapache + phpとphpスクリプトの完全なセットがあり、Webに関しては、すべてのノードは完全に同一です（すべてが同じmysqlに移動し、全員がメインノードでmemcachedを使用します）。 任意のマシンのWebインターフェースを介して、このすべての設計で何が起こっているかをリアルタイムで制御および監視できます。 Webインターフェイスは同じMySQLで動作します。 さらに、一部のコマンドは目的のノードのアスタリスクに直接送信されます。 たとえば、グループまたは品質管理部門のヘッドのWebパネルにある「このオペレーターとクライアントが今話していることを聞きたい」（これは新しいオペレーターをトレーニングし、不正なオペレーターをキャッチするときに不可欠です-私たちはお金で仕事をしています）

別の小さなインスタンスでは、nginxが回転し、Webへのすべての外部リクエスト（電話の自動設定、プロキシからのIPの更新、管理/統計へのアクセス）を実サーバーに解決します。 このインスタンスにはスナップショットがあり、数秒で新しい同じマシンを持ち上げ、そのような必要がある場合に古いIPをハングさせるスクリプトがあります。 この機械は非常にシンプルで原始的であるため、鉄を除いて、故障して死ぬものは何もありません。 後者は、上記のスクリプトによって解決されます（これまでのところ、テストを除き、使用されたことはありません）。

もちろん、電子メールとSMS（重大な状況について）による通知ですべてを監視しています。 この構造全体のコンポーネントに関する情報を収集するために、 NetXMS +自家製スクリプトのヒープの助けを借りて監視します。



負荷について。



奇妙なことに、主な負担は会話によってもたらされるわけではありません。 実際に、顧客と話すことは負荷の15〜25％です。 アスタリスクの観点から非常にリソースを消費するアクション。これは主に保留音とIVRです。 クライアントがオペレーターと通信すると、すべてのリーシュのアスタリスクがトラフィックをスローします。 クライアントが並んでいて、音楽を聴き、彼がどれほど重要で価値があるかを保証するとき、この時間に彼のためにこのオーディオストリームを作成します。 50人が並んでいる場合、その場で50のオーディオストリームを作成し、これらのストリームを既にクライアントに送信することを強制されます（これは単純化されており、実際にはこれらは異なるキュー、異なるIVRなどです。つまり、1つのストリームがあります。一部の電話交換で行われたように、すぐにすべての人に渡すことはありません）。



通話録音（またはボイスメール）をmp3に変換するのは非常に高価です。 しかし、電話からだけでなく、ブラウザ/作業中のコンピュータでそれを聴きたいという願望がある場合、これは避けられません。 そして、欲求があります。 はい、ディスク容量は再び節約されます。



Webインターフェースはさらに高価です。 あらゆる種類のレポートとリアルタイム統計は、リソースのブラックホールです。 可能な限り、ログを作成し、あらゆる種類のレポートでさらに使用するために統計を収集するアジシェクの海を見つけることができます。 コールごとに約5MBの異なるデータ。何か問題が発生した場合の完全なSIPトレースコールを含む。



これらすべてが処理されると、多くの有用な情報を取得できます。 「過去3か月間の夕方にこのエージェントに電話をかけたのはどの州ですか？」、「この部門からの不在着信の割合は？」、「このクライアントは今月何時に電話しますか？」、「SIPパケットの損失の平均割合は何ですか？」パキスタンに電話するとき？」など。



会社の各内部システム（CRM、広告管理、フロントエンド）は、あらゆる種類のリアルタイム統計を定期的に要求します。 たとえば、 yaturist.ruプロジェクトのフロントエンドには、少なくとも1人のエージェントが現在このプロジェクトのコールキューにサービスを提供している場合にのみ、オペレータと通話できる電話が表示されます。 その他の場合、電子形式でアプリケーションを提出するためのフォームが表示されます。



また、各プロジェクトの管理パネルは、XMLRPC呼び出しを通じて多くの重要なことを実行できます。 たとえば、顧客により良いサービスを提供するエージェントは、キューのサービス時に高い優先度を受け取りますが、特定の1日の販売制限を処理した後、優先度が低くなり、他に誰も残っていない場合のみコールを受信します。 したがって、「売上高を犠牲にして」ではなく、各クライアントとより徹底的に作業する必要があります。 VIPクライアントの呼び出しは、VIPクライアントとの作業を許可されたオペレーターのみに受けられ、適切でない場合は、オンラインで利用可能な最高のオペレーターに受けられます。 そして、これらすべては、常に要求される統計に基づいて、XLMRPC要求の束を通じてこれらのシステムの腸から絶えず「ねじれ」、アスタリスク構成を常に（「オンザフライ」）「ねじり」ます（MySQLで）。



統計のレポートと表示を禁止し、通話録音/ボイスメールと保留音をオフにし、XMLRPCを一時的にブロックします。理論的には、ピーク時にも1つのノードですべてを実行できますが、リソースはまだあります。 しかし...これを行うと、その意味が失われます。なぜなら、私の意見では、アスタリスクは、企業の発展と同時に絶えず「スピンアップ」できるようなビジネスニーズとの深い統合を生み出す素晴らしい機会だからです。 実践が示しているように、これは、3人用のミニPBXから、ほぼあらゆるレベルの複雑さの巨大なインストールまで、あらゆるものを構築できるプラットフォームです。



おわりに



それはむしろレビュー記事であり、多くの技術的な詳細が舞台裏に残されています。 私たちは皆あまりにも違うので、あなたにとって何が面白いのか正確にはわかりません。 このトピックに興味がある場合は、質問してください。 別の記事で、興味のある技術的な詳細に答えたり、説明することもできます。