L'ingénierie du chaos est facile à minimiser.
Si tout ce que vous entendez est "détruire aléatoirement des serveurs en production", cela semble irresponsable. Si tout ce que vous faites est d'arrêter un pod en staging, cela semble performatif.
Le juste milieu utile est le suivant :
Testez les modes de défaillance que votre architecture prétend tolérer.
La bonne question
Si la plateforme dit qu'elle est résiliente à travers les régions, les zones de disponibilité ou les répliques, vous devriez être en mesure de répondre :
- Qu'est-ce qui détecte la défaillance ?
- Qu'est-ce qui déclenche le basculement ?
- Quel état est perdu ou retardé ?
- Comment le trafic se déplace-t-il ?
- Comment les opérateurs savent-ils si cela a fonctionné ?
Si ces réponses n'existent que sur un diagramme, le système n'est pas encore prouvé.
Pourquoi les journées de simulation sont plus efficaces que le hasard
Les exercices de défaillance structurés sont généralement plus précieux que la perturbation aveugle.
Ils vous permettent de :
- définir une hypothèse
- choisir un rayon de détonation sûr
- capturer des métriques avant et après
- apprendre quelque chose d'actionnable
C'est bien meilleur comme boucle d'ingénierie que "casser des choses et espérer".
Commencez par de réelles dépendances
Pour la plupart des systèmes, les premières expériences utiles ne sont pas des attaques régionales dramatiques. Ce sont des pannes ciblées telles que :
- base de données primaire indisponible
- croissance de la file d'attente
- augmentation des délais d'attente pour les dépendances
- échec du DNS ou de la découverte de services
- une région marquée comme non saine
Ces tests révèlent si la logique de basculement est réelle ou simplement supposée.
L'objectif est la confiance, pas le théâtre
L'ingénierie du chaos est précieuse lorsqu'elle transforme les affirmations de résilience en comportements observés.
Si l'expérience vous apprend :
- quelle alerte se déclenche
- combien de temps la récupération prend
- si le système s'est dégradé en toute sécurité
alors elle a fait son travail.
Lectures complémentaires