Operationen und Verwaltung → Dienstabhängigkeiten

Dienstabhängigkeiten

1) Warum es notwendig ist

Jede Produktionsplattform ist ein Graph: Benutzer von → Edge/API → Domain-Dienste → Warteschlangen/Streams → DB/Caches → externe Anbieter (Zahlungen, KYC, Spieleanbieter). Ein Fehler an einer Kante des Graphen „läuft“ oft im gesamten Netzwerk: Verzögerungen nehmen zu, Retrays werden ausgelöst, Warteschlangen verstopfen, kaskadierende Ausfälle treten auf. Das Abhängigkeitsmanagement reduziert den „Explosionsradius“ und macht Freigaben vorhersehbar.

• Sehen Sie den vollständigen Aufrufgraphen und verstehen Sie, wer von wem abhängt.
• Verhindern Sie kaskadierende Ausfälle und einen „Sturm von Retrays“.
• Planung von Releases unter Berücksichtigung von Kompatibilität und SLO-Propagierung.
• Erhöhen Sie die MTTR: Finden Sie schneller den wahren Grundknoten (root cause).

2) Arten von Abhängigkeiten

Synchron (RPC: REST/gRPC/GraphQL): starre Konnektivität in Latenz/Verfügbarkeit. Wir brauchen Timeouts, Breaker, ein Retrail-Budget.
Asynchron (Event/Stream: Kafka/Rabbit/Pulsar): stabilere Konnektivität, aber es gibt Lag/Backlog und Liefersemantik (at-least-once, idempotency).
Speicher (DB/Cache/Object Store): geteilte Ressourcen → Inhalt, Konnektivitätslimits/IOPS, Eviction, Replikation.
Externe Anbieter (PSP/KYC/Spieleanbieter): Quoten, kostenpflichtige Anrufe, Servicefenster, rechtliche SLAs.
Operativ (Releases, Ficheflags, Configs): indirekte Abhängigkeiten durch Einstellungen, Geheimnisse, Schema-Registry.

3) Dienstverzeichnis und Abhängigkeitsgraph

• Besitzer (Squad/Chat/On-Call Rota), Repos, Umgebung, Artefakte.
• API-Verträge (OpenAPI/AsyncAPI), Versionen, Kompatibilität (back/forward).
• Eingehende/ausgehende Abhängigkeiten (Upstream/Downstream) mit Typ (Sync/Async), Kritikalität, SLO-Erwartungen.
• Budget von Timeouts/Retrays, Breakern, Bulkhead-Pools.
• Daten über Quoten und Grenzen externer Integrationen.

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO: p99 ≤ 300 ms, 99. 9% uptime.
• Timeouts: 200 ms zu „PSP-X“, 150 ms zu „user-profile“.
• Retrays: 2 mit exponentieller Verzögerung, jitter.
• Breaker: offen für 30 s bei 5% Fehler/10 s.

4) SLO-Propagierung und „Latenzbudget“

In einer Kette von synchronen Anrufen wird der resultierende SLO aus der Summe der Verzögerungen und Ausfallwahrscheinlichkeiten gebildet.

• Das Anforderungsbudget ist von oben nach unten aufgeteilt: Front-End-SLO von 500 ms → Edge von 50 ms → API von 150 ms → Domänendienste von 200 ms → Anbieter von 100 ms.
• Timeouts „nach außen sind kürzer als nach innen“: Der Anrufer des Timeouts hat weniger interne Summe, so dass Ressourcen aktualisiert werden, anstatt Zombie-Aufrufe zu sammeln.
• Retrays nur für sichere Codes/Ausnahmen und mit Jitter; ohne Rückzüge für Zeiträume von Engpässen (sonst „Sturm“).

5) Verträge und Interoperabilität

API-Versionierung: SemVer für Verträge; backward-kompatible Änderungen über Felder „optional“, Schema-Erweiterungen; Entfernung - nur durch die „Deprecate-Periode“.
Consumer-driven contracts (CDC): Verbrauchertests (Pact-like) laufen gegen den Anbieter in der CI; Die Freigabe wird bei Inkompatibilität gesperrt.
Schema-Register (Async): Version der Topics/Ereignisse, Evolution der Schemas (Avro/JSON-Schema), Politik „can-read-old/can-write-new“.

6) Technische Muster der Nachhaltigkeit

