Melhores Práticas de Solução de Problemas em Produção
Hábitos de prevenção que reduzem a duração de incidentes para plataformas Go: SLOs, dashboards, runbooks e respostas ensaiadas.
//
Busque em todas as páginas da documentação
Hábitos de prevenção que reduzem a duração de incidentes para plataformas Go: SLOs, dashboards, runbooks e respostas ensaiadas.
Aplique como um rubrica de revisão de design e higiene trimestral da plataforma, não apenas após interrupções.
sql.DB.Stats() como Prometheus gauges. WaitCount alerta sobre esgotamento do pool antes da paralisação total.request_id e trace_id. A correlação reduz o tempo de busca de logs durante SEV-1./healthz. Correlação de deploy sem precisar vasculhar no CI./debug/pprof público.MaxOpenConns a partir da fórmula limite do DB / número de réplicas. Documente a aritmética no README do serviço.GOMEMLIMIT a ~90% do limite de memória do contêiner. Reduza OOMKilled antes de aumentar limites cegamente.GOMAXPROCS para corresponder à cota de CPU (ou use automaxprocs). A latência da fila de execução mostra incompatibilidade nos traces.QueryContext com deadlines em todas as chamadas de DB. Esperas no pool não devem ultrapassar os timeouts do cliente.context.Context para todas as goroutines em segundo plano. Reduz a classe de vazamento que sobrevive a reinícios.Server.Shutdown abaixo do período de graça do K8s. Evite falsos 5xx durante rollouts.Os níveis A e B devem estar estabelecidos antes de qualquer lançamento em produção.
Os níveis C a E amadurecem ao longo dos trimestres; priorize itens que queimaram budget de erro nos últimos dois incidentes.
Se todos os níveis passarem na revisão e o game day for bem-sucedido, adie novas ferramentas até a próxima lacuna medida.
Métricas RED, pool de conexões limitado, contexto em chamadas de DB, pprof não público, metadados de saúde e caminho de rollback.
Melhores práticas previnem classes de falha.
Runbooks executam passos durante incidentes ativos.
Ambos são necessários.
Execute um tabletop no mínimo uma vez por ano.
Trinta minutos de walkthrough superam o primeiro OOM real sozinho.
A queima do SLO aciona a severidade do incidente e a política de congelamento de deploy.
Alertas devem mapear para janelas de SLO, não apenas para limites estáticos.
RED por serviço, goroutines, heap, pausa do GC, espera do pool, CPU/memória vs limites, marcadores de deploy.
Sim.
Workers também precisam de limites de pool, cancelamento de ctx, métricas e acesso a perfis.
Após cada SEV-1 e quando atualizações de versão menor do Go alterarem o comportamento do GC.
O CI pode proibir sql.Query sem contexto em novo código, exigir ReadHeaderTimeout e bloquear rotas pprof públicas na revisão de configuração.
A passagem de plantão e os dashboards observam a queima de SLO por região.
Perfis podem ser específicos da região durante interrupções parciais.
Quando os SLOs estão verdes, os game days são aprovados e os últimos dois incidentes tiveram alertas disparados antes do impacto em toda a base de clientes.
Otimize recursos até a próxima regressão medida.
Versões de Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, go fix modernizers - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 18 de jul. de 2026