DevOps Enterprise

KAPITEL 10 · ENTERPRISE IT

DevOps Enterprise

Die Revolution der Softwareentwicklung – von CI/CD-Pipelines über Infrastructure as Code bis zu Container-Orchestrierung und DevSecOps. Wie Unternehmen schneller, sicherer und zuverlässiger Software ausliefern.

CI/CD Container IaC DevSecOps Monitoring

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernst du alles über DevOps in der Enterprise IT:

  • Definition: Was ist DevOps und warum ist es wichtig?
  • CALMS-Prinzip: Culture, Automation, Lean, Measurement, Sharing
  • DevOps-Phasen: Plan → Code → Build → Test → Release → Deploy → Operate → Monitor
  • CI/CD-Pipelines: Continuous Integration & Continuous Deployment
  • Infrastructure as Code: Terraform, Ansible, CloudFormation
  • Container & Orchestrierung: Docker, Kubernetes, Helm
  • DevSecOps: Security in der Pipeline
  • Site Reliability Engineering (SRE): Betrieb auf Enterprise-Level
  • Tools & Technologien: Die wichtigsten DevOps-Tools im Überblick
  • Best Practices: Bewährte Methoden für den Erfolg
  • FAQ & Praxisaufgaben: Wissen testen und vertiefen

1. Was ist DevOps?

Definition

DevOps (Kurzform von Development und Operations) ist eine Sammlung von Praktiken, Tools und einer Philosophie, die darauf abzielt, die Zusammenarbeit zwischen Softwareentwicklung (Dev) und IT-Betrieb (Ops) zu automatisieren und zu integrieren.

Das Ziel von DevOps ist es, die Bereitstellungszeit zu verkürzen, die Auslieferungsqualität zu erhöhen und die Zusammenarbeit zwischen Teams zu verbessern – alles bei gleichzeitiger Reduzierung von Risiken und Ausfallzeiten.

Analogie: DevOps ist wie eine Rennboxen-Crew in der Formel 1. Entwickler und Betrieb arbeiten Hand in Hand, um das Auto (die Software) so schnell wie möglich wieder auf die Strecke (in die Produktion) zu bringen – mit minimaler Downtime und maximaler Performance.

DevOps vs. Traditionelle IT

Aspekt Traditionelle IT DevOps
Team-Struktur Getrennte Teams (Dev, Ops, QA) Cross-funktionale Teams
Release-Zyklus Monate bis Jahre Tage bis Stunden
Automatisierung Manuelle Prozesse Hohe Automatisierung
Fehlerkultur Fehler vermeiden, Schuldzuweisung Fehler als Lernchance, Blameless Post-Mortems
Infrastruktur Manuell konfiguriert, "Pets" Code-basiert, "Cattle"
Monitoring Reaktiv (nach Ausfall) Proaktiv (vor Ausfall)
Feedback Langsam, indirekt Schnell, direkt, kontinuierlich

2. Das CALMS-Prinzip

Die fünf Säulen einer erfolgreichen DevOps-Transformation – ohne diese bleibt DevOps nur eine Ansammlung von Tools.

C

Culture

Kultur der Zusammenarbeit, Vertrauen und gemeinsamer Verantwortung. Dev und Ops arbeiten als ein Team.

A

Automation

Automatisierung repetitiver Aufgaben: Builds, Tests, Deployments, Infrastruktur-Provisionierung.

L

Lean

Lean-Prinzipien: Kleine Batches, schnelle Feedback-Zyklen, Verschwendung eliminieren, kontinuierliche Verbesserung.

M

Measurement

Messung von Performance, Qualität und Geschäftswert. Datengetriebene Entscheidungen statt Bauchgefühl.

3. Die DevOps-Phasen (Infinity Loop)

DevOps ist ein kontinuierlicher Kreislauf – kein linearer Prozess. Jede Phase fließt nahtlos in die nächste über.

Der DevOps Lifecycle

1
Plan

Anforderungen definieren, Backlog pflegen, Sprint-Planung

