Einstieg in DevOps: Ein praxisorientierter Leitfaden

Das Problem mit „wir machen DevOps"

Jede Engineering-Organisation, zu der wir kommen, sagt dasselbe: „Wir machen DevOps." Dann schauen wir in die Pipeline und finden 14 manuelle Approval-Gates, eine Jenkins-Box, für die niemand zuständig ist, und ein deploy.sh-Skript mit einem TODO von 2022. DevOps ist kein Team, kein Tool, kein Job-Titel. Es ist ein Set von Engineering-Praktiken, die die Feedback-Schleife zwischen Code schreiben und in Produktion betreiben verkürzen – sicher, wiederholbar und ohne Heldentaten.

Dieser Leitfaden richtet sich an Teams, die dem „Script-and-Pray"-Stadium entwachsen sind, aber noch keine Delivery-Pipeline haben, der sie vertrauen. Wir überspringen das Manifest und kommen zu dem, was Sie wirklich bauen müssen, in welcher Reihenfolge und mit welchen Tools. Der referenzierte Stack ist auf dem Stand Anfang 2026.

Warum es 2026 noch zählt

Der DORA-Report 2025 hat erneut dasselbe Muster gezeigt: Elite-Performer deployen mehrfach pro Tag, erholen sich von Incidents in unter einer Stunde und haben Change Failure Rates unter 5 %. Low-Performer deployen monatlich, brauchen Tage zur Erholung und scheitern in einem Drittel der Fälle. Der Abstand hat nichts mit Teamgröße oder Technologiewahl zu tun. Er korreliert fast vollständig mit vier Metriken:

• Deployment Frequency – wie oft Sie Code in Produktion bringen
• Lead Time for Changes – Dauer von Commit bis Produktion
• Change Failure Rate – Prozentsatz der Deployments, die Incidents auslösen
• Mean Time to Recovery (MTTR) – wie lange es dauert, wieder grün zu sein

Wenn Sie nichts sonst messen, messen Sie diese vier. Sie sind der Nordstern. Alles in diesem Beitrag bewegt entweder eine davon oder geht aus dem Weg.

Die vier Capability-Loops

Denken Sie an DevOps als vier verschachtelte Loops, jeder kurz genug, dass das Feedback-Signal zurückkehrt, bevor Sie vergessen haben, warum Sie angefangen haben.

Loop	Dauer	Was Sie lernen
Local Dev	Sekunden	Kompiliert mein Code und bestehen die Unit-Tests?
CI	Minuten	Integriert es mit main? Regressionen?
Pre-Prod	Zehner von Minuten	Bestehen Integrations- und Security-Tests?
Production	Stunden bis Tage	Hält es unter realem Traffic stand?

Eine gesunde Organisation investiert in alle vier. Eine kaputte hat einen zehnminütigen Local-Loop, eine vierzigminütige CI, kein Pre-Prod und ein furchterregendes Produktions-Deploy. Beheben Sie zuerst den schlimmsten.

Capability 1: Source Control und Trunk-Based Development

Beginnen Sie mit dem Langweiligen. Wenn Sie lang lebende Feature-Branches haben, die zwei Wochen vor dem Merge verweilen, wird Sie nichts Downstream retten. Trunk-Based Development mit kurzlebigen Branches (< 24 Stunden) und Feature Flags ist das einzige Muster, das wir Teams über fünf Personen empfehlen.

Branching-Regeln, die wir bei jedem Kunden durchsetzen:

• main ist jederzeit deploybar. Wenn nicht, „stop the line".
• PRs mergen in unter einem Tag. Sitzt ein PR eine Woche, splitten Sie ihn.
• Keine Direct Pushes auf main. Alles durch Review und CI.
• Feature Flags (LaunchDarkly, Unleash oder OpenFeature) entkoppeln Deploy von Release.

Capability 2: Continuous Integration

CI ist der erste Ort, an dem die meisten Teams schieflaufen. Sie bolzen entweder einen einzigen „Run Tests"-Job dran oder bauen einen 2000-zeiligen Workflow, den niemand versteht. Zielen Sie in die Mitte.

Hier ist eine minimale, aber produktionsreife GitHub-Actions-Pipeline für einen Node.js-Service. Sie cached Dependencies, führt Type Checks, Unit Tests, Security Scans aus, baut einen Container und pusht ihn in eine Registry:

name: CI
on:
  push:
    branches: [main]
  pull_request:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "pnpm"
      - run: corepack enable
      - run: pnpm install --frozen-lockfile
      - run: pnpm run lint
      - run: pnpm run typecheck
      - run: pnpm run test --coverage
      - uses: codecov/codecov-action@v4

  security:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: aquasecurity/[email protected]
        with:
          scan-type: fs
          severity: HIGH,CRITICAL
          exit-code: "1"

  build:
    needs: [test, security]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-ci
          aws-region: eu-west-1
      - uses: aws-actions/amazon-ecr-login@v2
        id: ecr
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: |
            ${{ steps.ecr.outputs.registry }}/api:${{ github.sha }}
            ${{ steps.ecr.outputs.registry }}/api:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

