Modelo de Post-Mortem para Incidentes em Go
Referência densa para post-mortems sem culpa sobre interrupções de serviços em Go.
//
Busque em todas as páginas da documentação
Referência densa para post-mortems sem culpa sobre interrupções de serviços em Go.
Copie seções para o seu documento de incidente.
Colete evidências de tempo de execução específicas de Go para que os acompanhamentos sejam acionáveis, não apenas narrativos.
| Campo | Valor |
|---|---|
| ID do Incidente | <INC-1234> |
| Título | <Breve descrição voltada ao cliente> |
| SEV | <1 / 2 / 3> |
| Data (UTC) | <AAAA-MM-DD> |
| Duração | <início - fim> |
| Autor | <nome> |
| Status | <Rascunho / Final> |
| Pergunta | Sua resposta |
|---|---|
| Impacto no cliente | <quem, o que quebrou, magnitude do erro/latência> |
| Causa raiz (uma linha) | <causa técnica em linguagem clara> |
| Gatilho | <deploy, tráfego, dependência, configuração> |
| Correção enviada | <rollback, patch, escala, flag> |
| Risco de recorrência | <baixo/médio/alto até que os acompanhamentos sejam feitos> |
| Hora (UTC) | Evento | Responsável |
|---|---|---|
<t0> | Alerta disparado: <nome do alerta> | PagerDuty |
<t1> | Plantonista reconheceu | <nome> |
<t2> | Mitigação: <rollback/escala> | <nome> |
<t3> | Causa raiz identificada | <nome> |
<t4> | Incidente resolvido | <nome> |
<t5> | Post-mortem agendado | <nome> |
| Item | Valor |
|---|---|
| Versão do Go | <runtime.Version() / tag da imagem> |
| SHA de Build | <git sha de /healthz ou CI> |
GOMAXPROCS | <env ou automaxprocs> |
GOMEMLIMIT | <valor ou não definido> |
GOGC | <padrão 100 ou override> |
| Limite de memória do contêiner | <limite K8s> |
| Contagem de réplicas | <no pico> |
| Link das métricas de GC / heap | <URL do painel> |
| Artefato | Coletado? | Localização |
|---|---|---|
| Perfil de CPU (20-30s) | <S/N> | <caminho ou link> |
Perfil de Heap (inuse + alloc) | <S/N> | <caminho> |
Dump de Goroutine debug=2 | <S/N> | <caminho> |
Gráfico sql.DB.Stats() | <S/N> | <link> |
| Exemplos de ID de Rastreamento | <S/N> | <link> |
| Diff de deploy / Diff de configuração | <S/N> | <link> |
| Logs de stack de pânico | <S/N> | <link> |
| # | Por quê? |
|---|---|
| 1 | <sintoma> porque <causa imediata> |
| 2 | Porque <causa mais profunda> |
| 3 | Porque <lacuna no processo ou design> |
| 4 | Porque <falta de barreira de proteção> |
| 5 | Porque <lacuna organizacional/técnica raiz> |
| Categoria | Fator |
|---|---|
| Código | <ex: falta de deadline ctx> |
| Configuração | <ex: MaxOpenConns muito alto x réplicas> |
| Observabilidade | <ex: sem alerta WaitCount> |
| Processo | <ex: deploy durante freeze> |
| Dependência | <ex: falha de failover do DB> |
<ex: runbook de rollback em menos de 5 minutos><ex: perfis salvos antes da reinicialização><ex: token pprof expirou><ex: sem GOMEMLIMIT no novo serviço>| ID | Ação | Responsável | Prioridade | Vencimento |
|---|---|---|---|---|
| 1 | <correção de código> | <equipe> | P0 | <data> |
| 2 | <alerta> | <equipe> | P1 | <data> |
| 3 | <atualização de runbook> | <equipe> | P2 | <data> |
| 4 | <cenário de game day> | <equipe> | P2 | <data> |
| Família de Sintomas | Ação Típica |
|---|---|
| OOMKilled | Definir GOMEMLIMIT, corrigir vazamento, ajustar limite |
| GC / latência | Reduzir hot path de alocação, canary GOGC |
| Esgotamento de pool | Redimensionar MaxOpenConns, adicionar alerta WaitCount |
| Vazamento de Goroutine | Cancelamento de ctx, CI goleak, perfil de vazamento em staging |
| Pânico | Auditoria de interface nula, adicionar teste com -race |
Duas a quatro páginas, incluindo tabelas.
A profundidade importa na cronologia e nos acompanhamentos, não no comprimento da prosa.
Foque em sistemas e barreiras de proteção.
Conduta sensível a RH está fora do escopo do documento de engenharia.
Documente hipóteses descartadas, lacunas de evidências e monitoramento adicionado para capturar a próxima ocorrência.
Sim, para definições de SEV.
Marque claramente o que é visível ao cliente versus interno no resumo executivo.
Proprietário do serviço e EM para P0/P1.
Acompanhe no mesmo sistema do trabalho de engenharia normal.
A política da equipe varia.
Regra comum: qualquer SEV-1/2 ou queima de orçamento de SLO acima do limite.
Sim.
Perfis pré-rollback provam a regressão; pós-rollback confirmam a correção.
Armazenamento de objetos com prefixo de ID do incidente.
Link da tabela de evidências; não cole binários na wiki.
Sempre registre runtime.Version().
O comportamento do GC difere entre as versões, especialmente 1.26 Green Tea.
Use a mesma estrutura de cronologia.
Redija detalhes sensíveis; envolva a equipe de segurança separadamente.
Versões de Stack: Esta página foi escrita para Go 1.26.x (padrão GC Green Tea, go fix modernizers - verifique o patch na build), chi (última versão - verifique na build), gin (última versão - verifique na build), echo (última versão - verifique na build), google.golang.org/grpc (última versão - verifique na build), sigs.k8s.io/controller-runtime (última versão - verifique na build), kubebuilder (última versão - verifique na build), tinygo (última versão - verifique os alvos de placa na build), wazero (última versão - verifique na build) e golangci-lint (última versão - verifique o conjunto de linters na build).
Revisado por Chris St. John·Última atualização: 18 de jul. de 2026