devops-troubleshooter
Déboguer Rapidement les Incidents de Production
Diagnostiquez et résolvez rapidement les incidents de production avec le débogage guidé par l'IA, l'analyse de journaux et des méthodologies de dépannage systématiques.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "devops-troubleshooter". Mes pods Kubernetes subissent fréquemment des OOMKilled. Les limites de mémoire sont définies à 512Mi mais l'application utilise Java.
Résultat attendu:
Ceci est un problème courant de Java sur Kubernetes. La mémoire heap JVM n'est qu'une partie de l'empreinte mémoire. Voici mon évaluation :
**Actions Immédiates :**
1. Vérifier l'utilisation réelle de la mémoire : `kubectl top pods`
2. Examiner les flags JVM : Assurez-vous que -Xmx est défini de manière appropriée (typiquement 50-75% de la limite du conteneur)
3. Envisager de définir la mémoire JVM pour correspondre aux limites du conteneur en utilisant l'API downward de Kubernetes
**Cause Racine :** Le processus Java utilise heap + metaspace + stacks de thread + mémoire native. Une limite de 512Mi avec les paramètres JVM par défaut causera des OOMKills.
**Correction Recommandée :**
```yaml
resources:
limits:
memory: "1Gi"
env:
- name: JAVA_OPTS
value: "-XX:MaxRAMPercentage=75.0 -XX:+UseG1GC"
```
**Prévention :** Ajouter des alertes d'utilisation de mémoire au seuil de 80%.
Utilisation de "devops-troubleshooter". Nous observons des erreurs 504 intermittentes de notre load balancer. Les services backend semblent sains.
Résultat attendu:
Cela pourrait être causé par plusieurs facteurs. Laissez-moi vous guider à travers les étapes de dépannage :
**Investigation Immédiate :**
1. Vérifier les temps de réponse backend : `curl -w '%{time_total}' http://backend/health`
2. Examiner les journaux d'accès du load balancer pour les motifs de timing
3. Vérifier l'accumulation de files d'attente de connexion
**Causes Courantes :**
- Backend prenant trop de temps à répondre (vérifier les requêtes de base de données lentes)
- Paramètres d'expiration d'inactivité trop agressifs
- Mauvaises configurations de keep-alive entre le load balancer et les backends
- Délais de poignée de main TLS
- Vérifications de santé interférant avec le trafic
**Prochaines Étapes :**
1. Activer la journalisation détaillée sur le load balancer
2. Ajouter des métriques personnalisées pour les percentiles de latence backend
3. Vérifier si le problème corrèle avec des motifs de requête ou des heures spécifiques
Souhaitez-vous que je vous aide à enquêter sur l'un de ces domaines spécifiques ?
Audit de sécurité
SûrPrompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected 0 security issues. This is a pure text-based skill that provides debugging guidance through structured prompts. No risk factors present.
Score de qualité
Ce que vous pouvez construire
Réponse aux Incidents de Production
Obtenez une aide immédiate pour diagnostiquer et résoudre les pannes de production, de l'évaluation initiale à l'analyse de la cause racine.
Débogage de Cluster Kubernetes
Dépannez les échecs de pods, problèmes de réseau, problèmes de service mesh et contraintes de ressources dans les environnements Kubernetes.
Optimisation des Performances
Identifiez les goulots d'étranglement de performance grâce à l'analyse de journaux, la corrélation de traçage distribué et des recommandations de profilage système.
Essayez ces prompts
Mon service de production rencontre [décrire le problème : latence élevée/erreurs/panne]. Je dispose de [décrire les données disponibles : journaux de X, métriques de Y]. Aidez-moi à diagnostiquer la cause racine.
J'ai un pod Kubernetes dans [état CrashLoopBackOff/Running] avec les événements suivants : [coller la sortie kubectl describe]. Les journaux affichent : [coller les journaux pertinents]. Que dois-je enquêter ?
Je vois ce motif d'erreur dans mes [journaux ELK/Loki/cloud] : [coller les messages d'erreur et horodatages]. L'erreur a commencé [quand]. Aidez-moi à corréler ces journaux et identifier la cause racine.
Nous avons eu un incident où [décrire l'incident]. Chronologie : [coller la chronologie]. Les systèmes suivants ont été affectés : [liste]. Quels problèmes systémiques ont contribué à cet échec et comment pouvons-nous prévenir la récurrence ?
Bonnes pratiques
- Toujours rassembler les journaux, métriques et état du système avant de former des hypothèses pour éviter les mauvais diagnostics
- Commencer par l'explication la plus simple et escalader vers des causes complexes uniquement lorsqu'elles sont écartées
- Documenter toutes les étapes d'investigation et les résultats pour le postmortem et le partage de connaissances
Éviter
- Apporter des modifications aux systèmes de production sans d'abord reproduire le problème dans un environnement contrôlé
- Ignorer les messages d'erreur et symptômes qui semblent sans rapport avec le problème principal
- Se concentrer sur les symptômes plutôt que sur la cause racine, menant à des correctifs temporaires qui échouent plus tard