High Availability и SLA

High Availability и SLA

1) Termes et liens avec l'entreprise

SLI (Service Level Indicator) est un indicateur de service mesuré (par rapport à la proportion de demandes réussies 2xx/3xx ≤ T ms).
SLO (Service Level Objective) est la valeur cible de SLI (par exemple "99. 95 % des demandes ≤ 300 ms').
SLA (Service Level Agreement) est une obligation contractuelle envers le client (pénalités/crédits en cas d'infraction).
HA (High Availability) - Mesures architecturales et opérationnelles permettant l'exécution de SLO/SLA.

Principe : Le SLA repose sur le SLO et le SLO sur les SLI observés. Vous ne pouvez pas promettre en SLA ce que vous ne mesurez pas.

2) « Nine » et les mathématiques de l'accessibilité

Composition de disponibilité

Chaîne séquentielle (dépendances par « chemin rouge ») : 'A _ total = Π A_i' (chaque composant réduit le total).
Noeuds actifs-actifs parallèles : « A _ total = 1 − Π (1 − A_i) » (la réserve augmente le total).

3) Exactement quoi mesurer (SLI correct)

Un regard personnalisé : la réussite des opérations clés (login, dépôt, chèque-out) et leur latence p99.
Couloir horaire : agréger le long des fenêtres coulissantes (5/30/60 min) et par région.
Exceptions : les « fenêtres planifiées » sont prises en compte dans le SLO et dans le SLA seulement si cela est dit dans le contrat.

• Disponibilité : proportion de réponses réussies ≤ T.
• Qualité : p95/p99 latency.
• Composites : « proportion de dépôts réussis ≤ 5 s ».

4) Budget d'erreur et vitesse de combustion

Error Budget = `1 − SLO`. Pour 99. Une fenêtre mensuelle de 95 % donne 0. 05 % d'erreurs/d'inactivité.
Burn-rate : taux de consommation du budget (par exemple, 4 × signifie que vous mangez la limite journalière en 6 heures).
Politique : en cas de combustion rapide - stop releases, focus sur la stabilisation, feature-freeze.

5) Architecture HA : du nœud à la région

5. 1 Nœud/service

N + 1 : au moins une réplique redondante (Deployment ≥ 2, PDB, anti-affinité).
Isolation des ressources : limites CPU/RAM/IO, priorités (classe prioritaire).
Graceful shutdown/drain : pas de falaise de requête lors du restart.

5. 2 Zone/région

Multi-AZ : répliques dans différentes zones, équilibrage croisé, alimentation/réseau indépendant.
Multi-région : actif-actif (plus difficile : données/consistance) ou actif-passif (plus simple : plus haut RPO).
Données : CP pour l'argent/commandes (quorum/RAFT), EC/AP pour les caches/vitrines.

5. 3 Couche réseau et périmètre

L7-LB с health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast pour le trafic mondial, TTL courts.
Contrôle egress et flux tolérants aux pannes jusqu'à PSP/fournisseurs externes.

6) Dégradation au lieu de tomber

Fonctionnalité kill-switch (drapeaux de ficha) : désactiver le « chemin rouge » non critique.
Basculement vers des chemins simplifiés : Synchron → asynchron/file d'attente, « accepté en traitement ».
Taux-limite/quotas : mieux vaut limiter le trafic que de faire tomber tout le monde.
Stale-modes : Donner cache/données statiques lorsque l'origin n'est pas disponible.

7) Gestion des dépendances

Carte des dépendances (carte de service) : directe/transitive, criticité, SLO de chacun.
Liens vulnérables : fournisseur externe sans SLA - tourne autour de cache/file d'attente/duplication.
Isolation Bulkhead : différents pools de connexions/quotas pour les itinéraires lents.
Timeouts> Retraits : Timeouts courts, maximum 1 rétraction pour les opérations idempotentes.

8) Opérations et modifications

Gestion du changement : sorties via canaries/bleu-vert, gates SLO, retour automatique.
Fenêtres planifiées : normaliser - longueur, fréquence, communications.
Incidents : rôles (IC/Comms/Tech/DB), runbook 'et, postmortems avec mesures correctives.
Titris-ivents : en cas de compromission, le « mode panique » (read-only/tokens/rotation/blocage).

9) Observabilité et alerting

Modèle RED (Rate, Errors, Durée) pour chaque itinéraire.
SLI-dashboards : disponibilité/latence par région et par segment client.
Burn-rate alerts : rapide (1h, 14. 4 ×), lent (6h, 2 ×) est le signal avant la rupture de SLO.
Instances (Exemplars) : Permet de passer des métriques aux pistes de trace_id.
Synthétique : échantillons provenant de points extérieurs (périmètre, flou de paiement).

