Rédiger des mises à jour d’incident à partir d’une chronologie vérifiée

Fournissez une chronologie relue, indiquez ce qui reste inconnu et exigez l’approbation du responsable avant chaque publication client.

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. Comparez le brouillon aux cinq critères ci-dessous et conservez les échecs en relecture manuelle.

node --env-file=.env request.mjs incident.json incident-result.json

Télécharger request.mjs · Télécharger incident.json · Node.js · Clés d’accès aux modèles

Utiliser une chronologie vérifiée

Le fichier incident.json téléchargeable constitue le parcours principal complet : il contient déjà l’instruction et la chronologie fictive. Gardez-le inchangé au premier essai, y compris sa sortie en anglais. 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.

Comparer le brouillon enregistré aux faits fictifs

Télécharger les critères attendus. Ce fichier est une liste de relecture, pas une réponse du modèle ni une mesure automatique d’exactitude. Consignez réussite ou échec pour chaque critère à côté du brouillon :

1. Impact : certains exports de rapports échouent. Refusez une portée inventée, un nombre de clients, une panne de téléversement ou une perte de données ajoutés.
2. Cause : inconnue ou en cours d’analyse. Refusez toute cause affirmée, même une théorie interne plausible.
3. Action : l’équipe enquête et a suspendu le processus d’export concerné. Refusez une pause omise, une mesure de réduction, une réparation ou un rétablissement inventés.
4. Prochain point : 09:30 UTC désigne explicitement la prochaine communication. Refusez une promesse de rétablissement à cette heure ou l’absence de fuseau horaire.
5. Approbation : aucune publication, aucun envoi ni changement de statut. Conservez le brouillon localement jusqu’à validation de chaque phrase par le responsable d’incident.

Un champ manquant, une affirmation non étayée ou un critère échoué impose une relecture humaine. Réussir ces cas fictifs ne prouve pas la fiabilité pendant un incident réel.

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:05 UTC : certains exports de rapports échouent.
09:12 UTC : l’équipe enquête et a suspendu le processus d’export concerné.
09:30 UTC : prochaine mise à jour promise.
CAUSE RACINE : inconnue.

BROUILLON PRUDENT ILLUSTRATIF (pas une réponse enregistrée du modèle)
Certains exports de rapports échouent. Nous enquêtons et avons suspendu le processus d’export concerné. La cause reste inconnue. Nous publierons une nouvelle mise à jour avant 09:30 UTC.

INTERDIT
« Les exports 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.

Ensuite : adapter une intégration côté serveur

Après réussite de l’exercice téléchargeable, utilisez la même instruction dans un client autorisé construit à partir du guide de requête Serverless Inference. Remplacez [événements approuvés] par une chronologie relue, avec inconnues explicites et heure du prochain point. Reprenez les cinq critères et conservez l’entrée validée avec le brouillon. Ce parcours d’intégration est une alternative, pas un second prérequis au fichier d’exemple.

Questions fréquentes

Peut-il aussi écrire le postmortem ?

Il peut aider à organiser des éléments vérifiés, mais l’équipe d’incident doit garder l’analyse des causes et les engagements de correction.

Pourquoi indiquer l’heure de la prochaine mise à jour ?

Les clients doivent savoir quand ils auront de nouvelles informations, même si l’équipe ne connaît pas encore l’heure de résolution.