🟢
infrastructure

Haute Disponibilite

Capacite d'un systeme a rester operationnel avec un temps d'arret minimal.

Definition

La haute disponibilite (High Availability, HA) est la capacite d'un systeme a rester operationnel et accessible pendant un pourcentage tres eleve du temps, minimisant les temps d'arret planifies et non planifies.

La HA se mesure en "nines" — le nombre de 9 dans le pourcentage de disponibilite :

SLA Disponibilite Downtime par an Downtime par mois
99% "deux nines" 3.65 jours 7.3 heures
99.9% "trois nines" 8.76 heures 43.8 minutes
99.99% "quatre nines" 52.6 minutes 4.38 minutes
99.999% "cinq nines" 5.26 minutes 26.3 secondes

Principes fondamentaux

1. Eliminer les SPOF (Single Points of Failure)

Chaque composant critique doit avoir une redondance :

  • 2+ serveurs d'application
  • 2+ replicas de base de donnees
  • 2+ zones de disponibilite (AZ)

2. Redundance active-active vs active-passive

  • Active-active : tous les noeuds traitent du trafic (meilleure utilisation)
  • Active-passive : un noeud en standby prend le relais en cas de panne (plus simple)

3. Health checks et auto-healing

# Kubernetes : readiness et liveness probes
livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 3000

4. Failover automatique

Quand un composant tombe, le trafic est automatiquement redirige vers les composants sains. Pas d'intervention humaine.

Architecture haute disponibilite typique

Utilisateurs → CDN (Cloudflare) → Load Balancer
                                      ↓
                            ┌─────────┼─────────┐
                            │    App (AZ-1)     │
                            │    App (AZ-2)     │
                            │    App (AZ-3)     │
                            └─────────┼─────────┘
                                      ↓
                              DB Primary (AZ-1)
                              DB Replica (AZ-2)
                              DB Replica (AZ-3)

Strategies de Disaster Recovery

Strategie RTO RPO Cout
Backup & Restore Heures Heures Faible
Pilot Light Minutes Minutes Moyen
Warm Standby Secondes-Minutes Secondes Eleve
Multi-Site Active Quasi-zero Zero Tres eleve
  • RTO (Recovery Time Objective) : temps max pour restaurer le service
  • RPO (Recovery Point Objective) : perte de donnees maximale acceptable

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions frequentes

99.9% de disponibilite, c'est suffisant ?
Pour la plupart des applications, oui. 99.9% autorise 8.7h de downtime par an. Les 99.99% ou 99.999% coutent exponentiellement plus cher et ne sont necessaires que pour les systemes critiques (paiement, sante).
Comment tester la haute disponibilite ?
Pratiquez le chaos engineering : simulez des pannes (kill d'un pod, coupure d'une AZ) et verifiez que le systeme se retablit automatiquement. Netflix a popularise cette approche avec Chaos Monkey.
Multi-AZ ou multi-region ?
Multi-AZ est le minimum pour la HA (protection contre la panne d'un datacenter). Multi-region protege contre la panne d'une region entiere mais est beaucoup plus complexe et couteux. Commencez par multi-AZ.

Pages liees

Chaque semaine, le meilleur de la tech francaise

Tendances, salaires, outils et opportunites — directement dans votre boite mail.

Gratuit. Desabonnement en un clic. Pas de spam.