Résilience opérationnelle

Chaos engineering, disaster recovery, sauvegardes, runbooks et pratiques pour maintenir le système en fonctionnement face aux pannes.

Qu’est-ce que la résilience opérationnelle ?

La résilience opérationnelle est la capacité d’un système à continuer de fonctionner (ou à se rétablir rapidement) face aux pannes, aux erreurs et aux situations inattendues. Il ne s’agit pas d’éviter les pannes — dans les systèmes distribués, les pannes sont inévitables — mais de concevoir le système pour qu’il les tolère.

La résilience opérationnelle englobe :

• La prévention des pannes grâce à une conception robuste
• La détection rapide des problèmes
• La récupération automatique ou assistée
• L’apprentissage continu à partir des incidents

Chaos engineering

Le chaos engineering est la pratique consistant à injecter délibérément des pannes dans le système afin de vérifier qu’il peut les gérer. Le principe est simple : si vous ne testez pas les pannes dans un environnement contrôlé, vous les découvrirez en production.

Principes

1. Définir l’état stable : à quoi ressemble le système lorsqu’il fonctionne correctement ? (métriques, latence, taux d’erreur)
2. Formuler une hypothèse : « Si le service X tombe en panne, le système devrait se dégrader gracieusement »
3. Injecter la panne : simuler la condition de panne
4. Observer l’impact : le système s’est-il comporté comme prévu ?
5. Apprendre et améliorer : documenter les constats et corriger les faiblesses

Types d’expériences

• Terminer des instances : que se passe-t-il si un pod meurt subitement ?
• Injecter de la latence : que se passe-t-il si un service downstream répond lentement ?
• Simuler des erreurs réseau : que se passe-t-il si la connexion entre services est perdue ?
• Remplir le disque : que se passe-t-il si le stockage est saturé ?
• Saturer le CPU/la mémoire : que se passe-t-il sous une pression extrême sur les ressources ?

Outils

• Chaos Monkey (Netflix) : termine des instances de manière aléatoire en production
• Litmus Chaos : framework de chaos engineering pour Kubernetes
• Gremlin : plateforme commerciale de chaos engineering
• Chaos Mesh : outil open source pour Kubernetes
• Toxiproxy : proxy permettant de simuler des conditions réseau défavorables

Bonnes pratiques

• Commencer dans des environnements de staging avant la production
• Débuter par des expériences réduites et contrôlées
• Toujours disposer d’un plan de rollback
• Impliquer l’équipe — le chaos engineering est un exercice d’équipe
• Documenter chaque expérience et ses résultats

Disaster recovery

Le disaster recovery (DR) est le plan de récupération du système face à une panne catastrophique : perte d’un datacenter, corruption massive des données ou attaque de sécurité.

Métriques clés

• RTO (Recovery Time Objective) : durée maximale acceptable pour restaurer le service
• RPO (Recovery Point Objective) : quantité maximale de données pouvant être perdues (mesurée en temps)

Plan de disaster recovery

1. Identifier les systèmes critiques : quels services sont essentiels pour l’activité ?
2. Définir le RTO et le RPO : pour chaque système critique
3. Concevoir la stratégie : sauvegardes, réplication, multi-région
4. Documenter le processus : étape par étape pour la récupération
5. Tester régulièrement : un plan non testé est un plan qui ne fonctionne pas
6. Mettre à jour le plan : chaque changement d’architecture peut affecter le DR

Sauvegardes

Les sauvegardes sont la dernière ligne de défense contre la perte de données.

Types de sauvegarde

• Full backup : copie complète de toutes les données
• Incremental backup : uniquement les données modifiées depuis la dernière sauvegarde
• Differential backup : les données modifiées depuis la dernière full backup

Règle 3-2-1

• 3 copies des données
• 2 types de stockage différents
• 1 copie offsite (dans un autre emplacement géographique)

Bonnes pratiques

• Automatiser : les sauvegardes manuelles finissent par être oubliées
• Vérifier : tester régulièrement que les sauvegardes peuvent être restaurées
• Chiffrer : les sauvegardes contiennent des données sensibles
• Rétention : définir des politiques claires sur la durée de conservation
• Surveiller : alerter en cas d’échec d’une sauvegarde

Exemple de politique de sauvegardes

Base de données principale :
- Full backup : quotidien à 02:00 UTC
- Incremental : toutes les heures
- Rétention : 30 jours pour les quotidiennes, 7 jours pour les incrémentales
- Stockage : S3 avec réplication cross-region
- Vérification : restauration automatique hebdomadaire dans un environnement de test

Runbooks

Un runbook est un document qui décrit étape par étape comment répondre à un incident ou effectuer une opération. C’est la différence entre une réponse chaotique et une réponse ordonnée.

Structure d’un runbook

1. Titre et description : quel incident ou quelle opération il couvre
2. Symptômes : comment le problème est détecté (alertes, métriques, logs)
3. Impact : ce qui est affecté et à quel point c’est grave
4. Diagnostic : étapes pour confirmer la cause racine
5. Résolution : étapes exactes pour résoudre le problème
6. Vérification : comment confirmer que le problème est résolu
7. Post-mortem : ce qu’il faut documenter après l’incident

Exemple : runbook pour une latence élevée sur l’API

## Latence élevée sur l'API Gateway

### Symptômes
- Alerte : latence p99 > 2s pendant 5 minutes
- Dashboard : graphique de latence en rouge

### Diagnostic
1. Vérifier les métriques CPU/mémoire des pods
2. Examiner les logs d'erreurs récents
3. Vérifier la latence des services downstream
4. Vérifier les connexions à la base de données

### Résolution
Si CPU > 90% :
  → Mettre à l'échelle horizontalement : kubectl scale deployment api --replicas=X

Si connexions DB saturées :
  → Vérifier les paramètres du connection pool
  → Redémarrer les pods en cas de connection leaks

Si service downstream lent :
  → Vérifier la santé du service
  → Activer le circuit breaker si nécessaire

### Vérification
- Confirmer que la latence p99 < 500ms
- Vérifier que le taux d'erreur < 0,1%
- Surveiller pendant 15 minutes

Incident management

Processus de réponse aux incidents

1. Détection : alertes automatiques ou signalement manuel
2. Triage : évaluer la gravité et l’impact
3. Communication : notifier les stakeholders
4. Investigation : diagnostiquer la cause racine
5. Mitigation : restaurer le service le plus rapidement possible
6. Résolution : appliquer la correction définitive
7. Post-mortem : documenter ce qui s’est passé, pourquoi et comment le prévenir

Niveaux de gravité

Post-mortem blameless

Après chaque incident significatif, réaliser un post-mortem sans recherche de coupable :

• Ce qui s’est passé : chronologie détaillée de l’incident
• Pourquoi c’est arrivé : analyse de la cause racine (5 whys)
• Ce que nous avons bien fait : ce qui a fonctionné dans la réponse
• Ce que nous pouvons améliorer : actions concrètes pour éviter que cela se reproduise
• Action items : tâches assignées avec responsables et échéances

Résumé

La résilience opérationnelle n’est pas optionnelle dans les systèmes distribués. Le chaos engineering valide que le système tolère les pannes, le disaster recovery prépare au pire, les sauvegardes protègent les données, les runbooks guident la réponse aux incidents et l’incident management organise la récupération. La clé est de pratiquer, de documenter et d’améliorer en continu.