適切なステージング環境がないため、本番システムで問題をデバッグする必要があることがよくあります。Web サーバー、アプリケーション サーバー、データベース サーバーがあります。
これを行うときに、本番環境に意図しない変更を誤って加えないようにするために、どのような保護手段を使用していますか?
このアプリケーションは、非常に複雑な B2B 垂直 Web アプリケーションです。関連するデータはたくさんあります。一部のテーブルには、1 億近くのレコードがあります。
私たちが用意しているステージング環境には、本番環境をミラーリングする能力がありません。実際のデータベース データ以外にも、数百ギガバイトのデータ ファイルが含まれます。
コードにはソース管理を使用しますが、ストアド プロシージャには使用しません。ソース管理には古いストアド プロシージャがいくつかありますが、それを最新の状態に保つ人はいません。
主な懸念事項は、ファイル システム上のデータベースとデータです。
ところで、私はこの会社のコンサルタントであり、実際の従業員ではありません。
最も直接的な答えは、「そうしないでください」です。
ソース管理。取り返しのつかない事態が発生した場合のロールバックのようなものはありません。また、差分は、変更を他の実稼働システムに複製するのにも役立ちます。
特定のアカウントの書き込みアクセスのみを許可するため、変更するには別の方法でログインする必要があります
Web サーバーには、互いにミラーリングする 2 つのディレクトリ構造があり、1 つの ID のみが書き込み可能で、もう 1 つのステージング ディレクトリは全員が書き込み可能です。
データベース サーバーには、1 つの ID のみが書き込み可能な 1 つの運用データベースがあり、全員が書き込み可能なステージング データベースがあります。ステージング DB には、夜間のバックアップを復元できます。
ただし、クエリが不適切であるか、ステージング システムにリソースを大量に消費している場合、本番環境からリソースが取り出され、マシンがハングする可能性があります。
読み取り専用/ゲスト アカウント。真剣に。これは、ルートまたは管理者として常にログインするとは限らないのと同じ理由です。
新しいプロダクション リリースは、システム担当者を通じて行われます。プログラマーと開発者は、新しいシステムを稼働させることのみを要求できます。承認も必要です。加えられた各変更がテストされていることを示します (すべてのスナップショットを含めることにより)。これは、本番リクエストでこのリリースでテストされました)。
問題が発生した場合のフォールバック用に、以前の製品リリースを保持します。
何かが壊れた場合 (適切なテスト手順と管理されたリリースでは頻繁に起こるべきではありません)、ロールバックまたはホットフィックスのいずれかを行うことができます。多くの場合、ライブで問題が発生し、修正が小さい場合は、ホットフィックスしてから修正をテストに移動して、適切なテストを行うことができます。
とにかく、うまくいくこともあります...
Web サーバーとアプリケーション サーバーの場合、環境を新しい場所 (ただし同じ環境内) にコピーし、影響を受ける人々にそのコピーで動作を再現してもらいます。これにより、少なくとも、クライアントの 100% を誤って台無しにすることをある程度回避できます。
データベース サーバーの場合、運用システムのユーザー アカウントを構成して、読み取り専用権限を付与します。
バージョン管理は、実稼働環境への変更を制御するのに非常に役立ちます。実稼働環境を、リポジトリから適切なディレクトリまたはディレクトリの作業コピーにするだけです。更新をロールアウトすると、ソース管理システムは、変更されたすべてのファイルがコピーされることを確認します。更新によって何かが壊れた場合、本番の作業コピーを壊れていない最後のリビジョンにロールバックできます。また、実稼働 WC をトランクからではなくタグからチェックアウトすることもできます。そうすれば、タグを調整することで、本番環境に適用するリポジトリ リビジョンを決定できます。
バージョン管理システムの概念に慣れていない場合は、調査を行うことをお勧めします。それらは概念的に複雑ですが、信じられないほど便利で強力です。ウィキペディアの記事は、開始するのに適した場所です: http://en.wikipedia.org/wiki/Revision_control
申し訳ありませんが、ステージング環境が必要です。これを回避する方法はありません。データセットのサイズを選別する必要があることを意味する場合は、それがあなたがしなければならないことです. VMware および VMware コンバーターを使用して、ダウン期間中に運用システムをインポートします (運用システムがある場合) (これは長時間のプロセスであるため、実用的ではない可能性があります)。
実稼働 DB (またはコピー) へのフル アクセスがなければ解決できない特定のクラスの問題があります。パフォーマンスはその 1 つです。しかし、データセットが削除された誰かのデスクトップ マシン上にある場合でも、ステージング環境を構築する必要があります。
それはさておき、私は過去にこれらのいくつかを使って生活しなければなりませんでした。実際、多くのバックアップ以外にできることはありません. 行うすべての変更の前に、増分バックアップを行う必要があります。そうすれば、何かを失敗したとしても、失った金額はそれほど大きくありません。SQL サーバーは、バックアップに使用されるディスク容量を制限する差分バックアップを作成できます。オラクルも同様です。
これは大変なことであり、「ステージング環境なし」の領域に当てはまります。
多くの理由から、デプロイ先のステージングとデバッグに使用できる専用の (複製された) PROD を用意するのが最善ですが、使い始めたばかりのときは、それがすぐにうまくいかなかったり、私たちが望むように徹底的に。
私が見た作業の 1 つは、VM の使用です。デバッグ環境とは別に、VM でミニ PROD を作成し、それを使用してデバッグできます。開発しているアプリの種類を考えると、これは実用的ではない可能性があるため、その領域の追加の詳細が役立ちます。
デバッグ中に PROD を変更しないようにすることについて: デバッグを容易にするために何かを変更する必要がある理由はありますか? もしそうなら、それは別の方法で解決することを検討する価値があるかもしれません.
他に選択肢がなく、慢性的な状況である可能性が高い場合に備えて... アプリケーションデータ (ファイルまたはデータベース) に何らかの方法を追加して、データセットに「実際に積極的に変更しないでください」というフラグを付けることを検討してください。このフラグがアクティブになっているプロセスの重要な位置でのデータ ダンプと組み合わせると、データが実際に処理されることなく、ほとんどの生産ロジックを実行できる場合があります。