Diapositives

Conception de présentation de télémétrie d’incident

Incident Telemetry — Operation Halcyon transforme une panne d’exécution illustrative en un briefing structuré permettant de retracer les causes, les risques et les décisions.

OpenDesignDistribution du modèle
Officiel

Distribué dans la bibliothèque de la communauté OpenDesign, avec des recommandations de conception attribuées à Taste Skill by Leonxlnx.

Jeu de diapositives sur la télémétrie de l’incident Operation Halcyon et la décision de refonte du résolveur11 diapositives
Couverture noire du rapport d’incident avec un 04 blanc surdimensionné, des marques de curseur rouges, le titre complet Incident Telemetry—Operation Halcyon et des métadonnées opérationnelles à chasse fixe.
Couverture du rapport d’incidentCapture d'écran 1 sur 11

Cas d’usage des briefings d’incident

  • Briefings de réponse aux incidentsTransformez les preuves d’une panne en un récit décisionnel structuré.
  • Revues SRE et plateformeReliez la télémétrie, les risques opérationnels et les modifications proposées du résolveur.
  • Comptes rendus d’incident pour la directionPrésentez l’impact technique avant de demander une décision.
  • Communication post-mortemRéunissez les événements, les responsables, les preuves et les engagements de suivi.

Points forts du jeu de diapositives opérationnel

  • Récit en onze diapositivesPasse du briefing de mission à la validation finale.
  • Chronologie opérationnelleOrdonne les événements liés au fournisseur, au résolveur, aux alertes et au statut.
  • Chemins de défaillance et politiqueAssocie deux lignes de propagation des défaillances au texte de la politique proposée pour le résolveur.
  • Artefact de décisionSe termine par une demande de ratification datée et des responsables nommés.

Conception de présentation de télémétrie d’incident

Incident Telemetry — Operation Halcyon est un compte rendu de terrain en onze diapositives consacré à une panne d’exécution illustrative datée du 2026.05.13, de 03:18Z à 06:41Z. Son instruction « Read top to bottom » se reflète dans la séquence : briefing de mission, objectifs, télémétrie, risques, séquence des événements, comparaison des résolveurs, décision, extrait d’audit et validation finale.

Le jeu de diapositives utilise un fond noir, une typographie blanc phosphorescent et des accents rouges pour donner au contenu l’apparence d’une transmission opérationnelle interne. La couverture associe le titre de l’incident à des champs consacrés à la mission, à l’opérateur, au système, à la cellule et à la diffusion. Ce cadrage propose au public un document à examiner plutôt qu’une présentation générique, même si la densité des métadonnées rend aussi l’ouverture moins immédiatement lisible d’un coup d’œil.

OpenDesign distribue cet exemple groupé de la communauté, avec des recommandations de conception attribuées à Taste Skill by Leonxlnx. Cette attribution à la source en amont ne signifie pas que l’artefact a été créé indépendamment par OpenDesign. Les personnes, chiffres, noms de systèmes et le récit d’incident qu’il présente constituent un contenu de présentation illustratif, et non une panne vérifiée ou un plan opérationnel approuvé.

Contexte de la mission

La couverture mentionne Operation Halcyon, Q. Albrecht, Halcyon-Runtime, EU-West-3 et une diffusion interne, précisant ainsi à qui s’adresse le briefing et quel système il concerne.

Convention de lecture

La phrase « Eleven slides. No friendly icons. Read top to bottom. » instaure l’attente d’un récit séquentiel, privilégiant un compte rendu contrôlé au détriment d’une vue d’ensemble rapide.

Des briefings qui exigent des preuves et des actions

Ce format de présentation convient à une revue d’incident dans laquelle le public doit comprendre à la fois ce qui s’est produit et ce qui devrait changer. La deuxième diapositive présente la plage temporelle, le niveau affecté, les tâches abandonnées, le montant des remboursements, la cause racine, le délai de résolution et les actions ouvertes avant que le jeu de diapositives ne demande à quiconque de ratifier une refonte.