Timeouts: Trennen Sie die SLA des Geschäfts von den technischen Erwartungen; jede ausgehende Verbindung ist ein expliziter Timeout.
Retries + Backoff + Jitter: nicht mehr als 2-3 Versuche, angesichts der Idempotenz.
Circuit Breaker: „schneller Fall“ während des Downstream-Abbaus; halb-offene Proben.
Bulkhead (Isolierung von Pools): für verschiedene Downstreams - separate Pools von Threads/Pods/Verbindungen.
Rate-Limit/Leaky-Bucket: um Downstreams bei Peaks nicht zu töten.
Idempotency & Deduplizierung: Idempotency-Schlüssel auf Anforderungs-/Nachrichtenebene; Großvater-Leiter und Retray-Warteschlangen.
Caching und Vollbacks: lokale/verteilte Caches, Stale-while-revalidate-Status, Content-Degradation.

outbound:
psp-x:
timeout_ms: 200 retries: 2 retry_on: [5xx, connect_error]
backoff: exponential jitter: true circuit_breaker:
error_rate_threshold: 0. 05 window_s: 10 open_s: 30 pool: dedicated-psp (max_conns: 200)

7) Beobachtbarkeit von Abhängigkeiten

Verteilte Verfolgungen (TraceID, Baggage): Sehen Sie den Abfragepfad nach Links; Spans auf ausgehende Anrufe mit den Tags' peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• Karte von Diensten mit Farbanzeige von SLO und fehlerhaften Kanten.
• „Top N problematische Abhängigkeiten“ für die letzte Woche.
• „Blast radius“ - eine Liste von Diensten, die leiden, wenn X fällt.
• Korrelationsprotokolle: 'trace _ id '/' span _ id' in Protokolle aufnehmen.

8) Releasemanagement unter Berücksichtigung von Abhängigkeiten

Abhängigkeit-aware Pipelines: Die Freigabe des Anbieters wird blockiert, wenn die CDC-Tests der Verbraucher rot sind.
Schrittweise Einbeziehung (Ficheflags): Neue Felder/Endoints → für 1% der Verbraucher → 10% → 100%.
Kanarische Releases: Wir überprüfen die wichtigsten Abhängigkeiten und das „Latenzbudget“ auf den Verkehrsanteil.
Vereinbarkeit der Regelungen: Der Hersteller schreibt „vNew“, die Verbraucher lesen „vOld/vNew“; nach dem Übergang - „Müllabfuhr“ der alten Felder.

9) Vorfälle und Eskalationen nach Spalte

Wir definieren den „wahren Schuldigen“: Alert-Korrelation - wenn die' PSP-X 'degradiert ist, wird nicht der gesamte „Zahlungsbusch“ aufgerufen, sondern der Eigentümer der Integration.
Autodegradation: Ficheflag „Minimalmodus“ (weniger schwere Endpoints, abgespeckte Bundles, Abschaltung unkritischer Fich).
Gardens von Kaskaden: Begrenzen Sie die Parallelität, schalten Sie die Retrays auf dem heißen Ast aus, öffnen Sie den Breaker im Voraus (Pre-Open).

• Diagnose: welche Dashboards/Metriken, wie man Quoten/Limits überprüft.
• Aktionen: RPS reduzieren, zum Backup-Provider wechseln, Cache-Antworten vorübergehend aktivieren.
• Rollback und Validierung: Parameter zurückgeben, p95/p99 Norm und Error-Rate überprüfen.

10) Abhängigkeitskritikalitätsmatrix

• Für die „Kritischen“ - Doppelprovider, Brecher, separate Pools, Chaos-Tests.
• Für die „Hohen“ gibt es zumindest eine Degradierung und einen „grünen Knopf“, um das Fichi auszuschalten.
• Für „mittel/niedrig“ - Grenzen für Retrays und Warteschlangen-Budget.

11) Prozess: von der Inventur bis zum Betrieb

1. Graph Mapping: Sammeln Sie die tatsächlichen Aufrufe (Traces) + deklarative Abhängigkeiten aus dem Verzeichnis.
2. Weisen Sie Eigentümer zu: Für jeden Service und jede externe Integration ist ein verantwortungsvoller On-Call erforderlich.
3. Definieren Sie SLOs und Budgets: Latenz/Fehler, Timeouts/Retrays/Pools.
4. Formalisieren Sie Verträge: OpenAPI/AsyncAPI, Schemas und CDC.
5. Nachhaltigkeitsmuster einschließen: timeouts/retries/circuit/bulkhead.
6. Richten Sie Dashboards und Alerts per dependency ein.
7. Release-Gates setzen: Block nach CDC/Kompatibilität/Kanarienvogel.
8. Regelmäßige Spieltage: Chaos-Experimente zum Fall der Schlüsselrippen.
9. Postmortems mit Fokus auf Kommunikation: Was die Kaskade verstärkt hat, wie man den Radius einengt.

12) Alerts auf Abhängigkeiten (Ideen von Regeln)

• `outbound_error_rate{to="X"} > 3% FOR 10m` → warning; `>5% FOR 5m` → critical.
• `outbound_p99_latency{to="X"} > SLO1. 3 FOR 10m` → warning.

