Melhores Práticas de Entrega Corporativa

Uma lista de verificação condensada de regras de entrega para microsserviços Go: disciplina de artefatos, promoção em estágios, segurança de tráfego, verificação, flags, rollbacks, métricas e conformidade.

Como Usar Esta Lista

• Incorpore as regras da Camada A em modelos de pipeline dourados antes que as equipes de serviço criem forks de repositórios.
• Revise a Camada B na revisão de arquitetura para novos serviços.
• Use a Camada C para sistemas regulamentados ou de alto raio de impacto.
• Revise trimestralmente contra tendências DORA e post-mortems de incidentes.

A - Artefatos e CI

• Construa imagens imutáveis ​​marcadas com o SHA do git. Auditores e rollbacks precisam de identidade exata do commit, não :latest.
• Execute go test ./... com -race em cada PR. Data races capturadas em CI são mais baratas do que incidentes em produção.
• Escaneie imagens e execute govulncheck antes da promoção. Portões de CVE pertencem ao pipeline, não a comentários de ticket.
• Use Dockerfiles multi-estágio com bases distroless ou mínimas. Superfície de ataque menor; pulls mais rápidas durante rollouts.
• Fixe a toolchain Go em CI e Dockerfile. go 1.26 em go.mod deve corresponder à imagem do builder.
• Gere SBOM ou anexe a saída de go version -m ao registro. Auditorias de cadeia de suprimentos perguntam o que estava em produção.

B - Promoção e ambientes

• Promova o mesmo digest do staging → prod. Nunca reconstrua no host de deploy.
• Configure via ambiente apenas. Mesmo binário em todos os ambientes; segredos do gerenciador, não camadas de imagem.
• Bloqueie o deploy de produção sem passagem de smoke test no staging. O smoke test deve atingir rotas de negócios, não apenas /healthz.
• Registre eventos de deploy para métricas DORA. Lead time, CFR e MTTR exigem logs de deploy estruturados.
• Mantenha o último SHA conhecido como bom a um comando de distância. Documente no README do serviço e no template de incidente.
• Congele deploys durante SEV-1 ativo, a menos que seja rollback. Evita o acúmulo de falhas durante a recuperação.

C - Mudança de tráfego e runtime

• Separe sondas de liveness e readiness. A verificação de readiness verifica dependências; a liveness permanece barata.
• Use canary ou blue-green para APIs voltadas para o usuário. A atualização rolling sozinha é fraca para alvos de alto CFR.
• Defina maxUnavailable: 0 para Deployments críticos. Nenhuma queda de capacidade durante os rollouts.
• Implemente desligamento gracioso em SIGTERM. Corresponda terminationGracePeriodSeconds à requisição mais longa.
• Exporte a versão de build em métricas e logs. Correlacione incidentes com SHA sem adivinhação.
• Aqueça pools de conexão antes de marcar como pronto. Evite picos de 5xx quando o canary receber tráfego inicial.

D - Schema, flags e dados

• Siga expand-contract para migrações de banco de dados. Implante o binário apenas após a fase de expansão estar ativa.
• Defina novas feature flags como desativadas por padrão em produção. Dark launch; ative via targeting após a verificação.
• Avalie flags uma vez por requisição. Evite tempestades de provedores em loops quentes.
• Retire flags em até 90 dias após o rollout completo. Ramos if flag permanentes se tornam inadministráveis.
• Planeje correções de dados separadamente do rollback do binário. Gravações ruins podem sobreviver à reversão da imagem.
• Nunca execute migrações de descida destrutivas em incidentes. Corrija para frente ou restaure de um snapshot com o DBA.

E - Verificação e rollback

• Conecte a análise de entrega progressiva ao Prometheus. Promova automaticamente quando verde; reverta automaticamente ao violar o limite.
• Execute synthetics externos em caminhos de produção. Smoke test dentro da VPC perde casos de borda de DNS, TLS e autenticação.
• Defina gatilhos de rollback antes do dia do deploy. Multiplicadores de 5xx e p99 documentados por serviço.
• Pratique game days de rollback trimestralmente. Meça MTTR; atualize o runbook quando a malha ou o CD mudarem.
• Desative flags antes do rollback do binário quando isolado. Recuperação mais rápida quando o binário canary está bom.
• Capture o ator do rollback e o digest no log de auditoria. SOX e post-mortems precisam de evidências.

F - Conformidade e governança

• Exija ID do ticket de alteração para o pipeline de produção. Falhe o job se CHANGE_TICKET estiver vazio em serviços regulamentados.
• Imponha a separação de funções na aprovação de produção. Merger ≠ aprovador único.
• Envie JSON de auditoria para armazenamento de log imutável. Retenção WORM ou SIEM por política.
• Documente o break-glass com SLA de revisão post-hoc. Emergências acontecem; evidências ainda devem existir.
• Assine artefatos com cosign ou equivalente. A proveniência vincula o digest ao pipeline e à referência git.
• Alinhe os portões de conformidade com o rastreamento DORA. Aprovações adicionam lead time - automatize todo o resto.

FAQs

Relacionados

• Enviando Serviços Go com Segurança em Escala Corporativa - visão geral conceitual
• Noções Básicas de Entrega Corporativa - exemplos práticos
• Runbooks de Rollback para Deploys Go - lista de verificação de incidentes
• Métricas DORA para Equipes Go - meça a saúde da entrega
• Gerenciamento de Mudanças e Portões de Conformidade - auditoria e aprovações

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).