Rédiger des mises à jour d’incident à partir d’une chronologie vérifiée
Créer des brouillons d’état calmes et exacts à partir de faits confirmés tout en laissant le commandement d’incident aux commandes.
Utiliser une chronologie vérifiée
Ce guide prépare un exercice de rédaction d’incident. Configurez la requête Serverless Inference avec le guide lié avant l’exercice. Commencez par des faits fictifs ; ce guide ne connecte ni ne publie une page de statut.
Une mise à jour d’état doit venir d’horodatages confirmés, de l’impact client, des actions de réduction et de la prochaine heure de communication. Excluez spéculations, blâme interne, secrets et journaux inutiles aux clients.
Un responsable d’incident marque chaque fait comme confirmé, incertain ou rejeté. Le modèle reçoit seulement les faits confirmés et une mention explicite des inconnues.
- Exécutez l’exemple inoffensif du guide lié depuis un client côté serveur autorisé.
- Remplacez son message utilisateur par l’instruction de rédaction ci-dessous. Remplacez le champ des événements par la chronologie confirmée de l’exemple, avec la cause inconnue et l’heure du prochain point.
- Conservez le brouillon localement. Vérifiez chaque phrase et assurez-vous que 09:30 UTC désigne le prochain point, pas le rétablissement. Faites approuver le texte par le responsable ; publiez avec la procédure manuelle habituelle.
Demander un brouillon avec des limites strictes
Serverless Inference de DigitalOcean convient à une courte requête côté serveur durant un incident irrégulier. Chaque requête doit contenir tout le contexte approuvé, car le service ne conserve pas de session.
Gardez la clé d’accès dans un stockage de secrets côté serveur. Ne copiez jamais identifiants de production, liste de clients ou clé dans une invite.
Rédigez une mise à jour client en utilisant uniquement les faits confirmés ci-dessous. Incluez impact, action en cours et heure de la prochaine mise à jour.
Ne nommez pas une cause racine sans confirmation. Ne promettez pas d’heure de résolution. Si un champ est inconnu, dites qu’il est en cours d’analyse.
Chronologie confirmée : [événements approuvés]Faire de l’approbation une étape obligatoire
Le responsable d’incident vérifie chaque phrase contre la chronologie, puis publie par le processus normal. Le flux peut préparer un brouillon. Il ne doit rien envoyer, modifier ni fermer.
Conservez la chronologie approuvée et le texte final ensemble. Après l’incident, comparez les brouillons à la séquence réelle.
CHRONOLOGIE CONFIRMÉE
09:04 UTC : certains clients ne peuvent pas téléverser de fichiers.
09:12 UTC : l’équipe enquête.
09:30 UTC : prochaine mise à jour promise.
CAUSE RACINE : inconnue.
BROUILLON PRUDENT
Nous enquêtons sur un problème qui empêche certains clients de téléverser des fichiers. Notre équipe cherche à en comprendre la cause. Nous publierons une nouvelle mise à jour avant 09:30 UTC.
INTERDIT
« Les téléversements seront rétablis avant 09:30 UTC. »
« Le problème est causé par [théorie non confirmée]. »S’entraîner avant la prochaine panne
Faites un exercice à partir d’un incident passé, avec un fait qui change, une inconnue et une théorie interne trompeuse. Le brouillon doit rester honnête.
Acceptez le brouillon seulement si chaque affirmation correspond à la chronologie approuvée.
Exécuter l’exemple fictif
Installez Node.js 22 ou ultérieur sur votre ordinateur. Téléchargez le script et le fichier d’entrée ci-dessous dans un nouveau dossier privé. Dans le catalogue, choisissez un modèle texte compatible avec chat-completions et créez une clé limitée à ce modèle. Copiez son identifiant exact.
Créez un fichier .env avec un éditeur dans ce dossier. Sur la première ligne, écrivez DIGITALOCEAN_TOKEN= suivi de votre clé. Sur la seconde, écrivez DIGITALOCEAN_MODEL= suivi de l’identifiant du modèle. Gardez ce dossier hors d’un dépôt et ne partagez pas .env. Ouvrez un terminal dans ce dossier et lancez la commande. Chaque essai consomme des jetons facturés.
Ouvrez le JSON produit dans l’éditeur et lisez le champ draft. Cette proposition attend une relecture. Les erreurs HTTP, réponses vides ou tronquées font échouer la commande. Utilisez un nouveau nom de sortie pour un autre essai. Si vous demandez du JSON, analysez aussi le champ draft et refusez champs manquants, identifiants inconnus ou répétés, affirmations non étayées et catégories invalides. Conservez les échecs dans la liste de relecture manuelle.
node --env-file=.env request.mjs incident.json incident-result.jsonVérifier le résultat
- Résultat attendu
- Le responsable d’incident peut relier chaque phrase à un élément confirmé avant la publication normale.
- Arrêter si
- Arrêtez si le brouillon ajoute une heure de résolution, une cause racine, une liste de clients ou un détail interne absent de la chronologie.
- Étape suivante
- Conservez le brouillon approuvé avec la chronologie et utilisez les écarts pour améliorer le prochain exercice.