yota.ruポータルのアップグレード方法

しばらく前に、ポータルwww.yota.ruを完全に再編集しました。 前のバージョンに比べてある程度の継続性がありましたが、サイトは完全にやり直されました（フロントエンドとバックエンドの両方）。 この大規模な近代化の必要性は、ヨータが携帯電話事業者としてサービスを提供し始めるとすぐに成熟しました。 以下に、なぜサイトをやり直す必要があるのか​​、どのタスクを解決したのか、どのような困難に直面し、現時点で達成したのかを説明します。



サイトの近代化とその後の決定の理由は、フロントエンド（デザイン、サイトマップ、ページ構造）とバックエンドに関連する2つのグループに分けることができます。 それぞれを個別に検討しましょう。

フロントエンド：設計と構造

2014年8月まで、Yotaは4Gワイヤレスインターネットの分野でサービスを提供し、ポータルの機能と機能はユーザーのニーズを満たしていました。 しかし、Yotaがモバイルオペレーターのステータスに移行したため、新しい要件がサイトに提示され始めました。



ヨータの申し出は、今日のモバイル市場で提示されているものとは異なることは言うに値します。 ポータルは単なる情報リソースではなく、すべてのサービスを独立して管理するために設計された重要なユーザーインタラクションツールであるため、まず、Yotaで発生した変更を反映する必要があります。 さらに、変更されるのはデザインだけではありませんでした。



サービスの範囲の拡大に伴い、サイトでのナビゲーションはより困難になりました。 ユーザビリティテストの結果によると、必要な情報を取得するために、ユーザーは非常に多くの不必要な動きをしなければならなかったことが判明しました。 要素とブロックが十分に明確かつ論理的に配置されていなかったため、目標に到達するまでに、訪問者はクリック数を増やしました。たとえば、都市を選択してカバレッジマップを表示します。



フロントエンドの変更の2番目の重要な理由は、内部構造のスケーラビリティの予備がなかったことです。 新しいサービスの出現とプレゼンスの地域の拡大により、サイト自体の構造を変更しない限り、コンテンツの拡大が非常に困難になるという事実に直面しました。 はい、それはあまり良く見えませんでした。



新しいデザインの作業を開始する前に、ターゲットオーディエンスの調査を実施しました。 明らかに、新しいサイトを設計するとき、特定のスタイル要件によって制限されていました。既存のコーポレートカラーとヘッドセットを使用する必要がありました。 さらに、サイトの設計には完全に明確なメッセージを伝える必要がありました。私たちは他のオペレーターとは異なり、サービスを非常に簡単に使用できます。



サイトの構造の観点から、次の問題を解決する必要がありました。 メインページを通じて、最大70％のユーザーがポータルにアクセスします。 そして、ここで適切な情報を見つけるか、ワンクリックで目的のセクションに移動できるようにすることが重要でした。 たとえば、ワイヤレスモデムを購入する前の主な質問の1つは、「自宅/オフィスでネットワークをカバーしていますか？」です。したがって、メインページを1回クリックするだけで、このことを知ることができました。



もう1つの重要なポイントは、以前のバージョンのポータルのメインページに関連していました。 メインページにアクセスしてからサイトを離れたユーザーの約25％。 長い間、この動作の理由を特定できませんでした。 開発中に実施されたUXテストでは、一部のユーザーは単にサイトメニューを回ることを望まないことが示されました。 理解し、目的のリンクを検索し、それをクリックする必要性は、過度のサイトの複雑さとして認識されていました。 メインページにモデムとSIMカードを注文するためのモジュールを配置するとすぐに、「refuseniks」の数が急激に減少しました。



UXテスト中に、ページ上のさまざまなコントロールの有効性もテストしました。 多くの興味深い点に加えて、以前のバージョンのポータルと比較して1.5倍にボタンを増やすと、ユーザーがボタンを2回クリックし始めたことがわかりました。

バックエンド：サイトプラットフォーム

新しいポータルの開発には、サイトのベースとなっているプラ​​ットフォームの変更が伴いました。 当時使用されていたBitrix CMSは、すべての要件を満たしていませんでした。理由は次のとおりです。

