Freitag 17 Uhr: „nahtlose“ Bereitstellung auf Clever Cloud. Der Healthcheck antwortet mit 200 auf „/“, auch wenn die API ausgefallen ist; Die PostgreSQL-Migration sperrt die Benutzertabelle; Redis-Sitzungen gehen beim Neustart verloren. Ergebnis: fünf Minuten von 502 – laut Entwickler „akzeptabel“, für den SLA-Vertrag inakzeptabel.
Clever Cloud ist ein PaaS, das für die häufige Bereitstellung konzipiert ist – vorausgesetzt, Sie betrachten die Bereitstellung als Architekturprojekt und nicht als magischen „Git Push“. Die Plattform kann eine Instanz sauber vom Router entfernen; Es korrigiert weder einen falschen Gesundheitscheck noch eine blockierende Migration.
Die drei Säulen von Zero Downtime
| Säule | Action Clever Cloud | Standardfehler |
|---|---|---|
| Gesundheitscheck | Tiefe „/health“-Route – DB, Cache | 200 auf statischer Seite |
| N/N+1-Kompatibilität | Abwärtskompatible API eine Version | Breaking Change + einzigartige Bereitstellung |
| Migrationen | Erweitern/Verkleinern, nicht ALTER sync | Sperrtabelle in der Produktion |
Konfigurieren Sie den Healthcheck im Dashboard oder über Clever Tools; Passen Sie Timeout und Kulanzzeitraum an die tatsächliche Startzeit Ihrer Anwendung an – JVM, OPcache, Poolverbindungen.
Empfohlene Bereitstellungsreihenfolge
Beginnen Sie mit einer Phase vor der Bereitstellung: Erweitern Sie die Migration – nullfähige Spalten, neue Tabellen. Stellen Sie dann die neue Version bereit. Ungesunde Instanzen bleiben außerhalb der Rotation. Führen Sie einen Rauchtest auf kritischen Endpunkten über die Clever-URL-Vorschau durch, falls verfügbar. Stellen Sie den Datenverkehr schrittweise oder über DNS auf Blau-Grün um. Schließen Sie die Vertragsmigration ab, nachdem Sie die alten Instanzen geleert haben.
Integrieren Sie für PHP, Node oder Java das Warmup – OPcache, JVM – in den Deep Health Check.
Sitzungen, Cache und Dateien
Sitzungen müssen im Redis-Add-on Clever oder im zustandslosen JWT stattfinden – nicht in der lokalen Speicherinstanz. Lokale Uploads sind mit der horizontalen Skalierung nicht kompatibel: Verwenden Sie einen externen Objektspeicher. Die Cache-Ungültigmachung muss versioniert werden, bevor der Datenverkehr umgeschaltet wird.
Ohne diese drei Punkte simuliert die horizontale Skalierung null Ausfallzeiten, verliert jedoch den Benutzerstatus – leere Körbe, Verbindungsabbrüche, nicht gefundene Dateien.
Der Gipfel: Push ohne Tiefengesundheit = Roulette
Das ist die Lücke zwischen Demo und Produktion an einem Freitagabend.
Entscheide dich und gehe ohne blinden Fleck voran
Führen Sie eine umfassende Integritätsprüfung im Repository durch, schreiben Sie ein Runbook für Erweiterungs-/Vertragsmigrationen, testen Sie eine wöchentliche Bereitstellung in der Clever-Staging-Umgebung und dokumentieren Sie eine Blue-Green- oder Canary-Strategie mit Sitzungsverwaltung. Konsultieren Sie das Clever Cloud-Datenblatt und den Vergleich, wenn Sie für Ihre Last zwischen PaaS und VPS zögern.
Häufig gestellte Fragen
Garantiert Clever Cloud keine Ausfallzeiten?
Nein – es hängt von der Gesundheitsprüfung, den Migrationen und der N/N+1-Kompatibilität zwischen den Versionen ab.
Welche Rolle spielt der Gesundheitscheck?
Es leitet den Verkehr so gut weiter. Bei falscher Konfiguration entsteht eine falsche Sicherheit oder es werden Deployer blockiert.
Wie verwaltet man Datenbankmigrationen?
Erweitern/Verkleinern: Schema kompatibel mit zwei Versionen, dann Bereinigung. Vermeiden Sie es, ALTER am Schalter zu blockieren.
Blaugrün auf Clever Cloud?
Zwei Umgebungen, DNS/Router-Failover, Drain-Sitzungen und Cache-Invalidierung dokumentiert.
Bevor Sie null Ausfallzeiten versprechen, sollten Sie eine Staging-Bereitstellung absichtlich scheitern lassen – der Gesundheitscheck wird die Wahrheit sagen oder nicht.