リリース前テストの重要性：本番前環境の外形テストでドリフトを検出

3. 本番前テストの結果を本番移行の判断基準にする

本番前環境で外形テストが失敗する場合は、本番環境への移行は一切中止すべきです。これは、失敗の原因がアプリケーション自体にある場合でも、外形テストの設定にある場合でも同様です。

本番前環境での外形テストは、顧客向けに変更をリリースする前の最後の品質チェックポイントです。これらのテストに失敗した場合は、以下のいずれかを意味します。

• 環境内の何かに問題がある
• テスト内の何か(セレクター、アサーション、タイミングなど)に問題がある

いずれにしても、そのままリリースへと進むとリスクが生じます。アプリケーションの動作の問題であれば、それは本番環境でのインシデントになります。テストの問題であれば、誤検出につながり、信頼性の低下や真の問題の見落としを招きます。

本番前の外形テストの結果を本番への移行の判断基準にすることで、デリバリープロセスに規律が生まれます。たとえば、以下の作業が重視されるようになります。

• 重要なジャーニーの健全性を検証する
• セレクターとアサーションが正しいことを確認する
• 本番環境のシグナル品質が低下する前にドリフトを検出する

チームの手間を増やしたいわけではありません。これは、本番環境での外形テストの信頼性を維持し、意図したとおりのシグナルを提供し続けるようにするために必要な作業です。

重要ポイント：テストの実行状況は、Splunk ObservabilityのUI内で直接確認することも、Splunk Observability Cloud APIにクエリーを実行して確認することもできます。どちらの方法でも、テストが期待どおりに実行され、有効な結果が返されていることをすばやく確認できます。

4. 本番前環境での問題には予測可能なタイムラインで対応する

本番前環境では24時間365日のオンコール体制は不要ですが、一貫性のある予測可能な対応は必要です。本番前環境の健全性に問題があると、開発者は開発を行えず、QA担当者は検証を行えず、パイプラインも停止してしまいます。顧客に影響が一切なくても、これは生産性の低下につながります。

組織のエンジニアリングチームの運用体制に合わせた対応基準を設定しましょう。たとえば、次のように設定します。

• 1営業日以内に対応する
• 主要な開発拠点のタイムゾーンのコアタイム中に対応する

たとえば、チームメンバーの多くがインド標準時に沿って仕事をしていて、インド標準時の午前10時に本番前環境の外形テストが失敗した場合は、プロセスの停止を招く重大問題として扱うべきです。目標は、すべての問題を緊急にエスカレーションすることではなく、問題が何日も気づかれずに放置されてデリバリーが遅れる事態を回避することです。

5. 本番前環境の実情に合わせてしきい値を調整する

本番前環境では、本番環境よりも頻繁に変更が行われます。新たなビルド、機能フラグの追加、設定変更、依存関係の更新、インフラの微調整などはすべて、まず本番前環境で行われます。このように本質的に変化が激しいため、しきい値を本番環境に近づけすぎるとノイズが増える可能性があります。

目標は、期待値を下げることではなく、環境の実情に合わせて以下のような調整を行うことです。

• アラートの発動条件となる問題の同時発生数を多めに設定する
• デプロイに伴う変動を考慮してパフォーマンスしきい値に若干の余裕を持たせる
• アラートを対応担当者ではなくエンジニアリングチャネルに送信する
• 持続的な問題は単なるノイズではなく対応すべき課題として扱う

Splunk Observability Cloudでは、チームへの通知方法を柔軟に設定できます。本番前環境で発生したアラートを、Slack、Jira、ServiceNowなどのコラボレーションツールに送信できます。これにより、通常の開発サイクル中に対応担当者に過度な負担をかけることなく、問題を常に可視化できます。

詳細：Splunk Observability Cloudのすぐに使える通知サービスインテグレーション

6. 外形テストの開発と調整は本番環境ではなく本番前環境で行う

外形テストは、調整を繰り返しながら開発していく必要があります。アプリケーションの成熟度が高まるとともに、セレクターは変化し、アサーションは進化し、タイミング戦略を練り直す必要が生じることもあります。本番前環境は、その作業を行うための最適な場所です。

本番環境で直接テストを調整すると、盲点、誤検出、アラート抑制などの問題が生じます。これにより、「本番環境の外形テストでアラートが発生したら緊急事態だ」という認識に対する信頼性が損なわれることになります。また、テストの調整に奔走している間に顧客に影響が及ぶ可能性もあります。

先に本番前環境でテストロジックを調整しておくことで、本番環境の外形テストの正確性、安定性、信頼性を維持できます。それこそが、外形テストの理想の運用方法です。

7. カオステスト、フェイルオーバーテスト、負荷テストを外形テストと組み合わせる

本番前環境は、負荷が高い状態でのアプリケーションの動作をテストするための最も安全な場所です。カオステスト、負荷テスト、フェイルオーバーシナリオなどの実験を行うときは、その間も外形テストを有効にしておきましょう。そうすれば、システムに負荷がかかったときの重要なユーザージャーニーに対する影響を、外形テストによって一貫して測定できます。

これらの実験によって以下の点を理解できます。

• ノードの障害、依存サービスの停止、トラフィックの急増時のユーザージャーニーの変化
• 環境が回復して安定するまでにかかる時間
• イベント発生時にアラートが発動するタイミング
• ダッシュボード、ランブック、ルーティングが対応の迅速化に役立っているかどうか
• 高可用性コンポーネントが設計どおりに動作するかどうか

これらの実験により、アプリケーションのレジリエンスを高めるだけでなく、運用態勢(検出、対応、伝達、復旧)を検証することもできます。本番前環境で外形テストを有効にしておくことで、これら実験が測定可能かつ反復可能なものとなります。

まとめと今後のステップ

リリース前にテストを行うことで、その後のすべてのプロセスを強化できます。本番環境と同じ規律に従って本番前環境を監視すれば、問題を早期に検出し、ドリフトをすばやく特定し、本番環境の外形テストの正確性と信頼性を維持できます。これにより、信頼できるシグナルを生成して、顧客への影響を回避できます。また、不安定な環境やテストの不具合に悩まされることがなくなり、作業効率が向上します。

本番前環境は、本番環境の簡易版ではありません。そこはデリバリーパイプラインの性能を検証するための場所です。本番環境と同等の「第一級市民」として扱い、本番環境と同じ外形テストを実行し、そこから得られたインサイトに基づいてリリースと監視戦略の両方を改善していきましょう。

このプラクティスに共感された方は、このシリーズの残りの記事も引き続きご覧ください。外形監視が信頼できる実践的な手法である理由を詳しく解説していきます。これまでにご紹介したプラクティスを組織の環境で実践してみたい方は、Splunk Observability Cloudの無料トライアル版をご利用いただけます。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。