SLOs pro Dependency: DNS, LB, Datenbank, externe API

SLOs pro Dependency sind eine der wirkungsvollsten SRE-Praktiken, um Verfügbarkeit und Performance nicht nur „für den eigenen Service“, sondern entlang der gesamten Wertschöpfungskette zu steuern. In modernen Architekturen hängt die Nutzererfahrung selten von einer einzigen Komponente ab: DNS entscheidet, ob ein Hostname überhaupt aufgelöst wird, der Load Balancer (LB) bestimmt Routing und Health, die Datenbank prägt Latenz und Fehlerverhalten, und externe APIs bringen zusätzliche Unsicherheit durch Provider, Netzpfade und Rate Limits. Wenn Sie nur ein globales SLO für den End-to-End-Service messen, sehen Sie zwar den Impact – aber nicht, welche Abhängigkeit das Error Budget verbrennt. Umgekehrt führt reines Component-Monitoring ohne SLO-Struktur oft zu Alarmflut ohne Priorität. SLOs pro Dependency schließen diese Lücke: Sie schaffen klare, messbare Ziele je Abhängigkeit, erlauben Budgetierung, priorisieren Verbesserungsarbeit und ermöglichen objektive Gespräche mit internen und externen Teams. Dieser Artikel zeigt, wie Sie SLOs pro Dependency für DNS, Load Balancer, Datenbank und externe API definieren, messen, interpretieren und in den Betrieb integrieren.

Warum SLOs auf Abhängigkeiten überhaupt sinnvoll sind

Ein Dependency-SLO ist kein Ersatz für ein Nutzer-SLO, sondern ein Ergänzungsinstrument. Das Nutzer-SLO beschreibt, was Kunden tatsächlich erleben (z. B. „99,9% aller Requests sind erfolgreich und schnell“). Dependency-SLOs beschreiben, wie zuverlässig einzelne Bausteine sein müssen, damit das Nutzer-SLO erreichbar bleibt. Dieser Gedanke passt zu etablierten SRE-Konzepten wie Service Level Objectives, Error Budgets und dem Fokus auf nutzerorientierte Messung. Eine gut zugängliche Grundlage bietet Googles SRE-Ansatz zu SLOs und Error Budgets, etwa über Service Level Objectives (Google SRE).

• Fehlerbudget-Aufschlüsselung: Sie sehen, welche Dependency das Budget verbrennt.
• Priorisierung: Verbesserungen werden datenbasiert priorisiert (z. B. „DB-Latenz dominiert“).
• Verantwortlichkeiten: Klare Schnittstellen zwischen Teams (Platform, Network, DB, Vendor).
• Verhandlungsbasis: Externe Provider können anhand messbarer Ziele bewertet werden.

Grundprinzip: Nutzer-SLO zuerst, dann Dependency-SLOs ableiten

Ein häufiger Fehler ist, Dependency-SLOs „aus dem Bauch“ zu definieren. Besser ist ein Top-down-Vorgehen: Sie starten mit einem End-to-End-SLO und leiten daraus ab, welche Zuverlässigkeit jede Abhängigkeit liefern muss. Dabei ist wichtig: Dependencies wirken nicht einfach additiv, sondern häufig verschachtelt, parallel und mit Fallbacks (Cache, Retries, Circuit Breaker). Deshalb brauchen Sie eine Methode, um Budgets aufzuteilen, ohne eine Scheingenauigkeit vorzutäuschen.

Error Budget als gemeinsame Währung

Das Error Budget ist der „Spielraum“, den ein Service innerhalb eines Zeitfensters verbrauchen darf. Für ein Availability-SLO von 99,9% pro 30 Tage liegt das Budget bei 0,1% Ausfallzeit bzw. Fehlschlägen in der Messdefinition. Das lässt sich formal ausdrücken:

$\mathrm{ErrorBudget}=1-\mathrm{SLO}$

Wenn Ihr End-to-End-SLO also 0,999 ist, beträgt das Budget 0,001. Dieses Budget können Sie dann nach Abhängigkeiten „budgetieren“ – nicht als exakte Mathematik, sondern als steuerbares Modell.

