Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Containers·Snapshots
TypFreigeschaltetPhaseProduktionSchwierigkeitEinfachAufgabeIncident-ForensikFürDevOps & InfraFürDev TeamsServicesPipeServicesFilesWarum HoodyHTTP-nativWarum HoodyMultiplayer von Haus aus
TypFreigeschaltetPhaseProduktionSchwierigkeitEinfachAufgabeIncident-ForensikFürDevOps & InfraFürDev TeamsServicesPipeServicesFilesWarum HoodyHTTP-nativWarum HoodyMultiplayer von Haus aus
use-cases / replay-this-mornings-incident / hero
PIPE · INCIDENT REPLAY
Spiel den Vorfall von heute Morgen für das ganze Team noch einmal ab
Es ist 14 Uhr. Der Vorfall von 7 Uhr morgens wird im Post-Mortem aufgearbeitet. Sechs Engineers wollen die exakte Log-Sequenz durchgehen, die der diensthabende SRE damals gesehen hat. Du streamst den Snapshot über eine einzige Hoody-Pipe-URL mit ?n=8. Alle sehen die Kaskade im selben Moment auf ihrem eigenen Terminal abfeuern – keine Screenshots, kein asynchrones Scrollen, keine Zoom-Aufzeichnung.
incident-2026-05-04 · 07:00 – 08:00
07:00
07:15
07:23
07:30
07:45
08:00
VORFALLSBEGINN
07:23:14 UTCalex
07:23:14INFOPOST /v1/checkout u_28f
07:23:15WARNstripe latency 2.4s
07:23:16ERR 500 stripe timeout
07:23:17···auto-rollback armed
ben
07:23:14INFOPOST /v1/checkout u_28f
07:23:15WARNstripe latency 2.4s
07:23:16ERR 500 stripe timeout
07:23:17···auto-rollback armed
chen
07:23:14INFOPOST /v1/checkout u_28f
07:23:15WARNstripe latency 2.4s
07:23:16ERR 500 stripe timeout
07:23:17···auto-rollback armed
dani
07:23:14INFOPOST /v1/checkout u_28f
07:23:15WARNstripe latency 2.4s
07:23:16ERR 500 stripe timeout
07:23:17···auto-rollback armed
ev
07:23:14INFOPOST /v1/checkout u_28f
07:23:15WARNstripe latency 2.4s
07:23:16ERR 500 stripe timeout
07:23:17···auto-rollback armed
fox
07:23:14INFOPOST /v1/checkout u_28f
07:23:15WARNstripe latency 2.4s
07:23:16ERR 500 stripe timeout
07:23:17···auto-rollback armed
läuft · im GleichschrittPOS1×
use-cases / replay-this-mornings-incident / mechanism
Ein Snapshot. Eine Pipe. Sechs Terminals im Gleichschritt.
Nimm die Logdatei der Vorfallszeit von heute Morgen aus deinem hoody-files-Snapshot. Streame sie durch einen Hoody-Pipe-Pfad mit ?n=8. Acht Engineers holen denselben Pfad per curl ab. Die Pipe wartet, bis alle verbunden sind, dann wandern die Bytes einmal mit dem Tempo durch, das du gesetzt hast – jeder Reader sieht dieselbe Zeile im selben Moment.
post-mortem.host · sender
PUT · replay# The 7am incident is captured in incident-2026-05-04.log
# (snapshotted from /var/log/app at 07:25 by the on-call SRE).
# Replay it through a pipe path with ?n=8 — the server waits
# until eight readers connect, then the bytes move through once.
# pv -L 50k rate-limits the replay to a readable 50KB/s.
cat incident-2026-05-04.log \
| pv -L 50k \
| curl -T - \
"https://prod-pipe.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/salle 8 Reader verbunden · die Pipe hält nichts · die Bytes fließen einmal durch
alex / ben / chen / dani / ev / fox / zwei weitere · Reader
GET · im Gleichschritt# Each engineer in the post-mortem call runs the same line.
# They block until everyone has joined, then the cascade scrolls
# past their terminal at the exact rate the SRE saw at 07:23.
curl "https://prod-pipe.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
# ...the whole cascade, in order, on every terminal at once.Zwei Bausteine der dokumentierten Pipe-API: PUT /api/v1/pipe/[path] auf der Sender-Seite, GET /api/v1/pipe/[path] auf jedem Reader, beide mit demselben n als Schlüssel. Der Server reicht den Content-Type des Senders weiter, hält die Verbindung bis zu einer 5-Minuten-TTL offen, während er auf Reader wartet, und wendet Backpressure an, wenn ein einzelner Reader langsam ist. Das Replay-Tempo bestimmt allein der Sender – pv, dd oder ein Rate-Limiter deiner Wahl.
use-cases / replay-this-mornings-incident / powers
Was gemeinsames Zuschauen schafft, was ein Dokument nicht kann
Ein scrollender Stream verändert das Gespräch. Die Leute hören auf zu streiten, was passiert ist, und fangen an, zu beobachten, was passiert ist. Drei Eigenschaften der Pipe machen das möglich.
MULTIPLAYER VON HAUS AUS
Sechs Terminals auf demselben Playhead
n=N ist in der Pipe-API dokumentiert: Jeder Reader, der mit demselben n in denselben Pfad einsteigt, bekommt eine identische Fan-Out-Kopie. Acht Engineers sehen alle dieselbe Zeile im selben Augenblick vorbeiscrollen – niemand ist voraus, niemand kneift die Augen vor dem Screenshare zusammen.
TEMPO BESTIMMT DER SENDER
Replay langsam genug zum Lesen
Echte Prod-Logs scrollen schneller, als Menschen sie aufnehmen können. pv -L 50k drosselt das Replay auf ein lesbares Tempo; die Pipe trägt das Tempo, das der Sender wählt. Du kannst das Post-Mortem pausieren, indem du den Sender mit ctrl-Z anhältst, und mit fg wieder starten – das Terminal jedes Readers pausiert mit dir.
VON HAUS AUS FLÜCHTIG
Replay endet, Pipe verschwindet
Die Pipe speichert null Bytes. Wenn cat fertig ist oder der SRE den Sender mit ctrl-C beendet, schließt sich der Pfad – kein übrig gebliebener Endpoint im Internet, kein Transkript, das verwaltet werden muss. Lass es aus dem Snapshot noch einmal laufen, für alle, die zu spät zum Call kamen.
use-cases / replay-this-mornings-incident / session
So läuft eine Replay-Session
Vier Schläge vom Vorfallszeit-Log bis zur gemeinsamen Post-Mortem-Wiedergabe. Nichts hier ist eigene Infrastruktur – der Snapshot lebt in hoody-files, das Replay reitet auf einer einzigen Pipe-URL.
- 0107:25
Logs snapshotten
Der diensthabende SRE kopiert /var/log/app um 07:25 in einen hoody-files-Bucket. Die Datei ist die Single Source of Truth für alles, was im Kaskaden-Fenster passiert ist.
- 0213:55
Den Meeting-Raum öffnen
Der Lead schreibt eine Hoody-Pipe-URL mit ?n=8 (sechs Engineers + zwei Plätze für Nachzügler) und postet sie in den Post-Mortem-Channel. Receiver können zuerst verbinden – die Pipe hält den Slot bis zu 5 Minuten.
- 0314:00
Play drücken
Der SRE leitet den Snapshot durch pv -L 50k in die URL. Der Server wartet, bis acht curls verbunden sind, dann fließen die Bytes einmal im Gleichschritt durch – die Kaskade feuert auf sechs Terminals im selben Augenblick ab.
- 0414:18
Replay für Nachzügler
Der Director kommt spät dazu. Lass dieselbe Zeile noch einmal laufen. Die Pipe ist ein Pfad, kein Ort – nichts zu suchen, nichts zurückzuspulen, nichts auf dem Server gespeichert. Einfach noch einmal Play drücken.
use-cases / replay-this-mornings-incident / capacity
Wie groß wird der Raum?
Aus der dokumentierten Pipe-API-Spezifikation. Limits und Verhalten, die aus einer einzigen URL ein Post-Mortem-Theater machen.
- READER PRO PFAD256
Dokumentiertes Limit für n. Deinem Post-Mortem-Call gehen die Plätze nicht aus – die Pipe skaliert auf eine ganze Org.
- GESPEICHERTE BYTES0
Die Pipe streamt direkt von Ende zu Ende. Das Replay hinterlässt keine Spur auf dem Server, sobald der Sender die Verbindung trennt.
- JOIN-FENSTER5 Min.
Receiver können sich vor dem Sender verbinden; die Pipe hält den Slot bis zu 5 Minuten für Nachzügler offen.
Quelle: Hoody Pipe API – dokumentierte Limits für /api/v1/pipe/[path], n-Parameter (1–256) und TTL für nicht etablierte Pipes.
use-cases / replay-this-mornings-incident / punchline
Das Post-Mortem ist kein Dokument. Es ist ein Stream, den alle gemeinsam anschauen.
kein asynchrones Scrollen · kein Screenshare-Geblinzeleine URL · acht curls · ein Playhead
POST-MORTEMgesternheute
- ARTEFAKTConfluence-Dokument mit Screenshotshttps://prod-pipe.../pipe/replay
- SYNCalle scrollen in ihrem eigenen TempoWiedergabe im Gleichschritt für n=8
- AUFBEWAHRUNGPDF lebt jahrelang weiterctrl-C und die Pipe ist weg
- REPLAYein zweites Zoom-Meeting ansetzendenselben curl noch einmal laufen lassen
use-cases / replay-this-mornings-incident / replaces
Was das ersetzt
Die Tools und Rituale, die du gerade aufrufst, um ein Team durch eine Vorfalls-Timeline zu führen. Jedes davon speichert etwas, kostet pro Sitz oder verliert das Timing. Die Pipe ist eine URL mit gemeinsamem Playhead.
- Confluence-Post-Mortem-DokumentStatische Seite mit veralteten Screenshots
- Notion-VorfallsberichtBullet-Liste, kein synchronisiertes Timing
- Screenshots in Slack einklebenVerliert Reihenfolge und Timing der Kaskade
- Manuelle Replay-the-Logs-SessionsEine Person scrollt, der Rest blinzelt
- Aufgezeichnete Zoom-TimelineAlle scrubben in ihrem eigenen Tempo
- Datadog-Notebook-AnnotationenLizenz pro Sitz, kein gemeinsamer Playhead
use-cases / replay-this-mornings-incident / cta
Die Kaskade feuert auf sechs Terminals zugleich. Das Gespräch verändert sich. Die Leute hören auf zu streiten, was passiert ist, und fangen an, zu beobachten, was passiert ist.
use-cases / replay-this-mornings-incident / related
Lies die anderen