La conception est particulièrement utile lorsqu’un problème technique franchit plusieurs périmètres opérationnels. La source mentionne les clients de l’agent de recherche, un fournisseur DNS en amont, les intervenants d’astreinte, les remboursements, les tickets clients, les communications et l’auditabilité juridique. Le regroupement de ces préoccupations dans un seul récit aide le lecteur à suivre l’incident au-delà d’une métrique de service isolée, même si la densité exige un présentateur ou un lecteur disposé à progresser diapositive par diapositive.

  1. Commencer par le cadre de l’incident

    Utilisez une couverture pour établir le système, la plage temporelle de l’incident, l’opérateur, la diffusion et le statut du document avant de présenter les métriques.

  2. Distinguer les preuves de la réponse

    Placez la télémétrie observée et la chronologie des événements avant les seuils, les budgets de nouvelles tentatives, la pondération des fournisseurs et l’automatisation des remboursements proposés.

  3. Terminer par une décision délimitée

    Concluez par la décision demandée, l’échéance, les responsables, les témoins et le contexte de validation finale plutôt que par un résumé sans limite définie.

De la fenêtre de défaillance à la décision sur le résolveur

Le récit commence par l’impact et se resserre progressivement sur l’intervention. La diapositive des objectifs énonce cinq engagements, notamment réduire le seuil de basculement de 600 ms à 180 ms, pondérer de manière égale trois fournisseurs DNS indépendants et remplacer les boucles de nouvelles tentatives par des budgets. Chaque ligne associe une modification de politique à une échéance telle que 14D, 21D ou 30D, afin que le public puisse interpréter la réponse proposée comme un calendrier d’engagements plutôt que comme une collection d’idées.

La diapositive de télémétrie fait passer la lecture de la prose à un ensemble compact de mesures. Elle indique un taux de défaillance Tier-3 de 17,3%, comparé à une hausse de +14,6 points de pourcentage, un p99 du résolveur de 3180 ms avec une comparaison annoncée de 41x par rapport au niveau de référence, 68k nouvelles tentatives avec une amplification de x4,6 et 37 tickets clients avec une comparaison de 11x. La répétition du modèle libellé-valeur facilite le balayage visuel, mais les métriques restent un exemple de contenu de présentation, et non des performances de production vérifiées.

Le registre des risques ajoute ensuite la responsabilité et la probabilité au récit technique. « Single-provider DNS resolver pin » porte la mention CRIT, avec une probabilité de 0.42, et est attribué à Q.ALB, tandis que « Status page is a heatmap, not a sentence » porte la mention MED, avec une probabilité de 0.61, et est attribué à L.ARR. Ces lignes montrent que le jeu de diapositives considère les communications et l’infrastructure comme des risques liés, tandis que la compacité du tableau laisse inexpliquée la méthodologie de calcul des probabilités.

La séquence des événements inscrit la causalité dans le temps. Elle va d’enregistrements A obsolètes à 03:18:04Z aux nouvelles tentatives du résolveur à 03:19:11Z, puis à une tempête de nouvelles tentatives Tier-3 et à des alertes envoyées à quatre ingénieurs à 03:21:48Z, avant la première mise à jour publique du statut à 03:38:00Z et le basculement manuel à 04:01:22Z. Cet ordre permet au lecteur de distinguer le déclencheur, l’amplification, la réponse et le rétablissement au lieu de considérer toutes les métriques comme simultanées.

Déclencheur observé

Le fournisseur 04 renvoie des enregistrements obsolètes, donnant à la chronologie une condition de départ concrète.

Chemin d’amplification

La résolution épinglée et les nouvelles tentatives Tier-3 relient le problème du fournisseur à la hausse du p99, aux alertes et aux tâches abandonnées.

Contrôle proposé

Bien que le titre de la diapositive indique « before & after », les deux lignes du diagramme montrent des chemins de défaillance. La politique proposée à trois fournisseurs, le seuil de 180 ms et le budget de nouvelles tentatives figurent dans le paragraphe situé en dessous, et non dans un diagramme distinct de l’état ultérieur.

Conception visible et limites fonctionnelles

