3 articles tagués avec « reliability »

La conversation de pointe en IA a discrètement changé de sujet. Pendant deux ans, c'était « quel est le modèle le plus intelligent ? ». Aujourd'hui, ceux qui livrent réellement des systèmes agentiques posent une autre question : « que met-on autour du modèle ? »

Cette machinerie environnante porte un nom — le harnais. Le modèle est le moteur. Le harnais, c'est le châssis, la direction, la ceinture et les freins. Un moteur génial boulonné à rien vous tue au premier virage ; un moteur modeste dans une voiture bien conçue vous ramène à la maison à chaque fois. Sur le système d'information ktayl-solution — une plateforme Kubernetes à six nœuds qui fait tourner tout le SI d'un assureur simulé — j'ai passé des mois à construire le harnais qui permet à un agent IA de faire un vrai travail d'ingénierie sur une infrastructure en production sans que je retienne mon souffle.

Cet article, c'est ce harnais, concept par concept. Pas la théorie — les règles réelles que j'ai mises en place, pourquoi chacune existe, et l'incident qui l'a le plus souvent imposée.

En durcissant la reprise après sinistre du système d'information ktayl-solution, une question légitime s'est posée : on réplique déjà les sauvegardes vers Cloudflare R2 — alors pourquoi garder un serveur MinIO qui tourne sur le contrôleur ? Ne pourrait-on pas le retirer et passer full cloud ?

L'offre gratuite de R2 est généreuse, le stockage objet cloud est durable, et avoir un service de moins à exploiter est toujours séduisant. C'est donc un instinct raisonnable. C'est aussi faux — et environ une heure après m'être expliqué pourquoi, je l'ai prouvé à la dure en supprimant le mauvais préfixe de bucket. Cet article, c'est ce raisonnement, et l'incident bien réel qui l'a validé.

Une alerte de supervision s'est déclenchée : le watchdog de la plateforme était DOWN. En quelques minutes, le tableau devenait moche — le DNS du cluster refusait les connexions, et peu après, les volumes de stockage distribué ont cessé de se reconstruire. Une cascade de manuel.

Voici le post-mortem complet : comment la panne s'est propagée, pourquoi la cause évidente s'est révélée être un symptôme situé à trois niveaux de la racine, le correctif, et — surtout — la prévention livrée pour qu'elle ne puisse pas se reproduire de la même manière. Chaque changement évoqué ici est une pull request publique et vérifiable.

La plateforme en question — minicloud — est un environnement Kubernetes de qualité production tournant sur des ThinkPads reconditionnés, construite et opérée en solo comme simulation du système d'information d'une entreprise. Du bare-metal, aucun plan de contrôle managé, aucun filet de sécurité. C'est précisément pour cela qu'elle enseigne bien.