• システムには非クラスター構成がありました。つまり、サイトの全負荷が1つのPHPサーバーに落ちました。 そのパフォーマンスリソースはほとんど使い果たされ、サイトの過負荷とアクセス不能のケースがありました。 また、クラスタリングをサポートするBitrixのバージョンへの移行は、コードの大幅な改訂を意味しました。
• すべてのコンテンツの更新は本番サーバーで直ちに行われ、エラーが発生した場合、サイトのパフォーマンスに反映されました。 つまり、事故率を下げる必要があり、それによってユーザーのサービス品質が向上しました。
• システムは、CMS Bitrixの機能を使用して、会社の事業単位の従業員によるコンテンツを自己編集しませんでした。 すべての変更は、特定のファイルを手動で編集することで行う必要があり、この責任はBitrixをサポートするプログラマーとIT部門にあります。 これは、リソースの追加コスト、インフラストラクチャのサポートとメンテナンスのタスクからのIT専門家の注意散漫などを意味していました。 サイト管理がIT部門に移管される頃には、この管理方法は完全に使い果たされていました。 サイトのコンテンツを入力して更新する義務から技術専門家を解放する時が来ました。 コンテンツを編集するためのコストと時間を削減し、最小限のメンテナンスコストで高可用性とパフォーマンスを提供するために、CMS機能の使用を最大化するソリューションを設計および実装する必要がありました。

Bitrixのさらなる開発の可能性の分析は、すべてのニーズを考慮して実行されました。 移行は非常に困難だったため、このパスは非実用的と見なされました。クラスタリングでは、Bitrixバージョンのアップグレード、モジュールの購入、コードの大部分の処理が必要でした。 最終的に、私たちが望むほど多くのコンテンツ管理の機会はありません。 つまり、技術者はまだ多くの非コア作業を実行する必要があり、他のシステムの場合は、それを会社の関連するビジネスユニットに転送できます。 そして、アーキテクチャと技術サポートに関連するアクセシビリティの問題。



そこで、Bitrixを思い起こさせるか、新しいCMSを導入するという選択に直面しました。新しいものを選択しました。 問題は小さいままでした：特定のシステムを決定すること。 独自のクローズド製品からソリューションプロバイダーへの完全な依存に至るまで、さまざまな提案が検討され、関連するすべてのリスク、未知のパフォーマンス、機能性、不十分なメンテナンスを伴うRubyでシステムを最初から作成しました。



その結果、 Liferayシステムを優先して選択が行われました。 このプラットフォームは、かなり豊富で柔軟な機能を提供しますが、これについては後で説明します。 重要な利点の1つは、システムのオープン性でした。ほとんどの場合、当社は製品の操作と機能を制御するだけでなく、ニーズに合わせて柔軟な構成を実行する機会を提供するため、オープンソーステクノロジーに依存しています。 Liferayの利点は、他のシステムや技術との均質性（主にJEE技術を使用）やメンテナンスの容易さなどです。 Liferayの展開中に、既存のインフラストラクチャ（オペレーティングシステム、アプリケーションサーバー、データベース）の使用を最大限に活用できたという事実を含め、Liferayの導入は特定の環境要件を提示しませんでした。



将来の痛みのないスケーリングが可能な新しい構成では、次のスキームが採用されました。アクティブクラスターモード（つまり、両方のデバイスがアクティブ）の2台のサーバーがサイト自体とサイトへの要求を処理します。 別のサーバーにコンテンツ管理のタスクがあります。 つまり、サイト自体のサーバーは積極的にバックアップされ、認証システムと統合されたYotaのさまざまな部門の従業員が働くサーバーは、企業サブネットに隠されています。

生産性を向上させるために、高性能アプリケーションによく知られたソリューションを使用しました。サイトで使用されるグラフィックファイル、テキスト、CSSファイルなどを含む多くのNginxサーバーをインストールすることにより、CDN（コンテンツ配信ネットワーク）モデルを実装しました。 したがって、サイトのサーバーから静的コンテンツを配信する負担を完全に取り除きました。 また、このソリューションは、Nginxサーバーの数を負荷の増加に応じて何度も増やすことができるため、その後のスケーリングも簡素化します。







