Die professionelle DevOps-Denkweise
Prüfungsbezug: Diese Lektion vermittelt das systemische Entscheidungsmodell für Domain 1. In der Prüfung sollst du das gesamte Bereitstellungssystem verbessern und nicht nur einen AWS-Dienst auswählen.
Lernziel
Erklären, wie sich Bereitstellungsgeschwindigkeit, Zuverlässigkeit, Wiederherstellbarkeit, Sicherheit, Nachvollziehbarkeit, Kosten und Betriebsaufwand gegenseitig beeinflussen. Mit diesem Modell einen Release-Prozess entwerfen, der schnelles Feedback sowie kleine und umkehrbare Änderungen ermöglicht.
| Schwierigkeitsgrad | Grundlage |
| Lernzeit | 150 Minuten |
| Voraussetzungen | AWS-Kenntnisse auf Associate-Niveau und CI/CD-Grundlagen |
Berufliches Szenario
Ein Unternehmen veröffentlicht alle zwei Wochen über eine lange manuelle Checkliste. Jeder Release enthält viele voneinander unabhängige Änderungen. Fehler treten häufig auf, und die Wiederherstellung hängt von der Person ab, die das Deployment ausgeführt hat. Das Management möchte täglich ausliefern, ohne die Auswirkungen auf Kunden zu erhöhen oder Compliance-Kontrollen abzuschwächen.
Die naheliegende Reaktion wäre, die vorhandene Checkliste zu automatisieren. Das reicht nicht aus. Enthält der Prozess unklare Verantwortlichkeiten, wiederholte Builds, nicht überprüfbare Freigaben und einen ungetesteten Rollback, führt Automatisierung diese Schwächen nur schneller aus. Eine professionelle DevOps-Lösung verändert zuerst die Arbeitsweise und automatisiert sie anschließend.
DevOps als Bereitstellungssystem
DevOps beschreibt die Gestaltung des gesamten Weges von einer Idee bis zu einer sicher betriebenen Änderung. Dazu gehören Menschen, Prozesse, Architektur und Automatisierung.
Vier Eigenschaften sind besonders wichtig:
- Fluss: Kleine Änderungen bewegen sich ohne lange Warteschlangen und Übergaben durch das System.
- Feedback: Ein Problem erreicht schnell die Person, die darauf reagieren kann.
- Lernen: Incidents und fehlgeschlagene Releases verbessern Tests, Runbooks, Architektur und Verantwortlichkeiten.
- Kontrolle: Sicherheits- und Compliance-Nachweise entstehen im normalen Bereitstellungsweg und müssen nicht nachträglich rekonstruiert werden.
Kein einzelner AWS-Dienst erzeugt diese Eigenschaften. CodePipeline kann Arbeit orchestrieren, CodeBuild kann Builds und Tests ausführen, CodeDeploy kann ein Deployment steuern und CloudWatch kann den Zustand zur Laufzeit bewerten. Die Qualität des Ergebnisses hängt weiterhin davon ab, wie diese Dienste verbunden und kontrolliert werden.
CI, Continuous Delivery und Continuous Deployment
Die Begriffe beschreiben unterschiedliche Zusagen:
| Vorgehen | Zusage | Typischer Kontrollpunkt |
|---|---|---|
| Continuous Integration | Kleine Änderungen werden häufig integriert und automatisch geprüft | Build- und Test-Feedback |
| Continuous Delivery | Jede erfolgreiche Änderung bleibt für Produktion auslieferbar | Eine Release-Entscheidung kann bestehen bleiben |
| Continuous Deployment | Jede erfolgreiche Änderung wird automatisch in Produktion veröffentlicht | Automatische Richtlinien- und Zustandsprüfungen |
Continuous Delivery bedeutet nicht, dass jeder Commit sofort Produktion erreicht. Die Software bleibt in einem veröffentlichungsfähigen Zustand, und der Release-Prozess ist wiederholbar. Eine regulierte Organisation kann eine dokumentierte Freigabe beibehalten und dennoch Continuous Delivery betreiben, wenn alle Schritte vor und nach dieser Entscheidung automatisiert und reproduzierbar sind.
Einmal bauen und dasselbe Artefakt weiterreichen
Eine Quellcodeversion sollte genau ein unveränderliches Release-Artefakt erzeugen. Dieses Artefakt wird getestet, bei Bedarf signiert oder gescannt, versioniert und ohne erneuten Build durch die Umgebungen weitergereicht.
Ein Artefaktmanifest sollte mindestens Folgendes enthalten:
- Quellcodeversion oder Commit-ID
- Build-Ausführung und Zeitstempel
- Abhängigkeits- oder Image-Version
- Ergebnisse von Tests und Sicherheitsprüfungen
- Digest oder Prüfsumme des Artefakts
- beim Deployment erwartete Konfigurationsversion
Ein erneuter Build pro Umgebung zerstört die eindeutige Herkunft. Selbst beim gleichen Commit können eine geänderte Abhängigkeit, ein anderes Basis-Image oder ein aktualisiertes Build-Werkzeug eine andere Binärdatei erzeugen. In Produktion würde dann etwas laufen, das in der vorherigen Umgebung nie getestet wurde.
Konfiguration wird getrennt behandelt. Das Artefakt bleibt identisch; umgebungsspezifische Werte werden über kontrollierte Konfiguration, Parameter oder Secrets bereitgestellt.
Feedbackschleifen und Bereitstellungskennzahlen
Kennzahlen sind nur sinnvoll, wenn daraus eine Entscheidung folgt. Eine einzelne Zahl darf nicht isoliert optimiert werden.
| Kennzahl | Leitfrage | Gefährliche Interpretation |
|---|---|---|
| Durchlaufzeit einer Änderung | Wie schnell erreicht ein Commit die Nutzer auf sichere Weise? | Tests entfernen, nur um die Pipeline zu beschleunigen |
| Deployment-Häufigkeit | Wie oft kann die Organisation sicher veröffentlichen? | Releases aufteilen, ohne Risiko oder Paketgröße zu senken |
| Fehlerrate von Änderungen | Wie oft erfordert ein Release Wiederherstellung oder Korrektur? | Fehler durch schwache Zustandskriterien verbergen |
| Wiederherstellungszeit | Wie schnell endet die Auswirkung auf Kunden? | Ticketabschluss statt Service-Wiederherstellung messen |
Diese Kennzahlen bilden ein System. Kleinere Änderungen können die Deployment-Häufigkeit erhöhen und gleichzeitig die Fehlersuche vereinfachen. Eine bessere Erkennung zur Laufzeit kann die gemessene Fehlerrate zunächst erhöhen, weil zuvor unsichtbare Fehler sichtbar werden. Das ist nützliche Information und kein Grund, das Monitoring abzuschwächen.
Durchgängiges Beispiel: vom Monatsrelease zum kontrollierten Fluss
Nehmen wir an, der ursprüngliche Prozess baut die Anwendung getrennt für Test und Produktion, verwendet eine gemeinsame Administratorrolle und betrachtet einen erfolgreichen Deployment-Befehl als Zustandsnachweis.
Ein besserer Zielfluss sieht so aus:
- Ein geprüfter Commit startet die Pipeline.
- Der Build erzeugt ein versioniertes Artefakt und speichert dessen Digest.
- Unit-Tests, statische Analyse und Abhängigkeitsprüfungen laufen sofort.
- Das Artefakt wird in eine isolierte Testumgebung deployt.
- Integrations- und Akzeptanztests prüfen das Verhalten.
- Für Produktion wird eine Deployment-Rolle mit temporären Zugangsdaten angenommen.
- Der Datenverkehr wird schrittweise verlagert, während technische und fachliche Alarme ausgewertet werden.
- Ein ausgelöster Alarm stoppt das Deployment oder macht es rückgängig.
- Ergebnis, gegebenenfalls freigebende Person, Artefakt-Digest und Zustandsnachweise werden aufbewahrt.
Dieses Design erhöht die Release-Häufigkeit, ohne Kontrolle aufzugeben. Außerdem wird die Wiederherstellungsentscheidung zu einem getesteten Ablauf: weitere Verlagerung stoppen, zum bekannten funktionierenden Stand zurückkehren und Nachweise für die Diagnose erhalten.
Architekturablauf
Kleine geprüfte Änderung
|
v
Einmal bauen -> testen und scannen -> unveränderliches Artefakt speichern
|
v
In Test deployen
|
Akzeptanznachweise
|
v
Kontrollierter Produktionsrelease
| |
gesund ungesund
| |
fortsetzen Rollback
Der Ablauf muss Erfolgs-, Fehler- und Wiederherstellungspfad zeigen. Ein Diagramm, das nur den Idealfall darstellt, ist unvollständig.
Entscheidungsmatrix
| Anforderung | Bevorzugte Richtung | Begründung |
|---|---|---|
| Häufige, risikoarme Releases | Kleine Pakete und automatische Prüfungen | Kleine Fehler sind leichter zu diagnostizieren und umzukehren |
| Strenge Produktionskontrolle | Continuous Delivery mit dokumentierter Freigabe | Erhält Verantwortlichkeit ohne manuellen Build |
| Schnelle Wiederherstellung | Unveränderliche Versionen und automatischer Rollback | Stellt einen bekannten funktionierenden Stand schnell wieder her |
| Eindeutige Herkunft | Einmal bauen und Artefakt-Digest speichern | Verbindet Quellcode, Nachweise und deployten Code |
| Sichere Prüfung in Produktion | Schrittweise Verkehrsverlagerung mit Alarmen | Begrenzt Auswirkungen während der Prüfung mit echtem Verkehr |
| Wiederholbare Compliance | Nachweise in der Pipeline erzeugen | Vermeidet manuelle Rekonstruktion nach dem Release |
Fehlerbilder und systematische Fehlersuche
Automatisierung erhält einen schlechten Prozess
Symptom: Die automatisierte Pipeline ist weiterhin langsam und wird häufig umgangen.
Untersuchung: Für jede Stage Wartezeit, manuelle Verzögerung, Ausführungszeit, Wiederholungen und Fehlerrate messen. Der Engpass ist häufig eine Übergabe oder ein instabiler Test und nicht fehlende Rechenleistung.
Unterschiedliche Artefakte erreichen die Umgebungen
Symptom: Der Test war erfolgreich, aber Produktion verhält sich bereits vor Berücksichtigung der Konfiguration anders.
Untersuchung: Quellcodeversion, Artefakt-Digest, Abhängigkeitssperrdatei, Basis-Image-Digest und Build-Ausführung vergleichen. Prüfen, ob Produktion das getestete Artefakt verwendet oder einen neuen Build erzeugt hat.
Die Pipeline ist grün, der Release aber fehlerhaft
Symptom: Die Deployment-API meldet Erfolg, während Kunden Fehler erhalten.
Untersuchung: Abschluss des Deployments und Zustand des Workloads getrennt bewerten. Load-Balancer-Zustand, Fehlerrate, Latenz, abhängige Systeme und eine fachliche Transaktion wie Anmeldung oder Bestellung prüfen.
Rollback existiert nur auf dem Papier
Symptom: Während eines Incidents zögern die Beteiligten, weil der Rollback Daten verlieren könnte oder nicht verstanden wird.
Untersuchung: Den Rollback mit denselben Annahmen zu Artefakt, Konfiguration, Datenbank und Datenverkehr testen, die in Produktion gelten. Manche Datenbankänderungen erfordern eine Korrektur nach vorn statt eines binären Rollbacks.
Sicherheit und Betrieb
- Kurzlebige Rollen statt gespeicherter Access Keys verwenden.
- Rechte für Menschen, Pipeline, Deployment und Laufzeit trennen.
- Artefakte gegen unbefugtes Ersetzen oder Löschen schützen.
- Secrets aus Quellcode, Build-Ausgabe, Logs und Freigabenachrichten fernhalten.
- Festhalten, wer einen Release gestartet und freigegeben hat, welches Artefakt deployt wurde und welche Nachweise die Beförderung erlaubt haben.
- Alarmkonfiguration und Rollback-Automatisierung wie Produktionscode prüfen und testen.
Praxislabor: einen manuellen Release neu entwerfen
Ziel: Einen manuellen Release in ein messbares Bereitstellungssystem überführen.
Ausgangsprozess
Verwende einen echten Prozess aus deiner Erfahrung oder diese Ausgangslage:
- wöchentliches Release-Fenster
- manueller Build auf einem Entwicklerrechner
- gemeinsam genutzte Testumgebung
- Administratorzugang für Produktion
- Smoke-Test nach dem Deployment
- Rollback-Beschreibung: „alte Version erneut deployen“
Aufgaben
- Alle heutigen Schritte vom Commit bis zum bestätigten Produktionszustand aufschreiben.
- Für jeden Schritt verantwortliche Person, Wartezeit, Ausführungszeit, Eingabe, Ausgabe und Nachweis erfassen.
- Manuelle Übergaben, wiederholte Builds, Secret-Offenlegung und ungeprüfte Annahmen markieren.
- Änderungen möglichst in kleinere, unabhängig auslieferbare Einheiten zerlegen.
- Stages für Source, Build, Test, Artefakt, Deployment, Verifikation und Rollback entwerfen.
- Identität und Manifest des unveränderlichen Artefakts festlegen.
- Vier Bereitstellungskennzahlen, deren Datenquellen und verantwortliche Personen definieren.
- Ein technisches und ein fachliches Zustandssignal für Produktion ergänzen.
- Die genaue Bedingung formulieren, die das Deployment stoppt oder rückgängig macht.
- Einen Fehler als Tabletop-Übung durchspielen und den ersten Diagnosenachweis notieren.
Validierungscheckliste
- Das Artefakt wird einmal gebaut und durch einen Digest identifiziert.
- Fehlende Pflichtnachweise blockieren die Beförderung.
- Produktionszugriff verwendet eine begrenzte temporäre Rolle.
- Deployment-Abschluss und Workload-Zustand werden getrennt bewertet.
- Rollback oder Korrektur nach vorn ist ausdrücklich beschrieben und testbar.
- Jede Kennzahl besitzt eine verantwortliche Person und eine daraus folgende Entscheidung.
Kostenkontrolle: Dies ist ein Design- und Tabletop-Labor; AWS-Ressourcen sind nicht erforderlich.
Aufräumen
In der Cloud ist kein Aufräumen erforderlich. Entferne echte Konto-IDs, interne URLs und vertrauliche Daten, bevor du das Design weitergibst.
Prüfungsfallen
- Continuous Delivery und Continuous Deployment verwechseln.
- Mehr manuelle Freigaben statt stärkerer automatischer Nachweise wählen.
- Ein Artefakt in jeder Umgebung neu bauen.
- Einen erfolgreichen Deployment-API-Aufruf als Beweis für Anwendungszustand betrachten.
- Deployment-Häufigkeit optimieren und Fehler sowie Wiederherstellung ignorieren.
- Einen komplexen eigenen Ablauf wählen, obwohl verwaltete Kontrollen die Anforderungen erfüllen.
Wichtigste Erkenntnisse
- Den vollständigen Wertstrom einschließlich Feedback und Wiederherstellung optimieren.
- Ein einziges unveränderliches und eindeutig identifizierbares Release-Artefakt weiterreichen.
- Kleine, umkehrbare Änderungen verbessern Geschwindigkeit und Zuverlässigkeit.
- Sicherheits-, Zustands- und Compliance-Nachweise als Teil der Bereitstellung erzeugen.
- Kunden- und Geschäftsergebnisse messen, nicht nur Pipeline-Aktivität.
Wiederholungsfragen
- Worin unterscheiden sich Continuous Delivery und Continuous Deployment?
- Warum sollte dasselbe Artefakt durch alle Umgebungen weitergereicht werden?
- Warum reicht Pipeline-Erfolg nicht als Nachweis für einen gesunden Release?
- Wie kann eine höhere Deployment-Häufigkeit das Risiko senken?
- Welche Informationen gehören in ein Artefaktmanifest?
- Warum kann die gemessene Fehlerrate nach verbessertem Monitoring zunächst steigen?
- Wann kann eine Korrektur nach vorn sicherer als ein Rollback sein?
- Wann ist eine manuelle Produktionsfreigabe mit Continuous Delivery vereinbar?
Modellantworten
- Continuous Delivery hält jede erfolgreiche Änderung auslieferbar und kann eine Release-Entscheidung beibehalten. Continuous Deployment befördert automatisch jede Änderung, die alle definierten Kontrollen erfüllt.
- Dadurch bleibt die Herkunft eindeutig. Die getesteten Bytes sind dieselben, die deployt werden; eine andere Abhängigkeit, ein anderes Basis-Image oder eine andere Build-Umgebung kann Produktion nicht unbemerkt verändern.
- Die Pipeline beweist nur, dass ihre konfigurierten Actions erfolgreich waren. Abhängigkeiten zur Laufzeit, Kundentransaktionen, Latenz und fachliche Ergebnisse können trotzdem fehlerhaft sein.
- Häufige Auslieferung begünstigt kleinere Pakete. Eine kleine Änderung enthält weniger zusammenwirkende Ursachen, ist leichter zu testen und schneller umzukehren.
- Mindestens Quellcodeversion, Build-Identität, Artefaktversion und -Digest, Abhängigkeits- oder Image-Identität, Testnachweise, Scan-Nachweise und erwartete Konfigurationsversion.
- Bessere Erkennung macht zuvor unsichtbare Fehler sichtbar. Die Kennzahl wird zunächst ehrlicher, bevor Prozessverbesserungen die Rate senken.
- Wenn eine Änderung nicht sicher rückgängig gemacht werden kann, etwa bei einer inkompatiblen Datenmigration, kann eine getestete Korrekturänderung den Service mit weniger Risiko wiederherstellen.
- Die Software bleibt auslieferbar, die Freigabe ist eine klare und dokumentierte Entscheidung, und der umgebende Build-, Nachweis-, Deployment- und Verifikationsprozess ist automatisiert und wiederholbar.