Enterprise-Kunden verhandeln Uptime nicht als angestrebtes Ziel. Sie verhandeln sie als vertragliche Verpflichtung. Wenn Deka Technology 99,7 % Uptime für eine Microservices-Plattform zusichert, entspricht diese Verpflichtung weniger als 22 Stunden Ausfallzeit pro Jahr — über alle Services, Deployments, Infrastrukturereignisse und Abhängigkeitsfehler hinweg. Diese Verpflichtung konsequent zu erfüllen, über Kunden in regulierten und nicht regulierten Branchen hinweg, erfordert systematisches Reliability Engineering statt heroischer Intervention nach Incidents.
Die richtigen SLIs und SLOs definieren
Vor dem Design für Zuverlässigkeit müssen Sie definieren, was Zuverlässigkeit für das spezifische System bedeutet. Wir beginnen jedes Engagement mit SLI (Service Level Indicator) Definitions-Workshops mit den technischen und Business-Stakeholdern des Kunden. Falsche SLIs produzieren die richtigen Zahlen gegen die falschen Outcomes. Für die meisten B2B-Plattformen sind die relevanten SLIs: Request-Erfolgsrate (4xx- und 5xx-Antworten als Anteil der Gesamtzahl), Latenz bei P95 und P99 (nicht Durchschnitt — Durchschnitt verbirgt den Tail) und Datenaktualität für Systeme mit Eventual-Consistency-Anforderungen.
Eine Erfolgsrate von 99,9 % klingt beeindruckend, bis man erkennt, dass 0,1 % der Requests auf einer Plattform, die täglich 10 Millionen Transaktionen verarbeitet, 10.000 fehlgeschlagene Transaktionen täglich bedeutet. SLO-Definition ist ein Geschäftsgespräch, kein technisches.
Circuit-Breaker-Muster in der Praxis
Microservices scheitern häufiger auf Abhängigkeitsebene als auf Service-Ebene. Ein Zahlungs-Microservice, der einen Betrugserkennungs-Service aufruft, ist nur so zuverlässig wie der Betrugserkennungs-Service — sofern er nicht anders konzipiert ist. Wir implementieren das Circuit-Breaker-Muster mit Resilience4j (JVM-Services) oder Polly (.NET-Services) mit drei Zuständen: geschlossen (Normalbetrieb), offen (Abhängigkeit schlägt fehl, Fast-Fail aller Requests statt Queuing bis Timeout) und halb-offen (Sondierung auf Erholung). Circuit-Breaker-Schwellenwerte — Fehlerratenprozentsatz und Langsamkeitsratenprozentsatz — werden pro Abhängigkeit basierend auf beobachtetem Baseline-Verhalten kalibriert, nicht auf generischen Standardwerten.
Health Checks und Readiness Probes
Kubernetes-Liveness- und Readiness-Probes sind die erste Verteidigungslinie gegen degradierte Services, die Traffic empfangen. Wir definieren drei Probe-Typen für jeden Service: Liveness (ist der Prozess am Leben? — neustart wenn nicht), Readiness (ist der Service bereit, Traffic zu verarbeiten? — aus dem Load Balancer entfernen, wenn nicht) und Startup (initialisiert sich der Service noch? — Startup nicht als Liveness-Fehler zählen). Readiness Probes testen tatsächliche Abhängigkeitskonnektivität — Datenbankverbindungspool-Zustand, Erreichbarkeit nachgelagerter Services — nicht nur Prozessstatus. Ein Service, der am Leben ist, aber seine Datenbank nicht erreichen kann, muss sofort aus der Rotation entfernt werden.
Blue-Green-Deployments für Zero-Downtime-Releases
Unsere Standard-Deployment-Strategie für Enterprise-Plattformen ist Blue-Green mit automatisiertem Smoke-Testing. Die neue Version (Green) wird neben der bestehenden Version (Blue) deployed, Smoke-Tests laufen gegen die Green-Umgebung mit Produktions-Traffic-Shadows, und Traffic wird in gewichteten Schritten verlagert (10 % → 50 % → 100 %) mit automatischem Rollback, wenn die Fehlerrate den SLO-Schwellenwert bei einem Schritt überschreitet. Die gesamte Traffic-Shift-Sequenz abschließt in unter 15 Minuten. Wenn das Green-Deployment bei einem Schritt fehlschlägt, ist der Rollback auf 100 % Blue automatisch und schließt in unter 60 Sekunden ab.
Incident-Response-Runbooks
Reliability Engineering ist zu 80 % Vorbereitung und zu 20 % Reaktion. Jeder Service, den wir betreiben, hat ein strukturiertes Runbook, das abdeckt: Alert-Definition und Schweregrad-Klassifizierung, initiale Triage-Schritte (was zuerst prüfen, in welcher Reihenfolge), Eskalationskontakte pro Schweregrad, häufige Fehlermodi und deren Behebungsverfahren sowie Rollback-Anweisungen. Runbooks werden versionskontrolliert neben dem Service-Code gepflegt und direkt aus Alert-Benachrichtigungen referenziert. Ein On-Call-Ingenieur, der einen PagerDuty-Alert erhält, sieht den Runbook-Link im Alert-Body — er sucht nicht danach unter Incident-Bedingungen.
Häufige Incident-Muster in Enterprise-Plattformen
Die Incidents, die in Enterprise-Microservices-Plattformen typischerweise am meisten zur Ausfallzeit beitragen, umfassen: Drittanbieter-Service-Ausfälle (gemildert durch Circuit Breaker, die den Impact auf den betroffenen Flow isolieren), Kubernetes-Node-Ausfälle während Cluster-Upgrades (gemildert durch Pod-Anti-Affinity-Regeln, die den Blast-Radius begrenzen) und Datenbankverbindungspool-Erschöpfung (oft verursacht durch falsch konfigurierte Verbindungslimits in neuen Service-Versionen). Systematische Post-Incident-Reviews, die die Runbook-Bibliothek verbessern, sind essenziell für kontinuierliche Zuverlässigkeitsverbesserung.
Mehr zu diesem Thema erfahren?
Erstberatung ist kostenlos — unverbindlich.