Débranchez tout. Actionnez le killswitch. Ces instincts fonctionnent lorsque vous êtes devant une machine unique. Ils échouent lorsque votre système d'IA s'étend sur cinquante nœuds répartis dans trois zones de disponibilité. La plupart des équipes d'ingénierie l'apprennent à leurs dépens. Elles mettent à jour une base de données centrale, passent un booléen de true à false, et supposent que le système s'arrête. Ce n'est pas le cas. La base de données semble propre. Le service est toujours en cours d'exécution.
L'illusion de l'interrupteur unique
Imaginez un contrôleur qui enregistre une révocation à l'epoch 12. Il écrit le changement dans un stockage persistant et pousse un soupir de soulagement. Pendant ce temps, le Worker B fonctionne sur une autorisation mise en cache provenant de l'epoch 11. Le worker n'a jamais reçu la note. Trente secondes plus tard, il lance une tâche d'inférence de modèle, démarre un cluster de GPU ou appelle une API externe. Le journal d'audit indique que l'accès a été révoqué. L'action a tout de même eu lieu.
C'est l'écart entre la persistance et la propagation. Une écriture en base de données n'est pas un état système. C'est une ligne dans une table, et de nombreux acteurs de votre système ne consultent jamais cette table au moment précis où ils le devraient. Si vous traitez un arrêt d'urgence comme un interrupteur de lumière, vous découvrirez que l'obscurité n'arrive jamais dans certains recoins de la pièce.
La dure réalité des systèmes distribués
Vous devez concevoir pour la panne. Pas pour une panne occasionnelle. Pour des pannes constantes, désordonnées et indépendantes. Des workers redémarrent au milieu d'une tâche. Des consommateurs de files d'attente accusent un retard de plusieurs minutes. Des services d'autorisation renvoient des données obsolètes parce qu'une réplique est bloquée. Des messages sont dupliqués. Des messages disparaissent. Des messages arrivent dans le désordre. Votre démon NTP dérive, et soudain, un nœud pense avoir dix secondes de retard sur les autres. Les horloges font des erreurs, et vous ne pouvez pas vous fier à l'heure réelle pour ordonner des événements à travers différentes limites.
Si votre protocole d'urgence suppose des réseaux fiables, une livraison de messages ordonnée ou des horloges synchronisées, vous n'avez pas un protocole. Vous avez un vœu pieux. Les workers, les consommateurs de files d'attente et les services d'autorisation tombent en panne de manière indépendante. Vos règles de sécurité doivent tenir bon, même lorsque l'infrastructure semble activement hostile.
Cinq règles qui fonctionnent réellement
La sécurité provient d'invariants qui survivent au chaos. Voici les règles qui empêchent une révocation de devenir une fiction.
Aucune action ne commence avec un epoch d'autorisation inférieur à l'epoch de révocation.
C'est votre garde-fou principal. Chaque octroi de permission porte un numéro d'epoch. Chaque révocation en porte un plus récent. Avant qu'un worker n'agisse, il compare les numéros. Si l'autorisation du worker est plus ancienne que la dernière révocation qu'il a vue, le worker s'arrête. Les epochs vous fournissent une horloge logique qui ne dépend pas de l'horloge système. Un worker détenant l'epoch 11 doit refuser de commencer le travail dès qu'il apprend que l'epoch 12 a révoqué l'autorité sous-jacente.
Les autorisations mises en cache expirent dans un délai imparti.
Une permission ne doit jamais vivre éternellement en mémoire. Les workers doivent revalider ou abandonner leurs droits après un intervalle délimité. Sans cela, un nœud qui se déconnecte pourrait se réveiller des jours ou des semaines plus tard et s'exécuter en utilisant une autorisation fossilisée. Définissez un bail. Appliquez-le strictement. Le temps devient votre équipe de nettoyage automatique.
Un redémarrage du système ne peut pas diminuer un epoch sauvegardé.
La persistance est cruciale. Si un contrôleur plante et redémarre, il doit récupérer l'epoch le plus élevé qu'il ait jamais émis. Revenir à un epoch plus ancien ressusciterait des permissions révoquées, comme si l'arrêt d'urgence n'avait jamais eu lieu. Stockez l'epoch de manière durable avant de le diffuser. Utilisez un journal d'écriture (write-ahead log), un fsync confirmé ou un groupe de consensus répliqué. L'histoire ne fait que progresser.
Doublons de rév