*この記事に記載されているものはすべて開発中であり、まだ公には発表されていません（ほぼ排他的）ので、動作が異なる場合やまったく動作しない場合があります

こんにちは

今日は、まだ公表されていないが、Testing In Production（TiP）と呼ばれるMicrosoft Azure Webサイトで既に使用可能なサービスについてお話します。 これにより、クラウドWebアプリケーションのテストをより微妙かつ正確に開始し、ごく一部のユーザーの新機能を表示して、ほとんどの訪問者を安全に保つことができます。 TiPを使用する1つの方法は、さまざまなシナリオで使用できるA / Bテストを使用することです。 要点を説明する前に、まずそれが何であり、何のためであるかを説明する必要があります。

A / Bテスト

方法論自体の名前に依存している場合、 A / Bテストは、製品のいくつかの2つのバージョン（AとB）をテストしているという事実について推測できます。 より具体的には、この手法（スプリットテストまたは実稼働環境でのテストとも呼ばれます）を使用すると、変更可能ないくつかの要因に応じてWebサイトユーザーの行動を分析できます。 たとえば、新しい機能を導入したいが、それが忠誠心とコンバージョンにどのように影響するか完全にはわかりません（何かを販売する場合）。 個人的な判断と好みに基づいて誤った仮定を立てないようにするために（悲しいことに、多くの場合、多数意見とは関係ありません）、サイトの以前のバージョンと並行して動作する新しい機能を起動して、あちこちのトラフィックの50％を導くことができます。 次に、得られた結果（メトリックからのデータ-変換、ページ遷移、コメント数など）に応じて、新しいソリューションが成功したかどうか、およびその将来の運命を決定します。 ％または完全に削除されました。

実際、A / Bテストははるかに複雑なものです。 統計からの多くの理論が含まれています。なぜなら、新しい機能の成功に関する決定はバランスが取れていなければならず、非常に具体的な理由があるためです。 たとえば、何かを販売しているオンラインストアを所有していて、12月25日からクリスマスツリーを販売すると決定した場合（ただし、これをA / Bテストの形式で入力）、もちろん12月25日から12月31日までオプションBは、単純にプラスの変換結果で輝きます。 突然非常に賢いビジネスオーナーではないことが判明した場合、結果が肯定的であるため、これらのツリーを常に販売用に残して、「ライブの新機能」を追加することを決定できます。 ただし、明らかな理由により、クリスマスが終了する1月7日以降のどこかにひどい失望を感じるでしょう。 そのため、新機能の起動またはロールバックに関する決定は統計的に正確である必要があることを理解することが重要であり、これには監視に長い時間が必要です。

A / Bテストとそれに関する統計調査の詳細については、 インターネットで見つけることができます。あなたの良心に任せます。 次に、Microsoft Azureでホストされているサイトのテストをどのように整理できるかを検討します。

テクノロジー

すでに理論的な部分をマスターし、統計とは何か、そしてどのように統計を理解していると仮定します 操作する 使用する。 しかし、今疑問が生じます-技術的な観点からA / Bテストを実装する方法は？ あなたがウェブサイトを持っている場合、どの特定のユーザーをどのオプション（AまたはB）に送信するかを彼（またはサーバー）がどのように理解できますか？ 誰がこれを行うべきか-直接WebアプリケーションまたはWebサーバー？ さらに進むと、次の質問が発生します。 新しい訪問者をどうしますか？ どういうわけか、訪問者の合計数が同じままになるように、オプションに従って配布する必要があります。 また、サイトに戻って、以前にサイトにアクセスし、既に実験に参加したユーザーをどうすればよいでしょうか？ ランダムに再配布するか、以前に所属していたグループに送信できます。 そして、この全体を監視する方法は？ 結局のところ、一般的な条件付き変換（増加または減少）を分析するだけでは不十分であり、各オプションに応じてこの変換がどのように動作するかを理解する必要もあります。

分割テスト用の組み込みソリューションは、たとえばMailChimpによって提供されます。 A / Bテストはマーケティングツールとして正確に使用されることが多いため、メーリングリストでの使用は正当化されています。 ウェブサイト用の同様のツールがあります。 たとえば、 Optimizely 、 Visual Website Optimizer、 Google Analyticsなどです。 しかし、それらはすべてコンテンツのみを操作できるため、一部の動作（またはまったく新しい機能）をテストおよび分析することはできません。 これらのツールは純粋にマーケティングであり、技術製品での使用には適していません。 コメントの誰かが、最小限のコストでアプリケーションのA / Bテストを実行できる他のサービス（またはWebサーバー用の既製のソリューション）を提供できることを願っています。 そして、このような問題を解決するためのMicrosoft Azureクラウドの新機能について説明します。

