Pourquoi
La question qui empêche de dormir quand on self-host : et si le serveur brûlait ce soir ? Est-ce que je saurais tout reconstruire ? En combien de temps ? Avec l’infra Cloud qui héberge mes projets, la réponse était “probablement, je crois, à peu près”. Pas très rassurant.
Plutôt que de croiser les doigts, j’ai décidé de simuler la catastrophe pour de vrai. Pas en production, mais dans une VM jetable qui reproduit exactement le même environnement. Si les playbooks Ansible sont capables de tout reconstruire à partir de zéro sur une VM vierge, ils seront capables de le faire sur un vrai VPS neuf le jour où il faudra.
Comment ça marche
Une VM QEMU simule un VPS Ubuntu vierge. Les playbooks Ansible de production sont joués contre cette VM. vm.sh reset recrée un disque vierge en une commande. On peut détruire et reconstruire autant de fois qu’on veut, sans risque.
10 scénarios testent trois choses : est-ce que l’infra se déploie correctement from scratch ? Est-ce qu’elle résiste quand on casse des trucs (kill de containers, injection de drift, nuke complet) ? Et est-ce que les règles de sécurité tiennent (pas de privilèges inutiles, pas de socket Docker exposé) ?
La réponse : tout se reconstruit en 3 minutes 30. Un nuke complet suivi d’un redéploiement prend 1 minute 08. Ce n’est pas un exploit, c’est juste le résultat normal quand l’infra est correctement automatisée. Mais maintenant je le sais, au lieu de le supposer.
Ce que j’en retiens
Le disaster recovery, c’est comme les tests unitaires : on sait qu’il faudrait le faire, on repousse toujours, et le jour où on le fait enfin on se demande pourquoi on a attendu. Une journée de travail pour pouvoir dormir tranquille, c’est un bon ratio.
Stats
| Scénarios | 10 |
| Services testés | 13 |
| Score | 52 PASS / 1 FAIL |
| RTO deploy complet | ~3m30s |
| RTO nuke + redeploy | ~1m08s |
| Durée du projet | 1 jour |