Définir un SLO Réaliste avec des Dépendances Tierces

Votre SLO ne peut pas dépasser le produit des disponibilités de vos dépendances. Voici comment calculer ce plafond et fixer une cible défendable.

Un SLO de 99,99 % semble ambitieux. Mais si votre stack dépend de Stripe, d'une base RDS et d'un CDN, votre plafond théorique est déjà sous les 99,93 % — avant même d'avoir écrit une ligne de votre propre code. Connaître ce plafond est le point de départ de tout SLO honnête.

SLA ≠ SLO

Un SLA (Service Level Agreement) est une promesse contractuelle d'un fournisseur envers vous, avec des pénalités financières en cas de non-respect. Un SLO (Service Level Objective) est votre objectif interne d'ingénierie. Le SLO doit toujours être plus strict que le SLA : si vous attendez que votre SLA soit violé pour réagir, vos utilisateurs souffrent depuis un moment. Un SLA de 99,9 % tolère 8,7h de panne par an — vous ne pouvez pas vous permettre d'attendre ça.

La loi du produit

La disponibilité d'une chaîne de services est le produit des disponibilités individuelles. Si votre flux de paiement dépend de Stripe (99,99 %), de votre base RDS (99,95 %) et d'une API interne (99,9 %), la disponibilité composite est 0,9999 × 0,9995 × 0,999 = 99,84 %. C'est votre plafond théorique — en supposant que les pannes sont indépendantes. En réalité, elles ne le sont souvent pas.

Disponibilité_composite = A₁ × A₂ × … × Aₙ

La marge de sécurité

Ne ciblez jamais exactement votre disponibilité composite théorique. Il faut une marge pour absorber vos propres bugs, vos fenêtres de déploiement, et les pannes corrélées (deux fournisseurs dans la même région AWS qui tombent ensemble). Une marge de 10 % est un bon point de départ : si votre composite est 99,9 %, ciblez 99,81 %. Cela laisse de la place pour manœuvrer sans violer votre SLO à chaque incident mineur.

Dépendances cachées

Les équipes oublient souvent : le résolveur DNS (si votre DNS tombe, tout tombe), le CDN edge (pour les assets statiques mais aussi souvent pour l'API), le fournisseur OAuth (si vous utilisez Google SSO, une panne Google = vos utilisateurs ne peuvent plus se connecter), et la région cloud elle-même. Une panne de région AWS peut affecter simultanément votre base RDS, vos lambdas et vos fournisseurs SaaS hébergés dans la même région.

Pièges courants

! Utiliser le SLA du fournisseur comme SLO cible : c'est le minimum contractuel, pas une cible d'ingénierie.
! Ignorer les limites de quota et de débit : être rate-limité par une API tierce est une indisponibilité du point de vue de vos utilisateurs, même si le fournisseur affiche 100 % de disponibilité.
! Supposer l'indépendance des pannes : deux services hébergés dans la même région cloud partagent un mode de défaillance commun.