本番環境で問題が発生した場合の問題を理解する

シナリオ：

• 本番にプッシュします
• プッシュは複数のことを壊しました
• その同じビルドはqaまたはdevを壊しませんでした
• 開発者は、製品にアクセスできません。
• 物事を機能させるには、上から多くのプレッシャーがあります。

詳細：

• ZendでAPI駆動型のPHP / MVCアプリケーション。
• 少数のサーバーに展開されました。

私の質問：

調査中に、何かが間違っているという予感があるとしましょう。しかし、私は確かに知りません。そしてもちろん、実稼働環境でテストすることはできません。その考えに基づいて修正案を提案している場合、問題が何であるかを理解する前に、それを試して適用し、機能するかどうかを確認するのが賢明でしょうか？

問題に関する可能な限り多くの情報（ログファイルなど）を入手し、運用サーバーを稼働状態にロールバックします。開発者の観点から言うと、これは当然のことですが、当然のことです。

次に、開発環境で問題を再現できるかどうか試してみてください。可能であれば、修正してからもう一度リリースしてください。

再現できない場合は、さらに診断を追加し、1つのサーバーに短時間リリースして問題に関する詳細情報を取得できるかどうかを確認してください。

それが不可能な場合は、本番環境とdev / qa環境の違いをより詳しく調べ、本番環境に近い開発環境を作成してください。

どのようにうまくあなたの問題を理解していますか？あなたの予感が事態を悪化させるリスクは何ですか？DEV / QAリージョンに戻って問題を再現することは可能ですか？DEV / QAリージョンを同期してPRODに近づけるために何ができますか？環境設定やデータベース設定を変更する必要があるかもしれません。PRODデータをDEVにインポートする必要があるかもしれません。デバッグ設定を変更する必要があるかもしれません。

一般に、別の地域で本当に正しいことを確認できない限り、ソリューションの束をPRODにプッシュすることはお勧めしません。PRODでバグが発生し、他の場所では再現できない場合に発生する問題の種類を理解しています。DEV / QAとPRODで他に何が違うのかを見て、それらに焦点を合わせることになります。私の経験では、それは通常、環境設定またはPROD専用の異なる構成です。そして、私はおそらくこれを修正するために上から多くのプレッシャーがあることを知っているので、以前の作業状態にロールバックしてからDEVで問題を再現しようとし、DEVで修正を思いついてから試してみることができます再びPRODで？それが私が提案することです。

修正の種類に依存します。多くの場合、本番環境でdevに表示されない問題は、データベースでの競合に関連しています。したがって、「外にある」ものを正確に確認せずにデータベースの内容を変更するバグを適用することは、大きな災害の最初のステップになる可能性があります。簡単に変更を元に戻すことができる場合は、試してみてください。ただし、一般に、直接アクセスできない場合は、少なくともテスト用のデータベースまたはサーバー全体のコピーが必要です。適切な権限を持つユーザーは、新しいコードを実行する必要がありますが、少なくともデータ損失のリスクはありません。（ただし、データベースのサイズまたはインフラストラクチャの複雑さがこのようなセットアップを禁止する場合があります）

さまざまな設定、ライブラリ、ソフトウェアのバージョンなど、多くの可能性があるため、本当に困難です。

バグの原因の推測が正しかった場合に、デバッグ出力で評価するコードを最初に記述してから、実際のバグ修正を適用することができます。

通常、コードまたはDBがProd、QA、およびdevで同一であると仮定すると、構成またはデータの問題です。

私は最初に次のものを見るでしょう：

• コードに含まれるログデータ。
• イベントビューアで未処理の例外を確認してください。
• アプリケーションの進行状況を表すデータを確認してください。DB、ファイルなどにある可能性があります。意味がありますか？あなたは何を期待していますか？

何が起こっているのかを理解したら、本番環境を稼働状態にロールバックし、修正して本番環境に再デプロイするまで、より低い環境で問題の修正に取り組む必要があります。

あなたの環境がPHPである間、私はJavaについてそれをどう考えるかについてプレゼンテーションをしました：http : //www.infoq.com/presentations/maintaining-production-java-apps

コアの問題は同じです-状況をトラブルシューティングするために考えられるチョークポイントを理解する：ネットワーク、ファイルシステムアクセス、ログファイル、デッドロックなど。また、適切な質問をする方法を知るには：「システムダウン」意味：Webページが遅い、特定のエラーメッセージがある、タイムアウトがある」など

さらに、トラブルシューティングを簡単にするツールがいくつかあります。ネットワークトラブルシューティング用のWiresharkは、絶対に最適であり、学ぶ価値があります。その他は、使用するO / Sに依存します。Windowsの場合、SysInternal（現在はMicrosoftの一部）の製品はどれも素晴らしいです。Unix / Linuxの場合は、truss / straceをご覧ください。

運用へのアクセス時に、運用グループはそれらのツール/テクニックの使用方法を知っているか、それらのビジネスケースを（あなたと一緒に）使用して学習する必要があります。その後、問題が発生したときに実行するトラブルシューティングプロトコルの特定のセットが必要になるため、オフラインで分析を行うことができます。

簡単な答え：選択の余地はありません。

長い答え：問題を理解していない場合、そのようなパッチにはいくつかのリスクが伴います。

1. 他の何かを壊す可能性があり、再現性が低下する可能性さえあります。
2. 問題をマスクするだけで、気づきや再現が難しくなります（これにより悪化します）。
3. あなたは潜在的な国内経験を捨てています-あなたがより良いプログラマーになると同時に、あなたの会社にとってより価値のある経験（つまり、潜在的な将来の昇給）になります。

一方、あなたの仮説の修正が動作するかどうか、私は最初の検査に害を見ていないし、それがない場合- その後、深く掘ると、本当の理由や問題を解決するために、他の可能性がより良い方法を見つけます。