Blue-Green-Bereitstellung
Zwei vollständige Produktionsumgebungen, bei denen der Traffic von der einen zur anderen umgeschaltet wird — dadurch ist eine sofortige, vollständige Rücknahme möglich, falls die neue Umgebung sich fehlerhaft verhält.
Bereitstellung & Aktivierung · Schritt 05 · Unsere Arbeitsweise
Freigabe ist eine Entscheidung, kein Ereignis.
Entwicklung & Integration erzeugt verifizierte Software — aber verifizierte Software ist noch keine Live-Software. Diese Phase regelt, wie, wann und wie sicher diese Software echtem Produktionsverkehr ausgesetzt wird und stellt sicher, dass die für ihren Betrieb verantwortlichen Personen vor ihrem Eintreffen bereit sind.
Die Bereitstellung bei OpenQCore wird als kontrollierte Risikoexposition behandelt, nicht als ein einzelner irreversibler Moment. Ein Release gilt nicht als "fertig", wenn Code die Produktion erreicht. Es gilt als abgeschlossen, wenn es schrittweise exponiert, unter realen Bedingungen beobachtet und als sicher bestätigt wurde — mit einem definierten Rückweg, falls dies nicht der Fall ist.
Nicht diese Frage
"Ist der Code bereit zum Ausliefern?"
Stattdessen diese Frage
"Wie führen wir diese Änderung bei echten Nutzern so ein, dass der Schadensradius unerwarteter Effekte begrenzt wird — und können wir sie bei Bedarf schnell rückgängig machen?"
Progressive Bereitstellung · Risikobegrenzung · Umkehrbarkeit · Einsatzbereitschaft · Befähigung
Warum die Bereitstellung der Verifikation folgt
Verifiziert ist nicht dasselbe wie im Produktionsbetrieb bewährt.
Die vorherige Phase bestätigt, dass eine Änderung ihre Akzeptanzkriterien unter Tests erfüllt. Sie bestätigt jedoch nicht, wie sich diese Änderung unter realer Produktionslast, realem Nutzerverhalten oder realen Interaktionen mit Systemen verhält, die in einer Testumgebung nicht vollständig nachgebildet werden können. Bereitstellung & Befähigung existiert genau deshalb — weil diese Lücke real ist und weil ihr sicheres Schließen eine eigene Disziplin erfordert.
Bereit für die Bereitstellung → Kontrollierte Exposition in der Produktion
Warum Disziplin bei der Bereitstellung wichtig ist
Geschwindigkeit ohne Umkehrbarkeit ist kein Fortschritt.
Die gleiche DORA-Forschung, die bereits während Entwicklung & Integration vorgestellt wurde — Forsgren, Humble und Kims Accelerate (2018) — koppelt ihre Durchsatzmetriken mit zwei Stabilitätsmetriken, die gerade in dieser Phase besonders relevant sind.
Bereitstellungsfrequenz
Wie oft eine Organisation erfolgreich in die Produktion ausliefert.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps-Forschung.
Zeit bis zur Wiederherstellung des Dienstes
Wie lange es dauert, den Dienst wiederherzustellen, wenn eine Bereitstellung die Produktion beeinträchtigt.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps-Forschung.
Leistungsstarke Organisationen deployen nicht einfach nur häufig — sie tun dies so, dass die Wiederherstellungszeit kurz bleibt, wenn etwas schiefgeht. OpenQCore betrachtet dies als ein einzelnes Ziel, nicht als einen Zielkonflikt: Die Praktiken in dieser Phase sind darauf ausgelegt, Bereitstellungen sowohl häufig als auch schnell umkehrbar zu machen.
Strategien für Progressive Bereitstellung
Trennen Sie die Entscheidung zur Freigabe von der Entscheidung zur Bereitstellung.
Die in Humble und Farleys einflussreichem Werk Continuous Delivery (2010) formalisierten Praktiken unterscheiden das Bereitstellen einer Änderung vom Freigeben für Nutzer — eine Unterscheidung, die OpenQCore als grundlegende Designentscheidung dafür betrachtet, wie Software in Produktion gelangt.
Canary-Releases
Eine neue Version wird zunächst einem kleinen Teil des realen Traffics ausgesetzt, anhand definierter Signale beobachtet und erst ausgeweitet, wenn diese Signale zufriedenstellend sind.
Feature-Flags
Code kann in die Produktion bereitgestellt werden, während er für Nutzer inaktiv bleibt — dadurch wird das Ausliefern von Code vom Freischalten einer Funktion getrennt.
Bereitstellungsumgebungen & Promotion
Eine Änderung erarbeitet sich ihren Weg in die Produktion. Sie wird nicht direkt dorthin geschickt.
Eine Änderung durchläuft definierte Umgebungen — Entwicklung, Staging und Produktion — mit expliziter Überprüfung bei jedem Umgebungsübergang, anstatt eines einmaligen Testdurchlaufs gefolgt von einer direkten Freigabe.
Entwicklung
Wo eine Änderung entwickelt und zunächst isoliert überprüft wird.
Staging
Wo eine Änderung gegen produktionsähnliche Bedingungen, Konfigurationen und Integrationen überprüft wird.
Produktion
Wo eine Änderung echtem Datenverkehr ausgesetzt wird — schrittweise und unter Beobachtung.
Rollback- und Wiederherstellungsdesign
Der Rollback-Plan wird vor der Bereitstellung geschrieben, nicht während des Vorfalls.
Eine Rollback-Strategie, die erst entschieden wird, während das System bereits beeinträchtigt ist, ist eine unter Druck getroffene Strategie, mit unvollständigen Informationen und oft zu spät. OpenQCore legt den Rollback-Pfad für eine Änderung fest, bevor sie bereitgestellt wird — nicht erst nachdem etwas schiefgeht.
Definierte Auslösebedingungen für einen Rollback
Die spezifischen Signale, die einen Rollback auslösen würden, im Voraus vereinbart und nicht spontan im Moment entschieden.
Daten- & Zustandskompatibilität
Explizite Prüfung, ob ein Rollback angesichts von Daten- oder Schemaänderungen, die die Bereitstellung eingeführt hat, sicher ist.
Ziel für die Wiederherstellungszeit
Ein festgelegtes Ziel, wie schnell der Dienst wiederhergestellt sein sollte, wenn ein Rollback erforderlich ist.
Infrastruktur als Code & Reproduzierbarkeit
Eine Bereitstellung, die nicht exakt wiederholbar ist, ist nicht vertrauenswürdig.
Bereitstellungsschritte werden als Code definiert — versioniert, geprüft und jedes Mal identisch ausgeführt — anstatt als manuelle Aktionen, die vom Gedächtnis einer Einzelperson über die richtige Reihenfolge abhängen. Dies ist eine grundlegende Praxis im selben Forschungsbereich zur Continuous Delivery, auf den oben verwiesen wurde: Ein Bereitstellungsprozess, der nicht exakt reproduziert werden kann, kann nicht verifiziert und nicht sicher automatisiert werden.
Bewertung des Bereitstellungsrisikos
Jede Bereitstellung wird bewertet, bevor sie stattfindet, nicht danach.
Im Einklang mit dem während Entwicklung & Integration eingeführten Bedrohungsmodell wird jede Bereitstellung vor dem Fortfahren auf ihr spezifisches Risikoprofil hin bewertet.
Ausbreitungsradius
Wie viele Benutzer, Systeme oder Workflows betroffen wären, wenn sich diese spezifische Änderung unerwartet verhält.
Umkehrbarkeit
Wie schnell und sauber diese konkrete Änderung rückgängig gemacht werden kann, falls erforderlich.
Abhängigkeits-Exposition
Welche nachgelagerten Systeme oder Teams von dieser Bereitstellung betroffen sind und ob sie informiert wurden.
Die progressive Rollout-Pipeline
Die Exposition wird nur erhöht, wenn die Beweise dies rechtfertigen.
Canary (kleiner Prozentsatz) → Überwache definierte Signale → Erhöhe die Exposition → Überwache definierte Signale → Vollständiges Rollout. An jedem Punkt dieser Reihenfolge ist ein Rollback ein geplantes Ergebnis — keine Notfallimprovisation. Die Ausweitung auf die nächste Stufe ist eine Entscheidung, die anhand der auf der aktuellen Stufe gesammelten Erkenntnisse getroffen wird, nicht eine automatische Voreinstellung, die mit der Zeit passiert.
Dieser Ansatz spiegelt das Konzept eines Error Budgets wider, beschrieben in „Site Reliability Engineering“ von Google (2016): eine definierte, akzeptable Menge an Instabilität, die ein System ausgeben darf und die dazu dient, den Kompromiss zwischen Release-Geschwindigkeit und Zuverlässigkeit zu einer expliziten, gemessenen Entscheidung zu machen statt zu einer impliziten.
Befähigung: Dokumentation & Team-Bereitschaft
Ein System, das niemand betreiben kann, ist nicht wirklich bereitgestellt worden.
Bereitstellungen werden häufig als abgeschlossen betrachtet, sobald die Software in der Produktion läuft. OpenQCore betrachtet sie jedoch erst dann als abgeschlossen, wenn die Personen, die für den Betrieb, die Unterstützung und die Fehlerbehebung der Software verantwortlich sind, tatsächlich darauf vorbereitet sind.
Betriebliche Runbooks
Dokumentierte Verfahren für gängige Betriebstätigkeiten, bekannte Ausfallmodi und wie darauf zu reagieren ist.
On-Call-Bereitschaft
Bestätigung, dass die für die Reaktion auf Vorfälle zuständigen Personen den Zugang, den Kontext und die Eskalationswege haben, die sie benötigen.
Wissensübergabe
Explizite Übergabe des betrieblichen Wissens an das Team oder die Organisation, die das System künftig betreuen wird.
Das Deployment-Entscheidungsgate
Eine Bereitstellung erfolgt, weil Beweise sie stützen — nicht weil sie geplant ist.
Jede geplante Bereitstellung erreicht ein definiertes Entscheidungsgate, bevor sie fortfährt.
Bereitstellen
Risikoabschätzung, Rollback-Plan und Bereitschaft sind erfüllt — die Bereitstellung erfolgt.
Aufschub
Ein identifizierter Risikofaktor wurde noch nicht ausreichend gemindert — die Bereitstellung wartet, bis dies der Fall ist.
Rollback
Eine bereitgestellte Änderung hat eine definierte Rollback-Bedingung ausgelöst — der vorherige Zustand wird wiederhergestellt.
Vorfall eskalieren
Eine Bereitstellung hat eine Auswirkung verursacht, die eine formelle Incident-Reaktion über einen Standard-Rollback hinaus erfordert.
Ein Deployment-Gate, das niemals verzögert oder zurückrollt, bewertet kein Risiko — es protokolliert lediglich einen Zeitplan.
Was diese Phase liefert
Ein laufendes System und die Fähigkeit, es zu betreiben.
Je nach Umfang des Engagements erzeugt diese Phase:
Bereitstellungs-Runbook
Das spezifische, wiederholbare Verfahren, mit dem diese Änderung und ähnliche zukünftige Änderungen bereitgestellt werden.
Rollback-Plan
Die definierten Auslösebedingungen, das Verfahren und das Wiederherstellungszeit-Ziel (RTO) für das Rückgängigmachen dieser Bereitstellung.
Aufzeichnung der Umgebungsfreigabe
Dokumentation darüber, wie die Änderung durch Entwicklung, Staging und Produktion gelangte und was in jeder Phase überprüft wurde.
Risikoabschätzungsdokument
Der vor der Bereitstellung bewertete Ausbreitungsradius, die Umkehrbarkeit und die Exposition von Abhängigkeiten.
Materialien zur Teambefähigung
Runbooks, Bestätigung der On-Call-Bereitschaft und der vor der Übergabe abgeschlossene Wissenstransfer.
Bericht zum schrittweisen Rollout
Die in jeder Phase der schrittweisen Einführung beobachteten Signale und die Nachweise, die eine Ausweitung auf den vollständigen Rollout stützen.
Von Bereitstellung zu Überwachung & Optimierung
Live ist nicht gleichbedeutend mit verstanden.
Deployment & Enablement erzeugt ein System, das sicher in der Produktion läuft, und bereitet die verantwortlichen Personen darauf vor, es zu betreiben. Es erzeugt jedoch noch kein kontinuierliches Verständnis darüber, wie dieses System sich im Zeitverlauf verhält, noch einen strukturierten Mechanismus zu dessen Verbesserung. Dafür ist die nächste und letzte Phase dieser Methodik gedacht.
Kontrollierte Produktionsexposition → Betriebsbereitschaft → Überwachung & Optimierung
Schritt 06
Überwachung & Optimierung
Verstehen, wie ein laufendes System sich tatsächlich verhält, und es kontinuierlich anhand realer Erkenntnisse verbessern.
Forschungs- & methodische Referenzen
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA-Studie zum Stand von DevOps
Quelle der oben genannten Metriken zur Bereitstellungsfrequenz und Wiederherstellungszeit.
Humble, J. & Farley, D. — Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Quelle der oben genannten Unterscheidung zwischen Deploy und Release, des Blue-Green-Deployments und der Infrastructure-as-Code-Prinzipien.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (eds.) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Quelle des in der Sektion zum schrittweisen Rollout genannten Error‑Budget‑Konzepts.