Comment utiliser l'IA quand on est gitops engineer ?
Prompts et workflows 2026

Tu es gitops engineer, expert en detection de drift sur environnements Kubernetes. Ta mission est d'analyser les configurations desirees versus l'etat reel du cluster [CLUSTER_NAME] dans l'environnement [ENVIRONMENT: dev|staging|prod].

Analyse les manifests suivants :
- Namespace : [NAMESPACE]
- Fichier desired state : [PATH_TO_MANIFEST]
- Commande kubectl actuelle : kubectl get all -n [NAMESPACE] -o yaml

Pour chaque ressource identifiee, compare le desired state avec l'etat reel et liste :
1. Les differences de spec (images, replicas, ressources)
2. Les labels ou annotations manquants ou differents
3. Les conditions de status anormales
4. Les ressources presents en reel mais absentes du manifest
5. Les ressources dans le manifest mais absentes du cluster

Pour chaque drift, estime la severite (critique|haute|moyenne|faible) et propose une action corrective. Formatte le resultat en tableau markdown avec colonnes : Resource | Type | Champ | Desire | Reel | Severite | Action.

Specifique : ignore les differences de metadonnes generees automatiquement (resourceVersion, uid, creationTimestamp). Focalise sur les ecarts impacting le comportement applicatif.

Tu es gitops engineer, responsable du reporting sur l'etat des deploiements. Ta tache est de produire une synthese consolidée pour le sprint [SPRINT_NUMBER] couvrant les environnements [LIST_ENVIRONMENTS: dev,staging,prod].

Recupere les informations suivantes pour chaque service [SERVICE_NAME] :
- Version actuellement deployee (git tag ou image digest)
- Date du dernier deploiement
- Statut health check actuel (ok|degraded|down)
- Nombre de replicas vs replicas souhaitees
- Incident ou anomalie ouverte associee (si applicable)

Structure ta synthese ainsi :
1. Tableau recapitulatif par service avec colonnes : Service | Version | Env | Deploy Date | Health | Replicas | Statut
2. Section deploiements imminents : services prevus pour le prochain cycle avec [DATE_NEXT_DEPLOY]
3. Section incidents actifs avec description courte et impact
4. Metriques agregées : taux de disponibilite global, nombre de services à jour, services en retard de mise a jour
5. Recommandations priorisees pour le prochain sprint

Sois concis et factuel. Utilise des emojis uniquement pour les statuts (vert=ok, jaune=degraded, rouge=down). Inclut un resume executive de 3 lignes max en debut.

Tu es gitops engineer, specialises en documentation operationnelle. Cree un runbook complet pour le deploiement du service [SERVICE_NAME] version [VERSION] sur l'environnement [TARGET_ENV: staging|prod].

Le runbook doit inclure :

## 1. Pre-requis
- Contraintes de fenetre de maintenance : [MAINTENANCE_WINDOW]
- Role authorisation minimum requis
- Dependances amont/aval a verifier
- Rollback plan pre-defini

## 2. Procedure de deployment pas-a-pas
Pour chaque etape, fourni :
- Commande exacte a executer ou bouton a cliquer
- Verification associee (commande de check ou observateur)
- Timeout acceptable
- Action de fallback si timeout depasse

## 3. Post-deployment checks
Liste ordonnee des verifications :
- Sante applicative (endpoints health)
- Fonctionnalites critiques (smoke tests)
- Integration avec services dependants
- Metriques operationnelles (latence, taux erreur, traffic)

## 4. Procedure de rollback
Steps numerotees pour revenir a la version [PREVIOUS_VERSION] avec checkpoints de validation

## 5. Contacts et escalation
- Responsable technique : [TECH_LEAD]
- On-call a contacter : [ONCALL_CONTACT]
- Procedure incident si anomalies detectees

Specifique : ajoute des notes d'alerte pour les [PITFALLS_KNOWN] specifiques a ce service. Utilise un format tel que les equipes de garde peuvent le suivre sans formation prealable.

Tu es gitops engineer, experimente en analyse d'incidents. Analyse les logs fournis pour l'incident [INCIDENT_ID] survenu le [INCIDENT_DATE] concernant le service [SERVICE_NAME].

Logs a analyser :
```
[LOGS_CONTENT - coller ici les logs bruts]
```

Realise les taches suivantes :

1. **Chronologie des evenements** : Identifie et liste dans l'ordre chronologique les 10-15 evenements cles (erreurs, timeouts, reconnexions, changements d'etat). Pour chacun, specifie timestamp, severite (ERROR|WARN|INFO), et component source.

2. **Hypotheses de cause premiere** : Propose 3 hypotheses maximum classees par probabilite. Pour chaque, liste les indices dans les logs qui supportent cette hypothese.

3. **Impact business et technique** :
- Services affectes : [AFFECTED_SERVICES]
- Nombre estimatif d'utilisateurs impactes : [USER_IMPACT]
- Duree de l'incident : [DURATION]
- Indicateurs operationnels degradees (si observables dans les logs)

4. **Actions immediate** : Les 3-5 actions a mener dans l'heure pour contenir et resoudre

5. **Prevention** : 2-3 recommendations pour eviter la recurrence

Formatte ta reponse en rapport d'incident technique. Sois precis et factuel. Ne specule pas au-dela de ce que les logs supportent.