Messmodell: Was ist ein „guter“ Dependency-Request?

Für jedes Dependency-SLO benötigen Sie eine klare Service Level Indicator (SLI)-Definition. Typischerweise kombinieren Sie Erfolg (Success/Failure) und Latenz (Time) – und definieren, was als „gut“ zählt. Wichtig: Retries und Fallbacks müssen explizit behandelt werden, sonst misst Ihr SLI nicht das, was Sie steuern wollen.

• Success-SLI: Anteil erfolgreicher Operationen (z. B. DNS-Resolution OK, DB-Query OK).
• Latency-SLI: Anteil der Operationen unter einem Schwellenwert oder Perzentile (P95/P99).
• Composite-SLI: „Gut“ ist nur, was erfolgreich und schnell ist.

Composite-SLI (MathML)

$\mathrm{GoodEvents}=\mathrm{SuccessEvents}\cap \mathrm{LatencyUnderThreshold}$

In der Praxis zählen Sie „GoodEvents“ als jene Operationen, die (a) ohne Fehler abgeschlossen und (b) innerhalb des definierten Latenzbudgets beantwortet wurden.

SLOs pro Dependency: DNS

DNS ist eine fundamentale Abhängigkeit, die oft unterschätzt wird, weil Caching Probleme verdecken kann. Ein DNS-SLO sollte daher zwei Perspektiven kombinieren: Resolver-Sicht (wie schnell und zuverlässig ist die Namensauflösung) und Client-Sicht (wie wirkt DNS auf die Gesamterfahrung). Sinnvoll sind synthetische Probes aus mehreren Regionen sowie Metriken aus internen Resolvern.

Geeignete DNS-SLIs

• DNS Success Rate: Anteil erfolgreicher Antworten (NOERROR) plus kontrolliert behandelte NXDOMAIN-Fälle.
• DNS Timeout Rate: Timeouts pro Zeitfenster (oft der härteste Indikator).
• DNS Latency: Resolution Time (P50/P90/P99), getrennt nach A/AAAA und ggf. nach Resolver.
• DNS Integrity: Antwortvalidität (richtige Records, erwartete TTLs, keine SERVFAIL-Spikes).

Für DNS ist es hilfreich, Error-Codes differenziert zu behandeln (SERVFAIL vs. NXDOMAIN vs. Timeout). Eine technische Referenz zur Bedeutung erweiterter Fehlerhinweise bietet RFC 8914 (Extended DNS Errors). Für Monitoring-Setups sind Blackbox-Probes verbreitet, etwa über Prometheus Blackbox Exporter.

SLOs pro Dependency: Load Balancer (LB)

Der Load Balancer ist oft sowohl Netzwerk- als auch Plattformkomponente: Er terminiert TLS, verteilt Traffic, setzt Timeouts und entscheidet anhand von Health Checks, welche Backends bedient werden. LB-Probleme äußern sich häufig als 502/503/504, erhöhte Connect-Latenz, TLS-Handshake-Probleme oder ungleichmäßige Lastverteilung. Ein LB-SLO sollte deshalb nicht nur „Up/Down“ messen, sondern das Routing und die Connection-Etablierung abbilden.

Geeignete LB-SLIs

• Handshake/Connect Success: Anteil erfolgreicher TCP/TLS-Verbindungsaufbauten.
• LB-to-Backend Success: Anteil erfolgreicher Upstream-Connections/Requests.
• LB Latency Contribution: Zeitanteil für Connect/TLS/Upstream-First-Byte.
• Health Check Quality: Anteil gesunder Backends, Flapping-Rate, Fehlklassifikationen.

Wenn Sie Envoy/NGINX/HAProxy einsetzen, sind deren Metrikmodelle nützlich, um „LB-Latenz“ zu trennen. Einstiegspunkte sind beispielsweise Envoy Dokumentation oder die NGINX Dokumentation für Monitoring- und Timing-Parameter.

SLOs pro Dependency: Datenbank

