Zusammenfassung: Ist etwas falsch daran, Inhalte direkt in die Produktion hochzuladen? Dies ist keine Code- oder Funktionsänderung. Nur das Bearbeiten/Hinzufügen von Inhalten. Wir verwenden derzeit 4 Server, um dies zu tun, das ist ziemlich mühsam. Weitere Einzelheiten finden Sie weiter unten.
Ich habe gerade ein SMB-Netzwerk geerbt, das alle möglichen Eigenheiten hat. Eine dieser Eigenheiten ist in ihrer Komplexität verblüffend. Ich bin ziemlich sicher, dass es einer Rube-Goldberg-Maschine ähnelt, aber ich möchte sichergehen.
Wir haben eine Client/Server-Anwendung, die einen IIS-basierten Anwendungsserver verwendet. Dieser Anwendungsserver vermittelt eine Web-GUI und eine Datenbankverbindung – die in unserem Fall auf einem anderen Server (MSSQL2005) gehostet wird. Es gibt .tif-Dateien, die über diese Anwendung hochgeladen und als Blob in der Datenbank gespeichert werden. Es gibt auch Daten, die eine Maske über dem Bild erstellen (damit ausgefüllte Formulare erstellt werden können). Wir hosten auch einen öffentlichen Server, der als Repository für diese Bilder/Masken dient, damit andere sie nicht manuell erstellen müssen.
Bis hierhin alles klar? Grundsätzlich gehen die TIF-Dateien und Daten an einem Ende hinein und am anderen Ende kann die Öffentlichkeit dieses Bild/diese Daten herunterladen.
Hier ist der seltsame Teil. Anstatt dass unsere Benutzer diese fertigen (und qualitätsgeprüften) Bilder direkt in die Produktion hochladen, gehen sie auf einen internen Server. Ein Prozess extrahiert dann den Blob und erstellt die .tif-Datei neu. Dieser Prozess extrahiert auch nur die erforderlichen Daten für die Formulare. Dann geht es auf einen Staging-Server. Dieser Staging-Server ist ein Duplikat des Produktionsservers, aber wir verwenden diesen Teil davon eigentlich nie – außer für diesen Prozess. Sobald er sich im Staging befindet, wird eine weitere Aufgabe ausgeführt, um das Bild und die Daten schließlich auf den Produktionsserver zu replizieren. Der Staging-Server wird jedoch für die Webentwicklung verwendet. Wenn etwas passiert, kann es diese Ereigniskette unterbrechen und die Replikationen stoppen.
Es ist auch erwähnenswert, dass dieser Produktionsserver regelmäßig gesichert wird, sodass der Staging-Server nicht für die Notfallwiederherstellung gedacht ist. Der Staging-Server ist auch in keiner Weise öffentlich, sodass er nicht für Redundanzzwecke verwendet wird. Er ist einfach da.
Um das Ganze noch schlimmer zu machen, werden diese Aufgaben anscheinend mit VBS-Skripten, BAT-Dateien und geplanten Windows-Aufgaben und nicht mit SQL Server-Aufgaben/-Triggern ausgeführt.
Meine Frage ist: „Ist das alles notwendig?“ Warum kann auf dem ursprünglichen SQL-Server kein Trigger eingerichtet werden, um den Produktionsserver zu aktualisieren, wenn ein QA-Flag auf „true“ gesetzt wird? Warum all diese Kopiervorgänge? Gibt es einen Grund, den ich übersehe?
Ich möchte nur sicherstellen, dass ich das Richtige tue, um unser Netzwerk in Ordnung zu bringen.
Danke fürs Lesen.
Antwort1
Ich spüre die fauligen Spuren der Faulheit. Ich schätze, irgendwo während des Entwicklungsprozesses dieser speziellen Anwendung hat etwas nicht funktioniert. Oder besser gesagt, es hat in der Staging-Phase funktioniert, aber nicht in der Produktion. Und um die Dinge zum Laufen zu bringenim AugenblickSie haben den Staging-Server auf die von Ihnen beschriebene Weise an die Produktion angeschlossen. Und das hat er auch getan. Und da es funktionierte, hat sich derjenige nicht die Mühe gemacht, herauszufinden, warum es überhaupt nicht funktionierte, und es einfach so gelassen.
Gib dich ein.
Warum ist das so? Weil es funktioniert.
Wie konnte es so weit kommen? Unbekannt, aber ich schätze, dass etwas kaputt gegangen ist, was ein wesentlicher Grund dafür war, dass es so weit gekommen ist.
Fühlen Sie sich frei, dies zu klären dieRechtsWeg.