本番環境でのテスト

本番環境でのテスト（TiP）の概念は最近Azureに登場し、現在も開発中です。 同社はこのサービスをまだ公式に発表していませんが、 新しいAzure管理ポータルで既に利用可能であり、実際に試してみることができます。

実際、TiPは、次の実装の成功を評価するための統合アプローチとしてのA / Bテストではなく、A / Bテストではありません。 TiPプラットフォームには、いくつかの基本的なテストタイプがあります（用語が英語であることは残念ですが、間違った翻訳を指定するリスクはありません）。

• カナリアテスト-アイデアの成功を評価するために、少量の外部ユーザーで初期バージョンまたは製品のプロトタイプをテストします。
• ランプアップテスト（Canary Deploymentとも呼ばれます）は、テストに関与するユーザーの割合が徐々に増加するプロトタイプテストプロセスです。 実際、これは大きなリスクを回避できるエラーが存在する場合の、新しいソリューションの遅い展開です
• 回復テストは、正確なテストではありません。 サーバーと戦うために新しい機能をリリースし、重大なエラーを検出すると、即座に以前の安定バージョンにロールバックします。これは、展開の複製の形のままです。
• A / Bテストは、私たちが始めた場所であり、以前のすべてのビューをとにかく減らすことができるものです。

これらのさまざまなテストアプローチはすべて、Azureの1つの技術ソリューションを中心に構築されているため、多くのドキュメント（ちなみに不在、ちなみに）を調べたり、さまざまなパラメーターを構成したりする必要はありません。 すべてが1か所で行われ、使用方法を正確に決定するのはユーザー次第です。 最後に、実用的な部分に移りましょう-Webアプリケーションの新機能をどのように取得しますか。

準備する

Production in Testingのサービスの使用を開始するには、サイトがまずMicrosoft Azureクラウドで動作し（これは明らかです）、次に標準構成レベルを持っている必要があります。 この要件は、テストのために、標準レベルのみにある新しい展開スロットを作成する必要があるという事実が原因です。


テストするサイトを選択してください

そのため、必要なWebサイトを選択し、設定パネルに移動します。 一番下のどこかに、Testing in Productionと呼ばれる大切なボタンがあります。このボタンをクリックすると、新しいサービスを作成するためのウィザードが開きます。


テスト作成リンク


テスト作成

新しいバージョンを展開するためのスロットを作成するように求められます。 必要なスロットの数を自分で自由に決めることができるため、ここから創造性の範囲が始まります。 また、テストに参加するためにも、これに関係なく、スロットを使用できることを理解する必要があります。 内部テスト用に個別のスロット（たとえば、継続的インテグレーションを構成した場合）、個別のスロットサンドボックス、個別の特定の機能などを設定できます。 同時に、同じスロットに基づいて、A / Bテストを整理することができます（以下について）。

スロットを追加するには、その名前と構成ソースを指定する必要があります。そこから別のスロットの設定をインポートできます。 ところで、名前のプロダクションはアプリケーションのメインバージョン用に予約されているため、Azureがこの名前を誓ったとしても驚かないでください。


新しいスロットを追加する

必要な数のスロット（たとえば3つ）を作成して、意味のある名前を付けましょう。


スロットリスト

実際、各スロットは独立したサイトであり、<メインサイト名>-<スロット名> .azurewebsites.netという形式のリンクからアクセスできます。 通常のサイトと同様に、パブリッシュプロファイルを使用するか、他の使い慣れた方法でコードをスロットにデプロイできます。

すべてのスロットが特定され、必要な機能がスロットに存在すると、テストの準備が整います。

テストセットアップ

ソリューションのテスト（A / Bまたはカナリアテスト）を開始するには、ユーザーのどの部分にどこにリダイレクトするかを指定する必要があります。 [実稼働環境でのテスト]パネルに戻ります。ここで、スロットごとのユーザーの分布の割合を調整できます。


テストオプションの追加

テストに新しいスロットを追加すると、いつでもメインサイトにリダイレクトされるユーザーの数を確認できます。 オプションがほとんどない場合、それはそれほど重要ではありませんが、新しい機能を積極的に使用し、多数のテストを実行し始めると便利です（幸運を祈ります！）。

ところで、各スロットは本格的なWebアプリケーションの一種であるため、ツリーテスト（テスト内のテスト）を使用して、より複雑なスクリプトを整理できます。


ネストされたテスト