La source est un jeu de diapositives HTML en onze sections, parcouru par défilement vertical, avec des lignes de balayage CSS, des accents clignotants et un indicateur de santé pulsant plutôt qu’une pagination scriptée. Elle présente des diagrammes, des blocs de métriques, des lignes de risques, des chronologies, des extraits d’audit et une composition de validation finale. Elle ne confirme ni une télémétrie en direct, ni un résolveur connecté, ni des registres d’audit authentifiés, ni des remboursements automatisés, ni une approbation menée à terme. Les chiffres et le récit de l’incident restent des exemples de contenu.

Son système visuel est précis : Archivo Black structure les éléments d’affichage surdimensionnés tels que « DNS. », tandis que JetBrains Mono et IBM Plex Mono servent aux libellés, horodatages, enregistrements et champs opérationnels. Le spécimen surdimensionné crée une pause marquée avant la diapositive de décision, mais interrompt également le fil analytique ; conservez-le lorsque la présentation bénéficie d’une rupture de chapitre typographique, ou remplacez-le par une transition étayée par les sources lorsque chaque diapositive doit faire progresser l’argumentaire relatif à l’incident.

La capture large actuelle de la couverture inclut le titre complet de l’incident ; une ancienne capture étroite, désormais remplacée, le tronquait. Une autre limite subsiste sur la diapositive de décision : le glyphe RTFY surdimensionné chevauche le texte explicatif. Le récit d’exemple varie également d’une diapositive à l’autre : les remboursements sont qualifiés d’automatiques dans le résumé, mais de manuels ailleurs, tandis que le résumé recense sept actions ouvertes et que l’audit répertorie onze éléments d’action. Considérez-les comme des détails non harmonisés de la source, et non comme la preuve d’un registre opérationnel cohérent unique.

La diapositive 06 montre la séquence des événements, depuis les enregistrements DNS obsolètes jusqu’au basculement et à l’ouverture du post-mortem.
La diapositive 06 montre la séquence des événements, depuis les enregistrements DNS obsolètes jusqu’au basculement et à l’ouverture du post-mortem.

Comment créer une présentation de télémétrie d’incident dans OpenDesign

  1. Télécharger et installer OpenDesign

    Téléchargez l'application de bureau, installez-la et finalisez la configuration. Créez un projet pour votre design.

    Télécharger OpenDesign
  2. Structurer le récit de l’incident

    Définissez onze diapositives allant du contexte et de l’impact de l’incident aux engagements, à la télémétrie, aux risques, aux événements, aux chemins de défaillance, à une pause typographique, à la décision, à un extrait d’audit et à la validation finale. Séparez les deux lignes de propagation des défaillances de la politique proposée placée en dessous ; le diagramme fourni ne montre pas un état ultérieur mis en œuvre.

    Invite suggérée

    Créez une présentation de télémétrie d’incident en onze diapositives pour une panne d’exécution fictive. Utilisez du noir, un blanc phosphorescent, un rouge de danger, la police d’affichage Archivo Black et des libellés opérationnels à chasse fixe. Incluez une couverture, un résumé de l’impact, cinq engagements de réponse, des métriques, un registre des risques, une séquence horodatée, deux diagrammes de chemins de défaillance accompagnés d’un paragraphe distinct sur la politique proposée, une pause typographique DNS, une demande de décision, un extrait d’audit et la validation finale des responsables. Présentez clairement toutes les données comme illustratives, réservez un espace dégagé autour du glyphe de décision et ne laissez pas entendre qu’il s’agit de télémétrie en direct, de registres d’audit vérifiés ou de modifications du résolveur déjà mises en œuvre.

  3. Affiner la typographie et les états de décision

    Utilisez le spécimen DNS comme pause narrative, puis revenez aux horodatages, responsables, risques et entrées d’audit à chasse fixe. Maintenez le glyphe de décision à l’écart du texte explicatif. Harmonisez les statuts de remboursement, le nombre d’actions et les dates de l’exemple avant d’adapter le récit ; conservez une distinction visible entre une politique proposée, le texte de validation affiché et une décision réellement menée à terme.

  4. Exporter et obtenir un lien de partage

    Exportez votre design finalisé, puis utilisez Partager dans OpenDesign pour obtenir un lien de partage. Ouvrez le lien dans une fenêtre de navigateur distincte et vérifiez que la version souhaitée ainsi que ses ressources sont disponibles avant de l'envoyer.