2
Code

Entwicklung, Code-Reviews, Branching-Strategien

3
Build

Kompilierung, Dependency-Management, Artefakt-Erstellung

4
Test

Unit-, Integration-, Performance-Tests, Security-Scans

5
Release

Versionierung, Release-Notes, Approval-Prozesse

6
Deploy

Automatisierte Auslieferung, Blue-Green, Canary

7
Operate

Betrieb, Wartung, Incident-Management, Scaling

8
Monitor

Logging, Metrics, Alerting, Feedback an Plan-Phase

4. CI/CD – Continuous Integration & Delivery

Das Herzstück von DevOps – automatisierte Pipelines, die Code-Änderungen schnell und zuverlässig in die Produktion bringen.

Was ist CI/CD?

Continuous Integration (CI): Entwickler integrieren Code-Änderungen mehrmals täglich in einen gemeinsamen Branch. Jede Integration wird automatisch gebaut und getestet, um Fehler früh zu erkennen.

Continuous Delivery (CD): Jede Code-Änderung, die alle Tests besteht, wird automatisch in ein deploy-fähiges Artefakt gebaut und kann jederzeit mit einem Klick in die Produktion ausgerollt werden.

Continuous Deployment (CD): Die Erweiterung von Continuous Delivery – jede erfolgreiche Änderung wird automatisch in die Produktion deployed, ohne manuelle Freigabe.

Vorteile von CI/CD

Schnellere Releases

  • Release-Zyklen von Monaten auf Tage/Stunden reduziert
  • Automatisierte Prozesse eliminieren manuelle Arbeit
  • Parallele Entwicklung durch Feature-Branches

Höhere Qualität

  • Automatisierte Tests bei jeder Änderung
  • Fehler werden früher erkannt (Shift Left)
  • Konsistente Build-Umgebungen

Einfachere Rollbacks

  • Kleine, häufige Änderungen sind leichter rückgängig zu machen
  • Automatisierte Rollback-Mechanismen
  • Blue-Green Deployments für sofortige Umstellung

Beispiel: GitHub Actions Pipeline

YAML name: CI/CD Pipeline on: push: branches: [main] jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Install dependencies run: npm install - name: Run tests run: npm test - name: Build run: npm run build - name: Deploy to production if: success() run: ./deploy.sh

5. Infrastructure as Code (IaC)

Infrastruktur wird nicht mehr manuell konfiguriert, sondern durch Code definiert, versioniert und automatisiert bereitgestellt.

Was ist IaC?

Infrastructure as Code (IaC) bedeutet, dass Server, Netzwerke, Datenbanken und andere Infrastruktur-Komponenten durch Code-Dateien (z.B. YAML, JSON, HCL) definiert werden, anstatt manuell konfiguriert zu werden.

Diese Code-Dateien werden in Git versioniert, durchlaufen Code-Reviews und werden automatisiert deployed – genau wie Anwendungscode.

Vorteile: Reproduzierbare Umgebungen, Versionierung, Audit-Trail, schnelle Provisionierung, Konsistenz zwischen Development, Testing und Production.

IaC-Tools im Vergleich

Tool Anbieter Typ Sprache Einsatzgebiet
Terraform HashiCorp Provisionierung HCL Multi-Cloud Infrastruktur
Ansible Red Hat Konfiguration YAML Server-Konfiguration, Orchestrierung
CloudFormation AWS Provisionierung JSON/YAML AWS-spezifisch
Pulumi Pulumi Provisionierung TypeScript, Python, Go Multi-Cloud mit Programmiersprachen
Chef Chef Software Konfiguration Ruby Enterprise Konfigurationsmanagement
Puppet Puppet Konfiguration Puppet DSL Large-Scale Konfigurationsmanagement

Beispiel: Terraform für AWS EC2

HCL provider "aws" { region = "eu-central-1" } resource "aws_instance" "web" { ami = "ami-0c55b159cbfafe1f0" instance_type = "t3.micro" tags = { Name = "WebServer" Environment = "Production" } } output "public_ip" { value = aws_instance.web.public_ip }