コンテンツマネージャサーバーは、バッファ、事前調整ツールとして機能します。 たとえば、ある部門の従業員がサイトでニュースやその他の情報を公開したい場合、データはコンテンツマネージャーサーバーに送信され、そこでその従業員のヘッドによって承認される必要があります。 これらのすべてのワークフロー、ワークフローは、統合されたBPMNエディターであるActivitiを使用して柔軟に構成できます。 コンテンツの承認後、サイトに公開されます。 この手順は、管理者が手動で実行することも、スケジュールに沿って自動で実行することもできます。 たとえば、夜間の出席が最小限の場合。 このような作業計画-ステージング、つまり段階への分解-により、コンテンツの変更を管理し、事故を防ぐことができました。 これで、サイトにアップロードせずにすべての変更をテストできます。



コンテンツ編集に関するLiferayのもう1つの利点は、WYSIWYGイデオロギーです（表示されるのは取得したものです）。 つまり、すべての変更はプログラムコードではなく、便利なグラフィカルインターフェイスを使用して行われます。 管理者権限を持つ管理者は、CMSサーバー上のブラウザーでサイトのコピーを開き、必要な要素をマウスで移動して追加し、テキストに直接変更を加えた後、変更を確認して、ユーザーにとってサイトがどのように見えるかをすぐに確認できます。 これにより、サイトの作業バージョンのレイアウトのタイプミスやエラーを回避できます。



個別のタスクは、デザイナーからサイトの変更の開始まで、サイトの開発と修正のエンドツーエンドプロセスの編成でした。 YotaのWebサイト（会社自体と同様）は非常に動的に開発されています-私たちは絶えずその改善に取り組んでいます-ここでは、新しいアイデアを実装するプロセスを可能な限り迅速にすることが非常に重要でした。 「アイデア」からサイトへのパスに最小限の時間がかかるように、いくつかのチームの作業を整理しました。 これは、開発/テスト/配信（Git、Grunt、プリプロセッサのセット）のためのブランチ上の定数アセンブリ、およびたとえば次のようなルールを反映するレイアウト標準に基づいています：機能的スタイルの混合の禁止; iFrameの禁止、コンテナへのハッシュタグの配置など。



多くのLiferay開発者は、JavaScriptをポートレットに統合するという問題に直面しています。 また、私たちの前に現れ、開発標準に反映された次の解決策を見つけました。グローバル変数の禁止、backbone.jsを使用してモジュール間の依存関係を管理、system.js、モジュールを接続。 すべてのJSモジュールパラメーターは、コンストラクター（ローカライズされたテキストリソース、DOM要素セレクター、バックエンドREST API要求パラメーターを含む）を介して設定されます。これは、ポートレットのレンダリング時にポータルによって初期化されます。 コンストラクターはデフォルトの呼び出しパラメーターも提供します。 jQueryを介したJavaScriptコンポーネントの相互作用。



これにより、おそらく技術的な深みから現れ、要約しようとするでしょう。

結果

エンドユーザーにとって、この作業の最も顕著な結果は、ページのデザインと構造の変更でした。 フロントエンドのパフォーマンスが向上しました。これは、特に個別のサーバーの静的要素が削除されたためです。 同時に、静的サーバーのクラスタリングと実装により、高負荷時の事故の可能性を排除することができました。 トラフィックが多い状況でも、サイトのパフォーマンスは低下しません。



Yotaの従業員がサイトを変更するという観点から、この手順は大幅に簡素化されました。

• プログラマーの参加なしにサイトの構造を変更できるWYSIWYGエディター。
• あらゆる部門の従業員のコンテンツへのアクセス。
• 行われた変更の承認プロセスの実装
• サイトでの完全に制御された公開プロセス。

現在、機能とパフォーマンスの両方の面でLiferayの機能の20〜30％しか使用していません。 したがって、実行されたバックエンドの近代化は、一時的なニーズだけの解決策と見なすことはできません。 これは戦略的なステップであり、将来、新しいサイトの機能と顧客のセルフサービス機能の拡大の両方について、新しいタスクをより迅速かつ効率的に解決できるようになります。