Pular para o conteúdo
use-cases / replay-this-mornings-incident / hero
PIPE · INCIDENT REPLAY

Reproduza o incidente desta manhã para o time inteiro

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.

Ler a API do pipe
use-cases / replay-this-mornings-incident / mechanism

Um snapshot. Um pipe. Seis terminais em sincronia.

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.

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/s
8 leitores conectados · pipe não guarda nada · bytes passam uma vez
alex / ben / chen / dani / ev / fox / mais dois · leitores
GET · em sincronia
# 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.

use-cases / replay-this-mornings-incident / powers

O que assistir junto faz que um doc não consegue

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.

MULTIPLAYER POR PADRÃO

Seis terminais no mesmo playhead

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.

RATE-LIMIT PELO REMETENTE

Replay devagar o suficiente para ler

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.

EFÊMERO POR PADRÃO

Replay termina, pipe some

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.

use-cases / replay-this-mornings-incident / session

Como uma sessão de replay roda

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.

  1. 0107:25

    Snapshot dos logs

    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.

  2. 0213:55

    Abre a sala de reunião

    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.

  3. 0314:00

    Aperta play

    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.

  4. 0414:18

    Replay para os atrasados

    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.

use-cases / replay-this-mornings-incident / capacity

De que tamanho fica a sala?

Da spec documentada da API do Pipe. Limites e comportamentos que transformam uma URL única em um teatro de post-mortem.

  1. LEITORES POR CAMINHO256

    Limite documentado para n. Sua call de post-mortem não vai ficar sem assentos — o pipe escala para uma org inteira.

  2. BYTES ARMAZENADOS0

    O pipe é direct-streamed de ponta a ponta. O replay não deixa rastro no servidor quando o remetente desconecta.

  3. JANELA DE ENTRADA5 min

    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.

use-cases / replay-this-mornings-incident / punchline

O post-mortem não é um doc. É um stream que todo mundo assiste junto.

sem rolagem fora de sincronia · sem apertar os olhos no compartilhamento de telauma URL · oito curls · um playhead
POST-MORTEMontemhoje
  • ARTEFATOdoc do Confluence com printshttps://prod-pipe.../pipe/replay
  • SINCRONIAcada um rola na própria velocidadeplayback em sincronia para n=8
  • RETENÇÃOPDF sobrevive por anosctrl-C e o pipe some
  • REPLAYagendar um segundo Zoomrodar o mesmo curl de novo
Ler a API do pipe
use-cases / replay-this-mornings-incident / replaces

O que isso substitui

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.

  • Doc de post-mortem no ConfluencePágina estática com prints desatualizados
  • Relatório de incidente no NotionLista de bullets, sem temporização sincronizada
  • Colar prints no SlackPerde a ordem e o tempo da cascata
  • Sessões manuais de replay-the-logsUma pessoa rola, o resto aperta os olhos
  • Timeline gravada no ZoomCada um navega no próprio ritmo
  • Anotações em notebook do DatadogLicença por assento, sem playhead compartilhado
use-cases / replay-this-mornings-incident / cta

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.

Ler a API do pipe
use-cases / replay-this-mornings-incident / related

Leia os outros