6. Container & Orchestrierung

Container sind die Standard-Technologie für moderne Software-Auslieferung – leichtgewichtig, portabel und isoliert.

Docker

Container-Runtime

Die führende Container-Plattform. Pakagt Anwendungen mit allen Abhängigkeiten in portable Container.

  • Dockerfile für Image-Build
  • Docker Compose für Multi-Container
  • Docker Hub für Image-Registry
  • Leichtgewichtig (shared Kernel)
Einsatz: Entwicklung, Testing, CI/CD-Pipelines

Kubernetes (K8s)

Container-Orchestrierung

Das De-facto-Standard-System zur Orchestrierung von Container-Workloads im großen Maßstab.

  • Automatische Skalierung (HPA, VPA)
  • Self-Healing (Neustart bei Fehlern)
  • Service Discovery & Load Balancing
  • Rolling Updates & Rollbacks
Einsatz: Produktion, Microservices, Cloud-Native Apps

Helm

Kubernetes Package Manager

Der "apt/yum" für Kubernetes. Vereinfacht das Deployment komplexer Anwendungen auf K8s.

  • Helm Charts für wiederverwendbare Deployments
  • Template-System mit Variablen
  • Versionierung von Releases
  • Artifact Hub für öffentliche Charts
Einsatz: Kubernetes-Deployments, App-Marketplace

Beispiel: Dockerfile

DOCKERFILE # Basis-Image FROM node:18-alpine # Arbeitsverzeichnis setzen WORKDIR /app # Dependencies kopieren und installieren COPY package*.json ./ RUN npm ci --only=production # Anwendungscode kopieren COPY . . # Port freigeben EXPOSE 3000 # Start-Kommando CMD ["node", "server.js"]

7. DevSecOps – Security in der Pipeline

Security wird nicht als nachträglicher Schritt, sondern als integraler Bestandteil des gesamten DevOps-Prozesses verstanden.

Was ist DevSecOps?

DevSecOps integriert Sicherheitspraktiken früh und kontinuierlich in den DevOps-Prozess – nicht erst am Ende vor dem Release. Security wird zur gemeinsamen Verantwortung von Development, Security und Operations.

Shift Left Security: Sicherheitstests werden so früh wie möglich im Entwicklungsprozess durchgeführt – idealerweise bereits beim Schreiben des Codes, nicht erst vor dem Deployment.

DevSecOps-Praktiken

Static Application Security Testing (SAST)

  • Analyse des Quellcodes auf Sicherheitslücken
  • Integration in IDE und CI/CD-Pipeline
  • Tools: SonarQube, Checkmarx, Snyk Code

Software Composition Analysis (SCA)

  • Prüfung von Third-Party-Dependencies auf bekannte Schwachstellen
  • Automatische Alerts bei CVEs
  • Tools: Snyk, WhiteSource, Dependabot

Dynamic Application Security Testing (DAST)

  • Test der laufenden Anwendung auf Sicherheitslücken
  • Simulation von Angriffen (Black-Box-Testing)
  • Tools: OWASP ZAP, Burp Suite, Acunetix

Container Security

  • Scanning von Container-Images auf Schwachstellen
  • Runtime-Security und Anomalie-Erkennung
  • Tools: Trivy, Clair, Aqua Security, Falco

Secrets Management

  • Sichere Speicherung von Passwörtern, API-Keys, Zertifikaten
  • Keine Secrets im Code oder Git
  • Tools: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault

Compliance as Code

  • Automatisierte Prüfung von Compliance-Anforderungen
  • Policy-as-Code mit OPA (Open Policy Agent)
  • Tools: Chef InSpec, Open Policy Agent, AWS Config

8. Site Reliability Engineering (SRE)

SRE ist die Antwort von Google auf die Frage: "Wie betreibt man Software im großen Maßstab zuverlässig?"

Was ist SRE?