Zwei nicht verhandelbare Punkte. Erstens: OIDC-basierte AWS-Auth – keine langlebigen Access Keys in Secrets. Zweitens: concurrency bricht überholte Runs ab, damit ein geschäftiger PR Ihr Runner-Budget nicht auffrisst.

Capability 3: Continuous Delivery und Deployment

CD ist der Punkt, an dem aus „wir haben den Build automatisiert" „wir haben das Business-Risiko automatisiert" wird. Die Unterscheidung zählt. Continuous Delivery heißt: Jeder grüne Commit könnte in Produktion gehen. Continuous Deployment heißt: Jeder grüne Commit geht in Produktion. Beginnen Sie mit Ersterem und steigen Sie zu Letzterem auf, sobald Sie dem Signal vertrauen.

Wählen Sie ein Deployment-Modell

Drei Modelle dominieren 2026:

• GitOps mit ArgoCD oder Flux – deklarativer Zustand in Git, durch einen Controller abgeglichen. Unser Default für Kubernetes.
• Push-basiertes CI/CD – die Pipeline ruft kubectl apply oder Ähnliches auf. Einfacher, aber Auditierbarkeit leidet.
• PaaS-Abstraktionen – Cloud Run, Fly.io, Render. Ideal für kleine Teams, die sich raushalten wollen aus dem YAML-Geschäft.

GitOps gewinnt bei mehreren Clustern, striktem Change Control oder einem Prüfer, der sehen will, wer wann was geändert hat.

Progressive Delivery als Default

Liefern Sie von Tag eins an hinter einer Canary- oder Blue-Green-Strategie aus. Rolling Update ist der Kubernetes-Default, bietet aber kaum Sicherheit. Mit Argo Rollouts bekommen Sie einen deklarativen Canary in wenigen Zeilen:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 6
  strategy:
    canary:
      canaryService: api-canary
      stableService: api-stable
      trafficRouting:
        istio:
          virtualService:
            name: api
            routes: [primary]
      steps:
        - setWeight: 10
        - pause: { duration: 2m }
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause: { duration: 5m }

Der analysis-Schritt fragt Prometheus ab und bricht den Rollout automatisch ab, wenn die Error Rate steigt. Das ist die Änderung mit dem höchsten Hebel, die die meisten Teams machen können: Rollback nicht länger als manuelle Eskalation behandeln, sondern der Pipeline überlassen.

Capability 4: Infrastructure as Code

Wenn Ihre Produktionsumgebung nicht aus einem Git-Repo neu erstellt werden kann, haben Sie keine Infrastruktur – Sie haben ein Artefakt. IaC ist die Grenze zwischen beidem. Wir nutzen Terraform in 90 % der Engagements, OpenTofu für Kunden, denen der Fork wichtig ist, und Pulumi für Shops, die echte Programmiersprachen bevorzugen.

Mindestlebensfähiges IaC-Layout für ein kleines Team:

infra/
├── modules/
│   ├── network/
│   ├── eks/
│   └── rds/
├── envs/
│   ├── dev/
│   ├── staging/
│   └── prod/
└── .github/workflows/terraform.yaml

Und hier ein kleines Modul, das einen S3-Bucket mit vernünftigen Defaults erstellt. Beachten Sie die Validierung, das Versioning, den Public-Access-Block und die Tags – nichts davon ist für einen Produktions-Bucket 2026 optional:

variable "name" {
  type        = string
  description = "Bucket name suffix. Will be prefixed with environment."

  validation {
    condition     = can(regex("^[a-z0-9-]{3,40}$", var.name))
    error_message = "Name must be lowercase alphanumeric with dashes, 3-40 chars."
  }
}

variable "environment" {
  type = string
}

resource "aws_s3_bucket" "this" {
  bucket        = "${var.environment}-${var.name}"
  force_destroy = var.environment != "prod"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
    Module      = "s3-bucket"
  }
}

resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_public_access_block" "this" {
  bucket                  = aws_s3_bucket.this.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Plan im PR, Apply beim Merge

Führen Sie terraform plan bei jedem Pull Request aus und posten Sie die Ausgabe als Kommentar. Führen Sie terraform apply nur beim Merge auf main aus. So bekommen Reviewer dieselbe „Was wird tatsächlich geändert"-Ansicht, die sie aus dem Code-Diff kennen.

Capability 5: Observability

Sie können nicht betreiben, was Sie nicht sehen. Die drei Säulen sind Metriken, Logs und Traces, aber die ehrliche Priorität für ein neues Team lautet:

