WAF++ WAF++
Back to WAF++ Homepage

Design-Prinzipien: Operational Excellence

Die Design-Prinzipien sind technische Anforderungen an die Architektur von Systemen, die exzellent betrieben werden sollen. Sie ergänzen die Prinzipien (OP1–OP7) um konkrete Designentscheidungen.

OD1 – Structured Logging mit konsistentem Schema

Alle Services MÜSSEN strukturierte Logs in JSON ausgeben. Das Log-Schema MUSS mindestens folgende Felder enthalten:

Feld Typ Beschreibung

timestamp

ISO 8601

Zeitstempel der Log-Zeile in UTC

level

String

DEBUG, INFO, WARN, ERROR, FATAL

service

String

Servicename (aus Umgebungsvariable oder Deployment-Konfiguration)

trace_id

String

OpenTelemetry Trace-ID oder AWS X-Ray Trace-ID

span_id

String

OpenTelemetry Span-ID

request_id

String

Anfrage-spezifische ID für Log-Korrelation

message

String

Lesbare Beschreibung des Events

error

Object (optional)

Fehler-Details mit type, message, stack

Implikation

  • Logging-Framework-Konfiguration ist Teil der Service-Vorlage

  • Log-Level ist via Umgebungsvariable konfigurierbar (kein Rebuild für Level-Änderung)

  • Sensitive Daten (Passwörter, PII) dürfen NIE in Logs erscheinen – Scrubbing im Logger

OD2 – Trace-ID-Propagation über Servicegrenzen

Alle Services MÜSSEN Trace-IDs und Span-IDs aus eingehenden Requests extrahieren und in ausgehenden Requests propagieren.

  • W3C TraceContext Header (traceparent, tracestate) sind der Standard

  • Bei Fehlen eines Trace-Contexts MUSS ein neuer Trace erzeugt werden

  • Async-Kommunikation (SQS, Kafka) MUSS Trace-Kontext in Message-Headern transportieren

Implikation

  • OpenTelemetry SDK ist in der Service-Vorlage konfiguriert

  • HTTP-Client und Server sind automatisch instrumentiert (Auto-Instrumentation)

  • Async-Messaging-Integration ist explizit instrumentiert

OD3 – Health Endpoints als Betriebsschnittstelle

Jeder Service MUSS folgende Health Endpoints bereitstellen:

Endpoint HTTP-Methode Beschreibung

/health/live

GET

Liveness-Probe: Service läuft (Antwort 200 = alive, 503 = restart erforderlich)

/health/ready

GET

Readiness-Probe: Service bereit für Traffic (prüft DB-Verbindung, Abhängigkeiten)

/health/startup

GET

Startup-Probe: Service-Initialisierung abgeschlossen

/metrics

GET

Prometheus-Metriken (Prometheus-Format oder OpenMetrics)

Implikation

  • Kubernetes/ECS liveness und readiness probes referenzieren diese Endpoints

  • /health/ready darf erst 200 zurückgeben wenn alle Abhängigkeiten erreichbar sind

  • /metrics ist nicht öffentlich erreichbar (internal service mesh oder VPC-only)

OD4 – Immutable Artifacts & Versionierte Deployments

Jedes Deployment-Artefakt (Container Image, Lambda ZIP, AMI) MUSS:

  • Unveränderlich sein – kein In-Place-Patching von deployter Artefakten

  • Versioniert sein – Git-SHA oder semantische Version als Tag

  • Signiert sein (Stufe 4+ Reife) – Container Image Signing via Cosign oder Notation

Implikation

  • latest-Tags in Produktions-Deployments sind verboten

  • Container-Images werden nach Deployment nicht verändert

  • Rollback = Deployment der vorherigen Version (nicht Patch der laufenden)

OD5 – Blue/Green oder Canary als Standard-Deployment-Muster

Produktions-Deployments MÜSSEN einen Mechanismus zur schrittweisen Traffic-Verschiebung haben.

Muster Beschreibung Empfohlener Einsatz

Blue/Green

Zwei vollständige Umgebungen; Traffic-Switch via Load Balancer

Stateful Services, Datenbank-Migrations-Deployments

Canary

Schrittweise Traffic-Erhöhung von 5% → 25% → 100%

Stateless Services, häufige Deployments

Feature Flags

Code deployed dunkel; Feature per Flag aktiviert

Neue Features, A/B-Tests, risikoarme Rollouts

Implikation

  • Deployment-Konfiguration definiert Traffic-Split-Mechanismus

  • Health Checks bestimmen automatisch ob Promotion oder Rollback

  • Alle Deployments sind innerhalb von 5 Minuten rollback-bar

OD6 – Idempotente Operationen & Retry-Sicherheit

Alle operativen Operationen (Deployments, Remediation-Scripts, Runbook-Automatisierungen) MÜSSEN idempotent sein: Mehrfaches Ausführen darf zu keinem anderen Ergebnis führen als einmaliges Ausführen.

Implikation

  • Terraform ist per Definition idempotent (deklarativ)

  • Runbook-Automatisierungen prüfen Vorzustand vor Aktion

  • API-Calls in Automatisierungen verwenden upsert-Semantik, nicht create

  • Retry-Logik in Deployments und Automatisierungen ist konfiguriert

OD7 – Konfiguration extern und überprüfbar

Alle Konfiguration MUSS von Code getrennt sein (12-Factor App, Faktor III).

  • Umgebungsspezifische Konfiguration in Umgebungsvariablen oder Secrets-Manager

  • Konfiguration in IaC definiert (Terraform-Variable, Parameter Store, App Config)

  • Konfiguration ist versioniert – Änderungen sind nachvollziehbar

  • Sensitive Konfiguration (Credentials, Tokens) NIEMALS in Code oder IaC-Variablen

Implikation

  • AWS Parameter Store, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager integriert

  • Configuration-as-Code Ansatz: Änderungen an Konfiguration gehen durch Pull Request

  • Konfigurationsänderungen sind im Audit-Trail sichtbar

OD8 – Operational Readiness als Deployment-Gate

Bevor ein Service in Produktion geht, MUSS er "Operational Readiness" nachweisen:

Kriterium Nachweis

Observability

Structured Logs, Metriken, Tracing konfiguriert und verifiziert

Health Endpoints

/health/live und /health/ready vorhanden und getestet

Alerting

Mindestens ein symptombasierter Alert konfiguriert und verlinkt mit Runbook

Runbook

Runbook für Deployment und bekannte Fehlerfälle vorhanden

Rollback

Rollback-Prozedur dokumentiert und getestet

Dependency Inventory

Alle Abhängigkeiten (DBs, externe Services, Queues) dokumentiert

Implikation

  • Operational Readiness Checklist ist Teil des Deployment-Pull-Requests

  • Peer Review beinhaltet Prüfung der Readiness-Kriterien

  • Services ohne Operational Readiness Nachweis dürfen nicht in Produktion