Site Reliability Engineering (SRE) ist eine Disziplin, die Aspekte des Software-Engineerings auf Infrastruktur- und Betriebsprobleme anwendet. SREs behandeln Betrieb als ein Software-Problem und setzen Automatisierung ein, um Systeme skalierbar und zuverlässig zu machen.

Kernprinzip: "Hope is not a strategy" – SREs verlassen sich nicht auf Hoffnung, sondern bauen Systeme, die auch bei Fehlern funktionieren.

SRE-Metriken

Metrik Beschreibung Typisches Ziel
SLI (Service Level Indicator) Messgröße für Service-Qualität (z.B. Latenz, Fehlerrate) -
SLO (Service Level Objective) Zielwert für SLI (z.B. 99.9% Verfügbarkeit) 99.9% - 99.999%
SLA (Service Level Agreement) Vertragliche Vereinbarung mit Konsequenzen bei Verletzung 99.9% - 99.95%
Error Budget Erlaubte Fehlermenge innerhalb eines Zeitraums 1 - SLO
MTTR (Mean Time To Recovery) Durchschnittliche Zeit zur Wiederherstellung So niedrig wie möglich
MTBF (Mean Time Between Failures) Durchschnittliche Zeit zwischen Ausfällen So hoch wie möglich

9. Die wichtigsten DevOps-Tools

Ein Überblick über die wichtigsten Tools in jeder Phase des DevOps-Lifecycles.

Version Control

Code-Verwaltung

Git ist der De-facto-Standard für Versionskontrolle. Plattformen bieten Collaboration-Features.

  • Git (Versionskontrolle)
  • GitHub, GitLab, Bitbucket
  • Pull Requests & Code Reviews
  • Branching-Strategien (GitFlow, Trunk-Based)

CI/CD

Pipelines & Automation

Tools zur Automatisierung von Build, Test und Deployment-Prozessen.

  • Jenkins (Open Source)
  • GitLab CI/CD, GitHub Actions
  • CircleCI, Travis CI
  • ArgoCD, Flux (GitOps)

Monitoring & Observability

Überwachung & Analyse

Tools zur Überwachung von Systemen, Anwendungen und Infrastruktur.

  • Prometheus (Metrics)
  • Grafana (Visualisierung)
  • ELK Stack (Elasticsearch, Logstash, Kibana)
  • Datadog, New Relic, Splunk

10. Best Practices für DevOps

Die wichtigsten Empfehlungen für eine erfolgreiche DevOps-Transformation in Unternehmen.

Automatisiere alles

  • Builds, Tests, Deployments, Infrastruktur
  • Keine manuellen Schritte in der Pipeline
  • Infrastructure as Code für alle Umgebungen
  • Self-Service für Entwickler

Teste früh und oft

  • Unit-Tests bei jeder Code-Änderung
  • Integrationstests in der Pipeline
  • Performance-Tests vor jedem Release
  • Security-Tests automatisiert (SAST, DAST, SCA)

Monitor everything

  • Application Performance Monitoring (APM)
  • Infrastructure Monitoring
  • Log-Aggregation und -Analyse
  • Alerting und Incident-Response

Security by Design

  • DevSecOps in jeder Pipeline-Phase
  • Least-Privilege-Prinzip
  • Regelmäßige Security-Audits
  • Automatisierte Compliance-Checks

Kultur der Zusammenarbeit

  • Cross-funktionale Teams
  • Blameless Post-Mortems
  • Geteilte Verantwortung (You build it, you run it)
  • Regelmäßige Retrospektiven

Dokumentation als Code

  • README.md in jedem Repository
  • Architecture Decision Records (ADRs)
  • Runbooks für Incident-Response
  • Automatisch generierte API-Docs

Die 3 goldenen Regeln von DevOps

  1. Automatisiere, was möglich ist: Manuelle Schritte sind fehleranfällig und langsam
  2. Messe, was wichtig ist: Datengetriebene Entscheidungen statt Bauchgefühl
  3. Teile Wissen und Verantwortung: Silos aufbrechen, Transparenz schaffen