1. Strukturierte Logs zuerst. Wenn Ihre Logs kein JSON sind, beheben Sie das vor allem anderen.
2. RED-Metriken als Zweites. Rate, Errors, Duration pro Endpoint. Prometheus plus ein Grafana-Dashboard bringt Ihnen an einem Nachmittag 80 % des Werts.
3. Traces, sobald Sie mehr als drei Services haben. OpenTelemetry SDK, OTLP Exporter und ein Backend Ihrer Wahl (Tempo, Honeycomb, Datadog).

Das eine Stück Telemetrie-Code, das jeder Service mitbringen sollte:

import { NodeSDK } from "@opentelemetry/sdk-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node";
import { resourceFromAttributes } from "@opentelemetry/resources";
import { ATTR_SERVICE_NAME, ATTR_SERVICE_VERSION } from "@opentelemetry/semantic-conventions";

const sdk = new NodeSDK({
  resource: resourceFromAttributes({
    [ATTR_SERVICE_NAME]: process.env.OTEL_SERVICE_NAME ?? "api",
    [ATTR_SERVICE_VERSION]: process.env.GIT_SHA ?? "dev",
  }),
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

process.on("SIGTERM", () => {
  sdk.shutdown().finally(() => process.exit(0));
});

Sobald Traces fließen, richten Sie SLOs ein. Ein 99,9-%-Verfügbarkeits-SLO auf einer öffentlichen API mit 30-Tage-Fenster gibt Ihnen ein Error Budget von 43 Minuten. Verbrauchen Sie es, hören Sie auf, Features zu shippen, und arbeiten Sie Reliability-Schulden ab. Das ist der mächtigste Einzel-Hebel, um Produkt- und SRE-Prioritäten auszurichten.

Kultur: Der Teil, den Sie nicht terraform applyen können

Jede Engineering-Führungskraft, mit der wir gearbeitet haben, hat die kulturelle Seite der Transition unterschätzt. Tools sind der einfache Teil. Der harte Teil ist, ein Team darauf einzuschwören, dass:

• Geteilter On-Call keine Bestrafung ist, sondern Feedback.
• Postmortems blameless, geschrieben und von allen gelesen werden.
• „Bei mir läuft's" ein Bug-Report ist, keine Ausrede.
• Dev das Produktionsverhalten seines eigenen Codes besitzt.

Das können Sie nicht kaufen. Sie können es nur vorleben. Der schnellste Weg, den wir Organisationen gehen sehen, ist, wenn die Engineering-Führung die erste On-Call-Schicht mit dem Team übernimmt, das erste Postmortem verantwortet und öffentlich der Person dankt, die ihren eigenen Bug gefunden hat.

Ein Zwölf-Wochen-Starterplan

Für ein Team, das nahe bei null beginnt, würden wir Folgendes sequenzieren.

Woche 1–2: Baseline. Messen Sie die vier DORA-Metriken. Sie können nicht fixen, was Sie nicht messen. Auditieren Sie außerdem jeden manuellen Schritt von Commit zu Prod – schreiben Sie ihn an ein Whiteboard.

Woche 3–4: CI. Wählen Sie einen Service. Bauen Sie eine grüne CI mit Tests, Lint, Typecheck, Security Scan, Container-Build. Noch nichts weiter.

Woche 5–6: CD nach Staging. Automatisieren Sie das Deploy in ein Staging. Falls Sie keins haben, erstellen Sie es mit IaC.

Woche 7–8: IaC für eine Umgebung. Bauen Sie Staging aus Terraform neu. Das wird viel Configuration Drift aufdecken. Beheben Sie ihn.

Woche 9–10: Observability. Strukturierte Logs, RED-Metriken, ein SLO, eine Alert-Page. Leiten Sie Alerts an PagerDuty oder Opsgenie des Teams.

Woche 11–12: Prod. Befördern Sie die Pipeline nach Produktion. Gaten Sie mit Canary. Fahren Sie einen Game Day. Feiern Sie das erste automatisierte Rollback.

Nächste Schritte

DevOps ist in zwölf Wochen nicht fertig – es ist nie fertig. Aber in zwölf Wochen kann ein Team von „wir deployen Freitag und beten" zu „wir deployen stündlich, und die Pipeline fängt ihre eigenen Fehler" kommen. Die nächste Grenze von dort ist meist Platform Engineering: Diese Pipeline in einen Golden Path zu verwandeln, den andere Teams konsumieren können.

Wenn Sie Unterstützung dabei wünschen, von null zu Trunk-Based, produktionsreifer CD auf einem echten Stack zu kommen, nehmen Sie Kontakt auf. Wir machen diese Arbeit gemeinsam mit Ihrem Team und übergeben sie, sobald Sie sie beherrschen.