Как произвести обновление программного обеспечения при непрерывном производстве 24\7. В частности больших баз 1С?
В текущей постановке вопроса - без остановки базы - никак.
Однако, если определить требования простоя, то возможно.
Например, простой базы 60 минут недопустим. В то время как простой базы 5 мин для обновления вполне приемлем.
Если допускается простой для обслуживания в 5 мин, то в этот интервал можно уложиться.

Что такое обновление базы 1С.
В процессе обновления выполняется накатывание нового кода, а также реструктуризация базы. Накатывание кода происходит быстро.
Основное время обновления занимает реструктуризация ИБ.
Вопрос в том - как сократить время реструктуризации ИБ.
Не каждое обновление затрагивает таблицы базы данных. Поэтому не каждое обновление будет долгим.
Рассмотрим случай, когда внесли изменение в большую таблицу.
Выполнение реструктуризации средствами 1С процесс долгий. Сначала создается новая таблица с новой структурой. Далее в эту новую таблицу перекладываются записи (по одной!) из старой таблицы. Мощность оборудования мало что решает при таком подходе. Какие бы мощные сервера не были, они не могут сильно ускорить процесс перекладывания записей "по одной".
Решение:
1. Организационное. Заранее определять "тяжелые" и "легкие" релизы. Т.е. релизы, которые затрагивают тяжелые таблицы, и которые не затрагивают.
2. Технические. Не вносить изменения в существующие поля "тяжелых" таблиц, а только добавлять новые поля, сбоку. При таком подходе можно вмешаться в процесс реструктуризации ИБ.
Дело в том, что когда вы добавляете новое поле, то 1С все-равно выполняет реструктуризацию, даже, если это поле пустое. Такая 1С-ка "тупая". Ничего не поделаешь. Однако это можно компенсировать при работе на уровне СУБД. На этапе реструктуризации можно подменять имена таблиц таки образом, что 1С-ка будет реструктуризировать пустую таблицу. Далее заменять таблицу обратно. Например:
Дано:
Таблица - А - большая и тяжёлая
В таблицу А добавили новое поле АБ
Задача:
Надо выполнить реструктуризацию таблицы А максимально быстро.
Решение:
На уровне скуля переименовываем таблицу А в _А
Включаем реструктуризацию 1С
Реструктуризация создает недостающую таблицу А в соответствии с конфигурацией
Перекачиваем данные из _А в А средствами СУБД - на уровне скуля это делается максимально быстро.
Запускаем 1С, убеждаемся в работоспособности данных
Удаляем _А

Как-то так.

P.S. Динамическое обновление НЕ советую применять никогда.
Никак, насколько я знаю
Вообще то по регламенту существует время "обслуживания" различного софта и оборудования.

Ну или поднимать 2 дублирующие 1с в кластер, 1 недоступна - работают на второй.