• ' circuit _ open {to =“ X“} = = 1 FOR 1m' → dem Eigentümer der Integration.

• „retry _ rate {to =“ X „}> baseline2 FOR 5m“ + „outbound _ rps> 0“ → Sturmgefahr.

• `consumer_lag{topic="Y"} growth > threshold FOR 10m` + `hpa at max` → крит.

• ' usage _ quota {provider =“ PSP-X „}> 90% window '→ Warnung, automatische Umschaltung von Routen.

13) Anti-Muster

„Ein gemeinsamer Pool von Streams für alle Downstreams“. Insgesamt: Head-of-Line-Blocking. Teilen Sie die Pools.
Keine Timeouts/mit endlosen Retraits. So entsteht ein Sturm.
Blinde Retrays nicht-idempotenter Operationen. Doppelte Abschreibungen/Wetten.
Eine versteckte „gemeinsame DB“ als Verbindungspunkt. Starke Konkurrenz und Lockdowns.
Die API-Version ändert sich ohne CDC und Deprecate-Plan. Fangen Sie massive Stürze.
Beobachtbarkeit nur für Dienstleistungen, nicht für Verbindungen. Man sieht nicht, wo die Kette reißt.

14) Dashboards: Mindestsatz

Service Map: Interaktive Karte der Dienste mit Kantenmetriken (latency/error/volume).
Upstream/Downstream Übersicht: Für den Servicebesitzer - eingehende Abhängigkeiten (wer anruft), ausgehende (wen wir anrufen), „Top-Probleme“.
Abhängigkeit Drilldown: spezifische Verbindungskarte: p50/p95/p99, Fehler nach Klasse, Prozentsatz der offenen Breaker, Retrays, Verbindungspool, Quoten/Costs.
Release Context: Anmerkungen zu Releases/Ficheflags in Abhängigkeitsdiagrammen.

15) Checkliste Umsetzung

• Dienstverzeichnis mit Eigentümern und Verträgen (OpenAPI/AsyncAPI).
• Vollständiger Abhängigkeitsgraph aus Traces (täglich aktualisieren).
• Service SLOs und „Latenzbudgets“ in der Kette.
• Explizite Timeouts, Retrays mit Jitter, Breakers, Bulkhead-Isolation.
• CDC-Tests im CI als Release-Gate.
• Dashboards per dependency und Servicekarte.
• Alerts auf den Rippen + Unterdrückung durch die Ursache.
• Game-days: Drop des Providers/Clusters/Topics und Überprüfung der Degradationen.
• Degradationsplan: Welche Files wir ausschalten, welche Caches wir einschalten.
• Regelmäßige Postmorteme mit Maßnahmen zur Verringerung der Konnektivität.

16) Qualitätskennzahlen des Abhängigkeitsmanagements

Abhängigkeit MTTR: Mediane Erholung durch die Kante.
Blast Radius Index: Die durchschnittliche Anzahl der betroffenen Dienste, wenn einer fällt.
Coupling Score: Anteil der Sync-Abhängigkeiten an allen; Abwärtstrend.
CDC Pass Rate:% der Freigaben ohne Vertragsverletzung.

Retry Storms/Monat: Zielwert → 0

Kosten für externe Anrufe: Kosten für externe Anrufe pro 1k RPS (sehen Sie den Caching/Follback-Effekt).

17) Schnellstart (Ausfälle)

Zeiträume: 70-80% des Verbindungsbudgets; die obere Zeitüberschreitung der Anforderung <die Summe der internen.
Retrays: max 2, nur auf idempotent 5xx/Netzwerk, mit backoff + jitter.
Breaker: Schwelle von 5% Fehler in 10s, offen = 30s, halb-offene Proben.
Bulkhead: dedizierte Pools/Verbindungslimits für jeden Downstream.
CDC: obligatorisch für alle öffentlichen APIs und Topics.
Async-Präferenz: wo möglich - Übergang zu Ereignissen/Warteschlangen (Entkopplung nach Zeit).

18) FAQ

F: Was ist wichtiger: Retrays oder Breaker?
A: Beides. Retrays retten vor kurzfristigen Ausfällen, Breaker schützt vor Dauerabbau und Stürmen.

F: Wie kann man verstehen, dass die Verbindung „zu zerbrechlich“ ist?
A: Hohe Fehlerkorrelation, niedrige Timeout-Marge, häufige Retrays, keine Vollbacks/Caches, synchrone lange Ketten.

F: Warum CDC, wenn wir Integrationstests haben?
A: CDC erfasst die Erwartungen des Verbrauchers und bricht die Freigabe des Anbieters bei Inkompatibilität - bevor der Code in den Prod.