Un PodDisruptionBudget configuré, une sonde de liveness réglée, un HPA qui scale : chacun de ces mécanismes repose sur une hypothèse de fonctionnement qui n’est vérifiée qu’une fois, en théorie, au moment de l’écrire. Le chaos engineering remplace cette hypothèse par une preuve : provoquer la panne délibérément, en conditions contrôlées, pour vérifier que le système réagit comme prévu, avant qu’un vrai incident ne le découvre à sa place.

Une discipline, pas un outil qu’on installe

Le chaos engineering n’est pas d’abord une question d’outillage : c’est une méthode expérimentale. Formuler une hypothèse précise (« si ce pod meurt, le trafic bascule sur les replicas restants sans erreur visible côté utilisateur »), définir un rayon d’impact limité, exécuter l’expérience, observer si l’hypothèse tient. Un outil comme Litmus ou Chaos Mesh automatise l’exécution, mais la discipline précède l’outil : sans hypothèse claire, une panne provoquée au hasard n’apprend rien de plus qu’un vrai incident, en pire (personne n’était en alerte).

# Chaos Mesh : tuer un pod aléatoire du déploiement,
# une expérience minimale mais représentative
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: kill-checkout-pod
spec:
  action: pod-kill
  mode: one
  selector:
    labelSelectors:
      app: checkout

Commencer petit, en environnement contrôlé

La première expérience de chaos ne se déroule jamais en production sans préparation : un environnement de staging représentatif de la charge et de la topologie réelle est le point de départ, avec un rayon d’impact délibérément restreint (un seul pod, une seule zone de disponibilité) avant d’envisager une expérience plus large. L’objectif initial n’est pas de casser fort, c’est de vérifier que l’observabilité elle-même fonctionne : une panne provoquée qui ne génère aucune alerte révèle un problème plus urgent que la panne testée.

Les expériences qui révèlent le plus

Tuer un pod valide le mécanisme le plus basique (remplacement automatique), mais les expériences qui révèlent le plus sont souvent moins évidentes : injecter de la latence réseau vers une dépendance (teste les timeouts et les retries, pas seulement la disponibilité), épuiser la mémoire d’un nœud (teste les priorités d’éviction et les PriorityClass), ou simuler la perte d’une zone de disponibilité entière (teste l’anti-affinité de pods réellement configurée, pas seulement documentée).

# Injecter 200ms de latence vers un service dépendant,
# révèle des timeouts mal calibrés qu'un simple kill ne révèle pas
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
spec:
  action: delay
  delay:
    latency: "200ms"
  selector:
    labelSelectors:
      app: payment-gateway

Ce type d’expérience trouve régulièrement des défauts qu’aucune revue de code ne révèle : un timeout client configuré plus court que le timeout serveur, une dépendance sans circuit breaker qui propage une lenteur en cascade, un retry sans backoff qui aggrave une surcharge au lieu de l’absorber.

Le game day : la version organisée, pas improvisée

Un game day formalise l’exercice : une expérience de chaos planifiée à l’avance, avec l’équipe de garde en observation active (pas surprise), un objectif d’apprentissage précis, et un compte-rendu qui documente ce qui a réellement été découvert. Cette formalisation transforme le chaos engineering d’un exercice ponctuel en une pratique répétable, alignée sur le cycle de révision d’un SLO : chaque game day teste une hypothèse de résilience précise, pas une panne générique.

À retenir

Un mécanisme de résilience jamais testé activement (PodDisruptionBudget, sonde de liveness, retry) reste une hypothèse jusqu’à preuve du contraire, et la preuve la moins coûteuse est une expérience provoquée délibérément plutôt qu’un incident réel. Commencer petit, en staging, avec un rayon d’impact restreint et une hypothèse précise, avant d’envisager la production ; les expériences les plus révélatrices dépassent le simple kill de pod (latence injectée, épuisement de ressource) ; le game day organise cette pratique en exercice répétable plutôt qu’en coup ponctuel, un des piliers d’une fiabilité et observabilité construite sur des preuves plutôt que des suppositions.