Modèle de coffre AIOps Orienté Agents

Compétence Compagnon du Coffre AIOps

Cette compétence est une couche procédurale. Elle ne contient pas les actifs courants de l'utilisateur. Les faits actuels résident dans le coffre AIOps local, normalement $AIOPS_ROOT ou ~/ai-ops.

Contrat de source de vérité

Utilisez cette répartition :

• README.md : règles locales stables, rôles des fichiers, limites de sécurité et conventions spécifiques au projet.
• resources.md : état actuel à considérer comme fiable maintenant.
• maintenance-log.jsonl : historique en ajout uniquement des décisions, maintenances, vérifications, incidents et corrections.
• secrets-location.md : noms des secrets, emplacements de stockage, notes d'accès/rotation uniquement ; jamais les valeurs secrètes.
• services/<service>/service-card.md : runbooks et détails par service lorsque le fichier de ressources central deviendrait trop volumineux.
• scripts/aiops.py : interface de commande basse consommation en tokens pour le coffre.

Ne déduisez pas l'infrastructure actuelle de cette compétence. Lisez le coffre et inspectez l'état réel là où c'est sûr.

Ordre de lecture par défaut

1. Résolvez le chemin du coffre : $AIOPS_ROOT si défini, sinon ~/ai-ops.
2. Lisez d'abord le README.md local du coffre si la tâche peut modifier des fichiers, services, expositions, identifiants ou sauvegardes.
3. Exécutez la couche de commande avant les lectures complètes :
   • python3 "$AIOPS_ROOT/scripts/aiops.py" index
   • python3 "$AIOPS_ROOT/scripts/aiops.py" resources --section "<section>"
   • python3 "$AIOPS_ROOT/scripts/aiops.py" service "<nom>"
   • python3 "$AIOPS_ROOT/scripts/aiops.py" host "<nom>"
   • python3 "$AIOPS_ROOT/scripts/aiops.py" log --tail 20 --summary
4. Lisez l'intégralité de resources.md, les fiches de service ou les lignes de journal uniquement lorsque la sortie découpée est insuffisante.
5. Utilisez l'historique de session uniquement lorsque l'état en direct et la documentation du coffre ne peuvent pas répondre à la question.

Limites de sécurité

• Ne lisez, n'imprimez, ne copiez ni ne stockez les valeurs secrètes. secrets-location.md est une métadonnée, pas un vidage de secrets.
• N'écrivez pas de secrets dans resources.md, les journaux, les fiches de service, les invites, les commentaires de tickets, les commits ou les résumés de chat.
• Confirmez avant les opérations irréversibles ou à haute exposition : suppression, écrasement, rotation, restauration, ouverture de ports publics, modification DNS, migration de données, désactivation de sauvegardes ou intervention sur des ressources tierces/appartenant à des amis.
• Gardez les pools de ressources explicites. N'intervenez pas sur l'infrastructure tierce ou appartenant à des amis sauf si l'utilisateur autorise spécifiquement cette cible.
• Préférez la moindre exposition : localhost derrière un proxy inverse ou réseau privé pour les chemins d'administration ; HTTPS public uniquement lorsque prévu et authentifié.

Flux de maintenance

1. Classez la cible : hôte, service, domaine/DNS, proxy inverse, donnée/sauvegarde, emplacement de secret, automatisation ou coffre lui-même.
2. Identifiez le pool de ressources et la limite d'autorité.
3. Chargez le contexte courant minimal via aiops.py et les fiches de service.
4. Inspectez l'état réel avec des commandes sûres si nécessaire.
5. Planifiez la plus petite action réversible et signalez les étapes à haut risque.
6. Exécutez avec le moindre privilège.
7. Vérifiez avec une sortie réelle côté consommateur : vérification de santé, journal, requête HTTP, systemctl, docker ps, liste de sauvegarde ou équivalent.
8. Mettez à jour la bonne couche :
   • faits courants -> resources.md ou fiche de service ;
   • historique important -> un objet maintenance-log.jsonl ajouté ;
   • emplacements de secrets -> secrets-location.md sans valeurs ;
   • détails locaux au service -> README/fiche du service.
9. Si le changement améliore un flux de travail/outillage AIOps réutilisable plutôt que seulement des faits locaux privés, synchronisez la partie générique vers le dépôt modèle dans ~/projects/aiops-vault-template, exécutez ses tests/vérifications, puis commitez et poussez pour que les consommateurs en aval d'AIOS Kit reçoivent l'amélioration. Ne copiez jamais de ressources privées, journaux ou secrets dans le modèle public.
10. Exécutez python3 "$AIOPS_ROOT/scripts/aiops.py" check après les modifications du coffre.
11. Signalez les fichiers modifiés, commandes, vérifications, éléments ignorés/bloqués et suivis.

Règles de réécriture

• L'état actuel appartient à resources.md ou à une fiche de service, pas seulement dans le journal d'historique.
• L'historique appartient à maintenance-log.jsonl, un objet JSON valide par ligne.
• Les corrections doivent être de nouvelles entrées correction ou supersede ; ne réécrivez pas l'historique sauf si l'utilisateur demande une migration.
• Évitez de dupliquer le même fait entre README, ressources, fiches de service et journaux. Choisissez la couche propriétaire.
• Les preuves brutes volumineuses doivent résider sous evidence/ ou en dehors du coffre avec une référence de chemin.

Liste de vérification avant finalisation

• python3 "$AIOPS_ROOT/scripts/aiops.py" check réussit ou les échecs sont expliqués.
• Les fichiers JSONL se parsent.
• Aucune valeur secrète évidente n'a été ajoutée.
• Les changements d'état courant ne se limitent pas au journal de maintenance.
• Les affirmations dans la réponse sont étayées par des fichiers du coffre ou une sortie de commande en direct.
• Toute action à haut risque a été confirmée ou explicitement laissée comme étape proposée.

Si le coffre est manquant

Si aucun coffre AIOps n'existe et que l'utilisateur en souhaite un, installez le dépôt modèle ou créez la structure minimale :

ai-ops/
  README.md
  resources.md
  maintenance-log.jsonl
  maintenance-log.schema.md
  secrets-location.md        # privé, ignoré par Git
  secrets-location.example.md
  scripts/aiops.py

Exécutez ensuite python3 scripts/aiops.py check.