11. FAQ – Häufige Fragen

Häufige Fragen zu DevOps

Was ist der Unterschied zwischen DevOps und Agile?

Agile ist eine Methodik für die Softwareentwicklung (z.B. Scrum, Kanban) mit Fokus auf iterative Entwicklung, Customer Feedback und flexible Planung.

DevOps erweitert Agile um den Betrieb und die Automatisierung. Während Agile sich auf "Wie entwickeln wir?" konzentriert, beantwortet DevOps "Wie liefern wir schnell und zuverlässig aus?"

Zusammen: Agile + DevOps = vollständiger Software-Lifecycle von der Idee bis zum Betrieb.

Was bedeutet "You build it, you run it"?

Dieses Prinzip (popularisiert von Amazon) bedeutet, dass Entwicklerteams auch für den Betrieb ihrer Software verantwortlich sind – nicht nur für die Entwicklung.

Vorteile:

  • Entwickler schreiben stabileren Code (weil sie selbst die Konsequenzen tragen)
  • Schnellere Fehlerbehebung (Entwickler kennen den Code am besten)
  • Bessere Zusammenarbeit zwischen Dev und Ops
  • Kein "Über-den-Zaun-Werfen" mehr
Was ist GitOps?

GitOps ist eine Erweiterung von DevOps, bei der Git als Single Source of Truth für Infrastruktur und Anwendungen dient.

Prinzip: Der gewünschte Zustand (Desired State) wird in Git-Repositories definiert. Ein Operator (z.B. ArgoCD, Flux) stellt sicher, dass der tatsächliche Zustand immer mit dem Git-Zustand übereinstimmt.

Vorteile: Versionierung, Audit-Trail, einfache Rollbacks, deklarative Konfiguration.

Was ist der Unterschied zwischen Blue-Green und Canary Deployment?

Blue-Green Deployment: Zwei identische Umgebungen (Blue = aktuell, Green = neu). Neue Version wird in Green deployed. Nach Tests wird der Traffic von Blue auf Green umgeleitet. Vorteil: Sofortiger Rollback möglich. Nachteil: Doppelte Infrastruktur-Kosten.

Canary Deployment: Neue Version wird schrittweise an einen kleinen Teil der User ausgerollt (z.B. 5%). Bei Erfolg wird der Anteil erhöht. Vorteil: Geringeres Risiko, keine doppelte Infrastruktur. Nachteil: Komplexeres Routing.

Was ist ein "Blameless Post-Mortem"?

Ein Blameless Post-Mortem ist eine Analyse nach einem Incident, bei der es nicht um Schuldzuweisung geht, sondern um Lernen und Verbesserung.

Prinzip: Menschen machen Fehler – Systeme sollten so gebaut sein, dass Fehler keine Katastrophen auslösen. Statt "Wer hat den Fehler gemacht?" fragt man "Warum hat das System diesen Fehler erlaubt?"

Ergebnis: Dokumentierte Lessons Learned, konkrete Maßnahmen zur Verbesserung, geteiltes Wissen im Team.

Was ist der Unterschied zwischen Container und VM?

Virtuelle Maschinen (VMs): Emulieren komplette Hardware, haben eigenes Betriebssystem. Vorteil: Starke Isolation. Nachteil: Schwerfällig (GB groß, Minuten zum Starten).

Container: Teilen sich den Host-Kernel, enthalten nur Anwendung + Dependencies. Vorteil: Leichtgewichtig (MB groß, Sekunden zum Starten), portabel. Nachteil: Schwächere Isolation als VMs.

Praxis: Container für Microservices und CI/CD, VMs für Legacy-Anwendungen und starke Isolation.

Wie messe ich den Erfolg von DevOps?

Die DORA-Metriken (DevOps Research and Assessment) sind der Industriestandard:

  1. Deployment Frequency: Wie oft wird deployed? (Ziel: On-Demand)
  2. Lead Time for Changes: Zeit von Code-Commit bis Production (Ziel: < 1 Tag)
  3. Mean Time to Recovery (MTTR): Zeit zur Wiederherstellung nach Incident (Ziel: < 1 Stunde)
  4. Change Failure Rate: Prozentsatz fehlgeschlagener Deployments (Ziel: < 15%)

