Резюме: Есть ли что-нибудь плохое в загрузке контента непосредственно в продакшн? Это не изменение кода или функциональности. Только редактирование / добавление контента. В настоящее время для этого мы используем 4 сервера, это что-то вроде свиньи. Подробности читайте ниже.
Я только что унаследовал сеть SMB, которая имеет всевозможные особенности. Одна такая идиосинкразия поражает своей сложностью. Я почти уверен, что это похоже на машину Руба-Голдберга, но я хочу быть уверенным.
У нас есть клиент-серверное приложение, использующее сервер приложений на основе IIS. Этот сервер приложений является посредником в веб-интерфейсе и соединении с базой данных, которое в нашем случае размещено на другом сервере (MSSQL2005). Есть файлы .tif, которые загружаются через это приложение и хранятся в базе данных в виде больших двоичных объектов. Есть также данные, которые создают маску поверх изображения (чтобы можно было создавать заполненные формы). Мы также размещаем общедоступный сервер, который действует как репозиторий для этих изображений / масок, чтобы другим не приходилось создавать их вручную.
Хорошо, со мной так далеко? Как правило, файл .tif и данные идут на одном конце, а на другом конце публика может загрузить это изображение / данные.
Вот что самое странное. Вместо того, чтобы заставлять наших пользователей загружать эти готовые (и прошедшие проверку качества) изображения непосредственно в производство, они отправляются на внутренний сервер. Затем процесс извлекает большой двоичный объект и воссоздает файл .tif. Этот процесс также извлекает только необходимые данные для форм. Затем он отправляется на промежуточный сервер. Этот промежуточный сервер является дубликатом рабочего сервера, но мы никогда не используем эту его часть, за исключением этого процесса. После подготовки выполняется другая задача для окончательной репликации изображения и данных на рабочий сервер. Однако промежуточный сервер используется для веб-разработки. Если что-то случится, это может разорвать эту цепочку событий и остановить репликацию.
Также стоит отметить, что для этого производственного сервера регулярно выполняется резервное копирование, поэтому промежуточная подготовка не предназначена для аварийного восстановления. Промежуточный сервер также никоим образом не является публичным, поэтому он не используется для резервирования. Это просто есть.
Чтобы добавить оскорбления к травме, эти задачи, похоже, выполняются с помощью сценариев vbs, файлов bat и запланированных задач Windows, а не каких-либо задач / триггеров SQL Server.
У меня вопрос: «Все ли это необходимо?» Почему нельзя настроить триггер на исходном сервере SQL для обновления производственного сервера всякий раз, когда для флага QA установлено значение true? Зачем проходить все это копирование. Есть ли причина, по которой меня не хватает?
Я просто хочу убедиться, что поступаю правильно, чтобы разобраться в нашей сети.
Спасибо за прочтение.
Я чувствую зловонный след лени. Предположительно, где-то в процессе разработки этого конкретного приложения что-то не сработало. Вернее, это сработало в постановке, но не в производстве. И чтобы все заработало сейчас они подключили промежуточный сервер к производственной среде, как вы упомянули. Что он и сделал. И так как это работало, кто бы ни не удосужился попытаться выяснить, почему это вообще не работает, и просто оставил это.
Войдите в вас.
Почему так? Потому что это работает.
Как это случилось? Неизвестно, но я полагаю, что что-то сломанное было ключевой частью того, почему это произошло.
Не стесняйтесь разобраться в этом право путь.