Datenbanken dominieren in vielen Systemen Latenz und Fehlerverhalten, weil sie sowohl CPU/I/O-bound sind als auch unter Locking, Connection Pool Saturation oder Query-Plan-Änderungen leiden. Ein Datenbank-SLO sollte daher nicht nur „Query erfolgreich“ messen, sondern die kritischen Engpasspfade abbilden: Connection Acquisition, Query Execution, Commit/Replication und ggf. Storage-Latenzen.

Geeignete DB-SLIs

• Query Success Rate: Anteil erfolgreicher Queries/Transaktionen (ohne Deadlocks/Timeouts).
• Query Latency P95/P99: getrennt nach Query-Klassen oder Endpoints.
• Connection Pool Health: Acquisition-Latenz, Pool Exhaustion, Warteschlangenlänge.
• Replication/Failover Signals: Lag, Failover-Events, Read Replica Staleness (falls relevant).

Für eine SRE-nahe Datenbankbeobachtung ist es wichtig, Latenz nicht nur „im DB-Server“ zu messen, sondern auch aus Applikationssicht (Connection warten, Retries, Circuit Breaker). So verhindern Sie, dass „DB ist okay“ behauptet wird, während der Pool in der Anwendung erschöpft ist.

SLOs pro Dependency: Externe API

Externe APIs sind eine besondere Kategorie, weil Sie deren Betriebsführung nicht kontrollieren. Dazu kommen Internetpfade, DNS, TLS, Rate Limits und Vendor-Änderungen. Ein externes API-SLO sollte daher sowohl technische Erreichbarkeit als auch funktionale Korrektheit berücksichtigen – und klare Regeln haben, wie Sie Vendor-Ausfälle von eigenen Fehlern trennen.

Geeignete External-API-SLIs

• Availability aus Sicht Ihres Systems: Anteil erfolgreicher Calls (2xx/erwartete Codes) innerhalb eines Timeouts.
• Latency Budget: P95/P99 der Round-Trip-Zeit, ggf. getrennt nach Region.
• Rate Limit Events: 429/Quota-Fehler als eigenes SLI, weil sie oft governance-bedingt sind.
• Timeouts vs. Server Errors: Timeouts sind häufig pfad-/kapazitätsbedingt und operativ anders zu behandeln als 5xx.
• Fallback-Rate: wie oft musste degradiert werden (Cache, Default-Antwort, Warteschlange).

Für Incident-Management und Kommunikation bei externen Abhängigkeiten sind klare Prozesse entscheidend; ein praxisnaher Incident-Framework-Ansatz findet sich z. B. bei PagerDuty Incident Response Documentation.

Budgetierung: Wie Sie Dependency-SLOs aus einem End-to-End-SLO ableiten

Es gibt mehrere Wege, Budgets aufzuteilen. Eine pragmatische Methode ist, Dependencies nach ihrem erwarteten Beitrag zum End-to-End-Risiko zu gewichten. Wichtig ist: Sie brauchen keine perfekte Mathematik, sondern ein Modell, das Entscheidungen unterstützt.

Gewichtete Budgetaufteilung (MathML)

$\mathrm{Budget}\left(d\right)=W\left(d\right)\times \mathrm{ErrorBudget}\left(\mathrm{service}\right)$

Hier ist W(d) ein Gewicht zwischen 0 und 1, und die Summe aller Gewichte ergibt 1. Wenn die Datenbank der häufigste Engpass ist, bekommt sie ein größeres Gewicht. Wenn DNS stark gecacht ist, kann das Gewicht geringer ausfallen – solange Sie die Risiken (z. B. Resolver-Ausfall) dennoch abdecken.

Messung in der Praxis: Synthetisch, passiv, und aus Nutzersicht kombinieren

Dependency-SLOs profitieren von mehreren Messperspektiven:

• Synthetisch: Blackbox-Probes für DNS, LB, externe API – gut für „von außen“.
• Passiv: Metriken aus Resolvern, LBs, DBs – gut für „von innen“.
• Nutzer-/App-Sicht: RUM/Tracing/Client-Metriken – zeigt tatsächliche Experience.

Diese Triangulation ist entscheidend, weil jede Methode blinde Flecken hat. DNS kann intern gut aussehen, aber in bestimmten Regionen schlecht. Eine DB kann gesund sein, aber der Connection Pool im App-Layer ist erschöpft. Ein externes API kann „up“ sein, aber in Ihrer Region Routenprobleme haben.

