Begriff
DevOps
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
DevOps ist keine Software, sondern eine Berufsphilosophie. Früher gab es zwei verfeindete Lager:
- Devs (Entwickler): Wollen ständig neue Features bauen. "Move fast!"
- Ops (Admins): Wollen, dass der Server stabil läuft. "Don't touch anything!"
DevOps reißt die Mauer zwischen ihnen ein. Entwickler sollen verstehen, wie Server funktionieren. Admins sollen verstehen, wie Code funktioniert. Ziel: Software schneller und sicherer veröffentlichen.
Merksatz: Die Verschmelzung von Entwicklung (Dev) und Betrieb (Ops) durch Zusammenarbeit und Automatisierung.
DevOps wird oft mit einer Unendlichkeits-Schleife (Infinity Loop) dargestellt: Plan -> Code -> Build -> Test -> Release -> Deploy -> Operate -> Monitor -> Plan...
Das wichtigste Werkzeug ist Automatisierung:
- Statt Software manuell auf den Server zu kopieren (gefährlich), baut man eine Pipeline (CI/CD).
- Sobald der Programmierer speichert, testen Roboter den Code und schieben ihn automatisch auf den Server.
- Wenn etwas kaputt geht, wird automatisch ein altes Backup eingespielt (Rollback).
1. Infrastructure as Code (IaC)
Früher hat man Server von Hand installiert (Klick, Klick, CD einlegen).
Im DevOps schreibt man die Infrastruktur als Code (z. B. mit Terraform).
resource "server" "web" { ram = 8GB }
Wenn man diesen Code ausführt, erstellt die Cloud automatisch den Server.
Vorteil: Man kann die gesamte Firmen-Infrastruktur löschen und in Minuten exakt gleich wieder aufbauen (Disaster Recovery).
2. Cattle vs. Pets
Ein wichtiges Mantra im DevOps: Behandle Server wie Vieh (Cattle), nicht wie Haustiere (Pets).
- Pet: Dein Server hat einen süßen Namen ("Gandalf"). Wenn er krank ist, pflegst du ihn gesund. (Schlecht).
- Cattle: Dein Server heißt "s-001". Wenn er krank ist, erschießt du ihn (löschen) und bestellst einen neuen ("s-002"). (Gut, weil schneller und sicherer).
3. SRE (Site Reliability Engineering)
Die Google-Version von DevOps. "Hope is not a strategy." SREs sind Programmierer, die sich um Operations kümmern. Sie definieren Fehler-Budgets ("Wir dürfen maximal 5 Minuten pro Monat offline sein"). Solange man im Budget ist, darf man riskante Updates machen.
1. DORA Metrics
Wie misst man, ob ein Team "gutes DevOps" macht? Nicht in Code-Zeilen, sondern durch die empirischen DORA Metriken (DevOps Research and Assessment):
- Deployment Frequency: Wie oft wird Code auf Produktion ausgeliefert? (Top-Teams machen das mehrmals pro Tag, anstatt alle 6 Monate).
Lead Time for Changes: Dauert es von einem Commit im Git bis zur echten Produktion Tage (schlecht) oder Minuten (gut)?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: DevOps wird oft mit einer Unendlichkeits-Schleife (Infinity Loop) dargestellt: Plan - Code - Build - Test - Release - Deploy - Operate - Monitor - Plan...Mean Time to Recovery (MTTR): Wie schnell ist das System nach einem fatalen Bug wieder intakt?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: DevOps wird oft mit einer Unendlichkeits-Schleife (Infinity Loop) dargestellt: Plan - Code - Build - Test - Release - Deploy - Operate - Monitor - Plan...- Change Failure Rate: Wie viel Prozent der Deployments führen zu einem Crash? Diese Metriken demaskieren sofort traditionelle "Wasserfall"-Kulturen, die CI/CD-Pipelines nur als teure Skripte betreiben.
2. Infrastructure as Code (IaC) vs. Configuration Management
Wenn alles Code ist, grenzen sich zwei Disziplinen scharf ab:
- Provisionierung (Terraform, CloudFormation): Das Erschaffen der nackten Blechschale in der Cloud. "Gib mir 3x Ubuntu Server auf AWS, eine RDS SQL, ein Loadbalancer und mache das Routing (VPC) startklar." (Immutable Infrastructure).
- Configuration Management (Ansible, Chef, Puppet): Das Konfigurieren des Systems nach dem Start. "Logge dich auf den laufenden 3 Ubuntu Servern ein, installiere Apache, konfiguriere die SSL Zertifikate und lege den User 'admin' an." (Mutable Configuration). Hochmoderne Umgebungen sparen sich Ansible völlig, und flashen stattdessen komplett fertige Maschinen-Images (AMIs, wie Container), gepackt via Packer.
3. GitOps als DevOps-Evolution
Die Krönung der Automatisierung. Anstatt dass eine Jenkins CI-Pipeline (außerhalb der Infrastruktur) mit Admin-Token hart in den Cluster zielt und Deploy-Befehle "hineinpusht" (Push-Modell), dreht man es um: Die komplette Infrastruktur-Soll-Konfiguration liegt als YAML strukturiert in GitHub. Operatoren (z.B. ArgoCD) nisten sich innerhalb der Infrastruktur ein und "pullen" (beobachten) nur dieses Git-Repo. Gibt es einen Merge auf den Main-Branch, liest der Cluster das und baut sich selbst um (Pull-Modell). Keine externen CI-Server kennen die Cluster-Passwörter mehr (Security-Plus).
Quick-Check
Ist DevOps eine Berufsbezeichnung oder eine Methode?
Eigentlich eine Methode/Kultur. Aber heute gibt es viele Jobtitel wie "DevOps Engineer" (jemand, der Tools für diese Methode baut).Warum wollen "Ops" (Admins) oft keine Änderungen?
Weil jede Änderung das Risiko birgt, dass etwas abstürzt (Never change a running system). DevOps löst das durch bessere Tests und Automatisierung.Was bedeutet "Shift Left"?
Dass man Dinge wie Sicherheit und Tests viel früher im Prozess (ganz links im Zeitstrahl) macht, statt erst ganz am Ende kurz vor dem Release.