Atlas est un outillage de diagnostic système. Il observe l’infrastructure, corrèle ce qu’il relève, en tire un diagnostic, et — dans des limites qu’il ne franchit pas seul — agit. En développement, non publié à ce jour.
Le problème
Diagnostiquer un incident sur une infrastructure, c’est presque toujours la même chose : se connecter à cinq machines, lancer vingt commandes, recouper des journaux, et reconstruire à la main un état que personne n’avait sous les yeux. Le travail est répétitif, il se fait sous pression, et c’est exactement dans ces conditions qu’on tape une commande de trop.
La supervision dit qu’il y a un problème. Elle ne dit pas lequel. Entre l’alerte et la cause, il reste un travail d’enquête, et c’est celui-là qu’Atlas outille.
Ce qui structure l’outil : séparer le savoir, l’accès et la décision
Un outil qui détient à la fois l’inventaire, les clés d’accès et le pouvoir de décider quoi exécuter est un outil dont la moindre erreur touche tout. Atlas est donc découpé en trois rôles, dans un sens unique :
- L’inventaire — la description déclarative des machines. Il ne se connecte à rien et n’analyse rien ; c’est la source de vérité, et chaque client détient la sienne.
- Atlas — le seul composant autorisé à se connecter aux machines. Il exécute des opérations d’un catalogue fermé, journalise chaque accès, et masque les données sensibles avant de rendre son compte rendu.
- Ce qui le pilote — l’outil d’audit ou la gestion de projet Karl. Ils demandent, ils ne touchent jamais un serveur, et ne détiennent aucune clé.
Ce découpage n’est pas de l’élégance d’architecte : c’est ce qui garantit que « demander un diagnostic » ne peut pas devenir « exécuter n’importe quoi ». Les opérations sont classées par niveau de privilège, et celles qui modifient un système sont refusées par défaut sur le canal de diagnostic — le refus est dans l’outil, pas dans la discipline de celui qui s’en sert.
Ce qu’il fait
- Observer — exécuter des sondes dont le format de sortie est un contrat versionné, pour que deux relevés à six mois d’écart restent comparables.
- Corréler — recouper l’état des machines avec les événements de supervision, plutôt que de les lire séparément.
- Diagnostiquer — remonter de l’alerte à la cause probable.
- Tracer — un journal d’accès unifié : qui a demandé quoi, sur quelle machine, et ce qui a été exécuté.
Atlas tourne dans ma propre infrastructure, et travaille sur les infrastructures que j’administre — il n’est pas installé chez le client. Il est multi-client par construction : mes propres serveurs y sont un parc comme un autre.
- PythonScripts d'administration et outillage.
- LinuxLe noyau et l'écosystème sur lesquels tout le reste repose.
- UbuntuDistribution Linux à support long ; le socle de la plateforme.
- ZaZabbixSupervision et alertes : disponibilité, disque, certificats, réplication.
- LXCConteneurs système : un service par conteneur, isolé, sauvegardé séparément.
- GitGestion de versions du code ; tout ce qui est écrit ici y passe.
La supervision telle qu’elle tourne aujourd’hui est sur Supervision & alertes ; l’infrastructure sur Infrastructure & hébergement.