CapordiaEspace client Décrire l’impact avant de proposer une cause
Donnez une phrase observable : certains travaux ne produisent plus de sortie, un accès autorisé est refusé ou un export ne peut plus être relu. Précisez le périmètre touché et ce qui continue à fonctionner. « Le serveur est en panne » devient vite une conclusion trop large lorsque seul un chemin de sortie échoue. Comptez les résultats acceptés, incomplets et non lancés avec des catégories exclusives.
Nommez un responsable de coordination et une personne autorisée à intervenir. Le guide de gestion d’incidents de Google SRE distingue la coordination des opérations et de la communication. Dans une petite équipe, une personne peut tenir plusieurs rôles, mais chacun doit savoir qui décide. Fixez le prochain point d’information en interne ; cette organisation ne crée aucun délai de réponse garanti du fournisseur.
Conserver une chronologie qui distingue les faits
Relevez la dernière situation connue correcte, le premier symptôme et les modifications intervenues entre les deux. Donnez le fuseau horaire et l’origine de chaque heure : journal, observation directe ou souvenir à confirmer. Une date copiée dans une capture n’a pas forcément le même référentiel que le journal de l’application. Si une borne manque, conservez l’intervalle d’incertitude plutôt que d’inventer une minute précise.
Pour chaque action, notez l’auteur, le périmètre, l’objectif et le résultat. « Redémarrage effectué » est incomplet sans savoir quel processus a été concerné et si le symptôme a changé. Gardez séparés observation, hypothèse et décision. Cette séparation permettra de reconstruire ce qui a réellement aidé et d’éviter que plusieurs personnes essaient simultanément des remèdes incompatibles.
Exemple fictif : un export partiel, pas une panne GPU démontrée
Dans la cellule fictive « Cartes du rivage », vingt documents doivent être livrés. Quatorze sorties ont été ouvertes et acceptées, quatre travaux signalent un refus d’écriture et deux restent à lancer. Six résultats ne sont donc pas encore livrables, mais il serait faux d’annoncer vingt résultats perdus. Aucun incident réel ni serveur Capordia n’est décrit par cet exemple.
La chronologie ci-dessous conduit à demander un examen ciblé du chemin de sortie. Elle ne démontre pas encore la cause : le changement proche dans le temps peut être lié au symptôme sans l’expliquer. L’équipe conserve les quatorze sorties acceptées et suspend seulement les nouvelles soumissions concernées. Les heures sont fictives et appartiennent au même fuseau, choisi pour éviter toute ambiguïté de lecture.
| Heure | Fait consigné | Interprétation permise |
|---|---|---|
| 9 h 40 | Dernière sortie ouverte avec succès | Borne de fonctionnement connue |
| 9 h 42 | Destination de sortie modifiée | Changement à examiner |
| 9 h 43 | Premier refus d’écriture consigné | Début observé du symptôme |
| 9 h 48 | Nouvelles soumissions concernées suspendues | Mesure de limitation de l’impact |
| 10 h 05 | Même refus avec un petit fichier fictif | Reproduction plus petite, cause à confirmer |
Réduire la reproduction sans effacer le défaut
Cherchez la plus petite entrée qui conserve le symptôme et le même chemin pertinent : type de fichier, destination, identité technique ou réglage. Remplacez le contenu métier par des données synthétiques lorsque c’est possible. Si la substitution fait disparaître l’erreur, documentez cette limite. Ne présentez pas comme reproduction fidèle une commande simplifiée qui ne traverse plus la partie suspecte.
Procédez par hypothèses vérifiables. Le chapitre de dépannage Google SRE recommande des tests permettant de départager les causes et rappelle que l’instrumentation ou les essais peuvent influencer le système. Notez donc le résultat négatif aussi soigneusement que le succès. Évitez de relancer en boucle un traitement qui publie des sorties ou aggrave le stockage ; le responsable fixe d’abord le périmètre de l’essai autorisé.
Préparer des preuves lisibles et expurgées
Le dossier de transmission contient les versions utiles, la procédure minimale, les heures, le message d’erreur exact et un extrait de journal autour du symptôme. Ajoutez l’identifiant de travail et la référence du dossier concerné lorsque cela facilite le rapprochement. Écartez le reste des journaux si personne n’en a besoin pour comprendre la situation. Conservez les originaux dans le périmètre autorisé de l’équipe.
OWASP rappelle que les journaux ne doivent pas exposer notamment mots de passe, jetons d’accès ou clés. Relisez aussi les chemins, noms de fichiers et arguments qui peuvent révéler le projet. Utilisez des remplacements cohérents, comme PROJET_A, tout en gardant la structure nécessaire au diagnostic. Une preuve expurgée doit annoncer ce qui a été retiré ; elle ne doit ni modifier le message d’erreur décisif ni faire disparaître une condition importante.
Formuler une demande d’escalade qui permet d’agir
Ouvrez la demande par l’impact et la question précise : examiner un refus d’accès, confirmer une propriété de l’allocation ou aider à localiser un écart reproductible. Joignez la chronologie et la reproduction expurgée. Indiquez les actions déjà tentées, celles qui n’ont rien changé et les opérations à éviter. Le destinataire doit pouvoir savoir ce qui est attendu sans explorer un dossier de captures non commentées.
Dans l’exemple, la demande peut être : « Le chemin de sortie nouvellement utilisé refuse l’écriture sous l’identité du traitement ; merci d’examiner les droits applicables à ce chemin. Quatorze sorties restent validées ; quatre travaux ont signalé un refus d’écriture, et ce refus a été reproduit avec une entrée fictive. » Ce texte n’accuse pas le GPU ni un opérateur. Il expose ce qui est connu et laisse la cause ouverte jusqu’à son examen.
Vérifier le retour avant de clôturer
Une erreur qui ne se reproduit plus ne suffit pas toujours. Vérifiez un résultat complet avec la même identité, les mêmes conditions décisives et une destination relue. Contrôlez ensuite les éléments touchés : les sorties déjà acceptées sont-elles conservées, les sorties partielles isolées et les travaux restants correctement identifiés ? Le responsable des résultats doit confirmer la reprise utile, distinctement de la réussite d’une commande technique.
Une migration est un changement organisé avant le déplacement du travail ; l’incident commence par un écart inattendu. Si sa résolution impose de déplacer les données ou de reprendre un traitement interrompu, utilisez alors le dossier de migration existant pour cette opération. La chronologie d’incident conserve la raison de cette décision ; elle ne réécrit pas la méthode de bascule ou le registre des lots.
Garder une conclusion exploitable, même si la cause reste ouverte
Clôturez avec l’impact final, le résultat de vérification, la cause démontrée ou encore inconnue et les actions décidées. Un contournement peut rétablir un résultat sans résoudre le problème de fond : dites-le clairement et nommez son responsable de suivi. Une absence de preuve ne doit pas devenir « aucun incident » ; une ressemblance avec un cas ancien ne doit pas devenir une cause certaine.
La relecture finale doit permettre à une autre personne de distinguer ce qui a été observé, ce qui a été tenté et ce qui reste à vérifier. Elle sert à améliorer une procédure, un contrôle ou un message d’erreur, pas à fabriquer un récit sans incertitude. Aucun nombre de captures, volume de journal ou niveau d’urgence ne remplace cette qualité de transmission.
Questions pour décider
Faut-il attendre de connaître la cause pour signaler un incident ?
Non. Signalez un impact vérifiable et le périmètre connu, puis séparez clairement les hypothèses. Une chronologie et une reproduction ciblée permettent souvent d’aider avant que la cause soit démontrée. Indiquez aussi les mesures déjà prises pour limiter l’impact.
Puis-je envoyer tous mes journaux pour gagner du temps ?
Préparez d’abord les extraits utiles et relisez-les. Des journaux complets peuvent contenir secrets et données de projet sans aider le diagnostic. Gardez les originaux dans un espace autorisé et expliquez les remplacements effectués dans la version transmise.
Quand considérer le dossier comme clos ?
Après un contrôle du résultat attendu et une décision explicite du responsable. Distinguez réparation confirmée et contournement temporaire. La clôture peut conserver une cause inconnue, à condition de nommer les limites, le contrôle réalisé et les actions restant ouvertes.