2022年6月17日 / 最終更新日時 : 2022年6月17日 user 事例・ソリューション

本番環境でのテストの始め方

なぜ本番環境でのテスト (TiP：Testing in Production) を行うべきなのでしょうか？率直に言って、真実は、あなたはすでにTiPを行っているということです。本当の問題は、TiPを慎重に、専門的に、信頼できるものにするかどうか、それとも、TiPが事故や危機の源であり続けるかということです。

少なくとも、顧客に直接影響を与えるインシデントや停電を処理する手順があるという意味では、すでに本番環境でテストを行っていることになります。もう少し投資すれば、そのワークフローはソフトウェア開発ライフサイクル (SDLC) のための継続的で管理可能な資産になります。そのための方法は以下のとおりです。

定義を第一に

現在の目的では、本番環境でのテスト (TiP) はWebアプリケーションと関係があります。組込みソフトウェア、インストール可能なソフトウェアなどの話は、ここでは範囲外です。また、TiPは、パブリッシャーが最初に見つけるべき不具合を大量に顧客に見つけてもらうような仕掛けではありません。ほとんどのテストは、今でもSDLCのできるだけ早い段階（英文）で行われています。その代わり、TiPは、本番環境が効果的に代替できないいくつかの状況について、他のすべての形式のテストを補完します。

TiPは、ステージング環境では不可能だったり非現実的だったりする状況を可能にします。

極端な規模でのデリバリー
エラーリカバリーの実践
顧客の多様性を表現しつつ顧客のプライバシーを尊重するデータ
優れたROI

これら 4つのテーマの重要な点は以下のとおりです。

規模に対するTiP

アプリケーションの中には、単に規模が大きいだけで、その設備や負荷を複製するには法外なコストがかかるものがあります。たとえば、複数のグローバルネットワークトポロジーを維持するのは非現実的かもしれません。

原則的に、ほとんどの開発組織では、最終的なデプロイ前に製品を徹底的にテストできるステージング環境を維持しています。しかし実際には、基本的にすべてのステージング環境は、少なくとも規模という観点で本番環境よりも小さく（英文）なっています。つまり、ステージング環境ですべてのテストに合格した場合でも、本番環境への導入で新たな課題が発生します。連携するノードが1桁多くなり、キャッシュをより徹底的にシャッフルする（英文）ために何百時間も連続してトラフィックが発生し、異常なデータのロングテール、ステージング環境のサイズの倍数のスレッドプール（英文）、まったく異なるクエリーの最適化など、さまざまな課題が発生します。

ステージング環境は本番環境のモデルになり、適度な負荷でアプリケーションが予測どおりに動作することを検証する場となります。しかし、本格的な実行は本番環境でしかできません。

ビジネス継続性

TiPに注力することの利点の1つは、ビジネス継続性手法（英文）の有用な障害回復 (DR：Disaster Recovery（英文））を実践することです。優れたTiPチームは、不具合を迅速に診断し、それに対する最適な対策を判断し、いざというときには確実に既知の良好なリリースに戻す方法を知っています。TiPは、組織のデジタル回復力（英文）を検証するまたとない機会なのです。

実データ

TiPの有用性のもう1つの特徴は、テストデータの提供方法（英文）です。従来のテストでは、顧客データに近いデータを使用しますが、当然ながら、類似性が高いデータではありません。類似性が高いデータは個々の顧客のセキュリティとプライバシーを侵害するからです。

しかし本番データは、顧客データに類似しているものではなく、顧客データそのものです。本物そっくりのデータを生成するのは意外とコストがかかる作業であり、時に実データを正しく使用できることは大きなメリットとなります。

同時に、データが漏洩しないように厳格な管理を行う必要があります。”test-password ” でテスト用データベースにアクセスできることをプログラマーが誤って公開してしまうことは、そこまで重大な問題ではありません。しかし、実際の顧客の個人情報を一人でも公開することは重大な問題であり、多くの法域で違法（英文）です。

ROI

エンジニアリングとは常に選択することであり、コストと利益の適切なバランス（英文）を見つけることです。TiPは、他のテストが不可能な場合の最後の手段と考えるべきではありません。むしろ、TiPが利益を生むような状況を考えてみてください。

たとえば、特定の負荷テストにおいて、顧客データを適切にモデル化したテストデータを作成することは可能かもしれません。このようなテストをTiPで行うことで、経験豊富なアナリストがデータ合成から解放され、直接的に収益を上げる分析に集中できるようになれば、TiPは直ちに利益につながります。

TiPを最大限に活用するためのヒント

TiPを実現するための最も重要な第一歩は、TiPを検討する柔軟性です。しかし、それを実現するためには、まだまだ多くのテクニックが必要です。実際、TiPはそれ自体が1つの専門分野（英文）といえるほど大きく有益なものに成長しています。特に、デプロイ、リリース、ポストリリースの3つのフェーズにおけるTiPのテクニックは、間違いなく、従来のプリプロダクション（実稼働前）ソフトウェアテスト（英文）のすべてと同じくらい洗練された複雑なものです。この範囲の手法を包括的に扱うことは、この紹介の範囲をはるかに超えています。

しかし、TiPに関するいくつかの広範なヒントは、記録しておく価値があります。

フィーチャートグルを設計や実装の中で自然に使用できるようにする

この後に続くすべてのヒントは、TiPの戦略的な役割を促進するものです。フィーチャートグル（英文） (開発者はしばしば「フィーチャーフラグ」と呼ぶ) は、たとえば分析作業などには便利ですが、それをはるかに超える利点があります。それは、市場投入までの時間を短縮し、アジリティを向上させる点です。また、複雑な結合を切り離すこともできます。フィーチャートグルは、デプロイ、テスト、フィーチャーデリバリーのスケジュールをより独立したものにします。その結果、デプロイのスケジュールはリスクを最小限に抑えることができ、テストのスケジュールは従業員の予定に合わせることができ、機能提供は市場機会を最大限に活用するために自由に行うことができます。信頼できるフィーチャートグルは、これらの異なる領域間の相反する関係をはるかに容易に管理できるようにします。

このように、フィーチャートグルは、TiPを単にリソースの制約に対処するためのテクニックではなく、機能的なチームワークを強化して顧客に価値を提供するまでの時間を短縮する戦略として役立てることができます。

人的リソースをスケジュールし、アプリケーションの負荷が最も低い時間帯と場所に最初のTiPの取り組みを集中できるようにする

TiPは確かにリスクがありますが、良い計画を立てればリスクの大部分を取り除くことができます。楽ができるように物事を簡単にしましょう。顧客の要求が少なく、テストやエンジニアリングのスタッフが十分にいるときに計画的にTiPをスケジュールします。単純なTiPで試し、そこから構築してください。何をすべきかがスタッフに分かるくらいTiPが日常的なものになり、そしてすべての恐怖心がなくなるまで、このプラクティスを続けます。

アプリケーションを監視・測定し、顧客が見ているものを見ることができるようにする

顧客からの苦情に対応することは良い中間目標です。しかし、さらに進化した目標は苦情を予測することです。アラームとモニタリングを組み込むことで、顧客が気付く前に、問題にスポットライトを当てることができます。TiPを難しいと感じるたびに、その認識を自動化またはダッシュボードに変えて、エンジニアリング組織が顧客よりも一歩先を行くのを助けましょう。