Elite Performer: Alle vier Metriken auf höchstem Niveau (laut DORA Report).

Was ist Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) bedeutet, dass Infrastruktur (Server, Netzwerke, Datenbanken) durch Code-Dateien definiert wird, anstatt manuell konfiguriert zu werden.

Vorteile:

  • Reproduzierbare Umgebungen
  • Versionierung in Git
  • Code-Reviews für Infrastruktur-Änderungen
  • Automatisierte Provisionierung
  • Audit-Trail aller Änderungen

Tools: Terraform, Ansible, CloudFormation, Pulumi, Chef, Puppet

12. Praxisaufgaben

Übungsaufgaben

Aufgabe 1: Erklären Sie das CALMS-Prinzip und nennen Sie für jeden Buchstaben ein konkretes Beispiel aus der Praxis.
Aufgabe 2: Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?
Aufgabe 3: Nennen Sie drei Vorteile von Infrastructure as Code (IaC) gegenüber manueller Infrastruktur-Konfiguration.
Aufgabe 4: Erklären Sie den Unterschied zwischen SLI, SLO und SLA.
Aufgabe 5: Was sind die vier DORA-Metriken und warum sind sie wichtig?
Aufgabe 6: Nennen Sie drei DevSecOps-Praktiken und erklären Sie, warum "Shift Left" wichtig ist.

Zusammenfassung

Die wichtigsten Punkte

  • Definition: DevOps integriert Development und Operations durch Automatisierung und Kultur
  • CALMS-Prinzip: Culture, Automation, Lean, Measurement, Sharing – die fünf Säulen
  • Infinity Loop: Plan → Code → Build → Test → Release → Deploy → Operate → Monitor
  • CI/CD: Continuous Integration + Continuous Delivery/Deployment für schnelle Releases
  • Infrastructure as Code: Terraform, Ansible, CloudFormation – Infrastruktur durch Code
  • Container & Orchestrierung: Docker für Container, Kubernetes für Orchestrierung, Helm für Packaging
  • DevSecOps: Security früh und kontinuierlich (Shift Left) in der Pipeline
  • SRE: Site Reliability Engineering mit SLI, SLO, SLA und Error Budgets
  • DORA-Metriken: Deployment Frequency, Lead Time, MTTR, Change Failure Rate
  • Best Practices: Automatisieren, Testen, Monitoren, Security by Design, Kultur, Dokumentation
  • 3 goldene Regeln: Automatisiere, Messe, Teile

Merke: DevOps ist eine Reise, kein Ziel

DevOps ist keine einmalige Implementierung, sondern ein kontinuierlicher Verbesserungsprozess. Starte klein, automatisiere schrittweise, messe den Fortschritt und lerne aus Fehlern. Die erfolgreichsten DevOps-Teams sind diejenigen, die nie aufhören zu lernen.

Weiterführende Themen

Container-Orchestrierung

Docker, Kubernetes und Helm im Detail – Container-Technologien für die Enterprise IT.

Zu Container-Orchestrierung
Infrastructure as Code

Terraform, Ansible, CloudFormation – Infrastruktur durch Code definieren und automatisieren.

Zu Infrastructure as Code
Monitoring & Logging

Prometheus, Grafana, ELK Stack – Systeme überwachen und analysieren.

Zu Monitoring & Logging
IT-Sicherheit

Sicherheitsgrundlagen, Kryptographie und Netzwerksicherheit für DevSecOps.

Zur IT-Sicherheit
Versionskontrolle (Git)

Git, GitHub, GitLab – Versionskontrolle und Collaboration für DevOps-Teams.

Zu Versionskontrolle
IT-Service-Management (ITIL)

ITIL-Framework für professionellen IT-Betrieb und Service-Management.

Zu ITIL & ITSM