Isso depende da sua definição de "tempo de inatividade zero". Um cenário de recuperação com falha de upgrade pode ser realizado facilmente, configurando a replicação entre seus dois servidores SQL, que também dá a você o benefício da redundância.
Isso funciona de maneira muito semelhante ao que você descreve acima: Quando você faz um upgrade, você divide seu par de replicação & atualize um deles (junto com alguns servidores de aplicativos), mude a carga para o conjunto atualizado de máquinas, atualize os outros e restabeleça a replicação. A ressalva é que você provavelmente ainda precisará parar de aceitar alterações (inserções / atualizações) durante a janela de atualização (pelo menos até os servidores atualizados estarem sendo executados), caso contrário você vai acabar com um cérebro dividido cenário em que você tem alterações no sistema "antigo" que será perdido no "novo".
Dependendo do tipo de alteração de esquema que você está falando, & quão bem escrito seu aplicativo é, você pode fazer algumas alterações sem tempo de inatividade (adicionar novas tabelas / visualizações, adicionar uma coluna, etc. pode ser feito sem uma interrupção, desde que seu aplicativo não surte quando o número de colunas em uma tabela muda).
Minha sugestão para você é que você insista em uma janela de manutenção adequada para todas as alterações / atualizações, para incluir o tempo de interrupção, se necessário. Pouquíssimos sistemas precisam ser realmente 24x7x365, e se você acabar com um problema inesperado, é sempre melhor que o sistema esteja off-line com tempo suficiente para corrigir o problema ou reverter suas alterações, em vez de ficar correndo em uma correção com usuários irritados. respirando no seu pescoço porque eles não estavam esperando uma interrupção ...