10) Tests de tolérance aux pannes

Jours de jeu : scénarios de coupure AZ/régions, dégradation des bases de données/caches, défaillance des fournisseurs externes.
Outils Chaos : Folts du réseau (latency/loss), kill-pods, surchauffe CPU/IO.
DR-drills : RTO/RPO pour les systèmes de Tier-0 (voir « Backups et DR »).

11) Conception de SLA

Définition de « disponibilité » : ce qui est considéré comme un incident (5xx, temps> T, erreurs de domaine).
Fenêtre de calcul : mois/trimestre ; inclusion/suppression des travaux planifiés.
Crédits/amendes : échelle (par exemple, 99. 9–99. 99 % - X %, inférieur à Y %).
Responsabilités du client : intégration, retraits dans des limites raisonnables, limites.
Notifications et procédure de clim : calendrier, format, base de preuves (logs/métriques).
Force majeure : formulation juridique et limites.

• Disponibilité de l'API SLI réussie ≤ 500 ms au moins 99. 95 % par mois civil. Les fenêtres planifiées (jusqu'à 60 min/mois annoncées en 48 h) sont exclues. À 99 ans. 90–99. 95 % - crédit 5 %; 99. 80–99. 90% — 10%; <99. 80% — 25%.»

12) L'économie des neuf

• Tier-0 (argent/commandes) : 99. 95–99. 99 %, multi-AZ, DR prêt.
• Tier-1 (fiches de base) : 99. 9–99. 95 %, multi-AZ.
• Tier-2 (non critique) : 99. 5–99. 9 %, la dégradation/stop est autorisée en cas d'incident.

13) Modèles HA par couches

Périmètre : CDN/edge, multi-CDN ou GSLB, WAF, rate-limit.
Équilibrage : L7 avec outlier-ejection, timeouts/retrai, sticky/consistent-hash.
Applications : Skale horizontale, read..../liveness, PDB, spread topology.
Données : leader + replicas, quorum pour CP, cache L2, idempotency, PITR.
Files d'attente : miroir/multiplaster, dedup, DLQ.
Secrets/configues : GitOps, snapshots atomiques, rollback.

14) Anti-modèles

SLA sans outils de mesure et synthétiques externes.
Zone unique/cluster comme SPOF.
Retraits incontrôlables → « samo-DDoS ».
Transactions longues/mutex sur le chemin chaud.
Migrations « lourdes »/sorties sans canaries et plan de repli.
L'absence de runbook et de communication avec les steakholders lors de l'incident.

15) Chèque de mise en œuvre (0-60 jours)

0-15 jours

Définir les SLI utilisateur critiques, définir les SLO par niveau de Tier-0/1/2.
Inclure les alerts à rate-burn, SLO-dashboards, contrôles de périmètre synthétiques.
Supprimer SPOF : répliques ≥2, PDB, multi-AZ pour les fronts et les OBD critiques.

16-40 jours

Entrez les versions canaries avec SLO-Gate et auto-retour.
Carte des dépendances + quotas/pools/délais/SV pour chaque « chemin rouge ».
Règlement sur les fenêtres de planification et les communications, modèles de messages d'incident.

41-60 jours

Game-day : arrêt d'AZ, échec du fournisseur externe, « burst » du trafic.
Recalculer les SLA et les crédits en fait, publier des rapports aux clients.
Révision du « coût ↔ neuf » et transfert sur le tiret.

16) Métriques de maturité

≥ 95 % des itinéraires critiques ont des alertes SLI/SLO et burn-rate.
Les erreurs SLO sont accompagnées d'un gel automatique des versions (politique).
Couverture multi-AZ Tier-0 = 100 %, drills DR réussis ≥ 1/trimestre.
Temps de « détection → mitigation » p50 <5 min, p95 <15 min.
Corrélation « sortie ↔ incidents » - en cours et raccourci (rollback rate↓).
Rapport public sur les incidents/prêts - dans les N jours ouvrables.

17) Exemples et extraits

• Rapide : "SLO 99. 95 %, fenêtre 1 h, burn ≥ 14. 4× → page on-call».
• Lente : « fenêtre 6 h, burn ≥ 2 × → ticket & monitoring ».

yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) Conclusion

La haute disponibilité n'est pas seulement des clusters et des répliques, mais un ensemble cohérent d'architectures, de processus et de métriques : SLI/SLO clair, SLA réaliste, « neuf » avec l'économie, la dégradation au lieu de la chute, la discipline des taimouts/quotas, les versions canaries, les exercices réguliers et la communication transparente. Rendre l'accessibilité mesurable et gérable - et elle deviendra un avantage concurrentiel, pas une loterie.