概要: コンテンツを本番環境に直接アップロードすることに何か問題がありますか? これはコードの変更や機能の変更ではありません。コンテンツの編集/追加のみです。現在、これを行うために 4 台のサーバーを使用していますが、少々手間がかかります。詳細については、以下をお読みください。
私は、あらゆる種類の特異性を持つ SMB ネットワークを引き継いだばかりです。そのような特異性の 1 つは、その複雑さに困惑させられます。ルーブ・ゴールドバーグ マシンのようなものだと確信していますが、確信を持ちたいと思っています。
IIS ベースのアプリケーション サーバーを使用するクライアント/サーバー アプリケーションがあります。このアプリケーション サーバーは、Web GUI とデータベース接続を仲介します。この場合は、別のサーバー (MSSQL2005) でホストされています。このアプリケーションを介してアップロードされ、データベースに BLOB として保存される .tif ファイルがあります。また、画像の上にマスクを作成するデータもあります (これにより、入力されたフォームを作成できます)。また、他のユーザーが手動で作成しなくても済むように、これらの画像/マスクのリポジトリとして機能するパブリック サーバーもホストしています。
ここまではわかりましたか? 基本的に、.tif ファイルとデータが一方の端に入り、もう一方の端では一般の人がこの画像/データをダウンロードできます。
奇妙なのは、ユーザーがこれらの完成した (QA 済みの) 画像を直接本番環境にアップロードするのではなく、内部サーバーにアップロードすることです。その後、プロセスによって BLOB が抽出され、.tif ファイルが作成されます。このプロセスでは、フォームに必要なデータのみが抽出されます。その後、ステージング サーバーに送られます。このステージング サーバーは本番環境サーバーの複製ですが、このプロセス以外では、この部分は実際には使用されません。ステージングに入ると、別のタスクが実行され、最終的に画像とデータが本番環境サーバーに複製されます。ただし、ステージング サーバーは Web 開発に使用されます。何か問題が発生すると、この一連のイベントが中断され、レプリケーションが停止する可能性があります。
また、この運用サーバーは定期的にバックアップされているため、ステージングは災害復旧用ではないことにも注意してください。ステージング サーバーは公開されていないため、冗長性のために使用されていません。ただそこに存在しているだけです。
さらに悪いことに、これらのタスクは、SQL Server タスク/トリガーではなく、vbs スクリプト、bat ファイル、および Windows スケジュール タスクを使用して実行されるようです。
私の質問は、「これはすべて必要なのか？」ということです。QA フラグが true に設定されている場合は常に、元の SQL サーバーにトリガーを設定して実稼働サーバーを更新できないのはなぜですか？なぜこのようなコピーをすべて行うのでしょうか。私が見逃している理由があるのでしょうか？
私は、ネットワークを整理するために正しいことをしているかどうかを確認したいだけです。
読んでくれてありがとう。
答え1
怠惰の悪臭を感じます。推測ですが、この特定のアプリケーションの開発プロセスのどこかで、何かがうまくいかなかったのでしょう。というか、ステージングではうまくいったのに、本番環境ではうまくいかなかったのです。そして、うまく機能させるには今すぐ彼らは、あなたが言及した方法でステージング サーバーを本番環境に接続しました。そして、実際に動作していました。そして、動作していたため、そもそも動作しなかった理由を調べようとしなかった人は誰も、そのまま放置しました。
あなたを入力してください。
なぜそうなるのでしょうか? それは機能するからです。
どうしてこうなったのでしょうか? 不明ですが、何かが壊れたことが、このようになった主な原因だと思います。
これを整理してみてください右方法。