andsmalexeyvgА что такого? Каждое изменение, каждый скрипт, делается так, что бы система как работала, так и продолжала работать.

Даже серьёзное изменение модели (типа, было несколько таблиц, стало несколько совсем других таблиц, связанных по другому, и с другими данными) можно делать так, что бы всё продолжало работать.

Я думаю, это практически нереально.
При таком подходе слишком высокий риск появления багов в коде. И если для какого-нибудь сайта это может быть допустимо, то для финансовой системы это не допустимо. Качество должно быть на первом месте.Я не вижу разницы в смысле "качества".

Но это в принципе неважно.
Если вы говорите, что система должна прекращать функционирование на период обновления, что любые средства уменьшения времени простоя недопустимо, потому что "Качество должно быть на первом месте", то непонятен вопрос топика.
Получается, исходный вопрос ставится так: "Как уменьшить время простоя, при условии, что его уменьшать недопустимо?"

КритикПопробуйте перейти на недельные релизы, тогда объем изменений будет невелик, соответственно и периоды обновления будут меньше по длительности. Доведете их, скажем, до 15 минут в неделю - большинство пользователей это должно устроить.Сомневаюсь, что это уменьшит время простоя.
Конечно, надо анализировать процесс, но наверняка основное время уходит на включение и повторную инициализацию репликаций
КритикОбновления с учетом изменений делать можно, но это довольно сложно, по сути трудоемкость разработки будет существенно выше (в разы). И все равно тогда 100% кому-то придется оправдываться в духе "я забыл, я это не учел", а кому-то придется это слушать.Конечно, трудоёмкость увеличится, скрипты деплоя будут сложнее, даже не скрипты как таковые, а усложняется процесс плавного бесшовного изменения при некоторых модификациях модели.

А ошибки будут и при варианте с остановкой системы на период обновления. Какая разница то?
Тут какой то особой зависимости нет, кроме очевидного "количество багов пропорционально количеству кода". Бизнес заказал дополнительную функциональность, добавились ошибки по этой функциональности, как и должно быть. Что бы их не добавлять, единственный вариант - ничего не делать.

andsmЯ как-то переводил БД с одной схемы данных на совсем другую, тоже для 24/7 системы и с активно пишущими пользователями. Некоторые таблицы превращались в несколько других таблиц, некоторые таблицы наоборот объединялись. Содержимое многих полей менялось при обновлении, и т.п. Размер БД был примерно 1.5 Тб. Так вот, время простоя составило 15 секунд. Да-да, секунд. Другое дело, что разработка такого перехода заняла несколько месяцев. Хочется поискать менее трудоемкие варианты.Да-да, вот, возможно же.

Но придётся заплатить трудоёмкостью.
Как иначе решить такую задачу? Кнопки волшебной нет.
Именно так все и делают.

Владислав Колосов24/7 - это Enterprise edition + Always on. Придется раскошелиться.У автора вопрос в другом.
Есть достаточно сложная система, состоящая из множества серверов СУБД, серверов приложений, клиентского софта и т.д.

Нету такого "Enterprise edition + Always on", который бы включал все эти компонеты.
Что бы половинку можно было бы обновить, а потом оно бы само синхронизировалось (например, при изменении модели данных).
И без потери траназкций.
И что бы ничего не писать, и что бы гарантированно рисков/багов не добавилось.

МуМу,

По моему, у вас описан какой то аццки сложный алгоритм :-)
Для добавления поля можно придумать более простые методы, без всяких сложных репликаций, которые как раз и могут создать проблемы.

Сложные схемы приходится придумывать для более сложных изменений, да ещё связанных с большими объёмами данных (например, большую таблицу, занимающую весь рейд, превратить в секционированную, без остановки).

МуМуАлгоритм с полем приведен как пример когда в логике приложения это поле учавствует, то есть раньше считалась какая то сумма из чего то а вот теперь решили сделать агрегацию. Получилось две ветки алгоритма, старый и новый. При учете непрерывности работы системы должны на сервере приложения работать два алгоритма до тех пор пока изменения не будут применены и останется только новый.Это в системах 24*7 делается проще.

На первом этапе добавляем новое поле, обеспечиваем его начальное заполнение и поддержку актуальности.
Когда этот этап завершён, и на продакшене всё работает, обновляется сервер приложений (клиент), на использование нового поля. И в этот же деплой удаляется старое (если, к примеру, новое вместо старого).
Такой подход, конечно, замедляет изменения, но зато в 2 раза дешевле, и менее багоёмкий.

Конечно, если фича нужна срочно, то можно и забашлять "за 2 алгоритма".
МуМуА в жизни чего только не бывает, попытайтесь например 1С сделать с ее регламентами сделать 24*7, боюсь практически это будет сделать без окон невозможно при текущей архитектуре.Ну понятно, что мы говорим о случае, когда есть контроль над всей системой.
Если нет, то тут 50% - либо получится, либо не получится :-)