そして今、このようになっています：
物語はほぼ2年前にちょうどHabrに到着したときに始まりました 。 最初のトピックは、特に、バグレポート、ヒント、アイデアについてでした。 特に、多くのオファーが古い個人アカウントにありました。 問題はそこでの迅速な変更に限定されないため、システムのほぼ完全な交換を開始しました。
最初に、なぜ彼らがゼロからそれを行うことにしたのかを説明します。 アーキテクチャを完全に整理する機会となりました。 古い個人アカウントは、少なくとも10年前は機能していましたが、スケーリングせず、特定の制限がありました。
技術部
32ビットプラットフォームが使用され、使用されるRAMのサイズに特定の制限が課されました。また、製造元によってサポートされていないことが多いレガシーAPIの使用は、Javaベースのアプリケーションの安定性に悪影響を及ぼしました。
ロードバランシング用の古いバージョンの個人アカウントは、HTTPセッションバランサーの機能のみを使用していました。 同時に、アプリケーションサーバーの1つで問題が発生した場合、そのようなアプリケーションサーバーに関連付けられている現在のユーザーセッションは失われました。
ソリューションのモジュール性が低く、プレゼンテーション層に大量のロジックが存在するため、アプリケーションアーキテクチャが「モノリシック」になり、単純な変更の開発とテストにもかなりの人件費が必要になりました。 また、水平スケーリングが複雑になり、アプリケーションの全体的な速度が低下しました。 その結果、特定の操作、特に請求書やクライアント情報の出力など、パフォーマンスに敏感な操作が不必要に長時間実行されました。 さらに、月の初めの最初の請求サイクルのアカウントの処理には数日かかる場合があります。 問題は処理アルゴリズムで、一時データがディスクアレイに保存されていたため、作業が遅くなりました。
64ビットプラットフォームに切り替え、レガシーライブラリの使用を放棄しました。 現在、フォールトトレランスと負荷分散を向上させるために、クラスターはアプリケーションサーバーレベルとデータベースレベルの両方で使用されています。 個人用アカウントの新しいバージョンの設計と実装中に、関連システムとの統合が改訂され、大幅に変更されたため、非常に困難でした。
「エンジニアリング」インターフェースから「人間」への移行
特にポストペイド支払いシステムの加入者に関して、重要な変更がシステムの機能に影響を及ぼしました。 グループ操作の機能、アドレス帳、グラフとチャートを使用した財務情報の視覚的表現、ユーザーレポートのデザイナーがあり、ユーザーは自分でパラメーターとフィルターを設定できます。
以前のバージョンと比較して、すでに起動時に新しいシステムは、サブスクライバーの数で3倍、同時トランザクションの数で約5倍の容量を持っています。 そのため、現在1秒あたり約100のトランザクションが処理されています。 ただし、大きな負荷をかけることはできます。
データ量に関して、システムは約8,000万人のサブスクライバーを格納し、それぞれのサービス、料金、残高、アカウント、注文の詳細およびその他の情報を格納します。
以前のバージョンの問題の1つは、請求書処理の速度でした。 約4 TBのアカウントが毎月新しい個人アカウントを通過します。
この場合、アカウントの大部分は、月初めの最初の請求サイクルに該当します。 新しいソリューションでは、アカウントデータをさらに処理できます。
3倍以上の速さで、8時間で敷設できます。
さらに、これは非常に重要であり、容量の拡張に関する初期の体系的な制限が解除され、必要に応じて、市場の要件に基づいて徐々に拡張できます。
さらに、個人アカウントは、多数の内部システムへのインターフェースです。 現在、請求システム、プリペイドプラットフォーム、コンテンツプラットフォーム、ウェブサイト、CRMシステムなど、15を超える情報システムとの統合が実装されています。複雑な統合チェーン全体の高速で信頼性の高い運用を確保する必要があります。
インターフェイスの哲学
「前」と「後」のプロファイル
古い個人アカウントと新しい個人アカウントの同じ画面のスクリーンショットの比較を見てください。 要素を再編成し、情報の認識に関してユーザーにすべてを最大限に集中させ、ほとんどの用語をロシア語の話し言葉に翻訳しました（加入者がコールセンターに連絡するときにこれらを呼び出すため）。
主なタスクは、キャビネットが特別な知識を必要とするものとして認識されなくなることです。 ヨーロッパの例では、高齢者がオペレーターの個人アカウントに簡単に出入りして、ユーザープロフィールを変更できます。 （ノルウェーでは、ローカルオペレーターの加入者の約半数が個人アカウントを使用しており、私たちはわずか数パーセントです）。
目標達成の違いは、ほぼ1桁です。
原則として、コールセンターへの呼び出しには基本的な理由があります-残高への懸念 。 より正確には、質問：「私は過払いではないのですか？」 たとえば、このトピックの読者の大部分は、現在の関税またはテレビで宣伝されている関税について、彼らにとってより有益なものを知らない可能性があります。 技術的な知識のないお客様にとって、オペレーターに尋ねる最も簡単な方法は簡単です。 そのような仕組み-新しいビデオが出ました。コマーシャルの休憩中に男性がそれを見て、心配になり、チェックすることに決め、私たちに電話しました。 これには、お金が来たかどうかのチェックも含まれます：「昨日、ターミナルに100ルーブルを入れました、彼らは来ましたか？」そして、償却質問。 一般的に、加入者は制御が必要です。 メイン画面で適切なデータの最大値を一度に収集し、さらに迅速なステートメントを作成することにより、このコントロール感を与えようとしました。 ステートメントを使用すると、アカウントで何が起こったのかを正確に理解でき、多くの人にとって非常に喜ばれます。 そしてここでは、技術的な部分（理由はすでにわかっています）を引き出して適切なインターフェースを作成することが重要でした。
財務情報
プロトタイプとテストの作成方法
入り口には、ユーザーが必要とするものに関するデータ（ロシアで最も有名なユーザビリティ研究所の1つがあります）、Lebedev Studioのスペシャリストのビジョン、そして何が可能で何ができないかに関する技術専門家からのデータがありました。 プロトタイプが判明し、最初に私たちの方法論に従ってテストされた後、ステートメントとテストの反復に進みました。
生きている人々との相互作用の視覚的結果
テストは次のように行われました。コールセンターに電話をかける一般加入者のプロファイルに従って、「通りから」人々を募集しました。 彼らは彼らの前で彼らの個人アカウントの特定のプロトタイプを立ち上げ、彼らがユーザーに直面する形でタスクを設定しました。 たとえば、「過去15日間の明細書を作成する」ではなく、「前回の旅行中に行ったウクライナからの電話料金はいくらだろうか？」ではなく、「関税オプションを接続するなど」ではなく、「明日あなたは行くキエフに、親relativeに電話する方がどれだけ安いか見てみてください」。 男性自身がオフィスを調査し、解決策を探しました。 彼の目の動き、マウスの動き、クリック、さらに「横から」の一般的なビデオを書きました。 このようなテストは、各レイアウトで何百回も実行されましたが、「ランダム」な人のほとんど（新しい反復の前にタイプした）のほとんどが非常にうまく機能することが明らかになりました。
その後、非常に長いベータテストがあり、Habrも大いに役立ちました。1時間のhabraeffectで、1週間でテスターと同じ数のエラーが見つかりました。
引き続き改良を続けており、異なるSIMカードへのアクセスを1つのアカウントに制限しているため、すべての個人アカウント（自宅のインターネットアカウントを含む）を1つにまとめることも計画しています。