ステージングでは決して得られない、本番環境が教えてくれること
デプロイが完了したとします。ステージングではすべてのテストがパスし、パイプラインはグリーン。チームは自信満々でした。ところが、リリースから30分後、ユーザーからメッセージが届きます。「アップデート後、ページの読み込みがすごく遅くなったんだけど」
ステージングを確認しても問題ありません。ローカルマシンでも大丈夫。しかし本番環境は苦戦しています。この瞬間、あなたは気づくのです。ステージングと本番環境は同じ場所ではないと。そして、本番環境から得られるフィードバックは、どんなシミュレーションでも代えがたいものだと。
ステージングと実際のユーザーの間にあるギャップ
ステージング環境は本番環境を模倣するために作られています。同様のハードウェア、同様のデータ、同様のネットワーク条件を設定します。しかし、常にギャップが存在します。実際のユーザーは、予測不可能性をもたらします。
ステージングでは、テスターはスクリプトに従います。期待される値でフォームを埋め、ボタンを一度だけクリックします。高速な回線でモダンなブラウザを使います。本番環境では、ユーザーは一行フィールドに段落を貼り付けます。ページの応答が2秒かかったため、送信ボタンをダブルクリックします。あなたが依存していたCSS機能をサポートしていない5年前のブラウザからアプリを開きます。
あらゆる可能性をスクリプト化することはできません。あらゆるデバイス、あらゆるネットワーク状況、あらゆるユーザー行動をシミュレートすることはできません。ステージングは管理された実験です。本番環境は野生です。
フィードバックは様々な形で届く
本番環境で何かがうまくいかないとき、フィードバックは必ずしも悲鳴をあげるユーザーや赤いアラートとは限りません。フィードバックは異なるチャネルを通じて届き、それらすべてを認識することを学ぶことは、本番環境でソフトウェアを運用する一部です。
メトリクスはしばしば最初のシグナルです。応答時間が上昇し始め、エラー率が上がり、メモリ使用量が安定せず増加します。これらの数値は、まだユーザーが苦情を言っていなくても、何かが変わったことを教えてくれます。適切な監視設定は、これらの変化がユーザーに見えるようになる前に捉えます。
ログは別のストーリーを語ります。これまで見たことのない新しいエラーメッセージが表示されます。常に存在していた警告が突然頻繁になります。ログはアプリケーションが何をしているかの生の物語であり、メトリクスだけでは説明できない問題を明らかにすることがよくあります。
直接的なユーザーフィードバックは最も明白ですが、最も遅れます。ユーザーは「この機能が動かなくなった」とか「ページが壊れて見える」と言うかもしれません。時にはインターネットのせいにし、時にはあなたのアプリのせいにします。いずれにせよ、彼らの報告は注意が必要なシグナルです。
本番環境の問題は必ずしもコードのバグではない
本番環境で問題が発生すると、最新のコード変更を見たくなるのが本能です。しかし、原因はしばしば別の場所にあります。設定変更がダウンストリームの依存関係を壊すフラグを反転させたかもしれません。1000行で問題なく動作していたデータベースクエリが、テーブルが100万行に成長したときにタイムアウトし始めます。アプリが依存しているサードパーティAPIが、予告なくレスポンス形式を変更します。
本当の原因を見つけるプロセスは、デバッグまたはトラブルシューティングです。コード、設定、インフラストラクチャ、外部依存関係を調べる必要があります。スキルは問題を修正することだけでなく、それに至った一連のイベントを追跡することにあります。すべての本番環境の問題は、システムが実際にどのように動作するかについての教訓であり、あなたが思っていた動作とは異なります。
フィードバックが次のイテレーションを形作る
本番環境からのフィードバックは、何が壊れているかを教えてくれるだけではありません。次に何を構築すべきかを教えてくれます。特定のページが頻繁にアクセスされているが読み込みが遅い場合、最適化の候補があります。ユーザーが一貫してフォームフィールドを誤って入力している場合、解決すべきUX問題があります。古いデータが決してクリーンアップされず、データベースが際限なく成長している場合、優先すべきメンテナンスタスクがあります。
これがソフトウェアを生かし続けるループです。アイデアはプロダクトミーティングや機能リクエストからだけ生まれるわけではありません。実際のユーザーの手でアプリケーションがどのように振る舞うかを見ることから生まれます。本番環境は目的地ではありません。方向性の源です。
本番環境のフィードバックがワークフローを変える方法
本番環境のフィードバックに注意を払うチームは、働き方を変え始めます。ステージングで捕捉されるべき問題を頻繁に見つける場合、より良いテストデータやより現実的なステージング環境に投資します。フルリリース後にのみ問題を発見し続ける場合、フィーチャーフラグやカナリアデプロイのような段階的なロールアウト戦略に移行します。根本原因を見つけるのに苦労する場合、ログを改善し、分散トレーシングを追加し、より優れた可観測性ツールを採用します。
それぞれの本番環境の問題は、デリバリープロセス自体を改善するためのシグナルになります。フィードバックループはバグを修正して終わりではありません。将来同様の問題を防止、検出、診断する方法を変えることにまで及びます。
本番環境のフィードバックに基づいて行動するための実践的チェックリスト
- 最初の本番環境デプロイ前に、応答時間、エラー率、リソース使用量の基本的な監視を設定する。
- 何かが壊れたときだけでなく、定期的にログを確認する。
- 本番環境の問題とその原因を文書化するためのシンプルなプロセスを作成する。
- 本番環境の問題を修正した後、「これはもっと早く捕捉できたか？」と問いかける。もしそうなら、パイプラインまたはステージング設定を調整する。
- リスクの高い変更には、段階的なロールアウト方法を使用する。
- ユーザーからの報告を苦情ではなくデータポイントとして扱う。
まとめ
本番環境はデリバリーパイプラインの終点ではありません。次のサイクルの始まりです。すべてのメトリクス、すべてのログ行、すべてのユーザーメッセージは、これまで見えなかったシステムについて何かを学ぶための招待状です。時間とともに上達するチームは、本番環境の問題を回避するチームではありません。すべての本番環境の問題をフィードバックとして扱い、すべてのフィードバックを改善の機会として扱うチームです。