上記の例では、ネストされたテストのスクリプトでは、データベースの役割は本番スロットではなく、選択されたテスト（この場合はtest-1）が果たしていることがわかります。 全体像を分析すると、次の結果が得られます-すべてのユーザーの10％がtest-1に送られます。 その後、50％がこのオプションに残り、さらに50％（最初の10％のことを忘れないでください）が実稼働に送り返されます。

テストのオプションが1つしかない場合は、統計と特定の指標に基づいて、50％のユーザーをデータベースに送信し、50％のユーザーをオプションに送信して、均等な分布を取得し、成功について決定するだけです。 しかし、複数のオプションを一度にテストする場合はどうでしょうか？ または、訪問者の50％がすぐに新しい機能にアクセスしたいのに、自分を10％に制限したいのではないでしょうか？ この場合、どちらの場合も訪問者の選択（絶対数）が異なるため、オプションとデータベースの比較は正しくありません。 このようなシナリオでは、最初にテストバージョンでユーザーの一部のみを切断し、その内部でデータベースに50％を「戻す」ときに、ツリーベースのアプローチを使用できます。 この場合、適切な監視により、同じ値に基づいて信頼できる結果を確認できます。

この配布はすべて、Webサイトの背後で行われるため、ユーザーは必要なページのURLを入力するだけです。 バージョンの置換は、リダイレクトや追加コードなしで、気付かれることなく行われます。 ただし、開発者として特定のオプションへの直接アクセスが必要な場合は、直接リンク（オプションsite.azurewebsites.net）を使用していつでも参照できます。

仕組み

これまでのところ、これがどのように配置されているかについてはほとんど情報がありません。 ただし、開発者としてテストの正確性についてあまり心配する必要がないように、TiPが背後で設計されていることを知っています（幸いなことに、これを共有することは禁じられていません）。 新しいユーザーが最初にサイトにアクセスすると、サービスはそれを決定するオプションを決定します。 これがどのように起こるかはまだ不明であり、すべてが単語に限定されていますが、興味があれば、詳細を調べることができます。 サーバーがユーザーの正確な宛先を決定すると、対応するCookieがサーバーに割り当てられます。 その後、サーバーはそれを使用して、訪問者が戻ってくることを決めた場合に、この訪問者をどこで識別するかを決定します。 これにより、ユーザーがCookieを削除することを決定するまで、同じ人が同じオプションに接続されることが保証されます。


クックを設置

モニタリング

これまでのところ、テスト結果を監視するための既製のソリューションはなく、適切なサービスを自由に選択できます。 Azureに組み込まれているアプリケーションインサイトサービスを使用すると、訪問などに関する統計情報を収集できます。 GoogleアナリティクスまたはYandex.Metricaの構成を試みることができます。 しかし、いずれにせよ、Microsoftが何を思いついたとしても、それぞれに独自のコンバージョンがあるため、コンバージョンを自分で追跡する必要があります。 たとえば、誰かにとってはコンバージョンはクリックスルーであり、誰かにとってはインストールされたアプリケーションまたは肯定的なフィードバックです。 いずれにせよ、それはすべて特定の製品とテストの目的に依存するので、普遍的なものを待たないでください。 MicrosoftはTiP用に特別に調整された監視ツールをすぐに表示するでしょうが、それらはすべての病気の万能薬ではなく、これを明確に理解する必要があります。

次は何ですか

この記事を読んだ後に生じるかもしれない合理的な質問は、「そして、私は生の製品で何をすべきですか？」です。 この記事は、サービスの公開前に、まだ開発中であるときに、意図的に作成しました。 私の目標は、まず、Webアプリケーションをテストするための非常に便利なツールについて話すことです（ちなみに、A / BテストはFacebook、Booking.com、および他の多くの企業で行われます）。あなたのフィードバックで、開発チームがサービスを改善するのを助けてください。 彼らは、まだやるべきことがたくさんあり、多くのチップがPowerShellからしか入手できないことを正直に認めていますが、作業は進行中であり、すぐにこのサービスは機能し、利益をもたらします。 あなたが最前線にいるのが好きなら、これは他の人の前に何かを試す素晴らしい機会です。

Azure Testing In Productionの動作例を示すライブビデオ-http://channel9.msdn.com/Shows/Web+Camps+TV/Enabling-Testing-in-Production-in-Azure-Websitesがあります 。

PS

本番環境のテストの新機能を独自にテストし、エラー/問題が発生した場合、または改善のための提案がある場合は、このことについて私に連絡してください。 このサービスを改善できるよう、すべてのフィードバックを開発チームに直接送信するようにします。