Opérations et Gestion des → Dépendances des services

Dépendances des services

1) Pourquoi est-ce nécessaire

Toute plate-forme de production est un graphique : les utilisateurs de → Edge/API → les services de domaine → les files d'attente/streams → les bases de données/caches → les fournisseurs externes (paiements, KYC, fournisseurs de jeux). L'erreur sur une côte du graphe est souvent « marchante » sur tout le réseau : les retards augmentent, les rétroactions sont déclenchées, les files d'attente sont marquées, les pannes en cascade se produisent. La gestion des dépendances réduit le « rayon explosif » et rend les rejets prévisibles.

• Voir le graphique complet des défis et comprendre qui dépend de qui.
• Prévenir les pannes en cascade et la « tempête des retraits ».
• Planifiez des versions compatibles et de la propagande SLO.
• Booster MTTR : trouvez plus rapidement le véritable nœud racine (root cause).

2) Types de dépendances

Synchrone (RPC : REST/gRPC/GraphQL) : connectivité rigide par latence/disponibilité. Il faut des temporuts, des breakers, un budget de retraite.
Asynchrone (Event/Stream : Kafka/Rabbit/Pulsar) : connectivité plus durable, mais il y a lag/backlog et sémantique de livraison (at-least-once, idempotency).
Stockage (DB/Cache/Object store) : Ressources partageables → contours, limites de connexions/IOPS, evection, réplication.
Fournisseurs externes (PSP/KYC/fournisseurs de jeux) : quotas, appels payants, fenêtres de service, SLA juridique.
Opératoires (sorties, ficheflags, configi) : dépendances indirectes via les réglages, secrets, schema registry.

3) Annuaire des services et graphique des dépendances

• Propriétaires (Squad/chat/On-call rota), repo, environnement, artefacts.
• Contrats API (OpenAPI/AsyncAPI), versions, compatibilité (back/forward).
• Dépendances entrantes/sortantes (upstream/downstream) avec type (sync/async), criticité, attentes SLO.
• Budget des timeouts/retraits, breakers, bulkhead pools.
• Données sur les quotas et les limites d'intégration externe.

• `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.
• Temporisation : 200 ms pour 'PSP-X', 150 ms pour 'user-profile'.
• Retrai : 2 avec retard exponentiel, gitter.
• Breaker : ouvert à 30 s avec 5 % d'erreurs/10 s.

4) SLO-propagande et « budget de la latence »

Dans une chaîne d'appels synchrones, le SLO final est formé à partir de la somme des retards et des probabilités de défaillance.

• Le budget de la demande est divisé de haut en bas : SLO de front 500 ms → Edge 50 ms → API 150 ms → services de domaine 200 ms → fournisseur 100 ms.
• Les taimauts sont « plus courts vers l'extérieur que vers l'intérieur » : le taimaute appelant a moins de temps intérieur total pour mettre à jour les ressources plutôt que de creuser des appels zombies.
• Retraits uniquement pour codes/exclusions sécurisés et avec jitter ; pas de retraits sur les timaouts des goulets d'étranglement (sinon « tempête »).

5) Contrats et interopérabilité

Versioning API : BouVer pour les contrats ; les modifications backward-compatibles via les champs « optional », extensions du schéma ; suppression - seulement après la « période deprecate ».
Contrats consommateurs-conducteurs (CDC) : les tests consommateurs (Pact-like) sont lancés contre le fournisseur de CI ; la libération est bloquée en cas d'incompatibilité.
Schémas-registres (Async) : version des topiques/événements, évolution des schémas (Avro/JSON-Schema), politique « can-read-old/can-write-new ».

6) Modèles d'ingénierie de durabilité

Timeouts : séparer les entreprises SLA des attentes techniques ; chaque connexion sortante est une temporisation explicite.
Retries + backoff + jitter : pas plus de 2-3 tentatives, compte tenu de l'idempotence.
Circuit Breaker : « chute rapide » lors de la dégradation du downstream ; échantillon half-ouvert.
Bulkhead (isolation de pools) : pour différents downstream - pools distincts de flux/pods/connexions.
Rate-limit/Leaky-bucket : pour ne pas tuer les downstream en cas de pics.
Idempotency & déduplication : Clé d'idempotentialité au niveau de la requête/message ; grand-père-leiters et rétrograde-file.
Cache et follbacks : caches locaux/distribués, statuts « stale-while-revalidate », dégradation du contenu.

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) Observabilité des dépendances

Traces distribuées (TraceID, Baggage) : voir le chemin de requête par lien ; Dormez sur les appels sortants marqués 'peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• Carte des services avec indication de couleur SLO et côtes erronées.
• « Top N des dépendances problématiques » de la semaine dernière.
• « Blast radius » est la liste des services qui seront touchés par la chute de X.
• Logs de corrélation : inclure 'trace _ id '/' span _ id' dans les logs.

8) Gérer les versions en fonction des dépendances

Pipelines dependency-aware : la sortie du fournisseur est bloquée si les tests CDC des consommateurs sont rouges.
Inclusion progressive (ficheflagi) : les nouveaux champs/endoints → pour 1 % des consommateurs → 10 % → 100 %.
Sorties canaries : nous vérifions les dépendances clés et le « budget de latence » sur la part du trafic.
Compatibilité des schémas : le producteur écrit 'vNew', les consumers lisent 'vOld/vNew' ; après la transition - « ramasser les ordures » des anciens champs.

9) Incidents et escalade selon le graphe

Nous identifions le « vrai coupable » : alert corrélation - si le 'PSP-X' a été dégradé, ce n'est pas la pagime tout le « buisson de paiement », mais le propriétaire de l'intégration.
Autogradation : ficheflag « mode minimum » (endpoints moins lourds, bandles coupés, coupure des fiches non critiques).
Gardas des cascades : limiter le parallélisme, éteindre les retraits sur la branche chaude, ouvrir le breaker à l'avance (pré-ouvert).

• Diagnostic : quels dashboards/métriques, comment vérifier les quotas/limites.
• Actions : réduire le RPS, passer au fournisseur de secours, activer temporairement les réponses cache.
• Retour en arrière et validation : retourner les paramètres, s'assurer de la norme p95/p99 et error-rate.

10) Matrice de criticité des dépendances

• Pour les « critiques » - double fournisseur, breakers, pools individuels, tests de chaos.
• Pour les « hauts », au moins la dégradation et le « bouton vert » de l'arrêt de la fiche.
• Pour les « moyennes/basses », les limites pour les retraits et le budget des files d'attente.

11) Processus : De l'inventaire à l'exploitation

1. Cartographie du graphe : collectez les appels réels (tracés) + les dépendances déclaratives à partir du catalogue.
2. Désigner les propriétaires : pour chaque service et intégration externe - responsable on-call.
3. Définir les SLO et les budgets : latence/erreurs, délais/retraits/pools.
4. Formaliser les contrats : OpenAPI/AsyncAPI, schémas et CDC.
5. Inclure les modèles de résistance : timeouts/retries/circuit/bulkhead.
6. Configurer les dashboards et les alerts per-dependency.
7. Mettre les gates de sortie : bloc par CDC/compatibilité/canari.
8. Jours de jeu réguliers : Expériences de chaos sur la chute des côtes clés.
9. Postmortem avec un accent sur la communication : ce qui a renforcé la cascade, comment réduire le rayon.

12) Alerte sur les dépendances (idées de règles)

• `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' → page au propriétaire de l'intégration.

