Casser la prod pour mieux dormir : comment et pourquoi nous détruisons nos systèmes volontairement

Etes vous prêts pour votre prochain incident de production?

Vos runbooks sont à jour ✅ Vos alertes sont en place ✅ Votre architecture a été validée en design review ✅

Mais avez-vous déjà essayé de tout casser pour vérifier que ça tient vraiment ?

Chez OVHcloud, nous avons décidé de ne plus faire confiance à nos hypothèses de résilience sans les prouver. Nous cassons volontairement nos systèmes de production pour valider nos procédures de reprise, découvrir nos vrais points de fragilité et entraîner nos équipes à réagir sous pression.

Dans ce talk, je vous présenterai notre démarche complète : comment organiser un “Game Day”, définir des scénarios de panne réalistes, et monter progressivement en intensité — du sabotage manuel jusqu’aux tests de charge massifs. J’illustrerai chaque étape avec un cas concret : le stress-test de notre cluster Grafana Mimir, la brique centrale de notre observabilité, déployée sur VMs et non sur Kubernetes.

Ce que nous avons appris nous a surpris : l’application elle-même a résisté 💪 Ce sont les couches en dessous qui ont cédé — bande passante réseau, I/O disque, limites du noyau Linux. Les vrais goulots d’étranglement ne sont jamais là où on les attend.

Que vous utilisiez Mimir ou non, vous repartirez avec une méthodologie reproductible pour stress-tester vos propres systèmes, et une conviction : la confiance en votre infrastructure se construit en la détruisant.