Fehlerklassifizierung: Damit „Failure“ nicht alles bedeutet

Ein häufiges Problem in Dependency-SLOs ist das Zusammenwerfen unterschiedlicher Fehlerarten. Für Steuerung und Kommunikation ist es besser, Fehler nach Klassen zu trennen:

• Timeout: häufig Kapazität/Netzpfad/Queueing; operativ dringlich.
• 5xx: serverseitiger Fehler (intern oder extern), oft incident-relevant.
• 4xx/Policy: Auth, Rate Limits, Quota; oft Governance- oder Integrationsproblem.
• DNS SERVFAIL vs. NXDOMAIN: technische Störung vs. „negatives Ergebnis“.

Durch diese Trennung vermeiden Sie, dass ein SLO „schlecht“ wirkt, obwohl eigentlich nur Quota-Limits erreicht wurden, die anders behandelt werden sollten.

Operationalisierung: Dashboards, Alerts und Runbooks pro Dependency

Dependency-SLOs sind erst dann nützlich, wenn sie operationalisiert sind: Dashboards zeigen den Budgetverbrauch, Alerts schlagen bei Burn-Rates an, und Runbooks leiten zu sinnvollen Aktionen.

• SLO Dashboard pro Dependency: SLI, SLO, Error Budget Remaining, Burn Rate, Top Fehlerklassen.
• Burn Rate Alerting: schnell (z. B. 5–15 Minuten) und langsam (mehrere Stunden) kombinieren.
• Runbooks: konkrete Schritte je Dependency (DNS: Resolver/Authoritative prüfen; LB: Health/Upstream; DB: Pool/Locks; External API: Rate Limits/Fallback).

Für SRE-typische Monitoring- und Alerting-Konzepte ist Googles SRE-Kapitel zu Monitoring ein solider Anker, siehe Monitoring Distributed Systems.

Governance: Ownership, SLAs und Verträge mit externen Parteien

Bei Dependencies ist Ownership zentral. Intern klären Sie: Wer besitzt DNS/Resolver, wer besitzt den LB, wer ist DB-Owner? Extern klären Sie: Welche SLAs existieren, welche Metriken gelten, und welche Eskalationswege gibt es? Ein Dependency-SLO ist dabei oft „strenger“ als ein externer SLA, weil Ihr Service sonst sein eigenes Nutzer-SLO nicht einhalten kann.

• Owner je Dependency: technische Verantwortung und On-Call-Kontakt.
• Definitionen schriftlich: Was zählt als Fehler? Welche Zeitfenster gelten?
• Eskalationspfade: interne und externe Kontakte, Statuspages, Support-Tiers.
• Review-Zyklus: SLOs pro Dependency regelmäßig an Architekturänderungen anpassen.

Praktische Vorlage: Beispielhafte SLO-Ideen je Dependency

• DNS: 99,95% erfolgreiche Resolutionen, P95 < 50 ms aus Kernregionen, Timeouts < 0,01%.
• Load Balancer: 99,99% erfolgreiche TLS-Handshakes, Upstream-Connect-Fehler < 0,01%, P99 Connect < 100 ms.
• Datenbank: 99,9% erfolgreiche Queries, P95 < X ms für kritische Query-Klassen, Pool-Exhaustion ~ 0.
• Externe API: 99,5% erfolgreiche Calls innerhalb Timeout, 429-Rate separat (z. B. < 0,1%), Fallback-Rate beobachtet.

Diese Werte sind bewusst als Denkrahmen formuliert. Die konkreten Schwellen sollten aus Baselines, Nutzeranforderungen und Architektur (Caching, Retries, Fallbacks) abgeleitet werden.

Weiterführende Ressourcen

• Google SRE: Service Level Objectives
• Google SRE: Monitoring Distributed Systems (Golden Signals)
• Prometheus Blackbox Exporter (synthetische Probes)
• RFC 8914: Extended DNS Errors
• Prometheus Dokumentation: Overview
• PagerDuty Incident Response Documentation

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.