Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERForensique d'incident
POURDevOps et infra
POURÉquipes de devs
SERVICESPipe
SERVICESFiles
POURQUOI HOODYHTTP-natif
POURQUOI HOODYMultijoueur par défaut
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERForensique d'incident
POURDevOps et infra
POURÉquipes de devs
SERVICESPipe
SERVICESFiles
POURQUOI HOODYHTTP-natif
POURQUOI HOODYMultijoueur par défaut
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERForensique d'incident
POURDevOps et infra
POURÉquipes de devs
SERVICESPipe
SERVICESFiles
POURQUOI HOODYHTTP-natif
POURQUOI HOODYMultijoueur par défaut
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERForensique d'incident
POURDevOps et infra
POURÉquipes de devs
SERVICESPipe
SERVICESFiles
POURQUOI HOODYHTTP-natif
POURQUOI HOODYMultijoueur par défaut
Retour aux cas d'usage
PIPE · REJOUER UN INCIDENT

Rejoue l'incident de ce matin pour toute l'équipe

Il est 14h. Le post-mortem de l'incident de 7h commence. Six ingénieurs veulent suivre la séquence exacte de logs que le SRE d'astreinte a vue à l'instant T. vous streamez le snapshot via une seule URL Hoody Pipe avec ?n=8. Chacun voit la cascade défiler sur son terminal au même instant — pas de captures d'écran, pas de scroll désynchronisé, pas d'enregistrement Zoom.

Lire l'API pipe

Un snapshot. Un pipe. Six terminaux synchronisés.

Prends le fichier de logs au moment de l'incident depuis votre snapshot hoody-files. Streame-le via un chemin Hoody Pipe avec ?n=8. Huit ingénieurs curl le même chemin. Le pipe attend que tout le monde soit connecté, puis les bytes traversent une fois au rythme que vous choisissez — chaque lecteur voit la même ligne au même instant.

post-mortem.host · sender
PUT · replay
# L'incident de 7h est capturé dans incident-2026-05-04.log
# (snapshotté depuis /var/log/app à 07:25 par le SRE d'astreinte).
# Rejoue-le via un chemin pipe avec ?n=8 — le serveur attend
# que huit lecteurs se connectent, puis les bytes traversent une fois.
# pv -L 50k limite le replay à un débit lisible de 50KB/s.

cat incident-2026-05-04.log \
  | pv -L 50k \
  | curl -T - \
      "https://prod-pipe.node-us-1.containers.hoody.com/api/v1/pipe/replay?n=8"

# [INFO] Waiting for 8 receiver(s) to connect...
# [INFO] Streaming to 8 receiver(s) at 50.0 KB/s
8 lecteurs connectés · le pipe ne stocke rien · les bytes passent une fois
alex / ben / chen / dani / ev / fox / deux autres · readers
GET · synchronisé
# Chaque ingénieur de l'appel post-mortem lance la même ligne.
# Ils bloquent tant que tout le monde n'a pas rejoint, puis la cascade
# défile sur leur terminal au rythme exact que le SRE a vu à 07:23.

curl "https://prod-pipe.node-us-1.containers.hoody.com/api/v1/pipe/replay?n=8"

# 07:23:14 INFO POST /v1/checkout u_28f
# 07:23:15 WARN stripe latency 2.4s
# 07:23:16 ERR  500 stripe timeout
# 07:23:17 ···  auto-rollback armed
# ...toute la cascade, dans l'ordre, sur chaque terminal en même temps.

Deux morceaux de l'API Pipe documentée : PUT /api/v1/pipe/[path] côté sender, GET /api/v1/pipe/[path] côté chaque lecteur, tous deux indexés par le même n. Le serveur forwarde le Content-Type du sender, garde la connexion ouverte jusqu'à un TTL de 5 minutes en attendant les lecteurs, et applique de la backpressure si un seul lecteur traîne. Le débit du replay est entièrement fixé par le sender — pv, dd, ou n'importe quel rate-limiter de confiance.

Ce que regarder ensemble fait qu'un doc ne peut pas faire

Un flux qui défile change la conversation. Les gens arrêtent de débattre de ce qui s'est passé et commencent à regarder ce qui s'est passé. Trois propriétés du pipe rendent ça possible.

MULTIJOUEUR PAR DÉFAUT

Six terminaux sur la même tête de lecture

n=N est documenté dans l'API Pipe : chaque lecteur qui rejoint le même chemin avec le même n reçoit une copie identique en fan-out. Huit ingénieurs voient la même ligne défiler au même instant — personne n'est en avance, personne ne plisse les yeux sur le screenshare d'un autre.

