
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
São 14h. O incidente das 7h está em post-mortem. Seis engenheiros querem percorrer a sequência exata de logs que o SRE de plantão viu na hora. Você transmite o snapshot por uma URL do Hoody Pipe com ?n=8. Todo mundo assiste à cascata acontecer no próprio terminal no mesmo instante — sem prints, sem rolagem fora de sincronia, sem gravação de Zoom.
Pegue o arquivo de log do horário do incidente desta manhã do seu snapshot do hoody-files. Transmita-o por um caminho do Hoody Pipe com ?n=8. Oito engenheiros fazem curl no mesmo caminho. O pipe espera todo mundo conectar, e aí os bytes passam uma vez no ritmo que você definiu — todo leitor vê a mesma linha no mesmo instante.
# 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.Duas peças da API documentada do Pipe: PUT /api/v1/pipe/[path] no remetente, GET /api/v1/pipe/[path] em todo leitor, ambos chaveados pelo mesmo n. O servidor encaminha o Content-Type do remetente, segura a conexão por até 5 minutos de TTL enquanto espera leitores e aplica backpressure se algum leitor for lento. A taxa de replay é definida totalmente pelo remetente — pv, dd ou qualquer rate-limiter em que você confia.
Um stream rolando muda a conversa. As pessoas param de discutir o que aconteceu e começam a ver o que aconteceu. Três propriedades do pipe fazem isso funcionar.
n=N está documentado na API do Pipe: todo leitor entrando no mesmo caminho com o mesmo n recebe uma cópia idêntica de fan-out. Oito engenheiros veem a mesma linha rolar no mesmo instante — ninguém adiantado, ninguém apertando os olhos no compartilhamento de tela alheio.
Logs reais de prod rolam mais rápido do que humanos absorvem. pv -L 50k limita o replay a um ritmo legível; o pipe carrega qualquer taxa que o remetente escolher. Você pode pausar o post-mortem com ctrl-Z no remetente e retomar com fg — o terminal de cada leitor pausa junto.
O pipe armazena zero bytes. Quando o cat termina ou o SRE dá ctrl-C no remetente, o caminho fecha — sem endpoint sobrando exposto à internet, sem transcrição pra gerenciar retenção. Rode de novo a partir do snapshot pra quem entrou na call atrasado.
Quatro passos do log do horário do incidente até o playback compartilhado do post-mortem. Nada aqui é infraestrutura customizada — o snapshot mora no hoody-files, o replay anda numa URL do Pipe.
SRE de plantão copia /var/log/app às 07:25 para um bucket do hoody-files. O arquivo é a fonte da verdade pra tudo que aconteceu na janela da cascata.
Líder escreve uma URL do Hoody Pipe com ?n=8 (seis engenheiros + folga pra dois retardatários) e cola no canal do post-mortem. Receivers podem conectar primeiro — o pipe segura o slot por até 5 minutos.
O SRE manda o snapshot por pv -L 50k para a URL. O servidor espera oito curls conectarem, e aí os bytes passam uma vez em sincronia — a cascata aciona em seis terminais no mesmo instante.
A diretora chega tarde. Roda a mesma linha de novo. O pipe é um caminho, não um lugar — não há onde buscar, nada pra rebobinar, nada armazenado no servidor. É só apertar play de novo.
Da spec documentada da API do Pipe. Limites e comportamentos que transformam uma URL única em um teatro de post-mortem.
Limite documentado para n. Sua call de post-mortem não vai ficar sem assentos — o pipe escala para uma org inteira.
O pipe é direct-streamed de ponta a ponta. O replay não deixa rastro no servidor quando o remetente desconecta.
Receivers podem conectar antes do remetente; o pipe segura o slot por até 5 minutos para retardatários.
Fonte: API do Hoody Pipe — limites documentados para /api/v1/pipe/[path], parâmetro n (1–256) e TTL de pipe não estabelecido.
O post-mortem não é um doc. É um stream que todo mundo assiste junto.
O conjunto de ferramentas e rituais que você invoca hoje para conduzir um time pela timeline de um incidente. Cada um armazena algo, cobra por assento ou perde o tempo. O pipe é uma URL com um playhead compartilhado.
A cascata aciona em seis terminais ao mesmo tempo. A conversa muda. As pessoas param de discutir o que aconteceu e começam a ver o que aconteceu.