Die Art von Details, auf die @Stephen hinweist, sind wirklich wichtig. Denn wir müssen verstehen, was Zero Downtime bedeutet. Beispielsweise könnte ich eine Zero-Downtime-Anforderung durch folgendes Vorgehen umgehen:
Ich definiere Zero Downtime so, dass ich einem Nutzer bei einer gültigen Anfrage niemals einen HTTP-Statuscode außer 200 zurückgebe (wobei 300er und 400er Codes bei Bedarf offen bleiben). Anschließend stelle ich Discourse auf einem 10-Dollar-Droplet in einer One-Container-Lösung bereit und füge Add an offline page to display when Discourse is rebuilding or starting up hinzu, um 500er-Fehler zu vermeiden. Auf diese Weise zeige ich keine Seite, die offline war.
Würde ich in einem rationalen Zustand denken, dass dies Zero Downtime ist? Niemals. Funktioniert es wie vorgeschlagen? Natürlich. Und ich könnte sogar einen Standby-Server in einer anderen Region hinzufügen, um es noch zero-downtime-sicherer zu machen.
Deshalb sind Qualifizierung und Semantik wichtig. Es ist nicht dasselbe, immer etwas anzuzeigen, wie immer Funktionalität auf der Seite zu gewährleisten.