DÉBIT PILOTÉ PAR LE SENDER

Replay assez lent pour être lu

Les vrais logs prod défilent plus vite que les humains absorbent. pv -L 50k throttle le replay à un rythme lisible ; le pipe transporte ce que le sender choisit. vous pouvez mettre le post-mortem en pause avec ctrl-Z sur le sender et reprendre avec fg — tous les terminaux des lecteurs se mettent en pause avec vous.

ÉPHÉMÈRE PAR DÉFAUT

Le replay finit, le pipe disparaît

Le pipe stocke zéro byte. Quand le cat se termine ou que le SRE ctrl-C le sender, le chemin se ferme — pas d'endpoint résiduel exposé sur Internet, pas de transcript à gérer en rétention. Relancez-le depuis le snapshot pour ceux qui ont rejoint l'appel en retard.

Comment se déroule une session de replay

Quatre temps depuis les logs au moment de l'incident jusqu'à la lecture partagée du post-mortem. Rien ici n'est de l'infra custom — le snapshot vit dans hoody-files, le replay roule sur une URL Pipe.

  1. 0107:25

    Snapshot des logs

    Le SRE d'astreinte copie /var/log/app à 07:25 dans un bucket hoody-files. Le fichier est la source de vérité pour tout ce qui s'est passé pendant la fenêtre de cascade.

  2. 0213:55

    Ouvrez la salle de réunion

    Le lead écrit une URL Hoody Pipe avec ?n=8 (six ingénieurs + deux retardataires de marge) et la colle dans le canal post-mortem. Les receivers peuvent se connecter d'abord — le pipe garde le slot jusqu'à 5 minutes.

  3. 0314:00

    Appuyez sur play

    Le SRE pipe le snapshot via pv -L 50k vers l'URL. Le serveur attend que huit curls soient connectés, puis les bytes traversent une fois en synchronisation — la cascade s'allume sur six terminaux au même instant.

  4. 0414:18

    Replay pour les retardataires

    Le directeur arrive en retard. Relancez la même ligne. Le pipe est un chemin, pas un endroit — rien à seek, rien à rembobiner, rien stocké sur le serveur. Appuyez juste sur play à nouveau.

Quelle taille peut atteindre la salle ?

D'après la spec API Pipe documentée. Limites et comportements qui transforment une URL unique en théâtre de post-mortem.

  1. LECTEURS PAR CHEMIN256

    Cap documenté sur n. votre appel post-mortem ne manquera pas de places — le pipe scale à toute une org.

  2. BYTES STOCKÉS0

    Le pipe est en stream direct end-to-end. Le replay ne laisse aucune trace sur le serveur quand le sender se déconnecte.

  3. FENÊTRE DE CONNEXION5 min

    Les receivers peuvent se connecter avant le sender ; le pipe garde le slot jusqu'à 5 minutes pour les retardataires.

Source : Hoody Pipe API — limites documentées pour /api/v1/pipe/[path], paramètre n (1–256), et TTL des pipes non établis.

Le post-mortem n'est pas un doc. C'est un flux que tout le monde regarde ensemble.

pas de scroll désynchronisé · pas de squint sur un screenshareune URL · huit curls · une tête de lecture
POST-MORTEMhieraujourd'hui
  • ARTÉFACTDoc Confluence avec captures d'écranhttps://prod-pipe.../pipe/replay
  • SYNCchacun scrolle à son rythmelecture synchronisée pour n=8
  • RÉTENTIONle PDF survit pendant des annéesctrl-C et le pipe disparaît
  • REPLAYplanifier un second Zoomrelancer le même curl
Lire l'API pipe

Ce que ça remplace

L'ensemble des outils et rituels que vous invoquez pour faire suivre à une équipe la chronologie d'un incident. Chacun stocke quelque chose, facture par siège, ou perd le timing. Le pipe est une URL avec une tête de lecture partagée.

  • Doc post-mortem ConfluencePage statique avec captures d'écran périmées
  • Rapport d'incident NotionListe à puces, aucune synchronisation temporelle
  • Captures collées dans SlackPerd l'ordre et le timing de la cascade
  • Sessions manuelles de replay-the-logsUne personne scrolle, le reste plisse les yeux
  • Timeline Zoom enregistréeChacun scrub à son rythme
  • Annotations notebook DatadogLicence par siège, pas de tête de lecture partagée

La cascade s'allume sur six terminaux à la fois. La conversation change. Les gens arrêtent de débattre de ce qui s'est passé et commencent à regarder ce qui s'est passé.

Lire l'API pipe

Lis les autres