• ' retry _ rate {to = » X »}> baseline2 FOR 5m' + 'outbound _ rps> 0' → risque de tempête.

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

• 'Utilisation _ quota {provider = 'PSP-X'}> 90 % window '→ avertissement, connexion automatique des itinéraires.

13) Anti-modèles

« Un pool commun de flux pour tous les downstream ». Total : head-of-line blocking. Partagez les pools.
Pas de délai d'attente/avec des retraits infinis. C'est ainsi que naît la tempête.
Retraits aveugles de chirurgie non-idempotente. Doublons de charges/paris.
La « base de données commune » cachée est un point de connectivité. Forte concurrence et blocages.
La version de l'API change sans CDC ni plan deprecate. Attrapez les chutes massives.
L'observation ne concerne que les services, pas les communications. Je ne vois pas où la chaîne se déchire.

14) Dashboards : recrutement minimum

Carte de service : carte interactive des services avec métriques des côtes (latency/error/volume).
Upstream/Downstream Aperçu : pour le propriétaire du service - les dépendances entrantes (qui appelle), sortants (qui appelle), « problèmes supérieurs ».
Dependency Drilldown : carte de communication spécifique : p50/p95/p99, erreurs par classe, pourcentage de breaker ouvert, retrai, pool de connexion, quotas/chat.
Release Context : annotations de release/ficheflags sur les graphiques de dépendance.

15) Chèque de mise en œuvre

• Annuaire de services avec propriétaires et contrats (OpenAPI/AsyncAPI).
• Graphique complet des dépendances à partir des traces (mise à jour quotidienne).
• SLO sur le service et les « budgets de latence » sur la chaîne.
• Timeouts explicites, retraits avec jitter, breakers, bulkhead-isolation.
• Les tests CDC dans CI comme un gate de sortie.
• Dashboards per-dependency et carte de service.
• Alerte sur les côtes + suppression sur la cause première.
• Journées de jeu : chute du fournisseur/cluster/topic et vérification des dégradations.
• Plan de dégradation : quelles fiches nous éteignons, quelles caches nous allumons.
• Des postmortems réguliers avec des actions pour réduire la connectivité.

16) KPI qualité de gestion des dépendances

Dependency MTTR : récupération médiane sur la côte.
Blast Radius Index : nombre moyen de services touchés par la chute d'un.
Score de couplage : proportion de sync-dépendances parmi tous ; tendance à la baisse.
CDC Pass Rate :% de sorties sans rupture de contrat.
Retry Storms/mois : valeur cible → 0.
Cost of External Calls : coût des appels externes sur 1k RPS (voir l'effet cache/follback).

17) Démarrage rapide (défauts)

Temporisation : 70 à 80 % du budget de liaison ; Temporisation supérieure de la requête <somme interne.
Retrai : max 2, uniquement sur idempotent 5xx/net, avec backoff + gitter.
Breaker : seuil de 5 % d'erreurs en 10 s, open = 30 s, échantillons half-open.
Bulkhead : pools/limites de connexion dédiés pour chaque downstream.
CDC : obligatoire pour tous les API et tops publics.
Async-prefence : où vous pouvez - passer aux événements/files d'attente (découplage temporel).

18) FAQ

Q : Qu'est-ce qui compte le plus : les retraits ou le breaker ?
A : Les deux. Les retraits sont sauvés des pannes à court terme, le breaker protège contre la dégradation permanente et les tempêtes.

Q : Comment comprendre que le lien est « trop fragile » ?
R : Corrélation d'erreur élevée, faible marge de temporisation, retraits fréquents, absence de folleback/cache, chaînes longues synchrones.

Q : Pourquoi le CDC si nous avons des tests d'intégration ?
R : CDC enregistre les attentes du consommateur et brise la sortie du fournisseur en cas d'incompatibilité - avant que le code ne tombe dans la trappe.