Compétences incident-runbook-templates
📋

incident-runbook-templates

Sûr

Créer des runbooks de réponse aux incidents

Également disponible depuis: wshobson

Créez rapidement des runbooks de réponse aux incidents complets avec des modèles éprouvés. Réduisez le temps de résolution des incidents en fournissant des procédures étape par étape pour la détection, le triage, l'atténuation et la communication.

Prend en charge: Claude Codex Code(CC)
🥉 75 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "incident-runbook-templates". Créer un runbook pour une latence élevée de la passerelle API

Résultat attendu:

Généré un runbook complet de latence de passerelle API avec des étapes de détection (vérifier la latence p99, les taux d'erreur, la santé des services en amont), des procédures de triage (identifier les goulots d'étranglement, vérifier la latence des dépendances), des actions d'atténuation (activer la mise en cache, augmenter les délais d'attente, mettre à l'échelle les services en amont) et des étapes de vérification pour confirmer que la latence est revenue à la normale.

Utilisation de "incident-runbook-templates". Construire un runbook d'épuisement du pool de connexions de base de données pour PostgreSQL

Résultat attendu:

Généré un runbook de pool de connexions PostgreSQL avec des requêtes SQL pour identifier les connexions de longue durée, des étapes pour terminer les connexions inactives, des recommandations de réglage de configuration (max_connections, taille du pool) et des stratégies de prévention incluant les meilleures pratiques de mise en pool de connexions et des alertes de monitoring.

Utilisation de "incident-runbook-templates". Créer des modèles de communication pour une panne de traitement des paiements

Résultat attendu:

Généré trois modèles de communication : (1) Notification interne initiale avec classification de sévérité, évaluation de l'impact et attribution d'un commandant d'incident, (2) Modèle de mise à jour de statut avec progression de l'atténuation et ETA, (3) Message destiné aux clients avec description transparente de l'impact, temps de résolution estimé et excuses avec offre de compensation si applicable.

Audit de sécurité

Sûr
v1 • 2/25/2026

All 62 static findings are false positives from Markdown documentation. The skill contains only template documentation with code examples (bash, kubectl, SQL) in fenced code blocks. No executable code, no prompt injection attempts, and no security risks detected. Safe to publish.

1
Fichiers analysés
398
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
100
Conformité aux spécifications

Ce que vous pouvez construire

Ingénieur d'astreinte répondant à un incident SEV1

Un ingénieur d'astreinte reçoit une alerte PagerDuty à 3 heures du matin pour une panne complète de service. Il utilise cette compétence pour accéder rapidement au modèle de runbook de panne de service, qui le guide à travers la vérification du statut des pods, l'examen des déploiements récents et l'exécution d'un rollback si nécessaire.

Équipe SRE construisant une bibliothèque de documentation

Une équipe SRE établit son processus de gestion des incidents. Elle utilise cette compétence pour générer des runbooks standardisés pour différents services (traitement des paiements, base de données, passerelle API) assurant des procédures de réponse cohérentes dans toute l'organisation.

Startup établissant un processus de réponse aux incidents

Une startup en croissance doit documenter ses procédures de réponse aux incidents à mesure qu'elle se développe. Elle utilise cette compétence pour créer son premier ensemble de runbooks, définir des niveaux de sévérité et construire des modèles de communication pour les mises à jour des parties prenantes pendant les incidents.

Essayez ces prompts

Générer un runbook de panne de service
Créez un runbook pour une panne de service Redis cache. Incluez des étapes pour vérifier le statut des pods, l'utilisation de la mémoire et le nombre de connexions. Ajoutez des procédures de rollback.
Construire un runbook d'incident de base de données
Générez un runbook de base de données pour le retard de réplication MySQL. Incluez des requêtes pour vérifier le retard, identifier les requêtes lentes et des étapes pour promouvoir un réplica si nécessaire.
Créer une matrice d'escalade
Concevez une matrice d'escalade pour une plateforme e-commerce. Incluez des conditions pour les incidents SEV1-SEV4 avec les contacts appropriés pour les équipes d'ingénierie, juridique, finance et direction.
Générer des modèles de communication
Créez des modèles de communication destinés aux clients pour un incident de confidentialité des données. Incluez la notification initiale, la mise à jour et les messages de résolution qui satisfont aux exigences légales.

Bonnes pratiques

  • Personnalisez les modèles avec vos noms de service réels, canaux Slack, plannings PagerDuty et URLs de tableau de bord avant de les utiliser en production
  • Testez les procédures des runbooks pendant des game days ou des exercices de chaos engineering pour valider l'exactitude et l'exhaustivité
  • Mettez à jour les runbooks après chaque incident sur la base des leçons apprises et des nouvelles idées des postmortems
  • Incluez des étapes de vérification après chaque action d'atténuation pour confirmer que la correction a fonctionné avant de passer à l'étape suivante
  • Liez les tableaux de bord réels (Grafana, Sentry) et les runbooks dans vos outils de réponse aux incidents pour un accès rapide pendant les urgences

Éviter

  • Ne copiez pas les modèles sans personnaliser les espaces réservés (noms de service, commandes, contacts) pour correspondre à votre environnement
  • Ne sautez pas les étapes de vérification - confirmez toujours qu'une action d'atténuation a fonctionné avant de continuer
  • Ne travaillez pas en isolation pendant les incidents - utilisez la matrice d'escalade pour impliquer les équipes appropriées dès le début
  • Ne traitez pas les runbooks comme des documents statiques - examinez-les et mettez-les à jour trimestriellement ou après des changements majeurs d'infrastructure
  • Ne supposez pas que le contexte est préservé pendant les incidents - écrivez les étapes suffisamment clairement pour un ingénieur privé de sommeil à 3 heures du matin

Foire aux questions

Puis-je modifier ces modèles pour mon infrastructure spécifique ?
Oui, ces modèles sont conçus pour être personnalisés. Remplacez les noms de service, commandes, URLs et informations de contact par vos détails d'infrastructure réels.
Ces runbooks fonctionnent-ils avec n'importe quel fournisseur de cloud ?
Oui, les modèles sont indépendants du cloud mais montrent principalement des exemples Kubernetes. Adaptez les commandes pour les outils spécifiques AWS, GCP ou Azure selon les besoins.
À quelle fréquence dois-je mettre à jour mes runbooks ?
Mettez à jour les runbooks après chaque incident pour capturer les leçons apprises et examinez tous les runbooks trimestriellement pour vous assurer qu'ils reflètent votre infrastructure actuelle.
Puis-je les utiliser pour des incidents non-production ?
Oui, adaptez les niveaux de sévérité et les temps de réponse pour votre environnement. Pour le staging, envisagez d'utiliser les classifications SEV3-SEV4 et des temps de réponse plus longs.
Dois-je être un expert Kubernetes pour utiliser ces modèles ?
Des connaissances de base en Kubernetes sont utiles pour les modèles de panne de service, mais les concepts s'appliquent à toute infrastructure. Adaptez les commandes pour votre plateforme de déploiement.
Comment les intégrer avec mes outils de monitoring ?
Remplacez les URLs d'exemple de tableau de bord (Grafana, Sentry) et les exemples d'alertes par les URLs réelles de vos outils de monitoring et vos configurations d'alertes.

Détails du développeur

Structure de fichiers

📄 SKILL.md