DevOps
Wenn Software geschrieben ist, muss sie irgendwann auf einem Server laufen. Der Weg vom fertigen Code bis zur laufenden Anwendung war lange ein manueller, fehleranfälliger Prozess. DevOps beschreibt die Praxis, diesen Weg zu automatisieren und die Trennung zwischen Entwicklung und Betrieb aufzuheben.
Was DevOps zusammenführt
In klassischen IT-Organisationen arbeiten Entwicklungsteams und Betriebsteams getrennt. Entwickler schreiben Code und übergeben ihn an den Betrieb. Der Betrieb installiert die Software auf Servern, konfiguriert Netzwerke und überwacht den laufenden Zustand. Zwischen beiden Teams liegt eine organisatorische Grenze: unterschiedliche Ziele, unterschiedliche Werkzeuge, unterschiedliche Verantwortlichkeiten.
Beispiel: Ein Entwicklungsteam veröffentlicht alle sechs Wochen ein neues Release. Der Betrieb erhält ein Installationspaket mit einer mehrseitigen Anleitung. Bei der Installation treten Fehler auf, weil die Testumgebung sich von der Produktionsumgebung unterscheidet. Der Betrieb meldet das Problem zurück. Der Zyklus beginnt von vorn.
DevOps löst diese Trennung auf. Beide Seiten arbeiten mit denselben Werkzeugen, denselben Repositories, denselben Pipelines. Die Verantwortung für eine Anwendung endet nicht mit dem Commit, sondern erstreckt sich über den gesamten Lebenszyklus.
Beispiel: Ein Team betreibt einen Webshop. Entwickler und Betrieb nutzen dasselbe Git-Repository. Änderungen am Code durchlaufen automatisierte Tests. Bei Erfolg wird die Software automatisch auf Staging-Servern installiert. Nach manueller Freigabe folgt das Produktions-Deployment. Fehler im Betrieb werden im selben Ticketsystem erfasst wie Feature-Anforderungen.
Der Kreislauf von Code zu Produktion
Der DevOps-Prozess folgt einem Kreislauf. Code wird geschrieben, getestet, gebaut, ausgeliefert, überwacht. Erkenntnisse aus dem Betrieb fließen zurück in die Entwicklung. Dieser Kreislauf wird häufig als CI/CD bezeichnet: Continuous Integration und Continuous Delivery.
Beispiel: Ein Entwickler ändert eine Funktion in einem Bezahlmodul. Der Commit löst eine Pipeline aus. Zuerst laufen Unit-Tests, dann Integrationstests gegen eine Testdatenbank. Bei Erfolg wird ein Container-Image gebaut und in eine Registry hochgeladen. Ein Deployment-Schritt installiert das Image auf einem Staging-Server. Nach manueller Prüfung erfolgt das Rollout auf Produktion.
Continuous Integration bedeutet: Jede Codeänderung wird automatisch gebaut und getestet. Fehler werden früh erkannt, bevor sie sich auf andere Teile des Systems auswirken. Continuous Delivery erweitert diesen Prozess um die automatisierte Auslieferung bis in produktionsnahe Umgebungen.
Beispiel: Ein Open-Source-Projekt auf GitHub nutzt GitHub Actions als CI-System. Bei jedem Pull Request laufen Linting, Unit-Tests und ein Build-Schritt. Nur wenn alle Schritte erfolgreich sind, kann der Pull Request zusammengeführt werden. Nach dem Merge in den Hauptbranch wird automatisch ein Docker-Image gebaut und in eine Registry gepusht.
Infrastruktur als Code
Ein zentrales Prinzip von DevOps lautet: Infrastruktur wird nicht manuell konfiguriert, sondern in Code beschrieben. Serverkonfigurationen, Netzwerkregeln, Datenbank-Setups liegen als Dateien im gleichen Repository wie der Anwendungscode. Dieses Prinzip heißt Infrastructure as Code (IaC).
Beispiel: Ein Team beschreibt seine Server-Infrastruktur in Terraform-Dateien. Drei Webserver, ein Load Balancer, eine Datenbank. Eine Änderung am Terraform-Code durchläuft dieselbe Pipeline wie eine Änderung am Anwendungscode: Review, Test, Deployment. Der Zustand der Infrastruktur ist jederzeit im Repository nachvollziehbar.
Der Vorteil: Infrastruktur wird reproduzierbar. Eine Testumgebung lässt sich mit demselben Code aufbauen wie die Produktionsumgebung. Konfigurationsdrift, also die schleichende Abweichung zwischen dokumentiertem und tatsächlichem Zustand, wird verhindert, weil der Code die einzige Quelle der Wahrheit ist.
Beispiel: Nach einem Serverausfall muss die gesamte Infrastruktur neu aufgebaut werden. Ohne IaC bedeutet das tagelange manuelle Arbeit. Mit IaC genügt ein einziger Befehl: terraform apply. Die gesamte Infrastruktur wird innerhalb von Minuten wiederhergestellt, identisch zum vorherigen Zustand.
Beobachtbarkeit im laufenden Betrieb
Software, die in Produktion läuft, erzeugt Daten: Logeinträge, Metriken, Traces. DevOps-Praktiken setzen auf systematische Auswertung dieser Daten. Drei Säulen bilden die Grundlage der Beobachtbarkeit: Logs (einzelne Ereignisse), Metriken (aggregierte Zahlenwerte über Zeit) und Traces (Verfolgung einzelner Anfragen durch verteilte Systeme).
Beispiel: Eine E-Commerce-Anwendung besteht aus fünf Microservices. Ein Kunde meldet, dass Bestellungen fehlschlagen. Das Team öffnet das Tracing-System und verfolgt eine fehlgeschlagene Bestellung durch alle beteiligten Services. Der Trace zeigt: Der Zahlungsservice antwortet nach 30 Sekunden mit einem Timeout. Die Ursache ist eine fehlerhafte Datenbankabfrage im Zahlungsservice.
Alerting ergänzt die Beobachtbarkeit. Schwellenwerte werden definiert: Wenn die Fehlerrate über 1% steigt oder die Antwortzeit über 500 Millisekunden liegt, wird das Team benachrichtigt. Gute Alerts unterscheiden zwischen Symptomen (der Nutzer erlebt ein Problem) und Ursachen (die Datenbank ist langsam).
Beispiel: Ein Team definiert ein Service Level Objective (SLO): 99,9% aller Anfragen sollen in unter 200 Millisekunden beantwortet werden. Das Monitoring-System berechnet laufend, wie viel des monatlichen Fehlerbudgets bereits verbraucht ist. Bei 50% Verbrauch nach einer Woche wird automatisch ein Incident erstellt.
Deployment-Strategien
Wenn Software häufig ausgeliefert wird, steigt die Bedeutung sicherer Deployment-Verfahren. Verschiedene Strategien reduzieren das Risiko:
Beispiel: Blue-Green-Deployment: Zwei identische Produktionsumgebungen existieren parallel. Die aktive Umgebung (Blue) bedient den Nutzerverkehr. Die neue Version wird auf der inaktiven Umgebung (Green) installiert und getestet. Nach erfolgreicher Prüfung wird der Verkehr umgeleitet. Bei Problemen genügt eine Rückkehr zu Blue.
Beispiel: Canary-Deployment: Die neue Version wird zunächst nur an 5% der Nutzer ausgeliefert. Das Monitoring vergleicht Fehlerraten und Antwortzeiten zwischen alter und neuer Version. Nur wenn die Metriken stabil bleiben, wird der Anteil schrittweise erhöht. Bei Auffälligkeiten wird automatisch zurückgerollt.
Feature Flags ermöglichen eine weitere Entkopplung: Neuer Code wird ausgeliefert, aber über Konfigurationsschalter deaktiviert. Teams können Funktionen gezielt für einzelne Nutzergruppen freischalten, ohne erneut zu deployen.
Beispiel: Ein Team entwickelt eine neue Suchfunktion. Der Code wird über die normale Pipeline ausgeliefert, aber hinter einem Feature Flag verborgen. Zunächst sehen nur interne Tester die neue Suche. Nach positivem Feedback wird die Funktion für 10% der Nutzer freigeschaltet, dann für alle.
DevOps bei KI-Systemen
Bei Machine-Learning-Anwendungen erweitert sich der DevOps-Kreislauf um zusätzliche Schritte. Neben Code müssen auch Trainingsdaten, Modellversionen und Hyperparameter verwaltet werden. Diese Erweiterung wird als MLOps bezeichnet.
Beispiel: Ein Team betreibt ein Empfehlungssystem. Das Modell wird wöchentlich mit neuen Nutzerdaten nachtrainiert. Die Trainings-Pipeline läuft automatisiert: Daten laden, bereinigen, Modell trainieren, evaluieren. Nur wenn die Evaluationsmetriken über einem Schwellenwert liegen, wird das neue Modell in Produktion übernommen.
Ein zentrales Problem bei KI-Systemen ist Drift: Die Eingabedaten in Produktion verändern sich über die Zeit, und die Modellqualität sinkt. Monitoring muss deshalb nicht nur technische Metriken (Latenz, Fehlerrate) erfassen, sondern auch fachliche Metriken (Vorhersagegenauigkeit, Verteilung der Eingabedaten).
Beispiel: Ein Spamfilter wurde mit E-Mails aus 2024 trainiert. Im Frühjahr 2025 ändern Spammer ihre Strategie: statt Links enthalten die E-Mails jetzt QR-Codes in Bildanhängen. Das Monitoring zeigt, dass die Erkennungsrate von 98% auf 71% gefallen ist. Die Pipeline startet automatisch ein Nachtraining mit aktuellen Daten.
Fachliche Einordnung: MLOps überträgt die Prinzipien von DevOps auf den Lebenszyklus von ML-Modellen. Die zusätzliche Komplexität liegt im Nicht-Determinismus der Trainingsergebnisse und der Abhängigkeit von Datenqualität. Während bei klassischer Software ein Build bei gleichem Quellcode stets dasselbe Ergebnis liefert, kann ein Modelltraining mit identischen Daten zu unterschiedlichen Gewichten führen. Das erfordert systematisches Experiment-Tracking und Modell-Versionierung.
Grenzen und Herausforderungen
DevOps ist kein Universalmittel. Die Einführung erfordert organisatorische Veränderungen, die über technische Werkzeuge hinausgehen. Teams müssen bereit sein, Verantwortung über bisherige Grenzen hinaus zu übernehmen. In stark regulierten Branchen (Finanzwesen, Medizintechnik, Luftfahrt) steht die Automatisierung in Spannung mit Auditierbarkeit und Freigabepflichten.
Beispiel: Ein Pharmaunternehmen muss jede Softwareänderung an einem validierten System dokumentieren und genehmigen lassen (GxP-Compliance). Vollautomatische Deployments ohne manuelle Freigabe sind nicht zulässig. DevOps-Praktiken werden hier angepasst: Die Pipeline automatisiert Tests und Dokumentation, aber das finale Deployment erfordert eine dokumentierte Freigabe.
Weitere Grenzen: Die Werkzeuglandschaft ist fragmentiert. Kubernetes, Docker, Terraform, Ansible, Jenkins, GitHub Actions, ArgoCD, Prometheus, Grafana, ELK-Stack. Die Auswahl und Integration dieser Werkzeuge erfordert Spezialisierung. Die Komplexität verlagert sich: statt manueller Server-Administration muss nun die Automatisierungsinfrastruktur selbst gewartet werden.
Sicherheit bildet eine weitere Herausforderung. Automatisierte Pipelines benötigen Zugangsdaten zu Produktionssystemen. Supply-Chain-Angriffe zielen auf Build-Systeme und Abhängigkeiten. DevSecOps erweitert den Ansatz um systematische Sicherheitsprüfungen in der Pipeline: statische Codeanalyse, Abhängigkeitsscans, Container-Image-Scans.
Beispiel: Eine CI-Pipeline integriert einen Abhängigkeitsscanner. Bei jedem Build werden alle Bibliotheken gegen eine Schwachstellendatenbank geprüft. Eine kritische Schwachstelle in einer Logging-Bibliothek wird erkannt, bevor die Software in Produktion geht. Der Build wird blockiert, bis die Abhängigkeit aktualisiert ist.
Fachliche Einordnung: DevOps hat sich seit der Begriffsprägung 2009 von einer Nischenbewegung zum Industriestandard entwickelt. Die jährlichen State-of-DevOps-Reports zeigen konsistent, dass Teams mit ausgereiften DevOps-Praktiken häufiger und stabiler deployen. Gleichzeitig wächst die Kritik am Begriff selbst: Wenn DevOps alles bedeutet (Kultur, Tools, Prozesse, Rollen), verliert der Begriff an analytischer Schärfe. Platform Engineering hat sich als jüngere Disziplin abgegrenzt, mit Fokus auf interne Entwicklerplattformen statt auf kulturelle Transformation.