
1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
午後 2 時。午前 7 時のインシデントのポストモーテムが行われています。6 人のエンジニアが、当時オンコール SRE が見ていた正確なログシーケンスを辿りたいと思っています。?n=8 を付けて 1 つの Hoody Pipe URL からスナップショットをストリーミング。全員が自分のターミナルで同じ瞬間にカスケードを目撃します — スクリーンショットも、同期がずれたスクロールも、Zoom 録画もありません。
hoody-files スナップショットから今朝のインシデント発生時のログファイルを取得します。?n=8 を付けて Hoody Pipe パスからストリーミング。8 人のエンジニアが同じパスを curl します。パイプは全員が接続するまで待ち、その後設定したレートでバイトが一度だけ通り抜けます — すべての読者が同じ瞬間に同じ行を見ます。
# 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/s# 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.ドキュメント化された Pipe API の 2 つのピース: 送信者側で PUT /api/v1/pipe/[path]、すべての読者で GET /api/v1/pipe/[path]、両方とも同じ n でキー付けされます。サーバーは送信者の Content-Type を転送し、読者を待つ間 5 分の TTL までコネクションを保持し、いずれかの読者が遅い場合はバックプレッシャーを適用します。再生レートは完全に送信者によって設定されます — pv、dd、または信頼するレートリミッターを使えます。
スクロールするストリームは会話を変えます。何が起こったかを議論するのをやめ、何が起こっているかを見始めます。これを実現するパイプの 3 つの特性。
n=N は Pipe API でドキュメント化されています: 同じ n で同じパスに参加する各読者は、同一のファンアウトコピーを受け取ります。8 人のエンジニア全員が同じ瞬間に同じ行がスクロールするのを目撃します — 誰も先に進まず、誰も他人の画面共有を覗き込みません。
実際の本番ログは人間が吸収できるよりも速くスクロールします。pv -L 50k は再生を読みやすいペースに絞ります。パイプは送信者が選んだレートで運びます。送信者を ctrl-Z で停止すればポストモーテムを一時停止でき、fg で再開できます — 読者全員のターミナルもあなたと一緒に一時停止します。
パイプはゼロバイトを保存します。cat が完了するか SRE が送信者を ctrl-C すると、パスは閉じます — インターネットに公開された残りのエンドポイントも、保持期間を管理するトランスクリプトもありません。会議に遅れて参加した人のために、スナップショットからもう一度実行してください。
インシデント発生時のログから共有ポストモーテム再生まで 4 つのビート。ここにカスタムインフラはありません — スナップショットは hoody-files に存在し、再生は 1 つの Pipe URL に乗ります。
オンコール SRE が 07:25 に /var/log/app を hoody-files バケットにコピーします。このファイルがカスケードウィンドウで起こったすべての真実のソースです。
リードが ?n=8 (エンジニア 6 名 + 遅参者 2 名のヘッドルーム) 付きの Hoody Pipe URL を作成し、ポストモーテムチャネルに貼り付けます。受信者は最初に接続できます — パイプは最大 5 分間スロットを保持します。
SRE が pv -L 50k 経由でスナップショットを URL に送ります。サーバーは 8 つの curl が接続するまで待ち、その後バイトが一度ロックステップで通り抜けます — カスケードが同じ瞬間に 6 つのターミナルで発生します。
ディレクターが遅れて参加。同じ行を再実行します。パイプは場所ではなくパスです — シークするものも、巻き戻すものも、サーバーに保存されているものもありません。もう一度再生を押すだけです。
ドキュメント化された Pipe API 仕様から。1 つの URL をポストモーテムシアターに変える制限と動作。
n のドキュメント化された上限。ポストモーテム会議は座席切れになりません — パイプは組織全体にスケールします。
パイプはエンドツーエンドで直接ストリーミングされます。送信者が切断されると、再生はサーバーに痕跡を残しません。
受信者は送信者より先に接続できます。パイプは遅参者のために最大 5 分間スロットを保持します。
ソース: Hoody Pipe API — /api/v1/pipe/[path]、n パラメータ (1–256)、未確立パイプの TTL についてドキュメント化された制限。
ポストモーテムはドキュメントではありません。みんなが一緒に見るストリームです。
現在チームをインシデントタイムラインに案内するために呼び出すツールと儀式のセット。それぞれ何かを保存し、シートあたり課金され、タイミングを失います。パイプは共有された再生ヘッドを持つ 1 つの URL です。
カスケードが 6 つのターミナルで一度に発生します。会話が変わります。何が起こったかを議論するのをやめ、何が起こっているかを見始めます。