Haute Disponibilite

Capacité d'un système à rester opérationnel avec un temps d'arrêt minimal.

Définition

La haute disponibilité (High Availability, HA) est la capacité d'un système à rester opérationnel et accessible pendant un pourcentage très élevé du temps, minimisant les temps d'arrêt planifies et non planifies.

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

SLA	Disponibilité	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+ réplicas de base de données
2+ zones de disponibilité (AZ)

2. Redundance active-active vs active-passive

Active-active : tous les nœuds traitent du trafic (meilleure utilisation)
Active-passive : un nœud 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 disponibilité 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)

Stratégies de Disaster Recovery

Stratégie	RTO	RPO	Coût
Backup & Restore	Heures	Heures	Faible
Pilot Light	Minutes	Minutes	Moyen
Warm Standby	Secondes-Minutes	Secondes	Eleve
Multi-Site Active	Quasi-zero	Zéro	Très élevé

RTO (Recovery Time Objective) : temps max pour restaurer le service
RPO (Recovery Point Objective) : perte de données maximale acceptable

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions fréquentes

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.