Use este checklist de entrega pronto para produção para empacotar ambientes, segredos, monitoramento, backups e runbooks, de forma que ops possa implantar e assumir seu app.
Uma entrega pronta para produção significa que ops pode rodar o app sem adivinhar. Eles conseguem implantar uma versão conhecida, confirmar que ela está saudável, responder a alertas e recuperar de um release ruim ou indisponibilidade. Se qualquer parte disso depende da memória de um desenvolvedor, a entrega não está completa.
Trate a entrega como um pacote que responde a uma pergunta: se os construtores originais desaparecessem por uma semana, ops ainda manteria o sistema seguro e disponível?
Um pacote sólido normalmente cobre o que o app faz, como é “saudável”, como funcionam os releases (deploy, verificação, rollback), onde a configuração vive, como os segredos são tratados, e como monitorar, fazer backups e responder a incidentes.
Igualmente importante é o que ela não cobre. A entrega não é uma promessa de adicionar funcionalidades, refatorar, redesenhar telas ou “limpar as coisas depois”. Essas são iniciativas separadas com escopo próprio.
Antes de declarar a entrega concluída, concorde sobre propriedade e tempos de resposta. Por exemplo: ops é responsável pela disponibilidade e faz os deploys; o time de produto é responsável pela roadmap; o time de desenvolvimento oferece uma janela definida de suporte pós-entrega para correções e dúvidas.
Ops só pode assumir responsabilidade pelo que consegue ver. Um inventário simples de uma página evita adivinhações durante deploys, incidentes e auditorias. Mantenha em linguagem clara e específica.
Liste cada parte em execução do sistema e onde ela está: API backend, app web, workers em background, jobs agendados e como apps mobile conectam. Mesmo que iOS/Android sejam distribuídos por lojas, eles ainda dependem do mesmo backend.
Inclua serviços externos dos quais o app não pode prescindir. Se você usa PostgreSQL, uma fila, armazenamento de objetos ou APIs de terceiros (pagamentos como Stripe, mensageria, email/SMS, Telegram), escreva o nome exato do serviço e para que ele é usado.
Capture requisitos de rede para que o hosting não vire tentativa e erro: domínios necessários (app, api, admin), portas e protocolos, quem renova certificados TLS, onde o DNS é gerenciado e quaisquer allowlists de entrada/saída.
Por fim, registre a carga esperada em números reais: picos de requisições por minuto, usuários ativos, tamanhos típicos de payload, tamanho atual do banco de dados e crescimento esperado. Mesmo intervalos aproximados ajudam ops a definir limites e alertas.
Se você construiu com AppMaster, inventarie o backend gerado, o app web e as integrações para que ops saiba o que precisa ser implantado junto.
Setups de produção costumam falhar na parte chata: configuração que só vive na cabeça de alguém. Trate a configuração como um entregável. Ops deve conseguir ver quais configurações existem, o que difere por ambiente e como mudá-las com segurança.
Comece nomeando cada ambiente que existe hoje, mesmo que pareça temporário. A maioria das equipes tem dev, staging e produção, mais cópias como “production-eu” ou “staging-us.” Anote qual ambiente é usado para testes de release, migrações de dados e simulações de incidentes.
Forneça uma referência única de configuração que liste nomes de variáveis e valores de exemplo seguros (nunca credenciais reais). Faça os placeholders ficarem óbvios.
Seu pacote de entrega deve incluir:
Adicione um processo simples de mudança. Por exemplo: solicitar por ticket, revisão pelo dono do serviço, aplicar primeiro em staging e então promover para produção numa janela agendada com um plano de rollback se as taxas de erro subirem.
Se você está exportando e self-hosting um app AppMaster, mantenha a mesma regra: envie um conjunto limpo e documentado de chaves de configuração junto com o código gerado para que ops possa rodá-lo de forma consistente entre ambientes.
Segredos são a maneira mais rápida de uma entrega limpa se transformar num incidente de segurança. O objetivo é simples: ops deve saber todo segredo que o app precisa, onde ele está armazenado, quem pode ler e como trocar sem downtime.
Comece com uma lista curta de segredos que ops consiga revisar em um minuto. Para cada item, anote o que ele desbloqueia (banco de dados, SMTP, Stripe, chave de assinatura JWT), onde fica (vault, secret store da nuvem, Kubernetes Secret, arquivo criptografado) e quem é o dono da rotação.
Descreva os passos de rotação como uma receita, não uma política. Inclua a ordem exata, quanto tempo o segredo antigo precisa permanecer válido e a única verificação que prova que funcionou.
Use este padrão para cada segredo:
Seja explícito sobre expectativas de criptografia. Segredos devem estar criptografados em repouso no cofre de segredos e protegidos em trânsito (TLS) entre o app e suas dependências. Nunca coloque segredos em controle de versão, artefatos de build ou documentos compartilhados.
Defina acesso de quebra-glass. Se uma indisponibilidade bloquear o acesso normal, especifique quem pode aprovar acesso de emergência, quanto tempo ele dura e o que deve ser auditado depois.
Ops só pode assumir responsabilidade pelo que consegue reproduzir. Um bom pacote de deployment torna três perguntas fáceis: o que exatamente estamos rodando, como implantamos de novo e como voltamos rapidamente se algo quebrar?
Inclua uma “lista de materiais” clara para o build. Nomeie o tipo de artefato e como verificá-lo, não apenas onde ele vive:
Adicione um pequeno exemplo concreto. Por exemplo: “Implemente a v1.8.2 atualizando a tag da imagem, executando migrações e então reiniciando os workers web. Se os health checks falharem em 10 minutos, reverta para a v1.8.1 e pare o job de migração.”
Um plano de rollback deve ler como instruções que você pode seguir às 2 da manhã. Deve indicar:
Se o app foi construído com AppMaster e exportado como código-fonte para self-hosting, inclua a versão do código gerado, instruções de build e as expectativas de runtime para que ops possa reconstruir o mesmo release depois.
Uma entrega não está completa até ops conseguir ver o que o app está fazendo e ser avisado antes que os usuários reclamem.
Concorde sobre quais logs devem existir e onde eles vão parar (arquivo, syslog, plataforma de logs). Garanta que os logs estejam sincronizados no tempo e incluam um ID de requisição ou correlação para que incidentes sejam rastreáveis de ponta a ponta.
Normalmente você quer logs de aplicação (eventos-chave e falhas), logs de erro (stack traces e jobs falhos), logs de acesso (requisições e códigos de status), logs de auditoria (ações administrativas e exportações) e logs de infraestrutura (reinícios, pressão em nós, problemas de disco).
Em seguida, defina um conjunto pequeno de métricas que reflitam o impacto no usuário e a saúde do sistema. Se for escolher só cinco: latência (p95/p99), taxa de erro, saturação (CPU/memória/disco), profundidade de filas e checks de disponibilidade externos à sua rede.
Regras de alerta devem ser inequívocas: o que dispara, severidade (paginar vs abrir ticket), quem está on-call e quando escalar. Adicione um snapshot de dashboard “conhecido bom” e uma nota curta descrevendo o que é normal (faixa típica de latência, taxa de erro esperada, profundidade usual da fila). Esse contexto evita alerts barulhentos e ajuda respondentes novos a agir rapidamente.
Backups não são algo que você “tem”. São algo de onde você consegue restaurar, sob demanda.
Documente o escopo exato: banco de dados, armazenamento de arquivos (uploads, relatórios, faturas) e as peças que as pessoas esquecem, como config que não está em código e as chaves de criptografia necessárias para ler dados protegidos.
Mantenha os alvos em termos simples. RPO é quanto dado você pode perder (por exemplo, 15 minutos). RTO é quanto tempo pode ficar indisponível (por exemplo, 1 hora). Escolha números aprovados pelo negócio, porque eles determinam custo e esforço.
Inclua:
Se você exporta e self-hosta um app construído com AppMaster, inclua passos de restauração do PostgreSQL além de quaisquer buckets de armazenamento externos e as chaves usadas para campos criptografados.
Agende um drill de restauração. Registre a hora, o que quebrou e o que você mudou para que o próximo restore seja mais rápido e menos estressante.
Uma entrega não é verdadeira até alguém ser capaz de receber um page às 2 da manhã e consertar o problema sem adivinhar. Runbooks transformam conhecimento tribal em passos que uma pessoa on-call pode seguir.
Comece com os incidentes que você espera que aconteçam primeiro: queda total, requisições lentas e um deploy que quebrou algo. Mantenha cada runbook curto. Coloque as checagens mais rápidas no topo para que respondentes encontrem sinal em minutos.
Mantenha a estrutura consistente para que seja escaneável sob pressão:
Se o app foi exportado ou self-hosted a partir do AppMaster, inclua onde os serviços gerados rodam, como reiniciá-los com segurança e quais valores de config são esperados por ambiente.
Mantenha um checklist curto pós-incidente. Registre a linha do tempo, o que mudou por último, as mensagens de erro exatas, usuários afetados e qual ação resolveu. Depois atualize o runbook enquanto os detalhes ainda estão frescos.
Ops só pode assumir um sistema se estiver claro quem pode tocar em cada coisa e como o acesso é rastreado.
Documente os papéis que você realmente usa. Para muitas equipes, estes são suficientes:
Documente a “política de porta” em passos claros: quem concede acesso, onde ele é concedido (SSO, cloud IAM, usuários do banco, CI/CD, painéis admin), quem pode revogar e como confirmar que foi removido durante offboarding.
Não esqueça acessos não-humanos. Liste cada conta de serviço e token usados por jobs, integrações e monitoramento, com uma nota de princípio de menor privilégio para cada um (por exemplo, “pode ler apenas do bucket X”). Se você exporta código AppMaster para self-hosting, inclua quais env vars ou arquivos de config definem essas identidades, mas nunca cole valores secretos no documento de entrega.
Também defina expectativas de logs de auditoria: o que deve ser registrado (login, deploy, mudança de config, ações de admin de BD), quem pode ler os logs, retenção, onde os logs ficam e como solicitar logs durante um incidente ou revisão.
Notas de segurança devem ser legíveis por não-especialistas, mas específicas o suficiente para que ops saiba agir. Adicione um resumo de uma página que responda: que dados armazenamos, onde vivem e quem pode acessá-los?
Comece com tipos de dados: perfis de clientes, tickets de suporte, metadados de pagamento, arquivos. Destaque categorias sensíveis como PII (nomes, emails, telefones), credenciais e quaisquer dados regulamentados que sua empresa precise proteger. Se você exportou código-fonte para self-hosting (incluindo do AppMaster), indique onde esses dados aparecem no banco de dados e quais serviços podem lê-los.
Depois escreva regras de retenção e exclusão em termos práticos. Diga o que você guarda, por quanto tempo e como a exclusão funciona (soft delete vs hard delete, purge atrasado, backups). Se houver retenção legal ou necessidades de auditoria, anote quem aprova exceções.
Logs frequentemente vazam mais que bases de dados. Seja claro sobre onde PII pode aparecer (logs de acesso, logs de erro, eventos de analytics) e como reduzir ou mascarar isso. Se um campo nunca deve ser logado, declare essa regra.
Mantenha aprovações explícitas:
Se puder adicionar apenas uma coisa extra, inclua uma nota de evidência: onde os logs de auditoria ficam e como exportá-los quando alguém pedir prova.
Ops está assumindo um portal de clientes construído por um pequeno time de produto e migrando para uma nova infraestrutura self-hosted. O objetivo não é só “rodar”, mas “ops conseguir rodar sem chamar os construtores”.
Dia 1: Ops faz um deploy limpo inicial em um novo ambiente usando apenas o pacote de entrega. O app sobe, mas o login falha porque falta uma variável de ambiente do provedor de email. Isso é adicionado ao template de env e o deploy é repetido até rodar do zero.
Dia 2: O primeiro alerta é disparado de propósito. Ops provoca uma falha controlada (para um serviço ou bloqueia envio de email) e confirma: métricas mostram o problema, alertas alcançam o canal certo e a mensagem diz o que fazer em seguida.
Dia 3: Um token vence no sandbox de pagamentos. Como a localização das credenciais e passos de rotação estão documentados, ops substitui sem adivinhar ou expor segredos.
Dia 4: Corte de DNS. Um registro ruim aponta para o IP antigo e o portal parece fora para alguns usuários. Ops usa o runbook para checar DNS, TLS e health checks na ordem certa.
Dia 5: Primeiro teste de restauração de backup. Ops restaura em um banco limpo e prova que o portal carrega dados reais.
O app rodou por 7 dias sem correções misteriosas, com um restore bem-sucedido, alertas claros e um deploy repetível que ops consegue executar sozinho.
A maneira mais rápida de transformar uma entrega tranquila em um incêndio às 2 da manhã é assumir que “dissemos tudo para ops” é o mesmo que “ops consegue rodar sem nós”.
Padrões de falha comuns após uma entrega para self-hosting incluem segredos compartilhados em planilhas ou chat, rollbacks que dependem de um desenvolvedor, backups que existem mas nunca foram restaurados, alertas que disparam o dia todo porque thresholds não foram ajustados e detalhes de ambiente que só vivem na cabeça de alguém (portas, nomes DNS, cron schedules, permissões na nuvem).
Exemplo: você exporta código-fonte do AppMaster para self-hosting e o primeiro deploy funciona. Duas semanas depois, uma mudança de config quebra logins. Se segredos foram enviados por chat e o rollback precisa do construtor original, ops perde horas só para voltar ao estado “funcionava ontem”.
Antes de fechar o ticket, faça um pequeno teste de início do zero. Dê o pacote de entrega a um engenheiro de ops e um ambiente limpo (VM nova, namespace Kubernetes novo ou um projeto de nuvem em branco). Se ele conseguir deployar, observar e recuperar o app dentro de um tempo definido (por exemplo, 2 horas), você está perto.
Use estas checagens:
Se você está exportando código gerado para self-hosting, confirme também que ops sabe onde inputs de build, versões e tags de release estão registrados para que releases futuros permaneçam reproduzíveis.
Faça uma última passagem com quem vai carregar o pager. Trate como um ensaio. Prove que deploy, rollback, restore e alerting funcionam com o pacote exato que você está entregando.
Uma última revisão costuma cobrir: deploy para um ambiente de teste e depois para produção usando os mesmos passos, rollback para a versão anterior e verificação de que o app continua funcionando, restauração de backup em um ambiente limpo e validação de um check simples (login, criar registro, enviar mensagem), disparar um alerta de teste e confirmar onde encontrar logs e dashboards durante um incidente.
Torne a propriedade explícita. Atribua um dono nomeado para cada runbook (deploy, incidente, restore) e para cada rota de alerta (on-call primário, backup, comportamento fora de horário). Se ninguém for dono de um alerta, ele será ignorado ou acordará a pessoa errada.
Escreva um plano curto de Dia 2 para que ops saiba o que melhorar após a primeira semana: ajustar thresholds, checar custos, limpar artefatos antigos e revisar acessos. Mantenha curto e com prazo.
Se você construiu com AppMaster (appmaster.io), inclua o código-fonte exportado ou os detalhes exatos de deployment (nuvem, regiões, settings de build, serviços necessários) para que ops possa reproduzir o app sem depender do workspace original do projeto. Defina uma cadência simples para atualizar o pacote sempre que os requisitos mudarem, para que os runbooks não se desvinculem da realidade.
O que “entrega pronta para produção” realmente significa?Uma entrega pronta para produção significa que ops pode fazer deploy de uma versão conhecida, confirmar que ela está saudável, responder a alertas e recuperar de falhas sem depender da memória de um desenvolvedor específico. Se uma semana sem os construtores colocaria a disponibilidade em risco, a entrega não está concluída.
O que deve ser incluído em um inventário básico do sistema?Comece com um inventário de sistema de uma página que liste cada componente em execução e onde ele vive: API, app web, workers, jobs agendados, banco de dados, armazenamento e serviços de terceiros necessários. Adicione domínios, portas, propriedade de DNS/TLS e uma estimativa de carga para que ops possa operar sem adivinhar.
Como entregamos a configuração dos ambientes sem vazar segredos?Forneça uma referência única de configuração que liste cada chave de configuração, seu tipo e um valor de exemplo seguro, além do que difere entre dev/staging/prod. Mantenha credenciais reais fora disso e documente onde a configuração é armazenada e como ela é aplicada durante os deploys para que mudanças sejam repetíveis.
Qual é o mínimo que devemos documentar sobre segredos e rotação de credenciais?Crie uma lista curta de segredos que indique para que cada segredo serve, onde está armazenado, quem pode lê-lo e quem é responsável pela rotação. Escreva os passos de rotação como um checklist com uma verificação clara e inclua um processo de "break-glass" para emergências com expectativas de auditoria.
O que torna um pacote de deploy “reproduzível” para ops?Ops precisa saber exatamente o que está rodando e como reproduzi-lo: nome/tag do artefato, versão, data de build, checksum e a referência de origem usada para construí-lo. Inclua o alvo de deploy recomendado, a ordem de deploy, o tempo esperado e como as migrações de banco de dados são executadas e verificadas.
O que um plano de rollback deve incluir para ser útil às 2 da manhã?Defina os sinais que disparam o rollback (como checks de saúde falhando ou aumento da taxa de erros), a última versão conhecida boa e os passos exatos para reverter rapidamente. Indique se mudanças no banco de dados são reversíveis e qual é a alternativa segura caso não sejam, para que o rollback não vire improvisação.
Quais sinais de monitoramento devemos priorizar durante a entrega?Escolha um conjunto pequeno de métricas que reflitam impacto no usuário: latência, taxa de erros, saturação (CPU/memória/disco), profundidade de filas e um check externo de disponibilidade. Deixe os alertas explícitos quanto à severidade, quem é acionado e o que é considerado “normal”, e garanta que logs estejam sincronizados no tempo com um ID de correlação.
Como tornamos backups e restores realmente confiáveis?Documente o que é feito backup, onde fica armazenado, retenção e quem pode executar restores. Inclua um procedimento passo a passo de restauração com uma verificação, e agende um exercício de restauração; backups só importam se um restore puder ser feito sob demanda em um ambiente limpo.
Como deve ser um runbook para quem está de plantão em incidentes comuns?Mantenha runbooks curtos e consistentes: sintomas, checagens iniciais, próximas checagens, pontos de decisão e escalonamento. Foque nos incidentes mais prováveis (queda total, lentidão, deploy quebrado) e atualize o runbook logo após o incidente enquanto os detalhes estão frescos para evitar perda de conhecimento.
Como documentamos controle de acesso e permissões para a propriedade pela ops?Liste os papéis que você realmente usa (deployer, admin de BD, somente leitura, comandante de incidentes), como o acesso é concedido e revogado, e o que deve ser registrado para auditoria. Não esqueça contas de serviço e tokens; descreva o que podem acessar e onde suas identidades são configuradas sem incluir valores secretos.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
